Channel-Manager und PMS: Schnittstellen in der Hotellerie richtig planen

Ein mittlerer Beherbergungsbetrieb betreibt heute mehr Software, als man von außen vermuten würde: ein Property-Management-System für Zimmerplan und Meldewesen, einen Channel-Manager für die Buchungsportale, eine Buchungsstrecke auf der eigenen Website, dazu Kassensystem, Buchhaltung, Newsletter-Werkzeug und oft noch ein Bewertungs- oder Gästemappen-Tool. Jedes dieser Systeme wurde irgendwann aus gutem Grund angeschafft. Zusammen geplant wurden sie selten.

Die Folgen zeigen sich im Alltag an der Rezeption: Eine Ratenänderung wird im PMS erfasst und muss im Channel-Manager nachgezogen werden. Eine Buchung vom Portal kommt herein, aber die Gästedaten werden für die Meldung noch einmal getippt. Und in der Hochsaison, wenn niemand Zeit hat, entsteht genau dann eine Überbuchung, wenn zwei Systeme für einige Minuten unterschiedliche Verfügbarkeiten zeigen.

Wer Channel-Manager und PMS verbinden will, sollte deshalb nicht bei der Technik beginnen, sondern bei der Frage: Welches System führt welche Daten, und in welche Richtung fließen sie.

Die Systemlandschaft eines Beherbergungsbetriebs

Im Zentrum steht fast immer das PMS: Es kennt Zimmer, Reservierungen, Gäste und Rechnungen und bedient die gesetzlichen Pflichten wie das Gästemeldewesen. Der Channel-Manager ist die Drehscheibe nach außen: Er verteilt Verfügbarkeiten und Preise an die Portale und nimmt deren Buchungen entgegen. Die eigene Buchungsstrecke auf der Website ist wirtschaftlich der attraktivste Kanal, weil keine Portalprovision anfällt, und technisch ein Kanal wie jeder andere.

Um diesen Kern gruppieren sich die Nebensysteme: Kassen- und Bezahlsysteme, Buchhaltung, Gästekommunikation. Für die Schnittstellenplanung genügt zunächst der Kern, denn dort liegen die drei Datenarten, an denen alles hängt: Raten, Verfügbarkeiten und Gästedaten.

Wo Doppelpflege entsteht

Doppelpflege ist selten eine bewusste Entscheidung. Sie entsteht, wenn zwei Systeme dieselbe Information halten und keine verlässliche Verbindung zwischen ihnen besteht. Typische Muster:

• Raten werden im PMS kalkuliert und im Channel-Manager händisch eingetragen, für jede Saison, jede Kategorie, jeden Kanal.
• Verfügbarkeiten werden bei Direktbuchungen manuell in den Portalen reduziert, mit der Überbuchung als ständigem Restrisiko.
• Gästedaten aus Portalbuchungen werden für Meldeschein, Rechnung und Gästekartei mehrfach erfasst, mit jedes Mal neuen Tippfehlern.

Doppelpflege kostet nicht nur Zeit. Sie erzeugt Widersprüche zwischen den Systemen, und Widersprüche erzeugen Misstrauen: Sobald das Team den Zahlen nicht mehr traut, wird wieder alles kontrolliert, und der Nutzen der Software verpufft.

Schnittstellen planen: Raten, Verfügbarkeiten, Gästedaten

Der wichtigste Grundsatz jeder Anbindung lautet: Für jede Datenart gibt es genau ein führendes System, alle anderen empfangen. Wer Raten im PMS pflegt, darf sie im Channel-Manager nur noch lesen, nicht mehr ändern. Diese Entscheidung klingt banal, ist aber der Punkt, an dem die meisten Anbindungen in der Praxis unsauber werden, weil Ausnahmen zugelassen werden, etwa die schnelle Preisänderung direkt im Portal.

Für die drei Datenarten sind unterschiedliche Fragen zu klären. Bei den Raten: Welche Ratenstruktur wird übertragen, wie werden kanalspezifische Auf- und Abschläge abgebildet, und wie schnell muss eine Änderung an den Portalen ankommen. Bei den Verfügbarkeiten: Läuft die Synchronisation in beide Richtungen, wie kurz ist die Verzögerung, und was passiert bei einem Ausfall der Verbindung. Bei den Gästedaten: Welche Felder liefert der Kanal tatsächlich, reichen sie für den Meldeschein, und wie werden Dubletten in der Gästekartei vermieden.

Ebenso wichtig wie der Normalbetrieb ist das Fehlerverhalten. Eine Schnittstelle, die still scheitert, ist gefährlicher als gar keine, denn sie erzeugt falsche Sicherheit. Jede Anbindung braucht eine sichtbare Fehlerliste und eine benannte Person, die sie täglich prüft.

Saisonfestigkeit

Beherbergungsbetriebe haben ein Lastprofil, das Schnittstellen gnadenlos prüft. Vor Saisonbeginn werden Raten und Kontingente für Monate im Voraus eingespielt, oft in großen Paketen. In den Spitzenwochen laufen Buchungen, Stornos und Umbuchungen in hoher Dichte. Genau dann darf die Synchronisation weder langsam noch lückenhaft sein.

Saisonfestigkeit lässt sich vorbereiten. Die Ratenladung für die kommende Saison sollte Wochen vor dem Verkaufsstart erfolgen und stichprobenartig auf allen Kanälen geprüft werden: Stimmen Preis, Kategorie und Stornobedingungen auf dem Portal mit dem PMS überein. Für die Spitzenzeit braucht es einen einfachen Notfallplan: Wie werden Verfügbarkeiten geschlossen, wenn die Verbindung ausfällt, und wer entscheidet das. Wer diese Fragen erst im August klärt, klärt sie unter dem größtmöglichen Druck.

Auswahlkriterien

Bei der Auswahl von PMS und Channel-Manager entscheidet weniger der Funktionskatalog als die Qualität der Verbindung. Fünf Kriterien haben sich bewährt:

• Zertifizierte, beidseitige Schnittstelle zwischen den konkreten Produkten, nicht nur ein Logo auf der Partnerliste. Die Tiefe der Integration variiert stark.
• Nachvollziehbares Fehlerhandling: einsehbare Übertragungsprotokolle statt einer Blackbox.
• Datenexport: Reservierungen, Gästedaten und Raten müssen sich vollständig exportieren lassen, sonst wird jeder spätere Wechsel zur Geiselhaft.
• Kostenmodell, das zum Betrieb passt: Gebühren je Kanal, je Buchung oder pauschal wirken sich je nach Portfoliogröße sehr unterschiedlich aus.
• Support in der Saison: Erreichbarkeit und Reaktionszeiten zählen dann, wenn das Haus voll ist, nicht im November.

Fazit

Die Anbindung von Channel-Manager und PMS ist kein technisches Detail, sondern die Grundlage dafür, dass ein Beherbergungsbetrieb seine Kanäle ohne Doppelpflege und Überbuchungsrisiko bespielen kann. Wer je Datenart ein führendes System festlegt, das Fehlerverhalten ernst nimmt und die Anbindung vor der Saison prüft statt in ihr, bekommt eine Systemlandschaft, die im Hintergrund arbeitet. Genau dort gehört sie hin, damit die Zeit des Teams den Gästen gilt und nicht der Software.