KI im CRM: Warum die Modelle selten das Problem sind — und die Kundendaten fast immer

Das Gespräch verläuft fast immer gleich. Ein Händler hat sich drei CRM-Systeme angesehen, in allen dreien dieselbe Demo gesehen — Kundenwert wird vorhergesagt, Abwanderung wird erkannt, Segmente entstehen von selbst — und fragt uns, welches davon das beste sei.

Die ehrliche Antwort ist unbequem: In den meisten Häusern würde keines dieser drei Systeme das liefern, was in der Demo zu sehen war. Nicht weil die Anbieter übertreiben, sondern weil die Demo auf einem Datenbestand läuft, den es in gewachsenen Handelslandschaften nicht gibt. Dort existiert dieselbe Kundin fünfmal, und jedes der fünf Fragmente kennt ein Fünftel ihrer Geschichte.

Dieser Text ordnet das Thema so, wie es im Projekt tatsächlich anfällt. Zuerst, was hinter dem Begriff steckt. Dann, woran es scheitert. Dann, welche Anwendungsfälle in welcher Reihenfolge realistisch sind — und warum ausgerechnet ein Plattformwechsel die günstigste Gelegenheit ist, die Voraussetzungen dafür zu schaffen.

Was “KI im CRM” technisch bedeutet

Der Begriff bündelt drei recht unterschiedliche Verfahren, die im Marketingmaterial als eines auftreten. Es lohnt sich, sie auseinanderzuhalten, weil sie unterschiedlich anspruchsvoll sind.

Mustererkennung auf Verlaufsdaten. Ein Modell sieht sich an, wie sich Kundinnen und Kunden in der Vergangenheit verhalten haben, und leitet Wahrscheinlichkeiten ab: Wiederkauf, Abwanderung, Interesse an einer Kategorie. Das ist der Teil, der am meisten verspricht und am meisten voraussetzt — ohne mehrere Quartale verlässlicher Historie rechnet er auf Rauschen.

Sprachverarbeitung. Texte aus Mails, Chats und Tickets werden eingeordnet, zusammengefasst, mit einer Stimmung versehen. Das funktioniert weitgehend unabhängig von Ihrer Datenqualität, weil der Text selbst die Eingabe ist. Entsprechend schnell ist dieser Teil produktiv.

Generative Erzeugung. Antwortentwürfe, Zusammenfassungen, Textvorschläge. Hier ist die Voraussetzung keine Datenmenge, sondern eine Kontrollinstanz: Generative Modelle produzieren zuverlässig plausible Sätze, und Plausibilität ist nicht dasselbe wie Richtigkeit. Ein Entwurf, der einen Liefertermin nennt, den es nicht gibt, ist schlimmer als kein Entwurf.

Die erste Kategorie ist die, um die es in Kaufentscheidungen fast immer geht. Und sie ist die, die an den Daten hängt.

Der Bruch, den keine Demo zeigt

Identitätsbruch

Ihre beste Kundin ist im System fünf verschiedene Menschen

Jedes Werkzeug führt eine eigene Kennung, und keine davon ist in allen Systemen dieselbe. Was als „360-Grad-Sicht“ verkauft wird, scheitert deshalb selten am Modell, sondern an drei fehlenden Brücken. Durchgezogen heißt: es gibt einen gemeinsamen Schlüssel. Gestrichelt heißt: es gibt ihn nicht.

• Ein Schlüssel, nicht fünf Eine Zusammenführung braucht eine Kennung, die alle Systeme unverändert weiterreichen. E-Mail-Adressen sind dafür der schwächste Kandidat — Haushalte teilen sie, Menschen wechseln sie.
• Fünf Profile, eine Person Ohne Brücke rechnet jedes Modell auf Bruchstücken. Die Kaufwahrscheinlichkeit einer Stammkundin sinkt, weil zwei Drittel ihrer Historie unter einem anderen Datensatz liegen.
• Der Wechsel ist die Gelegenheit Bei einer Migration werden Kundendatensätze ohnehin angefasst, dedupliziert und neu geschlüsselt. Danach ist derselbe Schritt ein eigenes Projekt mit eigenem Budget.

Wir sehen dieses Bild in nahezu jeder Bestandsaufnahme. Nicht weil die Systeme schlecht ausgewählt wurden, sondern weil sie zu unterschiedlichen Zeiten für unterschiedliche Zwecke eingeführt wurden. Der Newsletter kam vor dem Shop. Das Ticketsystem kam, als der Support aus dem Postfach herauswuchs. Die Kasse kam mit der ersten Filiale und kannte nie einen Kundenbegriff.

