Warum Doppelbelegungen entstehen
Sobald ein Hotel auf mehr als einem Weg buchbar ist, gibt es mehr als eine Belegungsliste: die eigene auf der Website und je eine auf jedem Portal. Diese Listen stimmen nur so lange überein, wie jede Änderung auf der einen Seite die andere rechtzeitig erreicht. Genau dort liegen die typischen Lücken.
Die erste Lücke ist die Verzögerung. Wird die Belegung nur in Abständen abgeglichen, ist das letzte freie Zimmer in der Zwischenzeit auf beiden Seiten buchbar. Die zweite Lücke sind Buchungen am System vorbei: Ein Gast ruft an, das Zimmer wird zugesagt, aber nicht erfasst — für die Portale bleibt es frei. Die dritte Lücke sind Meldungen, die ihr Ziel nicht erreichen: Eine Buchung ist im eigenen System angelegt, aber die Übertragung an das Portal ist fehlgeschlagen, ohne dass es jemand bemerkt. Und die vierte Lücke entsteht umgekehrt, wenn eine Portalbuchung nicht übernommen werden kann, weil die Zimmerkategorie des Portals keiner Kategorie im eigenen System zugeordnet ist.
Keine dieser Lücken ist ein Bedienfehler im eigentlichen Sinn. Sie sind die normale Folge davon, dass zwei Systeme dieselbe Wahrheit getrennt voneinander führen. Ein Buchungssystem muss deshalb von vornherein so gebaut sein, dass es mit diesen Lücken rechnet.
Was ein sauberes System technisch leisten muss
Überbuchungsschutz ist keine einzelne Funktion, sondern ein Zusammenspiel aus drei Ebenen, die jeweils eine andere Lücke schließen.
Die erste Ebene liegt im eigenen System: Verfügbarkeitsprüfung und Buchung laufen in einer einzigen Transaktion unter Sperre. Prüfen und Buchen sind also kein Nacheinander, zwischen dem ein zweiter Gast dasselbe Zimmer erwischen könnte, sondern ein unteilbarer Schritt. Versuchen mehrere Gäste gleichzeitig, das letzte freie Zimmer zu buchen, bekommt es genau einer.
Die zweite Ebene liegt bei der Übertragung an die Portale: Legt das System eine Buchung beim Portal an, setzt es dessen eigene Verfügbarkeitsprüfung immer mit. So prüft auch das Portal noch einmal, ob das Zimmer auf seiner Seite tatsächlich frei ist, statt die Buchung blind zu übernehmen.
Die dritte Ebene ist der regelmäßige Abgleich: Ein Hintergrundprozess vergleicht die eigene Belegung mit der des Portals. Stellt er eine Abweichung fest, schlägt er Alarm und sperrt den betroffenen Zimmertag automatisch, bis geklärt ist, welche Seite recht hat. Die Sperre ist bewusst: Lieber eine Nacht nicht verkaufen als ein Zimmer zweimal.
Am Rande gehört auch die Zahlung dazu. Meldungen des Zahlungsanbieters kommen mehrfach an; damit eine doppelt zugestellte Meldung nicht zwei Zahlungen erzeugt, braucht jede Meldung einen Idempotenzschlüssel, über den das System Wiederholungen erkennt.
Verfügbarkeit und Preise kommen aus dem eigenen System
Eine naheliegende Abkürzung wäre, die Website einfach beim Portal nachfragen zu lassen: Der Gast wählt ein Datum, die Website holt Verfügbarkeit und Preis live vom Portalanbieter und zeigt sie an. Das ist keine tragfähige Lösung. Die Anbieter solcher Schnittstellen verlangen ausdrücklich, dass Daten für öffentliche Seiten im eigenen System vorgehalten werden, und begrenzen die Zahl der Anfragen so, dass eine öffentliche Buchungsstrecke damit nicht betrieben werden kann. Hinzu kommt: Die Website wäre immer nur so schnell und so verfügbar wie das Portal.
Deshalb gilt: Verfügbarkeit und Preise für Gäste kommen aus der eigenen Datenbank. Das Portal wird nie befragt, während ein Gast wartet. Stattdessen meldet das System jede Änderung an Preis oder Verfügbarkeit ereignisgesteuert an die Portale weiter — die eigene Belegung ist die Quelle, die Portale sind Empfänger.
Meldungen vom Portal sind Auslöser, nicht Wahrheit
In der Gegenrichtung schicken die Portale Meldungen, sobald ein Gast dort bucht, ändert oder storniert. Diese Meldungen sind nützlich, aber nicht verlässlich: Sie kommen mit Verzögerung, nicht in fester Reihenfolge, manchmal mehrfach und nach einer gewissen Zeit gar nicht mehr. Beim Löschen einer Buchung auf Portalseite gibt es überhaupt keine Meldung.
Ein sauberes System behandelt eine Meldung deshalb nur als Anstoß. Es prüft sie, lädt die Buchung anschließend per Einzelabfrage beim Portal nach und übernimmt den Stand aus dieser Abfrage — nie den Inhalt der Meldung selbst. Der Status einer Buchung wird damit immer aus dem nachgeladenen Objekt abgeleitet. Was auf diesem Weg trotzdem verloren geht, holt der regelmäßige Abgleich nach.
Praxis-Checkliste für den Hotelier
Die beste Technik schützt nur, wenn sie alle Buchungen kennt. Fünf Gewohnheiten im Alltag machen den Unterschied:
- Jede Buchung ins System — auch die am Telefon oder per E-Mail. Was nicht im System steht, kann nicht an die Portale gemeldet werden.
- Zimmer zuweisen: Eine Buchung ohne festes Zimmer belegt zwar die Kategorie, aber Sie sehen erst bei der Zuweisung, ob sie wirklich noch hineinpasst.
- Belegungsplan täglich prüfen — mit Blick auf vorläufige Buchungen und auf alles, was rot markiert ist.
- Alarm-E-Mails ernst nehmen und sofort klären, welche Seite recht hat. Der gesperrte Zimmertag bleibt so lange unverkäuflich.
- Zimmerkategorien sauber zuordnen: Jede Kategorie auf dem Portal braucht ihr Gegenstück im eigenen System, sonst bleibt eine Portalbuchung hängen.
Dazu kommt ein Schritt je Portal: Die Verbindung geben Sie in Ihrem Portalkonto in der Regel selbst frei. Bei vielen Portalen sind das wenige Klicks; bei einzelnen müssen die Preise jährlich neu angelegt werden — dafür gehört eine jährliche Erinnerung in die Software.
Was gute Software sichtbar macht
Ein Schutz, den Sie nicht sehen, hilft Ihnen im Zweifel nicht. Gute Software zeigt deshalb offen, wo die Belegung gerade wackelt. Der Belegungsplan verschweigt nichts: Buchungen ohne feste Zimmerzuweisung werden sichtbar einsortiert und als vorläufig gekennzeichnet. Passt eine Buchung nirgends mehr hinein, erscheint sie als rote „Ohne Zimmer"-Zeile mit Warnhinweis, statt unbemerkt zu fehlen. Doppelbelegungen eines Zimmers sind rot markiert.
Ein Überbuchungs-Wächter prüft, ob für eine Nacht mehr Zimmer gebucht sind als vorhanden — falls ja, warnt das Dashboard sofort und das Hotel erhält eine Alarm-E-Mail. Das Dashboard zeigt außerdem an, wenn Buchungen die Portale noch nicht erreicht haben oder eine Portalbuchung nicht übernommen werden konnte, weil eine Zimmerkategorie nicht zugeordnet ist. Und eine Nachmelde-Automatik prüft alle fünf Minuten, ob eine bestätigte Buchung die Portale noch nicht erreicht hat, und holt das nach — unabhängig davon, ob die Buchung online, telefonisch oder über ein bestätigtes Angebot entstanden ist.
So macht es die Masaro-Hotelsoftware
Bei Masaro laufen Verfügbarkeitsprüfung und Buchung in einer Transaktion, die Portale erhalten jede bestätigte Buchung sofort, und eine Nachmelde-Automatik prüft alle fünf Minuten, ob eine Buchung die Portale noch nicht erreicht hat. Belegungsplan, Überbuchungs-Wächter mit Alarm-E-Mail und Dashboard-Hinweise machen sichtbar, was sonst unbemerkt bliebe. Wie das mit den übrigen Funktionen zusammenspielt, zeigt Ihnen der Funktionsüberblick.