Zwischen Zimmerwahl und Bestätigung liegt ein System, über das der Gast bestenfalls nie nachdenken muss.
Direktbuchung · Guide · 13 min Lesezeit Der Gast ist da.
Nicht irgendwo im Internet. Nicht auf Booking.com. Nicht bei Google.
Auf Ihrer Website.
Zimmer angeschaut. Lage geprüft. Preis akzeptiert. Reisedaten ausgewählt.
Er klickt auf „Buchen“.
Eigentlich müsste man jetzt nur noch die Tür aufhalten.
Stattdessen öffnet sich eine neue Welt.
Anderes Design. Andere Zimmernamen. Ein Kalender, der auf dem Smartphone erstaunlich viel Fingerspitzengefühl verlangt. Preise, die plötzlich anders aussehen. Frühstück irgendwo im Kleingedruckten. Dann Vorname. Nachname. Adresse. Postleitzahl. Land. Telefonnummer. Kreditkartendaten. Noch ein Häkchen. Noch eins.
Und plötzlich beschäftigt sich der Gast nicht mehr mit seinem Aufenthalt.
Sondern mit Ihrer Booking Engine.
Das ist kein gutes Zeichen.
Denn zu diesem Zeitpunkt ist bereits ziemlich viel passiert: Das Hotel wurde gefunden, geprüft und mit Alternativen verglichen. Zimmer und Preis kommen infrage. Der Gast hat auf „Buchen“ geklickt.
Die Booking Engine bekommt den Staffelstab ziemlich weit hinten im Rennen.
Ihre Aufgabe ist nicht, jetzt noch einmal Aufmerksamkeit auf sich zu ziehen.
Im Gegenteil.
Je weniger der Gast über das System nachdenken muss, desto besser macht es seinen Job.
Eine gute Booking Engine erklärt sich nicht ständig selbst. Sie überrascht nicht. Sie stellt keine unnötigen Fragen. Sie zwingt niemanden, interne Tariflogik zu verstehen oder auf dem Smartphone winzige Kalenderfelder zu treffen.
Zimmer wählen. Rate verstehen. Daten eingeben. Buchung abschließen.
Und im besten Fall war dazwischen nichts, worüber man später sprechen müsste.
Das ist keine fehlende Experience.
Das ist eine ziemlich gute.
Eine Booking Engine – auch Internet Booking Engine oder IBE – ist das Buchungssystem, über das Gäste auf der Hotelwebsite Verfügbarkeiten prüfen, Zimmer und Raten auswählen und eine Reservierung direkt abschließen.
Sie verbindet die Hotelwebsite mit der dahinterliegenden Systemlandschaft.
Je nach Setup tauscht sie Daten beispielsweise mit:
aus.
Der Gast bekommt davon idealerweise wenig mit.
Er gibt Anreise, Abreise und Personenzahl ein. Die Booking Engine zeigt verfügbare Zimmer und Preise. Der Gast wählt. Bezahlt beziehungsweise garantiert die Reservierung. Fertig.
Zumindest in der Theorie.
Die Hotelwebsite verkauft das Hotel.
Die Booking Engine verkauft die konkrete Verfügbarkeit zu einem konkreten Preis für einen konkreten Zeitraum.
Das ist ein wichtiger Unterschied.
Auf der Website kann das Superior-Zimmer noch mit Abendlicht, Balkon und Espresso am Fenster überzeugen.
In der Booking Engine steht dann:
SUP DBL FLEX BB – 189 €
Romantik vorbei.
Genau an dieser Schnittstelle entstehen erstaunlich viele Probleme.
Man kann eine Booking Engine mit Funktionen vollpacken.
Promo Codes. Cross-Selling. Upselling. Gutscheine. Pakete. Loyalty. Kalenderansichten. Preisvergleich. Zusatzleistungen. Pop-ups.
Alles schön.
Die wichtigste Aufgabe bleibt trotzdem ziemlich unspektakulär:
Eine Buchung einfach abschließen lassen.
Eine gute Booking Engine muss deshalb vor allem fünf Dinge können:
Orientieren. Vergleichen. Entscheiden. Vertrauen schaffen. Abschließen.
Nicht beeindrucken.
Nicht beschäftigen.
Nicht zeigen, was technisch alles möglich ist.
Der Gast hat an diesem Punkt bereits erhebliches Buchungsinteresse. Jede zusätzliche Funktion, jede weitere Entscheidung und jedes zusätzliche Feld muss sich deshalb eine unangenehme Frage gefallen lassen:
Brauchen wir das hier wirklich?
Eine gute Booking Engine ist deshalb nicht die mit den meisten Funktionen.
Sondern die, bei der Funktionen genau dann auftauchen, wenn der Gast sie braucht – und ansonsten aus dem Weg bleiben.
Hotelwebsite:
Großzügig. Modern. Klar.
Klick auf „Buchen“.
Booking Engine:
Willkommen im Jahr 2013.
Dieser visuelle und funktionale Bruch ist nicht nur ein Designproblem. Er kann Vertrauen kosten.
Die Booking Engine sollte sich deshalb möglichst selbstverständlich an die Hotelwebsite anschließen:
Besonders externe Booking Engines laufen häufig auf einer anderen Domain.
Technisch völlig normal.
Aus Gästesicht nicht zwangsläufig.
Wer gerade hotel-beispiel.de besucht hat und nach dem Buchungsklick plötzlich auf einer völlig anders aussehenden Anbieter-Domain landet, darf kurz überlegen, wem er jetzt eigentlich seine Kreditkartendaten gibt.
Und genau in diesem Moment ist die Technik sichtbar geworden.
Website:
Deluxe Doppelzimmer mit Balkon
Booking Engine:
DBL DLX BAL
OTA:
Deluxe King Room
Drei Namen für dasselbe Bett.
Zimmernamen, Bilder, Belegung, Leistungen und Beschreibungen sollten deshalb über Website, Booking Engine und wichtige Vertriebskanäle möglichst konsistent sein.
Der Gast sollte vergleichen können.
Nicht übersetzen müssen.
Stellen Sie sich eine Schachtel mit sechs Pralinen vor.
Haselnuss. Nougat. Marzipan. Kaffee. Karamell. Zartbitter.
Eine davon?
Geht.
Jetzt stehen 30 vor Ihnen.
Eigentlich besser. Schließlich ist die Wahrscheinlichkeit viel größer, dass genau die richtige Praline dabei ist.
Nur muss man sie jetzt finden.
Mit diesem scheinbaren Widerspruch beschäftigt sich die Forschung seit Langem unter dem Begriff Choice Overload. Bekannt wurde unter anderem eine Studie der Psychologen Sheena Iyengar und Mark Lepper: In Experimenten mit Marmeladen und Gourmet-Pralinen zeigte sich, dass eine größere Auswahl zwar attraktiv wirken kann – eine begrenzte Auswahl aber die Entscheidung erleichtern und sogar die spätere Zufriedenheit mit der getroffenen Wahl erhöhen kann.
Die Sache hat allerdings einen Haken: Weniger Auswahl ist nicht automatisch besser.
Spätere Untersuchungen konnten keinen universellen „Je weniger, desto besser“-Effekt bestätigen. Entscheidend scheint vielmehr zu sein, wie schwierig es ist, die angebotenen Alternativen sinnvoll miteinander zu vergleichen.
Und damit sind wir ziemlich schnell wieder im Hotel.
Acht Zimmerkategorien.
Jeweils vier Raten.
Mit Frühstück. Ohne Frühstück. Flexibel. Nicht stornierbar. Member Rate. Advance Purchase. Arrangement. Direktbuchervorteil.
Aus acht Zimmern werden nicht acht Möglichkeiten.
Sondern ziemlich viele Entscheidungen.
Natürlich braucht ein Hotel unterschiedliche Zimmer, Raten und Angebote. Aber nicht jede intern sinnvolle Tariflogik muss dem Gast in ihrer vollständigen Schönheit präsentiert werden.
Statt:
BAR FLEX RO
BAR FLEX BB
NRF RO
NRF BB
MEMBER FLEX
MEMBER NRF
ADVANCE 14
braucht der Gast eher Antworten auf:
Kann ich stornieren? Ist Frühstück dabei? Was spare ich?
Die Aufgabe einer guten Booking Engine besteht deshalb nicht darin, Auswahl möglichst klein zu machen.
Sondern Komplexität möglichst klein zu machen.
„Flexible Rate“ ist verständlich.
„Nicht stornierbar – 12 % günstiger“ ebenfalls.
„Member Rate LRA RO“ eher nicht.
Die Booking Engine ist kein Frontend für die Revenue-Abteilung.
Interne Tarifcodes dürfen intern bleiben.
Der Gast sollte bei jeder Option erkennen können:
Dabei helfen gute Bilder.
Nicht 27.
Aber genug, um die Kategorie eindeutig zu erkennen.
Wenn die flexible Rate 189 Euro und die nicht stornierbare Rate 174 Euro kostet, sollte der Unterschied sofort verständlich sein.
15 € sparen – nicht stornierbar
ist hilfreicher als zwei fast identische Tarifboxen mit jeweils sechs Zeilen Bedingungen.
Eine Booking Engine sollte Entscheidungen erleichtern.
Nicht die mathematische Begabung ihrer Gäste testen.
„Responsive“ ist inzwischen Mindeststandard.
Es bedeutet aber noch nicht automatisch, dass sich eine Booking Engine auf dem Smartphone gut bedienen lässt.
Ein Gast kann das Hotel morgens am Laptop entdecken, später auf dem Smartphone vergleichen und abends buchen.
Oder alles in sieben Minuten auf dem Handy erledigen.
Die Booking Engine weiß vorher nicht, welchen Weg sie bekommt.
Sie sollte deshalb auf dem kleinsten Bildschirm nicht zur schlechteren Version ihrer selbst werden.
Das betrifft insbesondere:
Die einfachste Prüfung kostet nichts.
Nehmen Sie ein Smartphone.
Öffnen Sie Ihre Hotelwebsite.
Suchen Sie ein Zimmer für übermorgen.
Buchen Sie bis unmittelbar vor Abschluss.
Nicht als Hotelier. Als Gast.
Wie viele Klicks waren nötig? Wo mussten Sie scrollen? Wo mussten Sie nachdenken? Wo war nicht klar, was als Nächstes passiert?
Und wie oft haben Sie mit zwei Fingern versucht, irgendetwas zu treffen?
Ein erstaunlich ergiebiger Test.
Ein Buchungsprozess darf hübsch sein.
Schnell wäre trotzdem ganz praktisch.
Gerade beim Wechsel von Hotelwebsite zu externer Booking Engine können zusätzliche Ladezeiten durch Skripte, Tracking, Consent-Lösungen, Zahlungsanbieter oder externe Inhalte entstehen.
Dabei zählt nicht nur der erste Seitenaufruf.
Auch Kalender, Zimmerauswahl, Tarifwechsel und Checkout müssen schnell reagieren.
Technisch lohnt sich deshalb ein Blick auf reale Nutzerdaten und die Core Web Vitals – insbesondere Ladezeit, Reaktionsfähigkeit und visuelle Stabilität.
Aber auch ohne Messwerkzeug erkennt man einiges.
Wenn Sie beim Öffnen des Kalenders genug Zeit haben, über das Reiseziel grundsätzlich noch einmal nachzudenken, ist das kein gutes Zeichen.
Natürlich soll der Buchungsprozess messbar sein.
Aber jede zusätzliche Tracking-, Marketing- und Personalisierungslösung kann weitere Skripte mitbringen.
Deshalb gilt:
Messen, was gebraucht wird. Nicht alles einbauen, was messbar wäre.
Eine langsame Booking Engine mit hervorragendem Tracking liefert am Ende sehr präzise Daten darüber, wie Gäste abspringen.
Auch eine Erkenntnis.
Titel.
Vorname.
Nachname.
Straße.
Hausnummer.
Postleitzahl.
Ort.
Land.
Telefon.
Mobiltelefon.
E-Mail.
Firma.
Anreisezeit.
Kommentar.
Wie haben Sie uns gefunden?
Die Booking Engine möchte den Gast offenbar sehr gern kennenlernen.
Der Gast möchte ein Zimmer.
Und genau hier lohnt sich ein Blick über die Hotellerie hinaus.
Aktuelle Checkout-Forschung des Baymard Institute zeigt, wie empfindlich Nutzer auf unnötige Komplexität reagieren: 17 Prozent der befragten Onlineshopper gaben an, innerhalb der vergangenen Monate einen Kauf wegen eines zu langen oder komplizierten Checkout-Prozesses abgebrochen zu haben. In den untersuchten E-Commerce-Checkouts werden außerdem im Durchschnitt deutlich mehr Formularelemente angezeigt, als aus Usability-Sicht erforderlich wären.
Das sind keine Hoteldaten.
Aber das zugrunde liegende Problem ist dasselbe:
Tippen ist Arbeit. Auf dem Smartphone noch mehr.
Jedes Pflichtfeld sollte deshalb eine einfache Prüfung bestehen:
Brauchen wir diese Information vor der Buchung wirklich?
Nicht:
„Hatten wir schon immer.“
Browser und Smartphones können Namen, Anschriften, E-Mail-Adressen und Zahlungsinformationen automatisch ausfüllen.
Die Booking Engine sollte das unterstützen.
Dasselbe gilt für:
Wer nach einem falsch formatierten Telefonnummernfeld das komplette Formular erneut ausfüllen muss, entwickelt möglicherweise Gefühle.
Nur nicht für das Hotel.
Spätestens beim Bezahlen ist Vertrauen nicht mehr optional.
Die Zahlungsseite sollte klar zeigen:
Gerade der Gesamtpreis sollte vor Eingabe der Zahlungsdaten eindeutig sichtbar sein. Baymards aktuelle Payment-UX-Forschung zeigt auch außerhalb der Hotellerie, dass Unsicherheit über den tatsächlich zu zahlenden Endbetrag ein konkreter Abbruchgrund ist.
Und die angebotenen Zahlungsmethoden sollten zum Markt und zur Zielgruppe passen.
Digitale Wallets und alternative Zahlungsverfahren haben einen sehr praktischen Vorteil:
Der Gast muss auf dem Smartphone nicht erst die Kreditkarte aus dem Portemonnaie holen und sechzehn Ziffern eintippen.
Apple Pay, Google Pay oder PayPal können deshalb weit mehr sein als ein hübsches Zusatzlogo.
Auch hier liefert allgemeine Checkout-Forschung einen Hinweis: Baymard sieht fehlende bevorzugte Zahlungsmethoden weiterhin als relevanten Abbruchgrund und empfiehlt mindestens eine alternative beziehungsweise Third-Party-Zahlungsmethode neben der klassischen Kartenzahlung.
Welche davon sinnvoll ist, hängt allerdings vom Hotel und seinen Herkunftsmärkten ab.
Zwölf Zahlungslogos machen den Checkout nicht automatisch zwölfmal besser.
Eine fehlgeschlagene Zahlung darf nicht in einer kryptischen Meldung enden:
ERROR PSP_403_AUTH
Hilfreicher wäre:
Die Zahlung konnte nicht bestätigt werden. Bitte prüfen Sie Ihre Daten oder wählen Sie eine andere Zahlungsart.
Der Gast muss wissen, was passiert ist.
Und was er jetzt tun kann.
OTAs haben einen Vorsprung, den Hotels nicht einfach wegdesignen können:
Gewohnheit.
Viele Reisende kennen die Oberflächen großer Buchungsplattformen seit Jahren. Zahlungsprozess, Bestätigung und Bedienung sind vertraut.
Eine unbekannte Booking Engine muss sich dieses Vertrauen erst verdienen.
Dazu gehören:
Allgemeine Checkout-Forschung bestätigt, wie relevant dieser Punkt ist: In Baymards aktuellen Daten gehört mangelndes Vertrauen bei der Eingabe von Zahlungsinformationen weiterhin zu den genannten Gründen für Kaufabbrüche.
Für Hotels ist das besonders interessant.
Denn häufig wechselt der Gast genau vor diesem sensiblen Moment von der vertrauten Hotelwebsite in ein externes System.
Der Übergang sollte deshalb möglichst wenig nach Übergang aussehen.
Der Gast sollte nicht erst im letzten Schritt entdecken, dass aus 189 Euro plötzlich 217 Euro geworden sind.
Steuern, Gebühren, obligatorische Leistungen und Zahlungsbedingungen gehören dorthin, wo eine Entscheidung getroffen wird.
Nicht dorthin, wo sie eigentlich schon gefallen ist.
Überraschungen sind im Urlaub schön.
Beim Checkout weniger.
Frühstück?
Parkplatz?
Late Check-out?
Champagner?
Hund?
Blumen?
Flughafentransfer?
Drei-Gänge-Menü?
Eine Booking Engine kann eine Menge zusätzlich verkaufen.
Und das ist grundsätzlich sinnvoll.
Zusatzleistungen können den Aufenthalt verbessern und gleichzeitig den Wert einer Direktbuchung erhöhen.
Aber an die richtige Stelle.
Der Gast muss zuerst sicher sein:
Dieses Zimmer möchte ich buchen.
Danach kann gefragt werden:
Darf es noch Frühstück sein?
Nicht gleichzeitig:
Zimmer? Rate? Frühstück? Parkplatz? Upgrade? Massage? Champagner?
Das Prinzip kennt man aus dem Restaurant.
Erst bestellen.
Dann darf jemand Dessert sagen.
Upselling sollte den Buchungsprozess ergänzen.
Nicht übernehmen.
Eine Booking Engine kann nur verkaufen, was sie bekommt.
Sind Preise, Verfügbarkeiten oder Restriktionen falsch gesteuert, löst auch das schönste Frontend das Problem nicht.
Deshalb gehören Booking Engine und Revenue Management zusammen.
Beispiele:
Gerade bei Dynamic Pricing im Hotel muss die Booking Engine Preisveränderungen sauber und verständlich an den Gast weitergeben.
Dasselbe gilt für die BAR-Strategie: Die beste Tariflogik hilft wenig, wenn Gäste in der Booking Engine nicht erkennen, welche Rate warum für sie interessant ist.
Ein Revenue Management System kann den perfekten Preis berechnen.
Wenn der Gast ihn nicht versteht oder nicht buchen kann, war es eine sehr akademische Übung.
Die Booking Engine hat 2,4 Prozent Conversion.
Gut?
Schlecht?
Kommt darauf an.
Eine einzelne Conversion Rate verrät erstaunlich wenig.
Viel interessanter ist der Buchungsfunnel.
Zum Beispiel:
Verfügbarkeit gesucht → Zimmer gewählt → Rate gewählt → Checkout begonnen → Zahlung → Buchung
Jetzt lässt sich erkennen, wo Gäste verloren gehen.
Angenommen:
1.000 Personen prüfen die Verfügbarkeit.
620 wählen ein Zimmer.
410 wählen eine Rate.
280 beginnen den Checkout.
94 schließen die Buchung ab.
Dann lautet die Frage nicht mehr:
„Wie erhöhen wir unsere Conversion?“
Sondern:
„Warum verlieren wir so viele Gäste nach Beginn des Checkouts?“
Das ist erheblich hilfreicher.
Der Funnel sollte mindestens nach Desktop und Mobile betrachtet werden.
Zusätzlich können – bei ausreichendem Datenvolumen – Browser, Betriebssystem, Herkunftsmarkt und Trafficquelle interessante Hinweise liefern.
Wenn Desktop sauber konvertiert und Mobile unmittelbar nach Öffnen des Kalenders einbricht, braucht man nicht als Erstes über neue Google Ads nachzudenken.
Das Problem sitzt wahrscheinlich ein paar Klicks später.
Relevant sind unter anderem:
Und natürlich:
Was kostet die Direktbuchung?
Denn direkt bedeutet nicht kostenlos.
Wie Direktkanal, Website, Preis und Distribution insgesamt zusammenspielen, behandeln wir ausführlicher im Beitrag Direktbuchungen steigern: Drei sind einer zu viel.
Nicht jede schlechte Conversion ist ein Booking-Engine-Problem.
Vielleicht stimmt der Preis nicht.
Vielleicht fehlen attraktive Zimmer.
Vielleicht stimmen Verfügbarkeiten nicht.
Vielleicht kommt ungeeigneter Traffic.
Vielleicht gibt es keinen erkennbaren Direktbuchungsvorteil.
Deshalb sollte eine Booking Engine nicht nach Bauchgefühl beurteilt werden.
Genauer hinschauen würde ich, wenn:
Dann reicht „optimieren“ irgendwann vielleicht nicht mehr.
Dann stellt sich die Frage, ob die eingesetzte Booking Engine noch zum Hotel, zur Zielgruppe und zur heutigen Hotelsoftware-Systemarchitektur passt.
Das ist keine reine Designfrage.
Es ist eine Vertriebs- und Systementscheidung.
Das Hotel wurde bereits gefunden.
Der Gast hat sich informiert.
Zimmer und Preis passen.
Der Buchungsbutton wurde geklickt.
Das ist ein ziemlich guter Ausgangspunkt.
Jetzt sollte möglichst wenig dazwischenkommen.
Eine gute Booking Engine reduziert deshalb nicht nur Klicks. Sie reduziert vor allem Unsicherheit, unnötige Entscheidungen und Arbeit.
Klare Zimmer.
Verständliche Raten.
Wenige Pflichtfelder.
Gute mobile Bedienung.
Schnelle Seiten.
Einfache Zahlung.
Transparente Preise.
Und ein Buchungsprozess, der sich nicht plötzlich wie ein fremdes System anfühlt.
Die Nachfrage muss an dieser Stelle nicht mehr überzeugt werden, dass sie verreisen möchte.
Sie muss auch nicht mehr überzeugt werden, dass Ihr Hotel infrage kommt.
Sie ist schon ziemlich weit.
Machen Sie den Rest nicht wieder schwer.
Eine gute Booking Engine fällt deshalb im besten Fall kaum auf.
Zimmer wählen. Rate verstehen. Daten eingeben. Bezahlen. Fertig.
Klingt unspektakulär.
Genau das ist der Punkt.