Modernizing a Legacy Hotel Booking Flow

Im DACH-Hospitality-Markt bettet eine große Zahl kleiner und mittlerer Hotels dieselbe eingebettete Buchungs-Engine eines SaaS-Anbieters in ihre Websites ein. Die Engine funktioniert technisch zuverlässig, ihr Interaktions- und Visual-Design stammt jedoch erkennbar aus einer älteren Generation.

Um belastbar zu urteilen, habe ich die Strecken zweier voneinander unabhängiger Betriebe analysiert, die dieselbe Engine nutzen — Objekt A (Ferienapartments) und Objekt B (Stadthotel). Beide haben keinerlei geschäftliche Verbindung; sie sind lediglich Kunden derselben Plattform. Genau darin liegt der methodische Wert: Wo sich beide Strecken gleichen, sehen wir das Verhalten der Plattform. Wo sie sich unterscheiden, sehen wir die individuelle Konfiguration des Betreibers.

Wirtschaftlicher Rahmen: Jede Direktbuchung spart dem Betrieb 15–18 % OTA-Provision. Der eigene Funnel ist der profitabelste Vertriebskanal — und verdient das beste Erlebnis.

Beide Strecken habe ich end-to-end durchgespielt und den angezeigten Preis in jedem Schritt protokolliert. Das Ergebnis war eindeutig: Bei Objekt A wuchs der Preis über vier Stufen um rund 11 % — eine erst in Schritt 5 sichtbare Reinigungsgebühr, spät ausgewiesene Kurtaxe, kryptische Ratenlabels. Bei Objekt B blieb der Preis von Anfang bis Ende konstant.

Weitere Unterschiede: Objekt A bot nur einen Standortfilter, keine AGB-Checkbox vor einer verbindlichen Buchung (Compliance-Lücke) und keine Währungswahl. Objekt B nutzte dieselbe Engine mit klaren Raten (Leistung + Ø-Preis pro Nacht), Mehrwährung und Zwei-Monats-Kalender — hatte aber zwei von vier Kategorien nur „auf Anfrage“.

Schlüssel-Erkenntnis: Der schwerwiegendste Conversion-Killer — ein Preis, der über mehrere Schritte unerwartet nach oben wächst — tritt bei Objekt A auf, bei Objekt B jedoch nicht. Dieselbe Engine zeigt bei B von Anfang bis Ende einen konstanten Preis. Das teuerste Problem ist also keine Plattform-Grenze, sondern eine Konfigurationsentscheidung — und damit lösbar.

Der Plattform zuzuschreiben (bei beiden gleich): die spät angezeigte kommunale Abgabe, fehlende native Ausstattungsfilter, der grundsätzliche visuelle Bruch zwischen Host-Website und eingebetteter Engine sowie ein Chat-Widget, das auf Mobile Formularfelder überdeckt. Adressierbar nur über den Plattform-Anbieter.

Der Betreiber-Konfiguration zuzuschreiben (unterschiedlich): Preisverlauf, versteckte Gebühren, Ratenbenennung, AGB-Checkbox, Zahlungs- und Währungsoptionen, Kalenderansicht und die Online-Buchbarkeit von Kategorien. Von jedem Betrieb im eigenen Backend lösbar — ohne auf den Anbieter zu warten.

Für ein Portfolio ist das die reife Aussage: Ein Senior-Designer erkennt, an welchem Hebel man drehen muss — statt pauschal „alles neu“.

Objekt A: der wachsende Preis, eine erst spät sichtbare Reinigungsgebühr, die fehlende AGB-Checkbox vor einer verbindlichen, nicht-stornierbaren Buchung (Compliance-Risiko) und kryptische Ratenlabels.

Objekt B: Zwei von vier Kategorien — darunter ausgerechnet das barrierefreie Zimmer — sind nur „auf Anfrage“ und damit nicht online buchbar. Ein echtes Inklusions-Problem: Gäste mit Behinderung werden auf einen manuellen Umweg gezwungen. Hinzu kommen ein Pflicht-Geburtstagsfeld (mehr PII-Reibung) und eine telefonische Sonderregel für Familien.

Leitprinzip: Jede Zahl, jede Bedingung und jeder nächste Schritt ist vorhersehbar. Da beide Betriebe unabhängig sind, formuliere ich das Ergebnis als übertragbares Best-Practice-Playbook für jeden Nutzer dieser Engine.

Kernstück ist eine persistente Preis-Zusammenfassung (Desktop: sticky Sidebar, Mobile: aufklappbarer Footer): Übernachtung, eine etwaige Reinigungsgebühr und die Kurtaxe sind ab Schritt 1 deklariert — der Preis „wächst“ nie mehr. Raten zeigen immer Leistung, Ø-Preis pro Nacht und Storno-Konsequenz.

Dazu echte Filter (Preis-Slider und Merkmale wie Balkon, Klima, Frühstück, barrierefrei), barrierefreie Kategorien online buchbar statt „auf Anfrage“, eine verpflichtende AGB-Checkbox und auf das rechtlich Nötige reduzierte PII. Das Engine-Theme wird mit dem Marken-Designsystem des Betriebs überschrieben; das Chat-Widget nie über Feldern, Tap-Targets ≥ 48 px, Kontraste nach WCAG-AA und „Schritt X von Y“ statt bloßer Prozentzahl.

Ohne Produktions-Analytics habe ich hypothesengetrieben gearbeitet und die Messung mitkonzipiert. Primärhypothese: Die Angleichung der schwächeren Konfiguration an die konsistente Preislogik senkt den Abbruch am letzten Schritt spürbar.

Metriken: Checkout-Completion, Abbruch pro Schritt, Mobile-Conversion sowie Direkt- vs. OTA-Anteil. Setup: A/B-Test der persistenten Preis-Sidebar, fünf moderierte Usability-Tests (Maze) und Session-Recordings (Hotjar). Sekundär: Online buchbare barrierefreie Zimmer erschließen ein bislang manuell abgewiesenes Segment.

Der Vergleich zweier unabhängiger Betriebe auf einer gemeinsamen Plattform demonstriert Senior-Kompetenzen: systemisches Denken (saubere Trennung von Plattform-Grenze und Konfiguration), analytische Tiefe (der „wachsende Preis“ wird erst durch schrittweises Protokollieren sichtbar) und Evidenz statt Meinung.

Hinzu kommen Ethik und Inklusion — das nicht online buchbare barrierefreie Zimmer als reales Menschen-Problem — sowie intellektuelle Ehrlichkeit: Wirkung als Hypothese mit Testplan statt erfundener Kennzahlen.