Kundenbindung jenseits der Stempelkarte

Die meisten Kundenbindungsprogramme im Gastgewerbe sind reine Vanity Metrics.

Die Struktur ist bekannt. Ein Kunde tritt dem Programm bei. Der Kunde sammelt Punkte oder Stempel für seine Ausgaben. Irgendwann löst der Kunde eine Belohnung ein. Das Programm meldet Mitgliederwachstum, Einlösungsraten und eine Steigerung der durchschnittlichen Ausgaben. Der Vorstand genehmigt weitere Investitionen. Das Programm wird fortgeführt.

Das Problem ist, dass fast keines dieser Programme tatsächlich das Verhalten fördert, von dem seine Wirtschaftlichkeit abhängt. Mitglieder geben ungefähr genauso viel aus wie Nicht-Mitglieder. Die Einlösungsrate ist niedrig, weil das Sammeln von genügend Punkten für eine sinnvolle Prämie länger dauert, als Mitglieder zu warten bereit sind. Die „exklusiven Angebote“, die an Mitglieder gesendet werden, sind in Wahrheit gar nicht exklusiv: Es sind dieselben Angebote, die das Marketingteam öffentlich bewirbt. Das Stufensystem ist rein theatralisch: Die meisten Betreiber verfügen über Daten, die zeigen, dass „Gold-Mitglieder“ bei gleicher Besuchsfrequenz genauso viel ausgeben wie „Silber-Mitglieder“.

Das ist kein Scheitern der Strategie. Es ist ein Scheitern der Datenintegration. Echte Kundenbindung erfordert, dass sich die Daten an einem einzigen Ort befinden – und in den meisten Gastronomie-Software-Stacks ist das nicht der Fall.

Warum fragmentierte Stacks bei der Kundenbindung strukturell schlechtere Ergebnisse liefern

Die Performance von Kundenbindungsprogrammen hängt von der Zuverlässigkeit dreier Integrationen ab: der Integration zwischen dem POS und dem Kundenbindungssystem (damit Punkte im Moment des Kaufs korrekt berechnet werden), der Integration zwischen dem Kundenbindungssystem und dem CRM (damit die Segmentierung stufengerechte Angebote ansteuern kann) und der Integration zwischen dem Kundenbindungssystem und der Marketingplattform (damit getriggerte Kommunikationen bei Kundenbindungsereignissen korrekt ausgelöst werden).

In einem fragmentierten Stack sind alle drei Integrationen auf eine Weise unzuverlässig, die der Kundenbindungsanbieter nicht kontrollieren kann.

Die POS-Integration erfolgt in der Regel über einen nächtlichen Batch-Prozess. Ein Kunde tätigt am Freitagabend einen Kauf. Die Punkte erscheinen am Samstagmorgen, manchmal erst am Sonntag, im Kundenbindungssystem. Der Kunde öffnet seine App, sieht die Ausgaben von gestern nicht berücksichtigt, geht davon aus, dass das System fehlerhaft ist, und verliert das Vertrauen in das Programm. Das Vertrauen in ein Kundenbindungsprogramm ist jedoch die einzige Voraussetzung dafür, dass es tatsächlich zu wiederholten Besuchen anregt. Ist das Vertrauen erst einmal zerstört, wird das Programm zum reinen Dekorationsobjekt.

Die CRM-Integration ist üblicherweise eine Einweg-Synchronisation: Kundenbindungsdaten fließen in das CRM, aber die Verhaltensdaten des CRM (Browserverlauf, E-Mail-Engagement, Support-Tickets) fließen nicht zurück in das Kundenbindungssystem. Dadurch ist die Kundenbindungssegmentierung mangelhaft: Sie kann nach Ausgabenstufe segmentieren, nicht aber nach „Mitgliedern, die seit 60 Tagen nicht mehr zu Besuch waren UND unsere letzten drei E-Mails geöffnet haben“.

