Warum Kundenprogramme an der Datenfrage scheitern und nicht am Konzept

Das Konzept war gut. Trotzdem steht das Programm still.

Die Geschäftsführung eines Mittelständlers beschließt ein Kundenprogramm, etwa ein Bonusprogramm für Stammkunden oder eine durchgängige Kundenreise vom Erstkauf bis zur Nachbestellung. Das Konzept überzeugt. Das Budget wird freigegeben, der Kickoff findet statt.

Einige Wochen später steht das Projekt. Es hängt an Fragen, die niemand beantworten kann:

Woher kommen die Kaufdaten, aus dem Warenwirtschaftssystem, aus dem Shop oder aus beiden?
Wer darf die Adressfelder ändern, der Vertrieb, der Kundenservice oder das Marketing?
Welche Einwilligung gilt, wenn zwei Systeme Unterschiedliches sagen?

Jede dieser Fragen landet in einer Abstimmungsrunde. Die IT verweist auf das Marketing, das Marketing auf den Vertrieb. Solange niemand entscheidet, wartet das Programm.

Kundenprogramme scheitern selten am Konzept. Sie bleiben hängen, weil nicht geklärt ist, wer für welche Kundendaten zuständig ist.

Woran Kundenprogramme wirklich hängen bleiben

Meist kommen drei Bruchstellen zusammen.

Erste Bruchstelle: Die Kundendaten liegen an vier Orten. Die Rechnungsadresse steht im ERP, also im System für Warenwirtschaft und Buchhaltung. Ansprechpartner und letzte Vertriebsnotiz stehen im CRM. Die Onlinebestellungen liegen im Shop, Newsletter-Einwilligung und Öffnungsraten im E-Mail-Tool. Jedes System erfüllt seinen Zweck. Keines kennt den ganzen Kunden. Ein Loyalty-Programm braucht aber genau das: wer was gekauft hat, wer angeschrieben werden darf, wie hoch der Punktestand ist. Wer die Daten zusammenführen will, findet oft denselben Kunden in drei Systemen unter drei Schreibweisen.

Zweite Bruchstelle: Für die Datenqualität fühlt sich niemand zuständig. Doppelte Datensätze, veraltete Adressen, leere Pflichtfelder. Jeder im Haus kennt das Problem, niemand behebt es. Der Vertrieb pflegt, was er für den Abschluss braucht. Der Kundenservice korrigiert, was ihm im Gespräch auffällt. Den ganzen Bestand hat keiner im Blick.

Dritte Bruchstelle: Zwischen IT und Marketing liegt ein Niemandsland. Die IT liefert Schnittstellen. Das Marketing verantwortet Inhalte, Kampagnen und das Programm. Beide machen ihren Teil richtig. Offen bleibt, was zwischen den Systemen passiert. Welches System hat recht, wenn sich zwei Adressen widersprechen? Wer merkt, dass die nächtliche Übertragung vom Shop ins E-Mail-Tool seit Tagen fehlschlägt? Wer gibt frei, dass ein neues Feld ins Programm einfließt? Für diesen Datenfluss ist häufig schlicht niemand verantwortlich.

Das Muster ist nicht auf den Mittelstand beschränkt. In einer im Mai 2026 veröffentlichten Befragung von 310 Loyalty- und Marketing-Entscheidern, durchgeführt von Forrester im Auftrag des Softwareanbieters Zeta Global, sagen 91 Prozent, dass datenbezogene Hürden sie ausbremsen. 68 Prozent geben an, dass ihre Loyalty-Daten nur teilweise mit anderen Systemen verbunden sind. Als Bremsen nennt die Studie Datenqualität, fragmentierte Systeme und organisatorische Silos. Nur 26 Prozent halten ihr Programm für sehr wirksam.

Die Studie hat ein Anbieter beauftragt, der von diesem Befund profitiert. Zuständigkeit führt sie nicht als eigene Kategorie. Wer aber verstreute Systeme und Abteilungssilos auseinandernimmt, landet meist bei derselben offenen Frage: Wer verantwortet diese Daten, und wer entscheidet, wenn es hakt?

