Hospitality Agent Platform — Gästekommunikation mit begrenzter Autonomie
Ein interner Build: Omnichannel-Gästekommunikation, bei der das Modell klassifiziert und vorschlägt — und ein deterministisches Policy-Gate, nicht das Modell, alles autorisiert, was Geld oder ein Türschloss berührt.
1 / 2
Die Herausforderung
Hotelgruppen mit mehreren Häusern betreiben Gästekommunikation rund um die Uhr über sechs Postfächer und mehrere Sprachen, und die Nachtschicht beantwortet in allen dieselben wiederkehrenden Fragen — langsame Antworten, entgangener Umsatz. Die Kanäle sind WhatsApp, SMS, Webchat, Airbnb und Booking.com, und der Blocker für Automatisierung ist nicht das Sprachverständnis, sondern die Befugnis: Kein Direktor lässt ein generatives Modell an Rückerstattungen, Stornierungen, Zahlungslinks oder Tür-PINs, denn eine Halluzination ist dort ein finanzielles und sicherheitsrelevantes Risiko, kein schlechter Satz. Jedes glaubwürdige System muss bei den einfachen 70 % schnell und beim Rest nachweislich unfähig sein, allein zu handeln.
Die Lösung
Wir haben eine Plattform gebaut, in der die Befugnis des Modells eine explizite Design-Entscheidung ist. Jeder Provider-Webhook wird in einen kanonischen Event-Umschlag mit deterministischer UUIDv5-Event-ID normalisiert, geprüft per HMAC-SHA256-Signatur und einem Replay-Fenster für Zeitstempel-Abweichungen. Ein austauschbarer mehrsprachiger Klassifikator deckt 13 Hospitality-Intents in acht Sprachen ab und liefert strukturierte Metadaten — Intent, kalibrierte Konfidenz, Begründungscode — sodass nachgelagert nie freier Modelltext geparst wird. Ein fail-closed Policy-Gate entscheidet dann: Lesevorgänge (FAQ, Zimmerverfügbarkeit) werden automatisch freigegeben; Schreibvorgänge (Bestandssperren, Rückerstattungen, Stornierungen, Türcodes) landen in einer menschlichen Warteschlange. LangGraph-Checkpointing hält die Gesprächsherkunft über Neustarts hinweg dauerhaft; ein transaktionaler Outbox-Mechanismus publiziert at-least-once mit exponentiellem Backoff und Dead-Letter-Klassifikation, und der Tool-Ausführungs-Worker ist durch SHA-256-Idempotenzschlüssel geschützt, sodass ein Netzwerk-Retry weder doppelt abbuchen noch doppelt buchen kann. Der Zustand liegt in sieben PostgreSQL-Tabellen hinter einer Zero-PII-Audit-Senke — Tür-PINs und Kartendaten werden nie in Traces oder Logs geschrieben. Die Betriebskonsole ergänzt RBAC (Operator / Manager / Admin, Rückerstattungen nur für Manager) und ein Notfall-Übernahme-Routing, das Rauch-, Feuer-, Gas- und Sicherheitsereignisse vollständig aus der Automatisierung herausnimmt.
Die Wirkung
Gästefragen mit geringem Risiko werden in Sekunden ohne Menschen beantwortet; jede risikoreiche Aktion stoppt in einer Freigabe-Warteschlange, mit vollständiger Korrelations- und Kausalitätskette — der Operator gibt also eine Entscheidung frei, statt sie zu rekonstruieren. Weil die Befugnis in Policy-Code statt in einem Prompt liegt, ist das Sicherheitsverhalten testbar: 39 automatisierte Tests für Policy-Gate, RBAC-Grenzen, Idempotenz und Outbox-Retry-Pfade laufen in rund 2,5 Sekunden. Dies ist ein interner Build gegen einen Sandbox-PMS-Adapter — eine Referenzimplementierung und eine Demo, die wir Interessenten von Anfang bis Ende zeigen können, kein ausgeliefertes Kundensystem.
Eingesetzte Technologien
verwandte Case Studies
Weitere Case Studies ansehen
Sprechen wir