Jedes dieser Systeme funktioniert für sich einwandfrei. Der Fehler entsteht erst in dem Moment, in dem jemand eine Frage stellt, die über Systemgrenzen geht — und “Welche Kundinnen wandern gerade ab?” ist genau so eine Frage.

Die Folge ist nicht, dass das Modell keine Antwort gibt. Es gibt eine, und sie sieht überzeugend aus. Sie ist nur falsch, weil sie eine Stammkundin mit zwölf Bestellungen als Neukundin mit zwei Bestellungen bewertet, während die restlichen zehn unter einer zweiten E-Mail-Adresse liegen. Diese Art Fehler fällt lange nicht auf, weil es keine Gegenprobe gibt: Niemand vergleicht die Prognose mit dem, was tatsächlich passiert wäre.

Wie man Kundendaten systematisch zusammenführt und wann dafür eine eigene Plattform nötig ist, haben wir in Customer Data Platform und Shopify auseinandergenommen. Die Kurzfassung: In den meisten Setups ist die fehlende Kennung das Problem, nicht das fehlende Werkzeug.

Sieben Anwendungsfälle, drei Zeitpunkte

Fast jede Anbieterliste nennt dieselben sieben Punkte, und sie stehen dort gleichwertig nebeneinander. Im Projekt sind sie das nicht. Zwei laufen mit dem, was Sie heute haben. Zwei brauchen ein zusammengeführtes Profil. Drei brauchen zusätzlich Zeit.

Anwendungsfälle

Sieben Versprechen, drei Voraussetzungsstufen

In Anbieterpräsentationen stehen diese sieben Punkte nebeneinander, als wären sie gleich weit entfernt. Sind sie nicht. Zwei laufen mit dem, was Sie heute haben. Zwei brauchen ein zusammengeführtes Kundenprofil — genau das Ergebnis, das eine saubere Migration ohnehin produziert. Drei brauchen zusätzlich Zeit, die niemand abkürzen kann.

sofort machbar 2 nach dem Umstieg 2 braucht Historie 3

1. 01 sofort machbar

   Routinearbeit abnehmen

   Datensätze anlegen, Dubletten zusammenführen, Kontakte zuordnen, Notizen aus Gesprächen verdichten.

   Setzt voraus Nichts außer Schreibrechten. Der einzige Anwendungsfall, der ohne Datenreife funktioniert.

2. 02 sofort machbar

   Service unterstützen

   Anfragen vorsortieren, Antwortentwürfe vorschlagen, Bestellstatus aus dem Shop beantworten.

   Setzt voraus Lesezugriff auf Bestell- und Versanddaten in Echtzeit. Ohne den bleibt der Assistent bei Allgemeinplätzen.

3. 03 nach dem Umstieg

   Segmente bilden

   Gruppen aus Kaufhistorie, Frequenz, Kategorie, Kanal und Reaktion auf Kampagnen statt aus drei manuellen Filtern.

   Setzt voraus Ein zusammengeführtes Profil je Person. Auf fragmentierten Datensätzen entstehen Segmente, die dieselbe Kundin dreimal enthalten.

4. 04 nach dem Umstieg

   Ansprache personalisieren

   Inhalt, Zeitpunkt und Kanal an der tatsächlichen Historie ausrichten statt an einem Verteiler.

   Setzt voraus Verlässliche Ereignisse aus dem Shop: Kauf, Retoure, Abbruch, Wiederbesuch — mit Zeitstempel und Kundenbezug.

5. 05 braucht Historie

   Abwanderung erkennen

   Verhaltensänderungen markieren, bevor die Kundin ausbleibt — sinkende Frequenz, ausbleibende Öffnungen, Retourenhäufung.

   Setzt voraus Mindestens vier Quartale lückenloser Historie. Ein Modell braucht Abwanderungen in den Daten, um sie zu erkennen.

6. 06 braucht Historie

   Kaufwahrscheinlichkeit schätzen

   Wiederkaufneigung und Kundenwert je Kontakt, damit Budget und Zeit dorthin gehen, wo sie wirken.

   Setzt voraus Historie plus korrekt datierte Retouren und Stornos. Sonst schätzt das Modell auf Umsätzen, die nie stattgefunden haben.