Warum das so viel Gewicht hat, zeigt ein Blick auf die Kundenreise. Aus Sicht des Unternehmens ist sie eine Kette von Übergaben: Bestellung im Shop, Rechnung aus dem ERP, Willkommensmail aus dem E-Mail-Tool, Anruf aus dem Vertrieb. An jeder Übergabe wandert Information von einem System ins nächste. Bricht der Fluss, merkt es der Kunde. An der Mail mit dem falschen Namen. Am Gutschein für ein Produkt, das er gerade zurückgeschickt hat.

Ein Kundenprogramm setzt auf genau diese Flüsse auf. Es kann nicht besser sein als die Daten, die bei ihm ankommen. Wer für welchen Abschnitt des Flusses zuständig ist, muss also am Anfang des Vorhabens feststehen.

Warum diese Frage vor dem Kickoff niemand stellt

Die Frage bleibt selten aus Nachlässigkeit liegen. Sie fällt durch die Art, wie Kundenprogramme entstehen.

Der Anstoß kommt aus Marketing oder Vertrieb. Das Ziel ist fachlich: Stammkunden binden, Wiederkäufe steigern, inaktive Kunden zurückholen. Wer so ein Programm anstößt, denkt in Zielgruppen, Angeboten und Kommunikationsstrecken. Woher die Kaufhistorie kommt und welches System im Zweifel recht hat, liegt außerhalb dieses Blickfelds. Es war bisher auch nicht ihre Aufgabe.

Datenfragen gelten als technisches Detail. In der Konzeptphase fällt oft der Satz: „Das klärt die IT.“ Die IT kann Schnittstellen bauen. Welche Adresse gilt, wenn CRM und Shop unterschiedliche Stände haben, kann sie nicht entscheiden. Das ist eine fachliche Entscheidung, und sie braucht einen Verantwortlichen im Fachbereich.

Dazu kommt die rechtliche Seite. Nach Art. 5 Abs. 2 DSGVO ist der Verantwortliche für die Einhaltung der Datenschutzgrundsätze verantwortlich und muss sie nachweisen können (Rechenschaftspflicht). Wer im Haus welche Kundendaten verantwortet, sollte also ohnehin feststehen, spätestens bei Einwilligungen.

Die Budgetfreigabe hängt am Konzept, nicht an der Umsetzbarkeit. Gremien entscheiden über das, was ihnen vorgelegt wird: Nutzen, Mechanik, Kosten für Software und Umsetzung. Ob die nötigen Daten in brauchbarer Qualität vorliegen und wer sie pflegt, steht selten im Entscheidungspapier. Die erwähnte Befragung zeigt die Spannung: 92 Prozent planen in den nächsten zwölf Monaten Investitionen in Technologie oder Prozesse, während 91 Prozent von datenbezogenen Hürden berichten. Das Geld ist da. Die geklärte Datenbasis oft nicht.

Die Folge: Die Klärung wandert in die Projektlaufzeit. Die offenen Fragen tauchen später auf, meist dann, wenn die erste Datenstrecke gebaut werden soll. Dann sitzen Marketing, Vertrieb, IT und Kundenservice in Abstimmungsrunden, während Zeitplan, Dienstleister und Budget schon laufen. Jede ungeklärte Zuständigkeit blockiert die Arbeitspakete, die von ihr abhängen. Vor dem Kickoff hätte dieselbe Klärung einen gut vorbereiteten Termin gekostet. Mitten in der Umsetzung kostet sie deutlich mehr, weil bezahlte Arbeit stillsteht.

Was ein Data-Ownership-Mapping ist und was nicht

Ein Data-Ownership-Mapping ist eine einzige Seite. Darauf stehen alle Datenarten, die Ihr Kundenprogramm braucht. Zu jeder Datenart beantwortet die Seite fünf Fragen:

Entsteht in: In welchem System wird die Information zuerst erfasst?
Gepflegt von: Welche Rolle korrigiert Fehler und hält den Bestand aktuell?
Freigegeben von: Welche Rolle entscheidet, ob und wie das Programm die Daten nutzen darf?
Gerufen bei Fehlern: Wen ruft der Kundenservice an, wenn etwas nicht stimmt?
Weg ins Programm: Automatisch über eine Schnittstelle, manuell per Export oder noch offen?

