FACT COPY · DE
Faktenfassung: Buchung, Servicing, Umbuchung und Storno mit MCP
Transaktionsdesign, Zustandsmaschinen, Zustimmung, Idempotenz und Kompensation für den vollständigen Reiselebenszyklus.
Originalseite: https://travel-mcp.com/de/reisebranche/buchung-servicing-storno/
Sachliche Zusammenfassung
Der größte Unterschied zwischen einer Reiseauskunft und einem produktiven Reiseagenten liegt im Umgang mit Zustandsänderungen. Buchung, Nachbetreuung und Storno benötigen eine explizite Zustandsmaschine – nicht nur einen erfolgreichen Tool-Aufruf.
Vorbedingungen einer Buchung
Vor Ausführung müssen Reisende, Leistungen, Preis, Währung, Bedingungen, Kontaktweg und Zahlungslogik vollständig sein. Der Server prüft Pflichtfelder und Fachregeln erneut. Der Client stellt die entscheidungsrelevanten Daten verständlich dar und erfasst eine eindeutige Zustimmung für genau diesen Zustand.
Eine frühere allgemeine Zustimmung reicht nicht, wenn Preis oder Bedingungen geändert wurden. Consent ist an Inhalt, handelnde Identität und Zeitpunkt zu binden.
Idempotenz und Zustandsabgleich
Netzwerkfehler können nach erfolgreicher Backendbuchung auftreten. Ein Retry ohne Idempotenzschlüssel erzeugt Doppelbuchungen. Der Server benötigt einen stabilen Schlüssel, prüft vor Wiederholung den bestehenden Zustand und gibt dasselbe fachliche Ergebnis zurück.
Ein HTTP- oder JSON-RPC-Erfolg beweist nur die technische Verarbeitung. Nach kritischen Aktionen sollte der Server Order, Supplier Confirmation und Zahlungsstatus aus den autoritativen Quellen lesen und Abweichungen explizit melden.
Teilbuchungen und Kompensation
Bei dynamischen Paketen können einzelne Leistungen bestätigt und andere abgelehnt werden. Eine universelle ACID-Transaktion existiert über unabhängige Lieferanten selten. Deshalb müssen zulässige Zwischenzustände, Haltefristen, Kompensationsschritte und manuelle Eskalation vorab definiert sein.
Der Agent darf eine Teilbuchung nicht als vollständige Reise darstellen. Der Tool-Output muss je Segment Status, Bestätigung, Kostenwirkung und nächsten sicheren Schritt enthalten.
Servicing als eigene Domäne
Umbuchung, Namenskorrektur, Zusatzleistung, Reklamation und Dokumentenneuausstellung folgen anderen Regeln als die ursprüngliche Buchung. Ein `update_order`-Tool ist zu unspezifisch. Besser sind fachliche Fähigkeiten, die Berechtigung, Bedingungen und Kostenfolge gezielt prüfen.
Der bestehende Orderzustand wird vor jeder Änderung gelesen. Angebote für eine Änderung sind von ihrer Ausführung zu trennen, sodass der Nutzer die konkrete Differenz bestätigen kann.
Storno und Erstattung
Storno beendet nicht zwangsläufig alle Leistungen und erzeugt nicht automatisch eine sofortige Erstattung. Lieferantenbestätigung, Stornogebühr, Erstattungsweg und Bearbeitungsstatus sind getrennte Zustände. Der Server muss diese Unterschiede abbilden.
Irreversible Aktionen erhalten erhöhte Freigabe, kurze Gültigkeit und vollständiges Audit. Wo gesetzliche, tarifliche oder organisatorische Prüfung erforderlich ist, übergibt das System kontrolliert an Mitarbeitende.
- Quote oder Vorschau der Änderung
- Explizite Zustimmung
- Idempotente Ausführung
- Autoritativer Zustandsabgleich
- Kompensation und Eskalation
FAQ
Warum ist ein generisches Buchungstool riskant?
Es verbirgt Vorbedingungen, Zwischenzustände und unterschiedliche Auswirkungen. Fachlich getrennte Capabilities sind besser prüf- und autorisierbar.
Kann ein Agent selbstständig stornieren?
Nur innerhalb klarer Rechte und Regeln; Gebühren, Umfang und Erstattungsfolge müssen vor Ausführung transparent bestätigt werden.