Modernizing a Legacy Hotel Booking Flow

Across the DACH hospitality market, a large number of small and mid-sized hotels embed the same booking engine from one SaaS vendor into their websites. The engine works reliably, but its interaction and visual design clearly belong to an earlier generation.

To judge rigorously, I analyzed the flows of two independent properties running the same engine — Property A (holiday apartments) and Property B (city hotel). They share no business relationship; they are simply customers of the same platform. That is exactly where the methodological value lies: where both flows match, we see the platform’s behavior; where they differ, we see the operator’s individual configuration.

Economic frame: every direct booking saves the property 15–18% in OTA commission. The owned funnel is the most profitable sales channel — and deserves the best experience.

I ran both flows end to end and logged the displayed price at every step. The result was unambiguous: on Property A the price grew across four stages by roughly 11% — a cleaning fee only revealed at step 5, a late-disclosed local tax, cryptic rate labels. On Property B the price stayed constant from start to finish.

Further differences: Property A offered only a location filter, no terms checkbox before a binding booking (a compliance gap) and no currency choice. Property B used the same engine with clear rates (inclusions plus average price per night), multi-currency and a two-month calendar — but had two of four categories available only “on request”.

Key insight: the most severe conversion killer — a price that unexpectedly grows across several steps — occurs on Property A but not on Property B. The same engine shows a constant price on B from beginning to end. So the most expensive problem is not a platform limit but a configuration decision — and therefore solvable.

Attributable to the platform (identical on both): the late-shown local tax, missing native amenity filters, the fundamental visual break between host website and embedded engine, and a chat widget that covers form fields on mobile. Addressable only via the platform vendor.

Attributable to operator configuration (differing): price progression, hidden fees, rate naming, the terms checkbox, payment and currency options, calendar view and the online bookability of categories. Solvable by each property in its own back office — without waiting on the vendor.

For a portfolio this is the mature statement: a senior designer identifies which lever to pull — rather than blanket “rebuild everything”.

Property A: the growing price, a cleaning fee visible only late, the missing terms checkbox before a binding, non-refundable booking (a compliance risk) and cryptic rate labels.

Property B: two of four categories — including, of all things, the accessible room — are available only “on request” and therefore not bookable online. A genuine inclusion problem: guests with disabilities are forced onto a manual detour. Add to that a mandatory date-of-birth field (more PII friction) and a phone-only special rule for families.

Guiding principle: every number, every condition and every next step is predictable. Because both properties are independent, I frame the outcome as a transferable best-practice playbook for any user of this engine.

The centerpiece is a persistent price summary (desktop: sticky sidebar, mobile: expandable footer): the night, any cleaning fee and the local tax are declared from step 1 — the price never “grows” again. Rates always show inclusions, average price per night and cancellation consequence.

Alongside it: real filters (a price slider plus attributes such as balcony, air conditioning, breakfast, accessible), accessible categories bookable online instead of “on request”, a mandatory terms checkbox and PII reduced to the legally necessary. The engine theme is overridden with the property’s brand design system; the chat widget never over fields, tap targets ≥ 48 px, WCAG-AA contrast and “step X of Y” instead of a bare percentage.

Without production analytics I worked hypothesis-driven and co-designed the measurement. Primary hypothesis: aligning the weaker configuration to the consistent price logic noticeably reduces drop-off at the final step.

Metrics: checkout completion, drop-off per step, mobile conversion and direct vs. OTA share. Setup: an A/B test of the persistent price sidebar, five moderated usability tests (Maze) and session recordings (Hotjar). Secondary: bookable accessible rooms unlock a segment previously turned away by hand.

Comparing two independent properties on a shared platform demonstrates senior competencies: systems thinking (a clean separation of platform limit and configuration), analytical depth (the “growing price” becomes visible only through step-by-step logging) and evidence over opinion.

Added to that are ethics and inclusion — the accessible room that cannot be booked online as a real human problem — as well as intellectual honesty: impact framed as a hypothesis with a test plan instead of invented metrics.