In jede Zelle gehört eine konkrete Rolle, also eine Funktion, die genau eine Person besetzt. „Teamleitung Vertriebsinnendienst“ ist eine Rolle. „Der Vertrieb“ oder „die IT“ ist eine Sammeladresse und reicht nicht. Rollen statt Namen, weil Personen wechseln und Zuständigkeiten bleiben sollen.

So kann die Seite aussehen. Die Einträge sind ein erfundenes Beispiel:

Datenart	Entsteht in	Gepflegt von	Freigegeben von	Gerufen bei Fehlern	Weg ins Programm
Stammdaten (Name, Adresse, Firma)	ERP, Shop-Registrierung	Teamleitung Vertriebsinnendienst	Leitung Vertrieb	Teamleitung Vertriebsinnendienst	Schnittstelle, nächtlich
Kaufhistorie	ERP, Shop	ERP-Verantwortliche:r IT	Leitung Vertrieb	ERP-Verantwortliche:r IT	Export, wöchentlich
Einwilligungen	Shop, Newsletter-Formular	CRM-Manager:in Marketing	Datenschutzbeauftragte:r	CRM-Manager:in Marketing	Schnittstelle
Interaktionen (Anfragen, Reklamationen)	Kundenservice-Tool	Teamleitung Kundenservice	Leitung Kundenservice	?	offen
Punktestände	Loyalty-System	?	?	?	?

Die Fragezeichen sind Absicht. Genau solche Lücken soll die Seite zeigen, bevor das Programm startet.

Was das Mapping nicht ist

Kein Data-Governance-Großprojekt. Data Governance meint ein unternehmensweites Regelwerk für den Umgang mit Daten. Gartner hat im Februar 2024 prognostiziert, dass bis 2027 80 Prozent der Governance-Initiativen für Daten und Analytics scheitern. Ein Programm, das keine priorisierten Geschäftsergebnisse ermöglicht, scheitert, so die Begründung. Das Mapping verfolgt genau ein Ergebnis: dass ein bestimmtes Programm starten kann. Alle anderen Daten im Unternehmen bleiben außen vor.

Kein Tool-Kauf. Eine Tabelle, ein Whiteboard oder ein geteiltes Dokument genügt. Software beantwortet keine Frage nach Zuständigkeit. Laut Gartner-Umfrage von 2023 nutzen Marketingabteilungen nach eigener Einschätzung nur 33 Prozent der Funktionen ihrer Marketing-Technologie, nach 42 Prozent im Vorjahr. Das spricht dagegen, eine Zuständigkeitslücke mit einem weiteren Werkzeug schließen zu wollen.

Keine Datenstrategie. Wohin Ihr Unternehmen mit seinen Daten in fünf Jahren will, klärt das Mapping nicht. Es beschreibt, wer heute für die Daten zuständig ist, die dieses eine Programm braucht. Deshalb reicht ein Workshop statt eines Projekts.

Keine Rechtsprüfung. Das Mapping dokumentiert Zuständigkeiten. Ob Ihre Einwilligungen und Prozesse den Anforderungen der DSGVO genügen, beurteilt es nicht. Das bleibt Aufgabe Ihres Datenschutzbeauftragten oder Ihrer Rechtsberatung.

So bauen Sie das Mapping in einem Workshop

Ein BI-Team ist dafür nicht nötig. Es braucht die richtigen Leute an einem Tisch, die vorbereitete Tabelle und eine Moderation, die bei jeder Datenart auf einer konkreten Antwort besteht.

Wer an den Tisch gehört

Laden Sie die Menschen ein, die die Daten im Alltag anfassen. Die Abteilungsleitung allein reicht nicht.

Vertrieb: kennt Kundenstammdaten, Konditionen und die Frage, wem ein Kunde „gehört“.
Marketing: verantwortet Kampagnen, E-Mail-Tool und meist das Konzept des Programms.
IT: weiß, welche Systeme es gibt und wo Schnittstellen laufen und wo nicht.
Kundenservice: sieht als Erster, wenn Daten falsch sind, weil sich die Kunden dort melden.
Datenschutz, falls vorhanden: gehört dazu, sobald Einwilligungen oder Kontaktdaten im Spiel sind.

