Startseite /Case Studies /Hospitality Agent Platform

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.

13 × 8
Intents × Sprachen, die der Klassifikator abdeckt
Fail-closed
Policy-Gate — Modell schlägt vor, Code autorisiert
39 Tests
Policy, RBAC, Idempotenz — grün in ~2,5 s
Zero-PII
Audit-Senke — keine Tür-PINs oder Kartendaten in Traces

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

PythonLangGraphPostgreSQLTransactional outboxHMAC-SHA256 webhookspytest

Sprechen wir

Sie haben etwas zu bauen?

Erzählen Sie uns, woran Sie arbeiten. Innerhalb von 24 Stunden antwortet Ihnen ein Ingenieur — mit Fragen und einem groben Plan, nicht mit einem Verkaufsgespräch.