Die Marketing-Integration ist am anfälligsten. Ein Kundenbindungsereignis (Erreichen eines Punktestands-Schwellenwerts, Stufen-Upgrade, ablaufende Prämie) muss eine Marketing-Kommunikation auslösen. Der Trigger wird im Kundenbindungssystem ausgelöst. Die Integration leitet ihn an die Marketingplattform weiter. Die Marketingplattform plant den Versand. Schlägt ein beliebiger Schritt fehl (und im Laufe eines Jahres passiert das garantiert), wird die Kommunikation nicht versendet, das Mitglied löst nichts ein und die Einlösungsquote – die einzige Kennzahl, die für den ROI des Programms entscheidend ist – leidet darunter.

All dies ist eine direkte Folge der Architektur. Der fragmentierte Stack verursacht das Performance-Problem bei der Kundenbindung. Selbst der fortschrittlichste Kundenbindungsanbieter kann dies nicht kompensieren.

Was eine vereinheitlichte Architektur für die Mathematik der Kundenbindung bedeutet

Wenn die Kundenbindung in derselben Datenbank angesiedelt ist wie POS, CRM, Marketing und Buchungen, lösen sich die architektonischen Gründe für die unzureichende Performance auf.

Punkte werden atomar innerhalb der POS-Transaktion berechnet. Die Kasse schließt die Bestellung ab. Innerhalb derselben Datenbanktransaktion aktualisiert die Loyalty-Engine den Punktestand in einem einzigen Alles-oder-Nichts-Schritt und prüft, woher jede Gutschrift stammt, damit derselbe Kauf niemals doppelt gezählt wird. Der Kontostand des Kunden aktualisiert sich noch vor dem Ausdrucken des Belegs. Der Trigger für die gesammelten Punkte wird aus derselben Transaktion heraus ausgelöst.

Es gibt keine Latenz. Es gibt keine Integration. Es besteht keine Möglichkeit, dass die Bestellung abgeschlossen wird, die Punkte aber nicht ankommen. Die App des Kunden zeigt den neuen Kontostand innerhalb von Sekunden nach dem Verlassen des Lokals an. Vertrauen in das Programm entsteht durch Genauigkeit – und die Architektur macht Ungenauigkeiten unmöglich.

Die CRM-Segmentierung ist ebenfalls vereinheitlicht. „Mitglieder, die seit 60 Tagen nicht mehr zu Besuch waren und unsere letzten drei E-Mails geöffnet haben“ ist eine einzige Abfrage über Kundenbindungsmitgliedschaft, Buchungen und E-Mail-Interaktionsverlauf hinweg. Keine Integration. Kein Datenverlust. Die Segmentierung kann jedes beliebige Feld aus jedem operativen System einbeziehen, da sich alle operativen Systeme in derselben Datenbank befinden.

Die Marketing-Trigger werden direkt aus den Kundenbindungsereignissen heraus ausgelöst. Gesammelte Punkte, der Aufstieg eines Mitglieds in eine höhere Stufe, eine eingelöste Prämie, eine automatisch ausgestellte Prämie, eine erfolgreiche Empfehlung, kurz vor dem Verfall stehende Punkte, der Geburtstag eines Mitglieds: Jedes dieser Ereignisse ist ein primärer Trigger, der von der Flow-Engine genutzt werden kann. Die E-Mail über ablaufende Prämien wird genau dann versendet, wenn die Punkte tatsächlich verfallen – nicht erst beim nächsten nächtlichen Batch-Lauf.

Der Wandel von Punkteprogrammen zu CLV-Kohorten

Die tiefgreifendere Chance, die eine vereinheitlichte Kundenbindung eröffnet, liegt nicht nur in der besseren Ausführung des bestehenden Programms. Es ist ein grundlegender Wandel in dem, was Kundenbindungsprogramme messen können.

In den meisten Gastronomiegruppen berichtet das Kundenbindungsprogramm über Programm-Kennzahlen: registrierte Mitglieder, gesammelte Punkte, Einlösungsquote, durchschnittliche Ausgaben pro Mitglied. Diese Kennzahlen beschreiben die Aktivität des Programms. Sie beschreiben jedoch nicht dessen Auswirkungen auf das Geschäft.

