Unique customer ID
Von José Manuel Maseda · Veröffentlicht am 27. Juli 2026
Der CMO sagt Ihnen überzeugt: Wir haben ein Kundenbindungsprogramm, und es funktioniert. Punkte, eine Karte, gestaffelte Rabatte, das Übliche. Anscheinend ist alles in Ordnung. Dann stellen Sie eine ganz einfache Frage: Kann der Kunde, der im Geschäft Punkte sammelt, seinen Kontostand in der App sehen? Meist gibt es darauf keine Antwort. Es ist nicht so, dass das Programm kaputt wäre. Es funktioniert nur an einem der Orte, an denen der Kunde einkauft, und heute beschränkt sich fast niemand mehr auf einen einzigen Vertriebskanal. Eine Karte, die im Geschäft lebt, aber auf der Website nicht existiert, oder umgekehrt, was ebenfalls vorkommt, ist wahrscheinlich der häufigste Fehler im mittelständischen Einzelhandel. Und der am schwersten rechtzeitig zu erkennende, weil er in keinem Bericht auftaucht, bis jemand beschließt, in Ruhe wirklich hinzusehen, was vor sich geht. Dies ist der erste Fall der Serie Kundenbindungs-Autopsie: die Diagnose, die tatsächliche Ursache und das Rezept dafür, warum Ihr Programm in zwei Hälften gespalten ist, ohne dass das jemals jemand bewusst so entschieden hätte. Denn letztlich entwirft niemand ein Programm, das nur die Hälfte der Zeit funktioniert.
Stellen Sie sich einen Stammkunden einer Modekette vor. Zwei Jahre lang sammelt er im Geschäft Punkte. Physische Karte, Mitgliedsnummer, das vage, aber reale Gefühl, dort etwas angespart zu haben. An einem beliebigen Sonntag kauft er auf der Website ein, gelangt zur Kasse, und vom Guthaben ist keine Spur. Er öffnet die App, und auch dort ist nichts. Er ruft den Kundenservice an, und der Mitarbeiter kann ihm nicht wirklich helfen, weil diese Daten nur in der Kasse des stationären Geschäfts liegen. Faktisch hat dieser Kunde zwei Kundenbindungsprogramme desselben Händlers, die nicht miteinander sprechen. Eines für das Geschäft und ein anderes, deutlich ärmeres, für alles andere. Und dieses „alles andere“ ist Jahr für Jahr dort, wo er am meisten ausgibt.

