23 Touchpoints, ein System
Die digitale Guest Journey durch eine vereinheitlichte Hospitality-Architektur – und warum die über 150 Trigger dahinter in fragmentierten Stacks nicht existieren können.

Dieser Artikel verfolgt eine einzelne Gästin (die 38-jährige Marketingleiterin Sarah, die ein langes Wochenende in einem Landhotel für den Hochzeitstag ihrer Eltern plant) durch dreiundzwanzig verschiedene digitale Berührungspunkte mit einem Gastronomie- und Hotelbetreiber. Vom ersten Google-Suchaufruf bis zur Bewertungsanfrage nach dem Aufenthalt wird jede Interaktion im selben kanonischen Gästeprofil erfasst, jedes Verhaltenssignal fließt in die nächste Entscheidung ein und jedes betriebliche Ereignis kann einen Marketing-Trigger auslösen, wenn der Betreiber dies entsprechend verknüpft.
Der entscheidende Punkt ist nicht die Journey selbst. Der entscheidende Punkt ist, dass jeder Touchpoint auf Daten aus einem anderen betrieblichen System angewiesen ist – und die gesamte Journey nur zusammenhält, weil all diese Systeme auf eine einzige Datenbank zugreifen.
In einem fragmentierten System-Stack platzt die Customer Journey aus allen Nähten. Sarah wird an Touchpoint 6 wie eine Neukundin behandelt, an Touchpoint 14 erneut und an Touchpoint 19 wieder. Ihre Präferenzen werden nicht gespeichert. Ihr Treuestatus begleitet sie nicht. Ihre Marketing-Einwilligung muss erneut eingeholt werden. Das operative Personal hat keinerlei Kontext. Das Marketing-Team hat keine Attribution. Achtzehn der dreiundzwanzig Touchpoints bleiben operativ im Dunkeln.
In einer einheitlichen Architektur bleibt jeder Touchpoint sichtbar. So sieht das in der Praxis aus.
Touchpoints 1–10: Vor der Anreise
Touchpoint 1: Sarah googelt „Cotswolds hotels with private dining for 8“. Sie landet auf einer Landingpage des Betreibers. Das CMS ist auf derselben Plattform angesiedelt wie alles andere. Die angezeigte Seite wird dynamisch gerendert, wobei die Verfügbarkeit für ihre Reisedaten live aus dem PMS abgerufen wird. Es gibt kein Buchungs-Widget eines Drittanbieters, das sie auf eine andere Domain umleitet.
Touchpoint 2: Bei einem ersten Besichtigungsbesuch zwei Wochen zuvor verbindet sie sich mit dem WLAN der Location (ihre Eltern wohnen in der Nähe, sie war auf einen Kaffee vorbeigekommen). Das Captive Portal erkennt ihre E-Mail-Adresse (dasselbe Gästeprofil), woraufhin ein Trigger für die erste WLAN-Anmeldung ausgelöst wurde, der sie in einen unverbindlichen Nurture-Workflow über die Location aufgenommen hat. Sie weiß davon nichts. Sie erinnert sich nur daran, dass ihr der Ort gefallen hat.
Touchpoint 3: Sie füllt das Anfrageformular für Private Dining auf der Website aus. Der Trigger für Raumanfragen wird ausgelöst. Die Event-Koordination der Location erhält eine Benachrichtigung. Sarah erhält eine automatische Bestätigungs-E-Mail mit der Private-Dining-Broschüre als PDF im Anhang – automatisch angefügt, weil das Formular direkt mit der Dokumentenbibliothek der Location verknüpft ist. Gesamte Latenz vom Absenden des Formulars bis zur Zustellung der E-Mail: unter 30 Sekunden.
Touchpoint 4: Zwei Stunden später sendet die Event-Koordination Sarah persönlich ein Angebot per E-Mail. Die E-Mail wird direkt aus dem zentralen mDOS-Posteingang versendet. Die Antwort landet im selben Thread. Der Thread ist mit Sarahs Kontaktprofil verknüpft. Der Deal wird automatisch mit der Phase „Anfrage: Angebot erstellt“ angelegt.
Touchpoint 5: Sarah nimmt das Angebot an und bucht acht Plätze im Private-Dining-Bereich für Samstagabend. Die Buchung wird in ihrem Kontaktprofil erfasst. Die Anzahlung wird über Stripe Connect auf dem verbundenen Konto der Location eingezogen. Der Trigger für die bezahlte Raum-Anzahlung löst aus und nimmt Sarah in einen Nurture-Workflow vor dem Event auf: Menübestätigung 7 Tage vorher, Formular für Ernährungsbedürfnisse 5 Tage vorher, Wein-Vorauswahl durch den Sommelier 3 Tage vorher, Anreiselogistik 1 Tag vorher. Keine dieser E-Mails wird manuell verfasst oder gesendet. Sie laufen automatisch, weil der Workflow vor sechs Monaten einmal eingerichtet wurde und nun für jede Private-Dining-Buchung im gesamten Anwesen ausgeführt wird.
Touchpoint 6: Drei Wochen vor dem Event bucht Sarah Zimmer für sich und ihre Eltern für dieselbe Nacht. Das Buchungs-Widget erkennt ihre E-Mail-Adresse (dasselbe Gästeprofil) und füllt Name, Telefonnummer und Adresse automatisch aus. Sowohl ihre PMS-Buchung als auch ihre bestehende Private-Dining-Buchung werden demselben kanonischen Kontaktprofil zugeordnet. So sieht das Team beide Buchungen zusammengeführt bei einem Gast, und ihre Ernährungspräferenzen aus dem Event-Formular sind für das F&B-Team sichtbar. Sie erhält eine einzige Bestätigungs-E-Mail mit allen Informationen statt drei E-Mails von drei verschiedenen Anbietern.
Touchpoint 7: Zwei Wochen vorher vergisst Sarah, das Formular für Ernährungsbedürfnisse auszufüllen. Der Trigger für das abgesendete Formular, der eigentlich auslösen sollte, bleibt aus. Stattdessen wird 10 Tage vor dem Event ein separater Inaktivitäts-Trigger im Event-Workflow ausgelöst. Sarah erhält eine freundliche Erinnerungs-E-Mail: „Kurze Nachfrage: Haben Ihre Gäste Allergien oder spezielle Ernährungsbedürfnisse, die wir berücksichtigen sollten?“ Sie klickt auf den Link, füllt das Formular aus, und der Workflow wird fortgesetzt.
Touchpoint 8: Eine Woche vorher bricht sie eine Buchung in einem legeren Schwesterrestaurant ab, das sie am Freitagabend vor dem Jubiläumsessen ebenfalls besuchen wollte. Sie war gerade dabei, Gerichte für eine Vorbestellung auszuwählen, wurde durch einen geschäftlichen Anruf abgelenkt und schloss den Tab. Der Trigger für abgebrochene Buchungen wird ausgelöst. Fünfundvierzig Minuten später erhält sie eine E-Mail: „Ihr Tisch im [venue] ist noch für Sie reserviert. Nur ein Klick zum Bestätigen.“ Ein-Klick-Link. Sie bestätigt.
Touchpoint 9: Drei Tage vorher trifft die E-Mail für die Sommelier-Vorauswahl ein. Sie wählt drei Weine aus einer zusammengestellten Liste aus. Ihre Auswahl wird als Vorbestellung für das Event gespeichert – genau die Liste, auf die Küche und Bar am Abend zugreifen. Die Weinvorschläge des Sommeliers in Sarahs E-Mail wurden auf Weine gefiltered, die diese Woche in dieser Location tatsächlich auf Lager sind – abgerufen aus demselben Warenwirtschaftssystem, das auch der Bar-Manager für Bestellungen nutzt.
Touchpoint 10: Einen Tag vorher trifft die E-Mail mit den Anreiselogistik-Informationen ein. Anfahrtsbeschreibung. Check-in-Zeit. WLAN-Passwort. Tischreservierungsbestätigung. Lage des Private-Dining-Raums. Jubiläumsmenü als PDF (gesendet, weil Sarah bei der ursprünglichen Anfrage „Besonderen Anlass feiern“ angekreuzt hatte, was einen Tag gesetzt und diesen Workflow bedingt hat). Alles in einer einzigen E-Mail im Design der Location, unterzeichnet vom General Manager.
Touchpoints 11–19: Der Aufenthalt und die Zeit danach
Touchpoint 11: Sarah trifft am Samstag um 15:00 Uhr ein und checkt ein. Der Check-in wird in der Datenbank erfasst. Ihr Check-in löst autonom zwei Vorgänge aus: den Willkommens-Flow (eine Nachricht mit ihrem Namen, wobei ihre Zimmerpräferenzen aus einem früheren Aufenthalt für das Team bereits in ihrer Akte hinterlegt sind) und den Spa-Upsell-Trigger: „Sie bleiben zwei Nächte bei uns. Möchten Sie für morgen Früh die Paarmassage dazubuchen?“ Sarah bucht die Behandlung über den Link in der Nachricht. Die Buchung wird als Zusatzleistung auf der Rechnung direkt im PMS verbucht.
Touchpoint 12: Die Reservierung für ein entspanntes Abendessen am Freitagabend findet im Schwesterbetrieb statt. Die Kasse stellt die Mahlzeit auf Sarahs Kontaktkonto aus. Der Trigger für abgeschlossene Kassenbestellungen wird ausgelöst. Treuepunkte werden atomar innerhalb derselben Transaktion wie die Rechnungsbegleichung berechnet und gutgeschrieben. Ihr Treuestatus steigt von Silber auf Gold. Der Trigger für das Treuestufen-Upgrade wird ausgelöst und nimmt sie in einen Upgrade-Flow auf, der am Sonntagmorgen zugestellt wird.
Touchpoint 13: Die Flasche Châteauneuf beim Private Dining am Samstagabend löst den Trigger für Käufe nach Kategorie für Wein aus. Lesen Sie mehr dazu in unserem Artikel zur Weinempfehlung.
Touchpoint 14: Sarah checkt am Sonntag um 11:00 Uhr aus. Der Check-out-Trigger wird ausgelöst. Die Rechnung wird beglichen und der Beleg automatisch per E-Mail versendet. Die Bewertungsanfrage nach dem Aufenthalt wird nicht sofort gesendet: Der Flow ist so konfiguriert, dass er erst +48 Stunden nach dem Check-out verzögert ausgelöst wird – zu einem Zeitpunkt, an dem die meisten Gäste emotional bereit sind, eine aussagekräftige Bewertung zu verfassen, anstatt einer überstürzten auf dem Parkplatz. Diese Entscheidung hat das Marketingteam auf der Grundlage von Analysen zur Bewertungs-Antwortquote aus den plattformeigenen Daten getroffen.
Touchpoint 15: Am Dienstagmorgen trifft Sarahs Bewertungsanfrage ein. Sie klickt sich durch zum plattformeigenen Bewertungsformular. Sie bewertet den Aufenthalt mit 5 Sternen. Der Trigger für positive Bewertungen wird ausgelöst. Sie qualifiziert sich nun für den Empfehlungs-Flow – den Flow für Rabatte auf den nächsten Aufenthalt bei Weiterempfehlung an Freunde, den das Marketingteam vor sechs Monaten erstellt hat.
Touchpoint 16: Am Mittwoch trifft die Weinempfehlungs-E-Mail ein.
Touchpoint 17: Sarahs Eltern (die noch nie mit dem Marketingsystem des Betriebs interagiert haben) erhalten eine Dankes-E-Mail vom General Manager. Die Event-Koordination hat diese manuell im zentralen Posteingang verfasst, adressiert an die namentlich genannten Gäste der Buchenden, da deren Daten an Touchpoint 7 erfasst wurden. Die Eltern sind nun als eigene Kontaktakten im CRM angelegt und derselben Buchung zugeordnet. Zukünftige Flows können sie mit entsprechender Einwilligung erreichen.
Touchpoint 18: Zwei Monate später steht der Geburtstag von Sarahs Vater bevor. Der Geburtstags-Trigger für Treuemitglieder wird ausgelöst (er wurde an Touchpoint 17 über eine implizite Registrierung mit Marketing-Einwilligung zum Treueprogramm hinzugefügt). Er erhält eine Geburtstags-E-Mail mit einem seinem Treuestatus entsprechenden Angebot für einen erneuten Aufenthalt.
Touchpoint 19: Er bucht. Der gesamte Kreislauf beginnt von vorn – diesmal weiß der Betrieb bereits Bescheid über die Familie, die Zimmerpräferenzen, die Ernährungsbedürfnisse und den Weingeschmack.
Touchpoints 20–23: Die operative Ebene
Die Touchpoints 20 bis 23 sind operative Trigger, die lautlos im Hintergrund ablaufen und Sarah nie direkt erreichen, aber jede Interaktion des Personals mit ihr verbessern: Der Nachtabschluss wird gesperrt, um die Bücher fertigzustellen; eine Wartungsanfrage aufgrund ihrer Anmerkung zu einer undichten Dusche wird für das Zimmer erfasst und vor der Ankunft des nächsten Gastes behoben; eine Concierge-Anfrage aufgrund ihrer Bitte um eine Restaurantreservierung in der Nähe; und die Erstellung eines Firmenkontos, da ihr Unternehmen den Betrieb nun bereits zum vierten Mal genutzt hat und ein Firmentarif eingerichtet wird.
Was diese Guest Journey beweist
Die obige Journey umfasst dreiundzwanzig Touchpoints. Sie nutzt sechzehn verschiedene Trigger von den mehr als 150, die in der mDOS-Flow-Engine integriert sind. Kein einzelner Touchpoint ist exklusiv für mDOS. Jeder Betreiber könnte theoretisch jeden einzelnen davon in einem fragmentierten Systemverbund mit entsprechendem Integrationsaufwand aufbauen.
Das Einzigartige an mDOS ist, dass alle dreiundzwanzig Touchpoints von Anfang bis Ende mit demselben zentralen Gästedatensatz verknüpft bleiben, dass die Daten, von denen jeder Touchpoint abhängt, in derselben Datenbank nur eine Abfrage entfernt sind und dass die Flows, die die Journey steuern, vom Marketingteam in der Benutzeroberfläche der Plattform erstellt und angepasst werden können – ganz ohne Integrationsagentur.
Das ist gemeint mit „eingebettet in die operativen Realitäten des Betriebs“. Die Marketing-Engine ist nicht nachträglich an die operativen Systeme angeflanscht. Sie ist Teil von ihnen. Jedes operative Ereignis ist ein Marketing-Trigger, der darauf wartet, verknüpft zu werden. Jeder Marketing-Trigger ist ein operatives Ereignis, das bereits in der Datenbank existiert.
Die 150+ Trigger sind die Oberfläche. Die einheitliche Datenbank ist das, was diese Oberfläche erst möglich macht.
Sprechen Sie mit dem Gründer darüber, wie sich die Architektur in Ihr Portfolio einfügt.
Erleben Sie mDOS mit Ihrem eigenen Unternehmen
Ein 30-minütiges Gespräch mit einem unserer Experten, genau darauf ausgerichtet, was Sie zuerst lösen möchten.
About the author
Ross Crawford is the founder of Mr Digital and mDOS, and a Fellow of the Chartered Institute of Marketing (FCIM).
- Fellow of the Chartered Institute of Marketing (FCIM)