Die Kennzahl, auf die es wirklich ankommt, ist der Customer Lifetime Value im Zeitverlauf. Konkret: Wie viel mehr gibt ein Mitglied über alle Besuche hinweg über mehrere Jahre hinweg bei uns aus im Vergleich zu einem ähnlichen Nicht-Mitglied? Das ist die Frage, die jeder CFO zu jedem von ihm finanzierten Kundenbindungsprogramm beantwortet haben möchte. In einem fragmentierten Stack ist sie unbeantwortbar: Die erforderlichen Daten erstrecken sich über zu viele Systeme für eine verlässliche Kohortenanalyse.

In mDOS summiert ein vorberechneter Lifetime-Value-Snapshot die POS-Ausgaben jedes Gastes auf (die Erweiterung des Snapshots auf Ausgaben für Unterkunft, Gastronomie, OTA und Channel-Manager steht auf der Reporting-Roadmap; das vereinheitlichte Gästeprofil führt diese Datenströme bereits für denselben Gast, sodass es sich um eine Aggregationsänderung und nicht um ein Integrationsprojekt handelt). Der Schwellenwert des 75. Perzentils identifiziert „Kunden mit hohem LTV“ als abfragbares Segment. Das Produkt-Affinitäts-Reporting stellt anschließend die Fragen: Was sind die beliebtesten Artikel, die von Kunden mit hohem LTV bestellt werden? Welche Gerichte korrelieren mit Wiederholungsbesuchen? Welche Standorte binden Kunden am besten? Welche Marketing-Flows konvertieren Kunden in die Kohorte mit hohem LTV?

Das sind andere Fragen als „Wie viele Punkte haben wir letzten Monat vergeben?“. Es sind die Fragen, die verändern, wie ein Treueprogramm finanziert, gestaltet und bewertet wird. Das Programm hört auf, eine reine Punkte-Engine zu sein, und wird zu einer CLV-Engine – und die Aufgabe des Marketingteams wandelt sich von „Neuanmeldungen steigern“ zu „Kohortenentwicklung fördern“.

Wie das in der Praxis aussieht

Für einen Commercial Director, der eine Gruppe mit mehreren Marken leitet, verändert eine vereinheitlichte Loyalty-Lösung die operative Realität auf konkrete Weise.

Das Produkt-Affinitäts-Reporting zeigt ihnen, welche Menüpunkte Kunden mit hohem LTV tatsächlich bestellen. Diese Daten fließen direkt in das Menu-Engineering ein: Der F&B Director weiß genau, welche Gerichte hervorgehoben, welche gestrichen und welche in kommenden Kampagnen beworben werden sollten. Entscheidungen werden auf der Grundlage des tatsächlichen Kohortenverhaltens getroffen – nicht nach Bauchgefühl.

Die an den CLV gekoppelte Segmentierung ermöglicht es dem Marketingteam, Flows zu erstellen, die gezielt auf bestimmte Kohortenentwicklungen ausgerichtet sind. Ein Flow, der sich an „Kunden richtet, die in den letzten 90 Tagen zweimal zu Besuch waren und mehr als den Median ausgegeben haben“, kann diesen einen gezielten Anreiz bieten, um sie in die Kohorte mit hohem LTV zu heben. Der Flow läuft kontinuierlich. Der Effekt verstärkt sich exponentiell.

Der Trigger für das Stufen-Upgrade wird in dem Moment ausgelöst, in dem ein Kunde einen Schwellenwert überschreitet. Die Glückwunsch-Kommunikation trifft also noch in derselben Schicht ein, in der der Kunde das Ziel erreicht hat – und nicht erst drei Tage später, wenn die Batch-Synchronisierung nachzieht. Der emotionale Moment wird genutzt. Der Kunde fühlt sich wertgeschätzt.

Der Trigger für ablaufende Prämien wird zuverlässig ausgelöst, da es sich um ein Datenbank-Ereignis und nicht um eine Integration handelt. Mitglieder, die ihre Prämien noch nicht eingelöst haben, erhalten den Anstoß zum richtigen Zeitpunkt. Die Einlösungsraten steigen messbar an.