Entscheidend ist eine Person, die entscheiden darf. Ohne sie endet der Workshop mit offenen Fragen, die niemand schließen kann.

Leitfragen pro Datenart

Bereiten Sie die Tabelle mit den sechs Spalten von oben vor. Gehen Sie die Datenarten dann nacheinander durch:

Stammdaten: In welchem System ist die Adresse „richtig“, wenn zwei Systeme unterschiedliche Angaben haben? Wer darf Adressfelder ändern, und kommt die Änderung in allen anderen Systemen an?

Kaufhistorie: Woher kommen die Kaufdaten, aus dem ERP, dem Shop oder beiden? Wie aktuell müssen sie für das Programm sein, und wie aktuell sind sie heute?

Einwilligungen: Wo wird festgehalten, wer welcher Kontaktaufnahme zugestimmt hat? Wer stellt sicher, dass ein Widerruf überall ankommt, auch im E-Mail-Tool?

Interaktionen: Welche Kontakte mit Service, Vertrieb und Kampagnen werden überhaupt erfasst, und wo? Wer entscheidet, welche davon das Programm nutzt?

Punktestände: Wo wird der Stand berechnet, und wer ist zuständig, wenn ein Kunde ihn anzweifelt? Was passiert mit dem Stand, wenn Kundenkonten zusammengeführt werden?

Schweigen auf eine Frage ist ein Ergebnis, und zwar genau das, das Sie suchen. Tragen Sie es als offenen Punkt ein, mit einer Rolle, die ihn bis zu einem festen Datum klärt.

Wie Sie den Termin führen

Halten Sie den Rahmen eng: die Datenarten dieses einen Programms, nicht die Datenlandschaft des Unternehmens. Diskussionen über neue Tools oder eine Datenstrategie gehören auf eine Parkliste. Füllen Sie die Tabelle direkt im Raum aus, sichtbar für alle. Dann widersprechen die Beteiligten sofort, wenn ein Eintrag nicht stimmt, und nicht erst Wochen später.

Am Ende liegt eine ausgefüllte Seite vor, dazu eine Liste offener Punkte mit Verantwortlichen. Sie gehört in die Unterlagen zur Budgetentscheidung.

Die drei Warnsignale im fertigen Mapping

Ein Mapping ohne Lücken ist selten, und Lücken sind kein Grund, das Vorhaben zu stoppen. Drei Muster verdienen aber einen genauen Blick. Zu jedem gehört dieselbe Frage: Muss das vor dem Start gelöst sein, oder kann das Programm mit einer Übergangslösung anlaufen?

1. Datenarten ohne benannte Rolle

So sieht es aus: In „Gepflegt von“ oder „Gerufen bei Fehlern“ steht ein Fragezeichen oder eine Sammeladresse wie „die IT“. Häufig betrifft das Interaktionsdaten wie Öffnungen, Klicks oder Serviceanfragen. Sie entstehen in mehreren Tools, und niemand fühlt sich zuständig.

Warum es zählt: Ohne benannte Rolle bleibt jeder Datenfehler liegen, bis er einem Kunden auffällt. Dann beginnt die Suche nach dem Zuständigen im laufenden Programm.

Vor dem Start lösen, wenn die Datenart rechtlich relevant ist, vor allem bei Einwilligungen. Wegen der Rechenschaftspflicht ist ein Fragezeichen in dieser Zeile ein Startrisiko. Wie der Nachweis im Einzelfall aussehen muss, stimmen Sie mit Ihrem Datenschutzbeauftragten ab.

Übergangslösung möglich bei Daten, die das Programm zunächst nur für Auswertungen nutzt. Besetzen Sie die Rolle kommissarisch und legen Sie ein Datum fest, an dem die Zuständigkeit endgültig geklärt ist.

2. Datenarten mit konkurrierenden Quellen