7. 07 braucht Historie

   Entscheidungen unterlegen

   Shop, Marketing und Service auf denselben Zahlen diskutieren lassen — eine Kundendefinition statt drei.

   Setzt voraus Eine führende Quelle je Kennzahl und eine Definition, auf die sich alle Abteilungen schriftlich geeinigt haben.

Die übliche Reihenfolge im Projekt ist genau umgekehrt: Gekauft wird für Zeile fünf bis sieben, geliefert werden kann Zeile eins und zwei. Wer die Stufen respektiert, hat nach acht Wochen zwei laufende Anwendungsfälle statt sieben angefangener.

Die Reihenfolge in dieser Übersicht ist keine Empfehlung für die Wichtigkeit, sondern für die Abfolge. Wer mit Zeile fünf beginnt, weil Abwanderungserkennung im Vorstandsgespräch am besten klingt, verbringt sechs Monate mit einer Datenaufbereitung, die niemand budgetiert hat, und hat am Ende ein Modell ohne Vertrauen.

Wer mit Zeile eins und zwei beginnt, hat nach wenigen Wochen zwei Dinge: eine spürbare Entlastung im Tagesgeschäft und — wichtiger — eine Organisation, die den Umgang mit maschinellen Vorschlägen geübt hat. Das ist die eigentliche Voraussetzung für die anspruchsvollen Zeilen, und sie steht in keiner technischen Anforderungsliste.

Was der Wechsel auf Shopify daran ändert

Hier liegt der Punkt, den wir in Migrationsprojekten am häufigsten erklären müssen: Ein Plattformwechsel ist kein CRM-Projekt. Er löst keinen einzigen der sieben Anwendungsfälle. Er verändert aber drei Voraussetzungen so grundlegend, dass sich der Aufwand für alles Nachfolgende verschiebt.

Erstens: Kundendatensätze werden ohnehin angefasst. Bei einer Migration wird jeder Kundendatensatz gelesen, geprüft, dedupliziert und neu geschrieben. Das ist der einzige Zeitpunkt im Lebenszyklus eines Shops, an dem eine vollständige Bereinigung kein separates Projekt ist, sondern eine Erweiterung eines Schritts, den Sie sowieso gehen. Zwei Wochen nach dem Cutover kostet dieselbe Arbeit ein eigenes Budget und eine eigene Begründung.

Zweitens: Ereignisse entstehen einheitlich. Ein Modell braucht keine Stammdaten, sondern Ereignisse mit Zeitstempel und Kundenbezug — Kauf, Abbruch, Retoure, Wiederbesuch, Abmeldung. In gewachsenen Systemen entstehen diese Ereignisse an verschiedenen Stellen in verschiedenen Formaten, teils nur als Nebenprodukt eines Logeintrags. Auf einer einheitlichen Plattform sind sie ein definierter Datenstrom, den jedes angeschlossene System in derselben Form bekommt. Welche Muster sich dafür in der Systemlandschaft bewährt haben, steht in ERP-Integration mit Shopify.

Drittens: Die Zahl der Brücken sinkt. Jede Schnittstelle zwischen zwei Systemen ist eine Stelle, an der Identität verloren gehen kann. Wenn Shop, Kasse und Kundenkonto nach dem Wechsel dieselbe Kundenkennung führen, verschwinden nicht die Systeme — es verschwinden die Übersetzungen dazwischen. Wie sich das auf die gesamte Werkzeuglandschaft auswirkt, haben wir im digitalen Ökosystem nach dem Umstieg beschrieben.

Was der Wechsel ausdrücklich nicht löst: Er ersetzt keine Historie. Wenn Ihre Verkaufsdaten der letzten drei Jahre lückenhaft, falsch datiert oder ohne Retourenbezug vorliegen, sind sie es nach der Migration auch. Eine Prognose braucht Vergangenheit, und die kann keine Plattform rückwirkend erzeugen. Dieselbe Mechanik gilt in der Beschaffung, wie wir in KI in der Lieferkette gezeigt haben — nur dass dort die Artikelnummer die Rolle spielt, die im CRM die Kundenkennung hat.

Wo der Mensch bleiben muss

Kontrollgrenzen

Wo automatisiert werden darf — und wer unterschreibt

„Mensch im Prozess“ steht in jedem Konzept und meint meist nichts Bestimmtes. Prüfbar wird der Satz erst, wenn je Entscheidungsklasse feststeht, wie viel das System allein tut und welche Rolle den Rest verantwortet. Die Balken sind Richtwerte; entscheidend ist das Gefälle von oben nach unten.