Treuepunkte-Dispute sinken auf null: Es gibt keinen Zustand, in dem eine Bestellung existiert, die Punkte jedoch nicht – es gibt also nichts zu beanstanden. Der Kundenservice gewinnt die Stunden zurück, die zuvor mit der Nachforschung von Punkte-Diskrepanzen verbracht wurden. Das Personal muss sich nicht mehr für das Programm rechtfertigen. Das Programm wird vertrauenswürdig – und das ist die Grundvoraussetzung für alles Weitere.

Die Firmenkunden-Dimension

Für Betreiber mehrerer Standorte mit B2B-Umsätzen (die meisten Pub-Gruppen, Hotelgruppen und Restaurantketten in Innenstadtlagen) muss das Loyalty-Modell über einzelne Mitglieder hinaus auf Firmenkonten ausgeweitet werden. Unternehmen, die regelmäßig buchen, müssen ebenfalls Werte ansammeln können: Verpflegungspauschalen, Übernachtungen, Veranstaltungspakete, Firmen-Punktepools.

mDOS löst dies über Firmen-Punktepools, die die Aktivitäten einzelner Mitglieder in einem gemeinsamen Unternehmensguthaben bündeln. Ein Mitglied des Kontos von Acme Corp sammelt bei seinem Aufenthalt Punkte; diese werden sowohl seinem persönlichen Guthaben als auch dem Firmenpool gutgeschrieben. Der Administrator des Firmenkontos kann anschließend im Namen jedes Mitglieds Punkte aus dem Pool einlösen oder das Poolguthaben bestimmten Veranstaltungen oder Aufenthalten zuweisen.

Das ist die Art von Funktion, die veraltete Treueplattformen entweder gar nicht unterstützen oder nur als umständliche Zusatzlösung anbieten. In mDOS ist dies eine Kernfunktion, da das Firmenkonto, das einzelne Mitglied, die Buchung und das Loyalty-Hauptbuch in derselben Datenbank liegen. Der Beziehungsgraph ist abfragbar, die Zuordnungslogik ist klar strukturiert und das Audit-Log ist vollständig.

Was das für den CFO bedeutet

Ein CFO, der ein Treueprogramm finanziert, wünscht sich drei Dinge: vertrauenswürdige Daten zur Programmperformance, Nachweise darüber, dass das Programm zusätzlichen Umsatz generiert, und eine operative Disziplin, die verhindert, dass das Programm zu einer Stornobelastung oder Buchhaltungsverbindlichkeit wird.

Eine vereinheitlichte Loyalty-Lösung liefert alle drei.

Die Performancedaten sind vertrauenswürdig, da es keine Integrationsabweichungen gibt. Die Loyalty-Zahlen im Dashboard sind identisch mit den vom POS erfassten Zahlen. Die Kohortenanalyse ist verlässlich, da die LTV-Werte direkt aus dem POS-Hauptbuch stammen, in dem die Ausgaben des Kunden verbucht wurden – ohne Integrationsabweichungen zwischen den Kassendaten und dem Dashboard-Bericht. Der Buchhaltungsabgleich ist sauber, da jeder ausgegebene und jeder eingelöste Punkt in einem einzigen Hauptbuch mit vollständigem Audit-Log geführt wird.

Für Käufer, die mDOS als IP bewerten, ist die Loyalty-Architektur ein klares Zeichen für technische Präzision. Die meisten Hospitality-SaaS-Lösungen behandeln Treueprogramme als Peripheriesystem: eine einfache Bearbeitungsmaske für eine Punkteliste mit begrenzter Geschäftslogik. mDOS behandelt sie als transaktionale Kernfunktion mit denselben Atomizitätsgarantien wie die Payment-Engine. Die Tiefe an dieser Stelle lässt auf die Tiefe im gesamten System schließen.

---

Die Loyalty-Engine läuft atomar innerhalb der POS-Transaktion mit vollständiger CLV-Kohortenanalyse. Technische Dokumentation unter gegenseitiger Vertraulichkeitsvereinbarung (NDA) erhältlich.