Ein Gast sagt seinem Assistenten: „Finde mir in Interlaken ein Doppelzimmer für zwei Nächte, Parkplatz wichtig, kostenlos stornierbar.“
Der Agent findet Ihre Website. Er erkennt ein Zimmer, CHF 240, Frühstück inklusive, Storno bis 48 Stunden vorher. Klingt gut. Doch als er weitergeht, ist der Preis nur ein „ab“-Preis, die Rate gilt nicht fürs Wochenende und das letzte Zimmer wurde vor drei Minuten im PMS verkauft.
Genau hier endet „AI kann unsere Website lesen“ und beginnt transaction-ready.
Für ein Hotel ist für Agenten vorbereitet Direct Booking nicht die Frage, ob ein Bot auf einen Buchungsbutton klicken kann. Es ist die Frage, ob Informationen und Transaktionszustände so eindeutig sind, dass weder Gast noch Agent eine Anfrage mit einer bestätigten Reservierung verwechseln.
Ein für Agenten vorbereitetes Hotel braucht mehr als strukturierte Daten
Eine maschinenlesbare Website hilft: klare Zimmernamen, Belegung, Ausstattung, Check-in, Stornobedingungen, Preislogik und Buchungslinks. Das ist die Informationsschicht.
Eine Buchung braucht aber mehr.
Google behandelt in seiner Hotel-Preis-Infrastruktur Verfügbarkeit, Raten, Inventar und Restriktionen als eigene, laufend zu aktualisierende Zustände. Ein Produkt ist nur buchbar, wenn die relevanten Verfügbarkeits- und Restriktionsbedingungen erfüllt sind. Preise sollen frisch und korrekt gehalten werden.
Das ist kein Beweis, dass Google-Hotel-Feeds direkt die Architektur für jeden AI-Agenten definieren. Aber das Grundprinzip ist wichtig: Preis und Verfügbarkeit sind Live-Zustände, keine Texteigenschaften einer Landingpage.
Bestätigter Fakt: Hotel-Booking-Infrastrukturen wie Google Hotel Prices modellieren Availability, Rates and Inventory separat und erwarten Updates bei Änderungen.
Empfehlung des Autors: Ein AI-Agent darf statische Website-Fakten lesen. Eine verbindliche Buchung sollte erst nach einem autoritativen Verfügbarkeits- und Preisprüfung im PMS, Booking Engine oder dafür vorgesehenen API-Endpunkt verbindlich gespeichert werden.
Vier Ebenen verhindern, dass „Anfrage“ zu „Reservierung“ wird
| Ebene | Beispiel | Darf der Agent? |
|---|---|---|
| Lesen | Zimmer, Ausstattung, Check-in, Policy | ja, aus aktueller Quelle |
| Vorbereiten | Daten, Reisedaten, Gästezahl, Präferenzen sammeln | ja |
| Buchung anfragen | Live-Preis/Verfügbarkeit prüfen, Transaktion vorbereiten | nur über autoritative Schnittstelle |
| Commit | Reservierung erzeugen, Preis bestätigen, Bestätigungs-ID erhalten | nur nach definiertem Commit-Ergebnis |
Diese Trennung wirkt banal, verhindert aber einen der schlimmsten Fehler: Der Assistent schreibt „Ihre Buchung ist bestätigt“, obwohl er nur ein Formular abgeschickt oder eine unverbindliche Anfrage erzeugt hat.
Definieren Sie im Backend klare Zustände wie quote, available_now, booking_pending, confirmed, failed, manual_review.
Das Frontend und der Agent sollten dieselbe Semantik verwenden.
Preis und Verfügbarkeit brauchen eine autoritative Quelle
Ein Hotel hat oft mehrere Systeme: Website-CMS, Booking Engine, PMS, Channel Manager, Google/OTA-Feeds. Wenn diese Zustände auseinanderlaufen, wird ein agentischer Flow nicht magisch besser. Er macht die Inkonsistenz schneller sichtbar.
Der AI-Agent sollte deshalb nicht aus einem Blogtext oder einer statischen Zimmerseite ableiten, dass ein Zimmer für den gewünschten Aufenthalt verfügbar ist.
Für den Transaktionsschritt braucht er mindestens:
- Check-in und Check-out;
- Anzahl Erwachsene/Kinder nach Hotel-Logik;
- Zimmer-/Rate-Plan-ID;
- aktuellen Gesamtpreis und Währung;
- Steuern/Gebühren, soweit relevant;
- Storno-/Änderungsbedingungen dieser Rate;
- Verfügbarkeitsstatus und Restriktionen;
- eindeutige Bestätigung nach erfolgreichem Commit.
Ein „CHF 220 pro Nacht“ auf der Marketingseite kann weiterhin sinnvoll sein. Er ist aber nicht automatisch der verbindliche Preis für den konkreten Aufenthalt.
Ausnahmen gehören vor die Automation
Direktbuchungen sind selten nur zwei Daten und eine Kreditkarte.
Gruppen, Kinderbelegung, Haustiere, barrierefreie Zimmer, Late Arrival, Parkplatzgarantie, Spezialraten, Gutscheine oder ein Preisunterschied zwischen Kanälen können menschliche Prüfung brauchen.
Für Agenten vorbereitet bedeutet deshalb auch, dass der Agent erkennen kann, wann er nicht weiterbuchen soll.
Eine gute Regel: Standardaufenthalte mit klarer Rate und Live-Verfügbarkeit können automatisiert bis zum Commit gehen. Sonderfälle wechseln in manual_review, ohne dass der Gast seine bereits eingegebenen Daten verliert.
Das Reservierungsteam erhält Reisedaten, gewünschte Rate, Sonderwunsch, bisherige Preisabfrage und den Grund der Eskalation.
Wenn der Preis zwischen Auswahl und Commit geändert wurde, muss der Agent den neuen Preis sichtbar bestätigen lassen, statt stillschweigend weiterzuklicken.
Fehlerfälle: doppelte Buchung, Timeout und „letztes Zimmer“
Agentische Systeme führen Tool-Calls aus. Dadurch entstehen dieselben Distributed-System-Probleme wie in klassischer Automation.
Der Commit-Request geht raus, aber die Antwort kommt wegen Timeout nicht zurück. Darf der Agent nochmals buchen? Nicht blind. Er braucht eine idempotente Buchungs-ID oder muss zuerst prüfen, ob die Reservierung bereits existiert.
Das letzte Zimmer ist zwischen Quote und Commit verkauft. Dann wird available_now zu failed/out_of_inventory, nicht zu einer erfundenen Bestätigung.
Die Payment- oder Booking-API ist down. Der Agent kann Reisedaten als Anfrage speichern, aber muss klar sagen, dass noch keine bestätigte Reservierung vorliegt.
Diese Fehlerlogik ist wichtiger als ein schicker Chat-Flow, weil sie direkt über Doppelbuchung und Gastvertrauen entscheidet.
Minimaler Pilot: ein Zimmertyp, eine Rate, ein klarer Bestätigungsschritt
Nehmen Sie nicht sofort das ganze Hotelangebot. Wählen Sie einen Standard-Zimmertyp und eine öffentliche flexible Rate.
- Definieren Sie alle maschinenlesbaren Fakten und ihre Verantwortlichen.
- Verbinden Sie den Live-Check mit der tatsächlich autoritativen Booking Engine/PMS-Schnittstelle.
- Trennen Sie
quote,pendingundconfirmedtechnisch und sprachlich. - Bauen Sie eine Idempotenz-/Duplicate-Protection für den Commit.
- Testen Sie Preiswechsel, letztes Zimmer, Timeout, ausverkauft und Sonderwunsch.
- Lassen Sie Ausnahmen mit vollständigem Kontext ans Reservierungsteam gehen.
Messen Sie Anteil Buchungsanfragen mit vollständigen Parametern, Preis- oder Verfügbarkeitsabweichungen vor Commit, erfolgreiche Commits mit eindeutiger Bestätigungs-ID, doppelte Reservierungen, manuelle Ausnahmequote und Fälle, in denen ein nicht bestätigter Zustand fälschlich als „gebucht“ kommuniziert wurde.
Der wichtigste Wert ist der letzte. Ein Agent, der mehr Buchungen „abschliesst“, aber Confirmation State falsch kommuniziert, ist kein Fortschritt.
Die Zukunft der Direktbuchung wird agentischer. Hotels müssen dafür nicht ihre Kontrolle an einen externen Assistenten abgeben. Im Gegenteil: Gute Vorbereitung auf Agenten macht klarer, welche Fakten öffentlich lesbar sind, welches System Preis und Verfügbarkeit besitzt und welcher technische Moment aus einer Anfrage wirklich eine Reservierung macht.
Unsere Branchenlösung für Hotels und Tourismus verbindet Anfrage, Telefon und Buchungslogik. Der Beitrag zu Social- und Video-Daten in Search Console zeigt zusätzlich, wie Inspirationsinhalte gemessen werden.
Quellen
- Google Hotel Prices — Documentation overview
- Google Hotel Prices — Availability message
- Google Hotel Prices — Pricing overview
- Google Hotel Prices — Landing page variables
- OpenAI — How agents are transforming work
FAQ
Reicht Schema.org, damit AI-Agenten direkt buchen können?
Nein. Strukturierte Daten helfen beim Verstehen. Eine Buchung braucht zusätzlich aktuelle Verfügbarkeit, Rate, Restriktionen und einen echten Transaktions-/Bestätigungsweg.
Darf der Agent einen Preis von der Website verwenden?
Als Information ja, wenn korrekt gekennzeichnet. Für die konkrete Buchung sollte der aktuelle Preis aus der autoritativen Buchungsquelle geprüft werden.
Wie unterscheidet man Anfrage und bestätigte Buchung?
Mit expliziten technischen Zuständen. Erst eine erfolgreiche Reservierung mit Bestätigungs-ID sollte als bestätigt kommuniziert werden.
Was passiert bei Gruppen oder Sonderwünschen?
Diese Fälle können gezielt in `manual_review` gehen. Wichtig ist, dass der Kontext und die bereits erfassten Daten erhalten bleiben.
Wie verhindert man Doppelbuchungen bei einem Wiederholungsversuch?
Mit Idempotenz Keys/eindeutigen Buchungs-IDs und einer Statusprüfung, bevor ein unsicherer Commit wiederholt wird.