Die kurze Antwort

Standard-PMS-Lösungen sind als Buchungs- und Rechnungsengine grundsolide. Sobald aber ein Hotel mehr als einen Verkaufskanal, mehr als ein Zusatzsystem und mehr als die Standard-Workflows braucht, beginnt der eigentliche Schmerz — und er sitzt fast immer in den Schnittstellen. Doppelpflege, zertifizierte Partner pro Integration, Add-on-Gebühren pro Channel, schwache APIs: das sind die wiederkehrenden Themen, sobald wir mit Hoteliers ins Detail gehen.

Warum Schnittstellen das eigentliche Thema sind

Ein Hotel betreibt heute typischerweise nicht ein System, sondern eine kleine Konstellation:

PMS (Reservierung, Check-in, Zimmer-Status, Rechnung)
Channel Manager (Booking.com, Expedia, HRS, eigene Booking Engine)
Revenue Management (dynamische Preise, Belegungsvorhersage)
POS (Restaurant, Bar, Wellness)
Buchhaltung (Debitoren, Hauptbuch, Zahlungsabgleich)
Door Locks, Telefonanlage, TV, WLAN-Captive-Portal
CRM / Gäste-Marketing (Newsletter, Loyalty)
Meldewesen (Gästemeldungen, Kurtaxe)
Reporting / BI

In der Theorie verbindet das PMS diese Welt. In der Praxis ist jede einzelne Verbindung ein eigener Vertrag, ein eigenes Add-on, oft ein eigener zertifizierter Partner mit eigener Lizenz. Wer drei OTAs, einen POS, ein Door-Lock-System und ein Newsletter-Tool will, sammelt schnell fünf bis acht Schnittstellen — jede davon eine eigene Fehlerquelle.

Die wiederkehrenden Schmerzpunkte

Aus den Gesprächen mit Hoteliers tauchen immer wieder dieselben Muster auf:

Doppelpflege. Raten und Verfügbarkeiten werden in zwei Systemen gepflegt — PMS und Channel Manager — weil die Synchronisation nicht alle Restriktionen abbildet (Mindestaufenthalt, Closed-to-Arrival, kanalspezifische Preise). Das kostet täglich Zeit und erzeugt Buchungsfehler.
„Zertifizierte Partner only". Will man ein neues Tool anbinden, muss es vom PMS-Hersteller offiziell zertifiziert sein. Ist es das nicht, gibt es keinen Datenfluss — egal wie sinnvoll die Integration wäre.
Add-on pro Channel. Jeder zusätzliche Verkaufskanal kostet eine monatliche Gebühr, oft unabhängig davon, ob über den Kanal auch wirklich gebucht wird.
API zugemauert. Es gibt zwar eine API, aber sie ist entweder Read-only, oder die schreibende Variante wird nur Partnern mit Rahmenvertrag gegeben. Eigene Entwicklungen am Datenmodell sind faktisch ausgeschlossen.
Daten gehören dem Anbieter. Beim Wechsel des PMS lässt sich der historische Gäste-Datenbestand nur eingeschränkt exportieren — Reservierungs-Historie, Gäste-Notizen, Zahlungsverläufe bleiben oft hinter dem alten System.
Reporting im Korsett. Standard-Reports decken den Standard ab. Sobald der Hotelier eine eigene Auswertung braucht — etwa Umsatz pro Quellmarkt, kombiniert mit Wetterdaten — wird's mühsam oder unmöglich.
Workflows starr. Spezielle Abläufe (Wellness-Pakete mit Restaurant-Reservierung, mehrstufige Anzahlungs-Logik, Gruppenkontingente mit Sub-Allotments) zwingen in die Schablone des PMS — oder werden draussen mit Excel weitergeführt.
Support reagiert, statt zu antworten. Tickets zu Schnittstellen-Fehlern landen oft zwischen PMS-Hersteller, Channel-Manager-Hersteller und Booking-Site — und niemand fühlt sich zuständig.

Drei Muster aus der Praxis

Muster A — Hotel mit mehreren OTAs und einem POS

Klassisches Setup: mittelgrosses Hotel, Restaurant, mehrere Vertriebsplattformen. Die Schmerzgrenze liegt selten bei einem OTA, fast immer beim dritten. Die monatlichen Channel-Gebühren summieren sich, und Raten-Inkonsistenzen führen zu Rate-Parity-Strafen seitens der OTAs.

Was hilft: Ein Channel Manager mit echter Zwei-Wege-Synchronisation und sauberer Rate-Plan-Logik direkt im PMS — nicht als nachträglich zertifiziertes Add-on. Sobald Raten, Restriktionen und Verfügbarkeit aus einer Quelle kommen, verschwindet der grösste Anteil des täglichen Aufwands.

Muster B — Das Seminarhotel mit individuellen Buchungsstrecken

Anfragen mit Tagungspauschalen, Optionsfristen, Gruppenkontingenten, parallelen Zimmer-Allotments und Tagesextras. Das Standard-PMS deckt zwei dieser Dimensionen ab, scheitert an der dritten.