Das ist eigentlich nichts Neues. Es gibt einen bekannten Vorläufer: Die klassische Kundenkarte, mit Stempeln und Rabatt an der Kasse, hat nie die gesamte Aktivität eines Kunden erfasst.
30-40 %
der Transaktionen war das Höchste, was eine klassische Kundenkarte je erfassen konnte; der Rest blieb unverfolgt, ohne Namen und ohne Möglichkeit zur Nachverfolgung.
Das heutige Punkteprogramm erbt dieselbe Grenze, mit einer Wendung: Der unsichtbare Kanal ist nun nicht mehr „das, was nie erfasst wurde“, sondern „das, was am falschen Ort erfasst wurde“. Der Kunde sammelt durchaus Punkte, nur nicht dort, wo er sie später einlösen möchte. Und hier wird es interessant: Das Symptom taucht in keinem Verkaufs-Dashboard auf. Der Umsatz fließt weiter, das Programm wirkt lebendig, kein Alarm geht los. Das Problem wird erst sichtbar, wenn jemand die tatsächliche Beteiligung misst: wie viele eingeschriebene Kunden in den letzten zwölf Monaten etwas eingelöst haben und wie viele über mehr als einen Kanal gekauft haben. Dann stimmen die Zahlen plötzlich nicht mehr. Und das Seltsamste, wirklich überraschend, wenn man darüber nachdenkt: Niemand lügt dabei. Das Geschäft sieht das Programm funktionieren, weil es in diesem Kanal funktioniert. Der E-Commerce zählt es nicht einmal in seinen Kennzahlen, weil dieses Programm aus seiner Sicht schlicht nicht existiert: Es erscheint nicht an seiner Kasse und fließt nicht in seine Conversion-Zahlen ein. Jedes Team hat mit den Daten, die es verwaltet, recht, und genau das ist die Falle. Das Problem steckt in keinem einzelnen Bericht; es steckt in der Lücke zwischen den Berichten.
Die Ursache ist selten Nachlässigkeit; sie ist Architektur, und zwar eine alte. Das Kundenbindungsprogramm entstand bei den meisten Händlern als Modul des Kassensystems: als Zusatz zum POS-Terminal, um Punkte zu addieren, wenn jemand im Geschäft bezahlte. Damals ergab das völlig Sinn, weil fast das gesamte Geschäft dort ablief. Das Problem ist, dass sich das Geschäft verändert hat und das Programm stehen geblieben ist. Der E-Commerce kam, dann die App, dann WhatsApp als Kanal für Kauf und Support, und das Kundenbindungsmodul blieb genau dort, wo es entstanden ist: am POS. Das ist ein Konstruktionsfehler, kein Mangel an Absicht, und das sollte man klar sagen, weil es meist falsch herum gelesen wird. Niemand ist eines Morgens aufgewacht und hat beschlossen: „Belohnen wir nur Kunden im Geschäft.“ Schlicht, das System, das den Vorteil verwaltet, wurde nie dafür gebaut, mit dem Online-Checkout zu sprechen, und es nachträglich anzubinden, auf einem System, das dafür nicht vorgesehen war, erweist sich als teuer, langsam und oft nie wirklich sauber gelöst. Und hier stecken viele Händler jahrelang fest: Die „naheliegende“ Lösung, das bestehende Punktesystem manuell in den E-Commerce zu integrieren, bedeutet meist, an POS, ERP und der Preis-Engine des Onlineshops zu arbeiten. Es ist nicht so, dass niemand das beheben will. Es ist so, dass das auf diese Weise zu einem Projekt wird, das mit anderen, dringenderen Prioritäten um Budget und IT-Zeit konkurriert. Und währenddessen kommt die Lösung nie. Der eigentliche Paradigmenwechsel geht in eine andere Richtung: Der Vorteil wird nicht in einem isolierten Modul berechnet und angewendet, sondern durch Abfrage der Kundendaten in Echtzeit, genau im Moment der Zahlung, egal über welchen Kanal diese erfolgt. Wenn die Kundenbindung im transaktionalen Gateway an der Kasse lebt und nicht in einer Ecke des Kassensystems, spielt es keine Rolle mehr, ob der Kunde im Geschäft, im Web oder vom Smartphone aus bezahlt: Die Engine prüft dieselben Daten. Sie wendet an allen drei Orten denselben Vorteil an.

