PMS, CRM, Booking Engine & Co. kennen denselben Gast unterschiedlich. So wird aus Datensilos ein Gesamtbild.
Hotelsoftware · Guide · 13 min Lesezeit Ein Gast bucht ein Zimmer.
Das PMS kennt Name, Adresse, Aufenthalt und Rate.
Die Booking Engine weiß, dass direkt gebucht wurde.
Das Newsletter-System kennt die E-Mail-Adresse und weiß, welche Mailings geöffnet wurden.
Das Restaurant hat zwei Abendessen verbucht.
Im CRM gibt es vielleicht noch einen Aufenthalt von vor drei Jahren.
Eigentlich weiß das Hotel ziemlich viel.
Nur leider nicht unbedingt an derselben Stelle.
Und manchmal weiß es nicht einmal, dass all diese Informationen zum selben Menschen gehören.
Willkommen bei Gästedaten im Hotel.
Das Problem ist selten, dass Hotels keine Daten haben. Im Gegenteil. Mit jedem neuen System, Vertriebskanal und digitalen Kontaktpunkt kommen weitere hinzu. Das Problem ist, dass diese Daten verteilt entstehen, unterschiedlich gespeichert werden und nicht automatisch ein gemeinsames Bild ergeben.
Das ist inzwischen weniger Ausnahme als strukturelles Problem der Hoteltechnologie. Im State of Hospitality Tech 2025 wurden Integration, Fragmentierung und fehlende Standards als die häufigsten Frustrationen der Branche genannt. Gleichzeitig lag die Nutzung spezialisierter Customer Data Platforms unter den befragten Hotelunternehmen noch unter zehn Prozent.
Also noch eine Plattform kaufen?
Nicht so schnell.
Denn bevor Gästedaten zusammengeführt werden können, sollte erst einmal klar sein, welche Daten wo entstehen, welches System wofür zuständig ist und welches Problem eigentlich gelöst werden soll.
Sonst bekommt der bestehende Tool-Zoo nur ein neues Gehege.
Gästedaten sind alle Informationen, die ein Hotel im Zusammenhang mit einem Gast und seinen Interaktionen mit dem Hotel erfasst.
Das beginnt bei ziemlich offensichtlichen Dingen:
Und hört dort längst nicht auf.
Je nach Hotel und Systemlandschaft können außerdem Informationen zu früheren Aufenthalten, Umsätzen, Restaurantbesuchen, Präferenzen, Newsletter-Interaktionen, Direktbuchungen, Stornierungen, Zusatzleistungen oder Loyalty-Programmen vorhanden sein.
Die interessante Frage ist deshalb nicht:
Welche Gästedaten haben wir?
Sondern:
Wo liegen sie – und wissen unsere Systeme, dass sie zum selben Gast gehören?
Genau dort beginnt das Problem.
Hotels arbeiten nicht mit einem System.
Das Property Management System (PMS) organisiert den operativen Hotelbetrieb.
Eine Booking Engine nimmt Direktbuchungen entgegen.
Das CRS verwaltet Reservierungs- und Vertriebsinformationen.
Ein CRM unterstützt Gästekommunikation und Kundenbeziehungen.
Das Kassensystem kennt Restaurantumsätze.
Das Spa-System kennt Anwendungen.
Das Newsletter-System kennt Kampagnen und Reaktionen.
Website und Analytics erfassen digitale Interaktionen.
Und vielleicht gibt es zusätzlich Loyalty, Gästemessaging, Check-in, Payment oder Business Intelligence.
Jedes dieser Systeme wurde für eine bestimmte Aufgabe gebaut.
Das ist zunächst völlig in Ordnung.
Problematisch wird es, wenn jedes System seinen eigenen kleinen Ausschnitt des Gastes besitzt – und diese Ausschnitte nicht sauber miteinander verbunden sind.
Nehmen wir Anna Becker.
Anna war vor zwei Jahren zum ersten Mal im Hotel und buchte über eine OTA.
Im PMS existiert:
Anna Becker
anna.becker@email.de
Beim zweiten Aufenthalt bucht sie direkt und verwendet ihre geschäftliche E-Mail-Adresse:
Anna Becker
a.becker@unternehmen.de
Beim Restaurantbesuch reserviert ihr Partner den Tisch.
Im Newsletter-System steht wiederum die private E-Mail-Adresse.
Und bei einer weiteren OTA-Buchung kommt möglicherweise eine vom Vermittler erzeugte beziehungsweise abgeschirmte Kontaktadresse hinzu.
Für Anna ist die Sache ziemlich eindeutig.
Sie ist Anna.
Für die Systeme kann die Lage komplizierter aussehen.
Je nachdem, welche Identifikatoren gespeichert und wie Profile abgeglichen werden, können daraus mehrere Datensätze entstehen.
Das Hotel sieht dann womöglich drei Aufenthalte.
Aber nicht unbedingt einen Gast mit drei Aufenthalten.
Klingt nach Wortklauberei.
Ist wirtschaftlich ein ziemlich großer Unterschied.
Dieses Problem wird häufig unter Begriffen wie Guest Identity, Identity Resolution oder Profile Deduplication behandelt.
Gemeint ist im Kern immer dieselbe Frage:
Welche Datensätze gehören tatsächlich zu derselben Person?
Ein System kann dafür beispielsweise verschiedene Merkmale vergleichen:
Je nach Technologie geschieht dieser Abgleich anhand eindeutiger Regeln oder zusätzlicher Matching-Logiken.
Denn Menschen sind für Datenbanken erstaunlich unkooperativ.
Sie wechseln E-Mail-Adressen.
Sie heiraten.
Sie vertippen sich.
Sie geben Telefonnummern unterschiedlich ein.
Sie buchen einmal privat und einmal geschäftlich.
Und „Dr. Anna Becker“, „Anna Becker“ und „A. Becker“ können dieselbe Person sein.
Oder eben drei verschiedene.
Einfach alles automatisch zusammenzukippen wäre deshalb keine besonders brillante Lösung.
Eine saubere Guest Identity muss Profile zusammenführen können, ohne unterschiedliche Gäste fälschlicherweise zu einer Person zu machen.
Genau dieses Thema vertiefen wir im Artikel „Guest Identity im Hotel: Who is Anna Becker?“.
An dieser Stelle kommt häufig ein Satz:
„Aber unsere Systeme haben doch Schnittstellen.“
Sehr gut.
Das ist wichtig.
Es löst nur nicht automatisch das gesamte Problem.
Eine Schnittstelle sorgt zunächst dafür, dass bestimmte Daten zwischen zwei Systemen übertragen werden können.
Welche Daten das sind, in welche Richtung sie fließen, wie häufig sie synchronisiert werden und welches System anschließend die führende Information besitzt, ist eine andere Frage.
Wie solche Integrationen grundsätzlich funktionieren, erklären wir ausführlicher im Guide „Schnittstellen im Hotel“. Gerade bei Hotelsoftware reicht „API vorhanden“ als Aussage nicht aus. Entscheidend ist, welche Daten tatsächlich gelesen, geschrieben und synchronisiert werden können. Auch bei der Auswahl von Hotelsoftware sollte deshalb die bestehende Systemlandschaft zuerst dokumentiert werden.
Für Gästedaten kommt noch eine weitere Ebene hinzu.
Angenommen, PMS und CRM tauschen Daten aus.
Dann fließen Daten.
Das beantwortet aber noch nicht automatisch:
Ist Anna Becker aus System A dieselbe Anna Becker wie in System B?
Datentransport und Datenverständnis sind zwei verschiedene Dinge.
Eine Schnittstelle ist die Straße.
Sie entscheidet noch nicht, welches Auto wohin gehört.
Das Ziel ist deshalb nicht zwingend:
Alle Gästedaten müssen in ein einziges System.
Das klingt ordentlich.
Die Realität von Hotelsystemen ist selten so ordentlich.
Ein PMS sollte weiterhin das tun, was ein PMS gut kann. Ein POS sollte Restauranttransaktionen verarbeiten. Eine Booking Engine sollte Buchungen ermöglichen.
Entscheidend ist vielmehr, dass relevante Informationen systemübergreifend einem Gast zugeordnet und dort nutzbar gemacht werden können, wo sie gebraucht werden.
Dafür wird häufig der Begriff Single Customer View oder im Hospitality-Kontext auch Single Guest Profile verwendet.
Vereinfacht:
Eine Single Customer View verbindet relevante Informationen aus verschiedenen Quellen zu einer konsistenten Sicht auf denselben Gast.
Aus:
Aufenthalt 1 + Direktbuchung + Restaurantbesuch + Aufenthalt 2 + Newsletter-Interaktion
wird:
Anna Becker.
Mit einer nachvollziehbaren Historie ihrer Beziehung zum Hotel.
Das klingt banal.
Technisch ist es das nicht.
Denn dafür müssen Datenquellen verbunden, Profile erkannt, Dubletten behandelt, Daten vereinheitlicht und Regeln dafür definiert werden, welches System bei widersprüchlichen Informationen die führende Quelle ist.
Genau deshalb widmen wir der Single Customer View im Hotel einen eigenen Artikel.
Spätestens jetzt tauchen drei Buchstaben auf, die gern durcheinandergeraten:
PMS. CRM. CDP.
Also sortieren wir kurz.
Das Property Management System ist das operative Kernsystem vieler Hotels.
Dort liegen typischerweise Informationen zu:
Vereinfacht gesagt:
Das PMS kennt vor allem den Gast im Zusammenhang mit seinem Aufenthalt.
Ein Customer Relationship Management System konzentriert sich stärker darauf, die Beziehung zum Gast zu verwalten.
Je nach Lösung gehören dazu beispielsweise:
Das CRM fragt also weniger:
In welchem Zimmer schläft Anna heute?
Und stärker:
Was wissen wir über Anna und wie kommunizieren wir sinnvoll mit ihr?
Eine Customer Data Platform verfolgt wiederum einen anderen Schwerpunkt.
Sie sammelt Daten aus verschiedenen Quellen, vereinheitlicht sie und kann daraus zentrale Kunden- beziehungsweise Gästeprofile bilden, die anschließend anderen Systemen zur Verfügung gestellt werden.
Das kann besonders interessant werden, wenn viele Datenquellen beteiligt sind.
PMS.
CRM.
POS.
Website.
Booking Engine.
Spa.
Loyalty.
Weitere Häuser einer Hotelgruppe.
Die Grenzen zwischen den Produktkategorien sind allerdings nicht messerscharf. Moderne Plattformen übernehmen teilweise Funktionen mehrerer Bereiche.
Deshalb sollte die Frage nicht lauten:
„Brauchen wir ein CRM oder eine CDP?“
Sondern zuerst:
„Welches Datenproblem wollen wir lösen?“
Die Technologien vergleichen wir deshalb separat in „CRM oder CDP: Was braucht ein Hotel wirklich?“
Interessant ist dabei der Blick auf den aktuellen Markt: In der internationalen State of Hospitality Tech 2025-Befragung waren PMS und CRS weit verbreitet, spezialisierte CDPs dagegen noch bei weniger als zehn Prozent der befragten Hotelunternehmen im Einsatz. Gleichzeitig wurden Fragmentierung und Integration als zentrale Probleme genannt.
Die Technik für zentrale Datenmodelle existiert also.
Die durchgängige Nutzung ist noch längst nicht selbstverständlich.
Hier kommt eine überraschend hilfreiche Antwort:
Nicht einfach alle.
Daten sammeln ist kein Selbstzweck.
Ein Hotel braucht nicht den digitalen Dachboden, auf dem seit 2017 alles liegt, weil man es vielleicht irgendwann noch gebrauchen könnte.
Stattdessen sollte für jede Datenart geklärt werden:
Wofür brauchen wir diese Information?
Zum Beispiel:
| Information | Mögliche Quelle | Möglicher Nutzen |
|---|---|---|
| Name und Kontakt | PMS / Booking Engine / CRM | Identifikation und Kommunikation |
| Aufenthalte | PMS / CRS | Wiederkehrende Gäste erkennen |
| Buchungskanal | PMS / CRS / Booking Engine | Direkt- und Drittvertrieb unterscheiden |
| Umsatz | PMS / POS / Spa | Gesamtwert eines Gastes besser verstehen |
| Präferenzen | PMS / CRM | Service und Kommunikation verbessern |
| Newsletter-Interaktion | CRM / Marketingtool | Kommunikation steuern |
| Loyalty-Status | CRM / Loyalty-System | Vorteile und Beziehung verwalten |
Dabei braucht nicht jede Abteilung Zugriff auf jede Information.
Und nicht jede Information muss dauerhaft gespeichert werden.
Gute Datenarchitektur bedeutet nicht maximale Datenmenge. Sondern klare Zuständigkeit.
Welches System welche Daten führen sollte und wo eine Synchronisation sinnvoll ist, behandeln wir ausführlich im Framework „Welche Hoteldaten gehören in welches System?“.
Jetzt wird die ganze Datenübung interessant.
Denn ein hübsches Gästeprofil allein zahlt noch keine Rechnung.
Ein Stammgast sollte nicht bei jedem Aufenthalt digital bei null anfangen.
Eine bessere Zuordnung macht sichtbar, wie häufig jemand tatsächlich übernachtet, über welche Kanäle gebucht wird und wie sich die Beziehung entwickelt.
Ein Gast kann beim ersten Aufenthalt über eine OTA kommen und später direkt buchen.
Wenn beide Aufenthalte unterschiedlichen Profilen zugeordnet werden, sieht das Hotel diese Entwicklung nicht.
Aus Vertriebssicht fehlt damit ein wichtiges Stück Information.
Der Gast mit der höchsten ADR muss nicht der wirtschaftlich interessanteste Gast sein.
Vielleicht bucht ein anderer Gast regelmäßig das Restaurant.
Spa.
Parkplatz.
Bar.
Late Check-out.
Oder mehrere Zimmer.
Wenn Zusatzumsätze in separaten Systemen bleiben, wird aus einem wertvollen Gast schnell ein ziemlich durchschnittlicher PMS-Datensatz.
Wer gestern ausgecheckt hat, braucht heute vermutlich keine Werbung für denselben Aufenthalt.
Wer bereits gebucht hat, muss nicht weiter mit derselben Buchungskampagne verfolgt werden.
Und wer seit fünf Jahren Stammgast ist, darf anders angesprochen werden als jemand, der gerade zum ersten Mal auf der Website war.
Personalisierung beginnt deshalb nicht beim Vornamen im Newsletter.
„Hallo Anna“ ist technisch personalisiert.
Besonders persönlich ist es noch nicht.
Gästedaten sind außerdem nicht nur Marketingdaten.
Sie können für Vertrieb, Revenue Management, Operations und Management relevant sein.
Welche Gäste buchen direkt?
Welche wechseln zwischen Kanälen?
Welche Segmente erzeugen Zusatzumsatz?
Wie entwickeln sich Wiederholungsbuchungen?
Welche Gästegruppen reagieren auf bestimmte Angebote?
Die Antworten werden besser, wenn Daten nicht isoliert betrachtet werden.
Eine 2025 veröffentlichte Untersuchung von Revinate und Hapi unterstreicht, wie praktisch dieses Problem weiterhin ist: 49 Prozent der befragten Hotelfachleute gaben an, Schwierigkeiten beim Zugriff auf Daten zu haben, die sie für wichtige Umsatz- und operative Entscheidungen benötigen. Als wesentliche Hindernisse nennt der Report unter anderem getrennte Systeme und ungenaue Daten.
Das ist der eigentliche Punkt:
Hotels brauchen nicht zwangsläufig mehr Daten.
Sie müssen besser an die kommen, die bereits da sind.
Bei Gästedaten gibt es allerdings einen ziemlich wichtigen Mitspieler:
die DSGVO.
Und sie sagt nicht:
Sammelt erstmal alles. Wir schauen später, wofür.
Zu den Grundprinzipien gehören unter anderem Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung sowie Integrität und Vertraulichkeit. Personenbezogene Daten dürfen also nicht einfach auf Vorrat für beliebige zukünftige Zwecke gesammelt werden.
Für Hotels bedeutet das:
Eine bessere Datenstrategie muss immer auch eine Datenschutzstrategie sein.
Es sollte klar sein:
Gerade eine zentrale Gästesicht macht Governance deshalb nicht unwichtiger.
Sondern wichtiger.
Denn je besser Daten verbunden werden können, desto sauberer müssen Zugriffsrechte, Zwecke und Verantwortlichkeiten geregelt sein.
Und dann wäre da noch KI.
Natürlich.
Hotelsysteme bekommen KI-Assistenten. Analysen werden automatisiert. Systeme sollen Fragen in natürlicher Sprache beantworten. Prozesse sollen selbstständig angestoßen werden.
Parallel entstehen mit Technologien wie dem Model Context Protocol (MCP) neue Möglichkeiten, KI-Systemen strukturierten Zugriff auf unterschiedliche Datenquellen und Funktionen zu geben.
Das macht die Frage nach einer sauberen Datenarchitektur noch wichtiger.
Denn eine KI kann zwar sehr schnell arbeiten.
Sie kann aber keine widersprüchliche Datenstruktur wegzaubern.
Wenn Anna Becker in drei Systemen drei verschiedene Profile besitzt, wird das Problem durch KI nicht automatisch kleiner.
Im schlimmsten Fall bekommt man die falsche Antwort nur schneller.
Deshalb gilt auch hier:
Erst Daten verstehen. Dann Systeme verbinden. Dann intelligent nutzen.
MCP, KI-Agenten oder neue Analysewerkzeuge ersetzen weder saubere Guest Identities noch definierte Datenquellen und Zugriffsrechte.
Sie erhöhen vielmehr den Wert einer gut aufgebauten Systemlandschaft.
Und machen eine schlechte schneller sichtbar.
Die gute Nachricht:
Für eine bessere Gästedatenstruktur muss nicht am Montagmorgen das PMS raus.
Und auch nicht automatisch eine CDP gekauft werden.
Der sinnvollere Start ist deutlich unspektakulärer.
Welche Systeme verarbeiten überhaupt Gästedaten?
Nicht nur die offensichtlichen.
PMS, CRS, CRM und Booking Engine sind schnell genannt.
Aber auch POS, Spa, Newsletter, Loyalty, Gästemessaging, Check-in oder andere Anwendungen können relevante Daten enthalten.
Für jedes System sollte geklärt werden:
Welche Gästedaten liegen dort?
Und:
Woher kommen sie?
So entsteht eine erste Datenlandkarte.
Welche Quelle gilt für welche Information?
Wo wird beispielsweise die primäre E-Mail-Adresse gepflegt?
Wo der Aufenthaltsstatus?
Wo Marketing-Einwilligungen?
Wo Präferenzen?
Wenn drei Systeme dieselbe Information verändern dürfen, wird Synchronisation schnell zum Mannschaftssport ohne Trainer.
Welche Systeme tauschen Daten aus?
In welche Richtung?
Wie häufig?
Welche Felder?
Was passiert bei Änderungen?
Was passiert bei Fehlern?
Unser Guide zu Hotelsoftware und Systemarchitektur setzt genau hier an: Erst Prozesse und bestehende Systemlandschaft verstehen, dann Anforderungen definieren und erst anschließend über neue Technologie entscheiden.
Wie viele Dubletten existieren?
Woran erkennt das System denselben Gast?
Welche Regeln gelten beim Zusammenführen?
Wie werden unterschiedliche E-Mail-Adressen, Namen oder Telefonnummern behandelt?
Das ist häufig der Punkt, an dem aus einem vermeintlichen „Reportingproblem“ plötzlich ein Datenqualitätsproblem wird.
Was soll am Ende besser funktionieren?
Zum Beispiel:
Wiederkehrende Gäste erkennen.
Gesamtumsatz pro Gast verstehen.
Direktbucher besser identifizieren.
Marketing sauber segmentieren.
Informationen hausübergreifend nutzen.
KI-Anwendungen kontrolliert auf Daten zugreifen lassen.
Erst wenn dieses Ziel klar ist, lässt sich beurteilen, welche Architektur und welche Technologie dafür gebraucht werden.
Vielleicht fehlt tatsächlich ein CRM.
Vielleicht eine CDP.
Vielleicht eine Integrationsplattform.
Vielleicht muss das bestehende PMS anders konfiguriert werden.
Vielleicht fehlt nur eine Schnittstelle.
Vielleicht sind die Schnittstellen vorhanden und die Daten schlicht schlecht gepflegt.
Oder fünf Systeme tun bereits alles, was benötigt wird – nur bislang nicht miteinander. Auch das kommt vor. Mehr Software löst eben selten automatisch ein Softwareproblem. Und ein Datenproblem erst recht nicht.
Hotels besitzen heute eine enorme Menge an Gästedaten.
Das PMS kennt den Aufenthalt.
Die Booking Engine die Direktbuchung.
Das CRM die Kommunikation.
Das POS den Restaurantbesuch.
Andere Systeme kennen weitere Teile der Reise. Das Problem beginnt, wenn aus diesen Teilen kein Zusammenhang entsteht. Dann gibt es zwar viele Daten. Aber wenig Wissen.
Eine gute Gästedatenstrategie versucht deshalb nicht, möglichst alles an einem Ort abzuladen. Sie schafft eine Struktur, in der klar ist:
Welche Daten existieren?
Wo entstehen sie?
Welches System ist dafür verantwortlich?
Welche Informationen gehören zum selben Gast?
Wo müssen Daten verfügbar sein?
Und wofür werden sie überhaupt gebraucht?
Erst danach kommen CRM, CDP, Single Customer View, KI und der ganze Rest des Abkürzungsregals.
Das klingt weniger spektakulär als „360° AI-powered Guest Experience Platform“.
Funktioniert aber vermutlich besser.