• Datenpflege

  Risiko gering

  Dubletten zusammenführen, Felder normalisieren, Kontakte zuordnen.

  90% System 10% Mensch

  Gegenzeichnung Stichprobe pro Woche, keine Einzelfreigabe

• Segmentierung

  Risiko gering

  Gruppen vorschlagen, Kundenwert-Klassen bilden, Listen aktualisieren.

  75% System 25% Mensch

  Gegenzeichnung Marketing prüft neue Segmente vor dem ersten Versand

• Ansprache und Timing

  Risiko mittel

  Inhalt, Kanal und Zeitpunkt je Kontakt bestimmen.

  55% System 45% Mensch

  Gegenzeichnung Textbausteine einmal freigegeben, Aussteuerung automatisch

• Serviceantworten

  Risiko mittel

  Antwortentwürfe zu Lieferstatus, Retoure, Rechnung.

  40% System 60% Mensch

  Gegenzeichnung Service gibt jede Antwort frei, die nicht reiner Statusabruf ist

• Preis, Kulanz, Sperrung

  Risiko hoch

  Rabatt gewähren, Retoure kulant abwickeln, Konto sperren.

  10% System 90% Mensch

  Gegenzeichnung Immer eine benannte Person — ohne Ausnahme, auch bei klarer Empfehlung

Die unterste Zeile ist die, an der Projekte scheitern — nicht weil das Modell falsch liegt, sondern weil eine automatische Kulanzentscheidung im Beschwerdefall niemanden hat, der sie erklärt. Legen Sie diese Grenze schriftlich fest, bevor der erste Anwendungsfall live geht.

Die Grenze in der untersten Zeile ist keine Vorsichtsmaßnahme, sondern eine Frage der Zuständigkeit. Wenn ein System einen Rabatt gewährt, eine Retoure ablehnt oder ein Konto sperrt, muss es dafür im Beschwerdefall jemanden geben, der die Entscheidung erklärt. “Das hat das Modell so berechnet” ist gegenüber einer Kundin keine Auskunft, und gegenüber einer Aufsichtsbehörde erst recht nicht.

Dazu kommt der Datenschutz, der bei Kundendaten nicht am Rand steht. Wer personenbezogene Daten durch ein Modell verarbeiten lässt, braucht eine Rechtsgrundlage, einen Auftragsverarbeitungsvertrag mit dem Anbieter und Klarheit darüber, wo verarbeitet wird. Bei automatisierten Entscheidungen mit rechtlicher oder ähnlich erheblicher Wirkung — und eine Kontosperrung fällt darunter — kommen zusätzliche Anforderungen hinzu. Das ist kein Grund, das Thema zu meiden; es ist ein Grund, die unterste Zeile der Grafik schriftlich zu fixieren, bevor der erste Anwendungsfall live geht.

Die Werkzeugfrage kommt zuletzt

HubSpot, Salesforce, Zoho, Klaviyo — die Auswahl ist groß, und jedes System wirbt mit einer eigenen Zusammenstellung von KI-Funktionen. Unsere Erfahrung aus Migrationsprojekten ist, dass die Funktionsliste der am wenigsten aussagekräftige Teil der Entscheidung ist.

Was tatsächlich zählt, sind vier Punkte:

Welche Quellen lassen sich anschließen — und in welcher Richtung? Ein System, das Bestelldaten liest, aber keine Segmente an den Shop zurückgibt, halbiert den Nutzen. Prüfen Sie beide Richtungen konkret, nicht als Häkchen in einer Tabelle.

Wie nachvollziehbar sind die Ergebnisse? Wenn ein Kontakt eine hohe Abwanderungswahrscheinlichkeit bekommt, muss das Team sehen können, woran das liegt. Ohne diese Erklärbarkeit wird die Empfehlung entweder blind befolgt oder komplett ignoriert — beides ist wertlos.

Wie werden Rechte verwaltet? Ein CRM mit Kundendaten und angeschlossenen Modellen ist ein Zugriffsthema. Eine zentrale Rechteverwaltung ist keine Bequemlichkeit, sondern die Voraussetzung dafür, dass Sie bei einem Personalwechsel wissen, wer noch hineinsieht.

Was passiert bei Wachstum? Die relevante Frage ist nicht, ob das System hunderttausend Kontakte verwaltet, sondern was der Sprung von zehntausend auf hunderttausend an Lizenz und Aufwand kostet. Diese Zahl steht selten im Angebot.