Der teuerste Teil dieses Fehlers ist nicht technisch, sondern betrifft das Vertrauen, und das ist ernster, als es klingt. Ein Kunde, der seinen Kontostand nicht abrufen kann oder feststellt, dass das, was er im Geschäft verdient hat, online wertlos ist, lernt schnell eine unbequeme Lektion: Auf dieses Programm ist kein Verlass, also rechnet man besser nicht damit. Er hört auf, seinen Kontostand zu prüfen, hört auf, den Vorteil zu erwarten, und das Unternehmen verliert genau das, was ein Kundenbindungsprogramm erzeugen soll: einen Grund zurückzukommen. Hinzu kommt, dass dieser Kunde schließlich den Kundenservice anruft, um etwas zu fragen, das er selbst klären können sollte. „Wie viele Punkte habe ich?“ sollte keinen Mitarbeiter am anderen Ende der Leitung erfordern. Und jedes Mal, wenn doch, entstehen Betriebskosten, die für das Kundenbindungsprogramm niemand eingeplant hat. Und dann sind da die Daten, der vielleicht unsichtbarste Schaden von allen. Wenn das Punktesystem getrennt vom Rest des Betriebs lebt, ist auch das Kundenverhalten auf zwei Datensätze verteilt, die nicht miteinander sprechen. Das Marketingteam kann nicht erkennen, ob derselbe Kunde, der im Geschäft kauft, auch online kauft, weil das System es buchstäblich nicht weiß. Und das trifft genau dort, wo es dem CMO am meisten wehtut: beim CLTV und bei der Marge. Wer den ganzen Kunden nicht sieht, kann nicht wissen, wie viel er wirklich wert ist oder welchen Bindungsaufwand er verdient. Ein Kunde, der über beide Kanäle kauft, kann in getrennten Berichten wie zwei durchschnittliche Kunden aussehen statt wie ein sehr guter, und Investitionsentscheidungen in die Kundenbindung, die mit diesem halben Bild getroffen werden, gehen fast zwangsläufig schief, so gut durchdacht die Strategie auf dem Papier auch wirken mag.
Die Lösung besteht nicht darin, sich mit dem aktuellen Programm „mehr anzustrengen“. Sie besteht darin, den Ort zu ändern, an dem die Kundendaten leben. Ein einheitliches Kunden-Wallet löst das Problem an der Wurzel: ein einziger digitaler Raum, der Guthaben, Historie und Vorteile des Kunden bündelt und aus verschiedenen Umgebungen zugänglich ist, integriert in die App des Händlers, in eine White-Label-App, über Apple Wallet oder Google Wallet mit Mobile Pass oder direkt im Browser, aber immer mit demselben Inhalt und derselben Erfahrung, in Echtzeit aktualisiert. In der Praxis bedeutet das, dass im Geschäft gesammelte Punkte im E-Commerce-Shop eingelöst werden können und umgekehrt, ohne Verzögerungen oder manuelle Synchronisierung, mit demselben Guthaben an jedem Kontaktpunkt, den der Kunde abrufen möchte. Wer früher anrief, um nach seinem Kontostand zu fragen, hat dieses Problem nicht mehr: Er kann ihn selbst abrufen, sofort, von wo es ihm am besten passt. Ein konkreter Fall: Ein Kunde kauft an einem Samstag im Geschäft ein und sammelt Punkte. Am Sonntag öffnet er vom Sofa aus die Website desselben Händlers und sieht dieses Guthaben aktuell in seinem Konto, keine Version von vor ein paar Tagen, sondern das echte. Er löst einen Teil dieser Punkte bei einem Online-Kauf ein. Das System zieht sie von diesem einen Guthaben ab, nicht von einer separaten Kopie. Wenn diese Person in der folgenden Woche wieder ins Geschäft geht, ist das Guthaben, das der Kassierer an der Kasse sieht, wiederum dasselbe. Es gibt keine „Geschäftsversion“ und keine „Webversion“ des Kunden. Es gibt einen Kunden mit einem Guthaben, von überall aus sichtbar. Und genau diese Kontinuität versteht ein Kunde unter „Mitglied in einem Kundenbindungsprogramm sein“. Das ist nicht viel verlangt. Es ist schlicht das Mindeste, was man von etwas erwartet, das diesen Namen trägt. Dafür müssen Sie nicht einmal das ERP oder die Preis-Engine des E-Commerce anfassen: Der Vorteil wird an der Kasse über ein Gateway berechnet und angewendet, indem die vorhandenen Daten im Moment der Zahlung geprüft werden. Das Marketing gewinnt Autonomie über das Programm, ohne von einem langen Integrationsprojekt abhängig zu sein, und das IT-Team muss nicht jedes Mal ein neues Entwicklungsticket öffnen, wenn sich eine Programmregel ändert. Und dafür braucht es nicht das einjährige Projekt, das viele Teams fürchten. Enterprise-Projekte mit CDP plus Kundenbindung bewegen sich typischerweise in Zyklen von 8 bis 18 Monaten. Eine Integration auf Basis einer einzigen Checkout-API dagegen bewegt sich in Wochen: Die meisten Fälle gehen in 4 bis 12 Wochen live, abhängig vom Kassen-Integrator des Händlers. Das ist kein weiteres Marketingversprechen. Es ist der Unterschied zwischen dem Neuschreiben des Kassensystems von Grund auf und dem Aufsetzen eines Gateways darüber.


Bevor Sie annehmen, dass das auf Sie nicht zutrifft, lohnt es sich, fünf konkrete Fragen zu stellen. Keine davon erfordert eine tiefgehende technische Analyse; sie lassen sich beantworten, indem man auf die reale Erfahrung des Kunden schaut, nicht auf das Produktdatenblatt des aktuellen Anbieters.
Wenn Sie bei einer dieser Fragen nachdenken müssen, statt sofort mit Ja zu antworten, hat Ihr Programm zumindest eine Variante genau dieses Problems. Und es ist nichts Schlimmes daran, das zuzugeben: Es ist mit Abstand der häufigste der vier Fehler, die wir in dieser Serie behandeln, was, anders betrachtet, eigentlich eine gute Nachricht ist. Es bedeutet, dass die Lösung bereits erprobt ist. Es muss nichts von Grund auf neu erfunden werden.
Kundenbindung, die der Kunde nicht greifen kann, schafft keine Kundenbindung. Dies ist der erste Fall der Kundenbindungs-Autopsie, der Serie, in der Wapping Fall für Fall und ohne Markennennung die häufigsten und leisesten Fehler von Kundenbindungsprogrammen im Einzelhandel beleuchtet. Als Nächstes: was passiert, wenn ein Rabatt an die gesamte Kundenbasis gleichermaßen verschickt wird, ohne zu unterscheiden, wer ihn wirklich brauchte und wer nicht.