So sieht es aus: In „Entsteht in“ stehen zwei oder drei Systeme. Die Lieferadresse gibt es im ERP, im Shop und im CRM. Die Kaufhistorie liegt im Warenwirtschaftssystem und im Shop, und beide zählen Retouren anders.

Warum es zählt: Solange nicht festgelegt ist, welches System gilt, rechnet das Programm mit Werten, die sich widersprechen.

Vor dem Start lösen bei allen Daten, aus denen das Programm etwas für den Kunden berechnet, also Kaufhistorie und Punktestände. Legen Sie pro Datenart ein führendes System fest: das System, dessen Wert im Zweifel gilt und an das alle anderen angepasst werden. Diese Entscheidung kostet eine Sitzung, keine Software.

Übergangslösung möglich bei Stammdaten wie Adressen, wenn ein führendes System bestimmt ist und die übrigen Quellen vorerst nur lesen. Die technische Angleichung kann folgen.

3. Datenflüsse, die nur manuell über Tabellen laufen

So sieht es aus: In „Weg ins Programm“ steht „Export“. Jemand zieht jede Woche eine Liste aus dem ERP und lädt sie ins E-Mail-Tool. Das funktioniert, solange diese Person da ist und daran denkt.

Warum es zählt: Manuelle Flüsse sind nicht falsch, aber verletzlich. Urlaub, Krankheit oder eine geänderte Spalte im Export reichen, damit der Fluss unbemerkt abreißt. Und was nur wöchentlich übertragen wird, ist im Programm bis zu eine Woche alt.

Vor dem Start lösen, wenn der Kunde die Daten direkt sieht und zeitnah erwartet. Ein Punktestand, der erst Tage nach dem Kauf erscheint, erzeugt Rückfragen im Kundenservice und kostet Vertrauen in das Programm.

Übergangslösung möglich bei internen Auswertungen und überschaubaren Mengen. Voraussetzung: fester Rhythmus, benannte Rolle mit Vertretung, kurze schriftliche Anleitung. Dann ist die Tabelle ein bewusster Zwischenschritt.

Die Faustregel

Zwei Prüffragen beantworten das „Jetzt oder später“ meist zuverlässig. Betrifft die Lücke rechtliche Pflichten, etwa bei Einwilligungen? Sieht der Kunde das Ergebnis direkt? Lautet eine Antwort Ja, gehört die Lücke vor den Start. Alles andere kann mit einer Übergangslösung anlaufen, sofern sie eine verantwortliche Rolle und ein Enddatum hat. Fehlt eines davon, wird aus dem Provisorium ein Dauerzustand.

Warum das Mapping zum Standard werden sollte

Eine Seite Papier klingt nach wenig, und das ist gewollt. Das Mapping kostet einen Workshop und etwas Nacharbeit. Dafür ändert es drei Dinge, an denen der Verlauf eines Kundenprogramms hängt.

Risiken werden sichtbar, bevor Geld fließt. Ohne Mapping entscheiden Sie über Budget und Zeitplan auf Basis des Konzepts. Mit Mapping sehen Sie vorher, ob die Kaufhistorie in der nötigen Form vorliegt und wer sie liefert. Eine Datenart ohne Verantwortlichen ist dann ein Projektrisiko, das auf dem Tisch liegt, bevor Sie unterschreiben.

Abstimmungsschleifen werden kürzer. Die Fragen vom Anfang verschwinden nicht. Sie werden früher gestellt, einmal, mit allen Beteiligten am Tisch. Wenn in der Umsetzung jemand fragt, wer die Kaufhistorie liefert, genügt ein Blick auf die Seite. Wie viel Zeit das spart, hängt vom Vorhaben ab. Häufig entfällt so ein großer Teil der Klärungsrunden, die sonst mitten in der Laufzeit auflaufen.

Fachbereich und IT sprechen über dasselbe. Das Marketing denkt in Zielgruppen und Kampagnen, die IT in Systemen und Schnittstellen. Das Mapping bringt beide Sichten auf eine gemeinsame Einheit: die Datenart. Darüber können beide Seiten verhandeln, ohne die Fachsprache der anderen zu lernen. Als Nebeneffekt hat Ihre Datenschutzverantwortung eine dokumentierte Ausgangslage. Eine Datenschutzprüfung ersetzt das nicht.