Wie sich die Werkzeugentscheidung in eine Marketingsteuerung einordnet, die tatsächlich auf Zahlen läuft, haben wir in Datengetriebenes Marketing auf Shopify Plus beschrieben. Und wenn der erste konkrete Anwendungsfall Rückgewinnung sein soll, finden Sie die Ablauflogik dazu in Kundenrückgewinnung mit Shopify Flow.

Wo Sie ansetzen, je nach Ausgangslage

Ihre Situation	Der erste Handgriff
CRM-Auswahl läuft, Migration ist geplant	Auswahl zurückstellen — die Datenstruktur nach dem Wechsel bestimmt, welche Anforderungen überhaupt gelten
Newsletter und Shop führen getrennte Kundenlisten	Prüfen, wie viele Kontakte in beiden Listen dieselbe Person sind; die Zahl ist meist zweistellig prozentual
Filialverkäufe erscheinen nicht im Kundenprofil	Klären, ob an der Kasse überhaupt eine Kennung erfasst wird — ohne sie ist keine Zusammenführung möglich
Historie liegt vor, aber Retouren ohne Ursprungsdatum	Datierung korrigieren, bevor irgendein Modell darauf rechnet — sonst prognostiziert es Phantomumsätze
Ein KI-Pilot läuft und niemand vertraut den Ergebnissen	Nicht das Modell wechseln, sondern zehn Fälle manuell gegenprüfen und die Abweichung dokumentieren
Serviceteam nutzt bereits Antwortentwürfe	Freigabepflicht schriftlich festhalten, bevor sich informelle Praxis einschleift
Kundendaten liegen in vier oder mehr Systemen	Eine führende Quelle je Feld benennen — vor jeder Werkzeugentscheidung
Migration steht kurz bevor	Datenbereinigung in den Migrationsauftrag aufnehmen, nicht als Folgeprojekt planen

Checkliste

Bestandsaufnahme vor der ersten KI-Funktion im CRM

Zehn Punkte, die geklärt sein sollten, bevor Sie ein CRM auswählen oder einen Anwendungsfall starten. Ihre Häkchen bleiben in diesem Browser gespeichert.

• Alle Systeme aufgelistet, die Kundendaten führen — inklusive Kasse, Buchhaltung und Ticketsystem
• Je System notiert, welche Kennung es führt und ob sie in einem anderen System vorkommt
• Eine führende Quelle je Kundenfeld benannt und schriftlich festgehalten
• Dublettenquote zwischen Shop-Konten und Newsletter-Liste einmal gemessen
• Geprüft, ob Retouren und Stornos mit dem Datum der Ursprungsbestellung verknüpft sind
• Länge der verwertbaren Verkaufshistorie in Quartalen bestimmt, nicht in Jahren
• Ersten Anwendungsfall aus der Stufe „sofort machbar“ ausgewählt, nicht aus der Prognosestufe
• Je Entscheidungsklasse festgelegt, wie viel automatisch läuft und wer gegenzeichnet
• Rechtsgrundlage und Auftragsverarbeitungsvertrag für die geplante Verarbeitung geklärt
• Messgröße für den Pilotfall definiert — mit Ausgangswert vor dem Start

---

Der vorletzte Punkt der Checkliste ist der, der am häufigsten fehlt. Fast jeder Pilot startet ohne Ausgangswert, und ohne Ausgangswert lässt sich hinterher nicht sagen, ob die Wiederkaufquote gestiegen ist oder ob das Quartal einfach besser lief. Das Ergebnis ist eine Diskussion über Eindrücke, und die gewinnt regelmäßig, wer lauter ist.

Der letzte Punkt ist der eigentliche. Künstliche Intelligenz im CRM ist kein Werkzeug, das Kundenbeziehungen ersetzt — sie ist eines, das Aufmerksamkeit umverteilt. Sie zeigt, wo sich Zuwendung lohnt, und nimmt Arbeit ab, die niemand vermisst. Damit sie das kann, muss sie wissen, mit wem sie es zu tun hat. Genau daran fehlt es in den meisten Landschaften — und genau das ist die Sorte Problem, die sich beim Plattformwechsel nebenbei lösen lässt und danach nur noch mit eigenem Budget.

Wenn bei Ihnen eine Migration ansteht und Sie wissen wollen, welche Ihrer Kundendatenbestände sich dabei ohne Mehraufwand zusammenführen lassen: Lassen Sie uns sprechen — wir sehen uns die Systemlandschaft, die geführten Kennungen und die verwertbare Historie an und sagen Ihnen, welche der sieben Anwendungsfälle danach realistisch sind.