Direktbuchungen

Stand: 2026-08-20

Ein Gast ruft an und fragt, ob am Wochenende noch etwas frei ist.

Bis diese Frage zu einer bezahlten Reservierung wird, liegen vier Schritte dazwischen, und an genau zwei davon scheitern die meisten Systeme. Diese Seite handelt von diesen zwei.

Der Ablauf

Anfragen. Hunzi fragt Verfügbarkeit, Rate und Zimmerkategorie direkt im PMS ab, während der Gast in der Leitung ist. Nicht aus einem nächtlich synchronisierten Abzug, sondern aus dem System, das auch deine Rezeption sieht.

Halten. Das passende Zimmer wird reserviert, bevor über Geld gesprochen wird. Warum das ein eigener Schritt ist, steht im nächsten Abschnitt.

Bezahlen. Der Gast bekommt einen Zahlungslink, der an genau diese Reservierung gebunden ist. Am Telefon kann Hunzi in der Leitung bleiben und warten, bis die Zahlung eingeht, statt aufzulegen und auf das Beste zu hoffen.

Bestätigen. Erst wenn die Zahlung da ist, gilt die Buchung als abgeschlossen.

Warum das Halten ein eigener Schritt ist

ibelsa kennt keinen vorläufigen Reservierungsstatus. Es gibt dort kein "unverbindlich vorgemerkt", das man nach zehn Minuten wieder verfallen lassen könnte.

Das ist keine Kleinigkeit. Ohne diesen Zustand hat man zwischen "Gast will das Zimmer" und "Gast hat bezahlt" ein Loch von mehreren Minuten, in dem dasselbe Zimmer ein zweites Mal verkauft werden kann, an der Rezeption oder am Telefon.

Also halten wir das Zimmer auf unserer Seite, für 15 Minuten. Lang genug, dass ein Gast den Link bekommt, sein Handy sucht und eine Karte einträgt. Fünf Minuten waren es zuerst, und sie waren zu kurz: Gäste liefen mitten im Bezahlvorgang in eine abgelaufene Reservierung.

Zahlt niemand, läuft die Reservierung aus und das Zimmer ist wieder frei. Niemand muss aufräumen.

Was verhindert, dass ein Zimmer doppelt vergeben wird

Zwei Dinge, und beide stehen im Code und nicht in einer Anweisung an das Sprachmodell.

Eine Buchung wird nicht abgeschlossen, solange keine bezahlte Reservierung dazu existiert. Das ist eine Prüfung mit zwei Bedingungen, die vor dem Abschluss steht. Sie hängt nicht davon ab, dass ein Modell sich an eine Regel erinnert.

Ein Wiederholungsversuch erzeugt keine zweite Buchung. Wenn das Halten eines Zimmers nicht antwortet, versucht Hunzi es erneut. Dabei wird nicht blind noch einmal gehalten: Das System gleicht ab, wie viele Zimmer für dieses Gespräch bereits gehalten werden, und legt nur die Differenz an. Ein zweiter Versuch für dasselbe Zimmer findet eines und legt keines an.

Das Anlegen der Reservierung selbst wird dagegen nie wiederholt. Ein Abbruch nach der Verarbeitung, aber vor der Antwort, würde sonst eine zweite Reservierung im PMS erzeugen. Lesende Abfragen werden wiederholt, weil sie nichts verändern. Der Unterschied ist bewusst: eine doppelte Buchung ist teurer als eine wiederholte Frage.

Der Unterschied ist wichtig, weil die naheliegende Umsetzung genau hier kaputt geht. "Bei Fehler noch einmal versuchen" ist die Zeile, mit der man an einem vollen Wochenende dieselbe Suite zweimal verkauft.

Die Reservierung ist vor dem Geld da

Das solltest du wissen, bevor du es im PMS siehst.

Ein Zahlungslink von ibelsaPay hängt an einem offenen Folio, und ein Folio gibt es erst, wenn die Reservierung angelegt ist. Die Reihenfolge ist also: Reservierung anlegen, Folio offen lassen, Zahlungslink erzeugen, Zahlung zuordnen.

Praktisch heißt das: Eine Reservierung taucht in deinem System auf, bevor das Geld eingegangen ist. Sie ist nicht bezahlt, und sie ist als solche erkennbar. Wir schreiben das hier hin, weil eine unbezahlte Reservierung im PMS ohne diese Erklärung wie ein Fehler aussieht, und weil die Alternative wäre, dir eine Reihenfolge zu erzählen, die das System nicht hat.

Wenn es fast ausgebucht ist, bucht Hunzi nicht

Das ist der Teil, der die meisten überrascht.

Sinkt der freie Bestand in einer Kategorie unter eine Schwelle, die du festlegst, schließt Hunzi die Buchung nicht ab. Es hält kein Zimmer, es nimmt kein Geld, und es versucht es auch nicht noch einmal. Der Gast bekommt gesagt, dass nur noch wenige Zimmer frei sind, und wird auf die Website deines Hauses geschickt, um dort direkt zu buchen.

Für einen Anbieter, der nach abgeschlossenen Buchungen aussehen möchte, ist das die falsche Entscheidung. Für ein Haus, das die letzten drei Zimmer eines ausverkauften Wochenendes nicht an einem automatisierten Ablauf verlieren will, ist es die einzig richtige.

Ohne Portalprovision

Eine Buchung, die über dieses System zustande kommt, ist eine Direktbuchung. Sie entsteht im Gespräch mit deinem Haus, sie läuft über deinen Zahlungsdienstleister, und sie landet in deinem PMS. Es gibt keinen Dritten, der prozentual mitverdient.

Das ist ausdrücklich kein Versprechen, dass deine Portalquote sinkt. Was wir sagen können, ist, wo diese eine Buchung entstanden ist.

Grenzen

Was das PMS nicht kann, kann Hunzi nicht ersetzen. Der fehlende vorläufige Status ist dafür das Beispiel auf dieser Seite. Wir arbeiten sichtbar darum herum, statt so zu tun, als gäbe es ihn.

Die Zahlungsbestätigung kommt von außen. Hunzi erfährt von der Zahlung, wenn der Zahlungsdienstleister sie meldet. Ist dieser Dienst gestört, wartet die Buchung, statt sich selbst zu bestätigen.

Gruppen und Sonderfälle gehören ans Telefon. Lange Aufenthalte, Firmenkontingente, Verträge mit Sonderraten: Das sind Gespräche, keine Formulare. Hunzi erkennt sie und übergibt an einen Menschen, statt eine Rate zu erfinden.

Der Unterschied

Ein Buchungsformular auf deiner Website wartet darauf, dass jemand es ausfüllt.

Der Anruf um 20 Uhr, das "haben Sie noch was frei?" auf WhatsApp, die Mail am Sonntagabend: Das sind die Anfragen, die heute an einer Rezeption hängen bleiben, die gerade Feierabend hat, und die am nächsten Morgen bei einem Portal gebucht sind.

Diese Seite beschreibt den Weg, auf dem daraus stattdessen eine bezahlte Reservierung in deinem eigenen System wird, während der Gast noch in der Leitung ist.