So gehen wir bei UNIT ONE an Kundensysteme heran: erst die Struktur klären, dann das Programm bauen. Das Mapping gehört deshalb als feste Voraussetzung vor jede Budgetfreigabe.

Ihr nächster Schritt

Steht in Ihrem Haus ein Journey- oder Loyalty-Programm an, drehen Sie die übliche Reihenfolge um:

Einen Termin ansetzen, bevor das Budget freigegeben wird. Mit Vertrieb, Marketing, IT und Kundenservice, bei Einwilligungen auch mit der Person, die bei Ihnen den Datenschutz verantwortet.
Für jede Datenart des Programms eine Zeile anlegen und die sechs Spalten füllen.
Die Warnsignale markieren: fehlende Rollen, konkurrierende Quellen, manuelle Flüsse. Für jedes entscheiden: vor dem Start lösen oder Übergangslösung mit Rolle und Enddatum?
Erst dann über Budget und Zeitplan sprechen, auf Grundlage dessen, was sich tatsächlich umsetzen lässt.

Was es dafür braucht, ist eine ehrliche Bestandsaufnahme und jemand, der das Gespräch zwischen Fachbereich und IT zu einem Ergebnis führt. Bei diesem zweiten Teil unterstützen wir Sie, etwa bei der Vorbereitung der Mapping-Seite für Ihr Vorhaben und mit der Moderation des Workshops. Die datenschutzrechtliche Bewertung bleibt bei Ihrem Datenschutzbeauftragten oder Ihrer Rechtsberatung. Wenn Sie vorab einordnen wollen, wo Ihre Kundensysteme stehen, ist die Diagnose ein guter Anfang.

Wissen Sie heute, wer in Ihrem Haus gerufen wird, wenn ein Punktestand nicht stimmt?

Häufige Fragen

Was ist ein Data-Ownership-Mapping bei Kundenprogrammen? Eine einzelne Seite, die für jede Datenart eines Programms festhält, wo die Daten entstehen, wer sie pflegt, wer sie freigibt, wer bei Fehlern gerufen wird und wie sie ins Programm kommen. Sie liegt vor dem Kickoff vor.

Wer sollte im Mittelstand für Kundendaten verantwortlich sein: IT, Marketing oder Vertrieb? Das entscheidet sich pro Datenart: Kaufhistorie liegt oft näher am Vertrieb, Einwilligungen näher am Marketing und am Datenschutz, Schnittstellen bei der IT. Eine benannte Rolle braucht auch der Datenfluss zwischen den Systemen.

Brauche ich ein Data-Governance-Projekt, bevor ich ein Loyalty-Programm starte? Nein. Das Mapping klärt nur die Daten, die Ihr Programm braucht.

Wie lange dauert es, ein Data-Ownership-Mapping zu erstellen? Das hängt vor allem von der Vorbereitung ab. Länger wird es, wenn für einzelne Datenarten niemand zuständig ist oder mehrere Systeme dieselben Daten liefern. Genau dieses Risiko sollten Sie vor der Budgetfreigabe kennen.

Was tun, wenn für eine Datenart niemand die Verantwortung übernehmen will? Dann haben Sie ein echtes Projektrisiko gefunden, und zwar rechtzeitig. Die Entscheidung gehört auf die Ebene der Geschäftsführung, weil sie Budget und Zeitplan betrifft. Zwei Wege sind möglich: Sie besetzen die Rolle und geben der Person die nötige Zeit, oder Sie starten ohne diese Datenart und nehmen sie später auf.

Hinweis: Dieser Beitrag beschreibt Zuständigkeiten für Kundendaten aus Sicht von Kundensystemen und Projektsteuerung. Er ist keine Rechtsberatung. Für die Bewertung Ihrer Pflichten nach der DSGVO, etwa zu Einwilligung, Widerruf und Rechenschaftspflicht, wenden Sie sich an Ihren Datenschutzbeauftragten oder eine Rechtsberatung.