On rebuilding a new-generation
booking engine
Context
I led product design on a year-long initiative to rethink a large-scale hotel booking engine used across a wide range of properties.
High user churn
Many users dropped as soon as the booking flow opened in a separate window. That handoff broke continuity at the most sensitive point in the journey and created an immediate trust problem.
Aging tech stack
The experience depended on legacy PHP services, some dating back to 2006. That constrained performance, security, and interaction design, so product decisions had to hold up within real technical limits.
Client and user variety
Our clients ranged from boutique villas and alpine chalets to budget hostels across Europe. The engine needed to flex across very different inventory models and brand expectations without turning into a one-off build for each property.
Existing product
The previous flow felt dated, narrow on desktop, and hard to parse at decision points. Key booking details were difficult to compare, and basic concepts such as guest count versus bed type were easy to misread. The result was slower decisions and weaker confidence.
- Decision friction: dense modules and weak hierarchy made the flow harder to scan than it should have been.
- Desktop experience: the narrow layout wasted available space and did not scale to larger screens.
- Critical ambiguity: guest count, bed type, and rate details competed for attention instead of clarifying the decision.
- Comparison quality: room cards did not make meaningful differences legible at a glance.
Research
We mapped 15 booking journeys across hotel types and reviewed 10 competitor tools to understand both expected patterns and avoidable weaknesses. Interviews with 12 guests and 8 hoteliers helped separate surface complaints from the underlying trust, clarity, and comparison problems driving abandonment. We synthesized the patterns through affinity mapping and used two cross-functional workshops to turn them into product priorities.
Design process
Our first direction explored a modular system. Hotels could show rooms only, rates only, a combined view, or a hybrid. Testing across 15 properties made the tradeoff clear: configurability increased internal optionality, but it also introduced too much cognitive overhead for guests.
The second iteration narrowed the system around clarity and trust. We simplified the decision path, strengthened hierarchy, and used imagery and typography more deliberately so each property could retain character without compromising speed or comprehension.
Delivery
Live examples
The new engine is live on more than 150 hotel sites. Keeping guests inside a clearer, more consistent flow reduced abandonment and made the booking experience feel more trustworthy from search to checkout.
After the fact
- Abandonment from ~60% to ~25%
- Time to book down ~50%
- NPS from 4 to 6
- ~150 key accounts live
Positive
- Measured outcome: abandonment was cut by more than half, and the path to booking became materially faster.
- Trust improved: NPS moved from 4 to 6. There is still room to grow, but the shift in perception was meaningful.
- Rollout scale: about 150 key accounts went live in year one, showing the system could hold across a broad client portfolio.
- Platform health: critical backend paths were cleaned up and modern bridges were added around legacy systems.
“It looks like a real product.”
“I felt bad about our guests seeing the other booking engine.”
Negative
- Time to market: delivery slowed because stakeholder alignment took time and the underlying stack was rigid.
- Migration reality: some properties still depended on older systems, which made a clean switchover uneven.
- Scope lesson: a narrower MVP would have reduced risk earlier and accelerated learning.
Next time: define the thinnest end-to-end release earlier, validate the riskiest assumptions first, and front-load the hardest technical constraints.