Was hilft: Ein PMS mit konfigurierbarem Pauschalen-Modul und offener API — oder ein ergänzendes Modul, das die Pauschalen-Logik abbildet und das PMS nur noch als Buchungs- und Rechnungsengine nutzt.

Muster C — Das Boutique-Hotel mit eigener Direktbuchungs-Strategie

Bewusst weniger OTA-Abhängigkeit, dafür hochwertige eigene Booking Engine, Newsletter-getriebener Direktverkauf, Loyalty. Hier wird die schwache Schnittstelle zwischen PMS und Marketing-Stack zum Engpass: Gäste-Segmentierung im PMS ist rudimentär, das CRM kennt keine Aufenthaltshistorie.

Was hilft: Eine offene Datenleitung zwischen PMS und Marketing-Tool — oder ein eigenes Gäste-CRM, das täglich gegen das PMS synchronisiert. Wichtig: Schreibrichtung klären, sonst überschreibt das CRM Gäste-Notizen aus dem PMS.

Die Auswege

Aus unserer Sicht gibt es drei realistische Wege, wenn man mit dem aktuellen PMS-Setup unzufrieden ist:

Anbieter wechseln. Die offensichtliche, aber riskanteste Option. Datenmigration ist mühsam, Personal muss neu geschult werden, und die Schnittstellen-Frage stellt sich beim Nachfolger neu. Lohnt sich nur, wenn das aktuelle PMS strategisch nicht mehr passt.
Offene Schnittstelle erzwingen. Statt für jeden Anwendungsfall ein neues Add-on zu lizenzieren, eine saubere bidirektionale API nutzen — wenn der Hersteller eine bietet. Damit lassen sich eigene Tools (Reporting, CRM, Marketing) anschliessen, ohne im zertifizierten-Partner-Universum gefangen zu bleiben.
Ergänzendes Modul. Das PMS bleibt für Buchung und Rechnung, eine zusätzliche Schicht (eigene Anwendung, ergänzende Plattform) übernimmt die Bereiche, in denen das PMS schwach ist — typisch: Pauschalen-Logik, Gruppenkontingente, Marketing-Segmente, individuelle Reports. Diese Schicht spricht mit dem PMS über API oder Datenbank-Sync.

Welcher Weg passt, hängt nicht primär an der Grösse des Hotels, sondern an der strategischen Frage: Wo soll das PMS in fünf Jahren stehen? Wenn es als Daten-Eigentümer und Workflow-Engine wachsen muss, lohnt sich der Wechsel. Wenn es eine solide Buchungs- und Fakturierungsmaschine bleiben soll, lohnt sich die ergänzende Schicht.

Fallstricke beim Wechsel oder bei der Ergänzung

Was wir wiederholt sehen:

Datenmigration wird unterschätzt. Reservierungs-Historie, offene Anzahlungen, Gäste-Notizen, Steuersätze, Preislisten — jeder Datenpunkt hat im Zielsystem eine andere Form.
Doppelt-laufende Phase fehlt im Plan. Zwei Systeme parallel zu betreiben — auch nur für vier Wochen — bindet Personal und produziert Fehler. Wer das nicht einplant, geht hart durch den Übergang.
Kanal-Mappings sind tückisch. Raten, Zimmertypen, Restriktionen werden auf den OTAs anders verstanden als im neuen PMS. Ein detaillierter Mapping-Plan vor dem Switch verhindert spätere Rate-Parity-Strafen.
Mitarbeitende werden zu spät einbezogen. Die Rezeption arbeitet jeden Tag im PMS. Wenn sie das neue System erst eine Woche vor Go-Live sieht, wird der Wechsel zur Belastung statt zur Verbesserung.
Vertragslaufzeiten beim alten System. Auch wenn das neue PMS bereit ist — wenn das alte noch zwölf Monate läuft, zahlt man doppelt.

Fazit

PMS-Unzufriedenheit ist selten das PMS allein, fast immer die Konstellation aus PMS und seiner Umgebung. Wer das so liest, kann zwei Dinge besser machen: erstens beim nächsten Vertrag explizit auf API-Offenheit, Datenbesitz und Export-Fähigkeit achten — nicht nur auf das Feature-Set des Kernsystems. Und zweitens nicht jedes Problem mit einem Anbieterwechsel lösen, sondern prüfen, ob eine ergänzende Schicht das System tragbar macht.

Wir sehen die Schnittstellen-Welt der Hotellerie aus erster Hand, weil wir ein eigenes Property-Management-System für Hotels entwickeln. Wenn Sie wissen wollen, welcher der drei Wege für Ihren Betrieb der pragmatische ist, sprechen wir gerne. Eine erste Bestandsaufnahme — welche Systeme, welche Schnittstellen, welche täglichen Schmerzpunkte — ist meistens schon eine eigene Entdeckung wert. Direkt Kontakt aufnehmen.

PMS und Schnittstellen — warum Hoteliers mit Standard-Lösungen kämpfen