The Booking Engine
Ruby GmbH · Workspaces · 2026
23% of bookings in its first seven weeks live.
A self-serve booking engine for Ruby Workspaces, replacing a staff-gated request flow. Customers pick a date, time and party size, see real-time meeting-room availability, reserve the room they want, and check out, without waiting for anyone to get back to them.
Year
2026
Role
End-to-end UX · Interaction Design
Team
Product Manager · Engineers
Platform
Desktop & Mobile
Context
Booking a meeting room at Ruby required a person on our side before anything could happen. A customer filled out a request form and waited for us to get back to them, or called in directly. Either way the reservation depended on staff being available and on a round of back-and-forth. The interface was built around our internal process, and customers paid for it in wait time.
The flow served our operations more than it served the customer standing in front of it.
What I owned
End-to-end UX and interaction design for the engine, working with a Product Manager and engineers. The Product Manager defined the MVP and the decision to launch with meeting rooms only. My scope was taking a defined opportunity through design and delivery to a shipped self-serve flow, and designing it so the products that were not in the MVP could use the same structure later.
What the evidence showed
There was no user research here, and it did not need any. The business case was explicit: staff were spending their days on calls and emails to book rooms, and that time was worth more elsewhere. Nobody needed convincing that a self-serve engine was necessary. The research went into how rather than whether. I benchmarked how competitor booking tools handled real-time availability, and audited Nexudus, the platform the engine runs on, to separate the real technical constraints from the assumed ones. That distinction shaped everything that followed.
The decision and trade-offs
The flow is built around the question the customer actually arrives with: is there a room for my group, on this day, at this time? Two decisions shaped how it answers that.
The first was payment. Nexudus made in-flow payment too large a lift for the timeline, so rather than compromise the booking experience to accommodate it, I ended the flow at reservation and handed off to pay. Payment is the final step, so the customer completes there rather than being sent back, but the last moment of a self-serve journey happens in a system I did not design.
The second was scope. The MVP covered meeting rooms. I built the flow so day passes, dedicated desks and add-on services could use the same structure without a redesign. That was work the MVP did not require, and those products are now on the roadmap.
Booking panel — enter date, time and party size; only the rooms free for that exact slot come back.
Room selection — the customer picks from real availability and moves straight to reservation.
Validation and delivery
There was no pre-launch user testing. The engine shipped and the tracking was the test: if customers would use a self-serve flow in meaningful numbers, the premise held. Payment sitting outside the engine meant coordinating the handoff with engineering so the reservation and the transaction stayed in step.
AI in the process
Both the competitor benchmark and the Nexudus audit ran through AI. It read platform documentation and pulled apart competitor flows faster than I could manually, which meant more of the time went into deciding what the findings meant. Which constraints were real, and what to build around them, stayed my call.
Outcome
In its first seven weeks of tracking, the engine took 23% of all meeting-room bookings. Those bookings ran about 22% higher in average value than staff-handled ones, so the channel accounted for 27% of meeting-room revenue over the same period.
Of all bookings
Of revenue
Value per booking