Ein Kundendatensatz, dem alle vertrauen: das Operating Model hinter einem CRM, das genutzt wird

Ein Operating Model für einen einheitlichen Kundendatensatz ist das Regelwerk, das festlegt, wem jedes Feld gehört, welches System die Quelle für jede Information ist und welcher Moment bei jeder Interaktion als maßgeblich gilt. Fehlt dieses Modell, wird ein CRM aufgegeben. Dem Datensatz darin vertraut dann niemand mehr, und kein Tool stellt Vertrauen wieder her, das das Modell nie definiert hat. Die Software war selten das Problem. Das Problem war, dass niemand festgelegt hatte, was der Datensatz bedeutet.

Dieses Muster steckt hinter den meisten festgefahrenen CRMs. Drei Teams pflegen jeweils ihre eigene Version des Kunden, die Reports passen nie zusammen, und innerhalb eines Jahres kehren die Leute still zu Tabellen zurück, weil das System ihnen Dinge anzeigt, von denen sie wissen, dass sie falsch sind. Der Reflex ist dann, die Daten zu bereinigen oder, schlimmer, eine neue Plattform zu kaufen und von vorn zu beginnen. Beides überspringt die eigentliche Lösung. Saubere Daten ohne Verantwortlichkeiten sind nach einem Quartal wieder verschmutzt, und eine Migration trägt dieselben fehlenden Regeln nur in schönere Software.

Im Folgenden geht es um das Operating Model selbst, aufgebaut aus den Entscheidungen, aus denen es besteht: die Regeln, die einen Datensatz vertrauenswürdig machen, wer wofür verantwortlich ist, welches System gewinnt, wenn zwei sich widersprechen, und wo das Modell typischerweise bricht.

Warum der Datensatz aufgegeben wird und neue Software daran nichts ändert

Ein Datensatz wird aufgegeben, sobald die Menschen, die auf ihn angewiesen sind, ihm nicht mehr glauben, und dieser Glaube bricht lange vor den Daten zusammen. Eine Single Customer View ist ein einheitliches, vertrauenswürdiges Kundenprofil, mit dem jedes Team arbeiten kann. Dass so wenige Unternehmen eines haben, liegt nicht am Speicher. Es liegt daran, dass ein CRM speichert, was jedes Team eintippt, und nichts an den Widersprüchen dazwischen ändert. Eine Plattform wie HubSpot bündelt die Daten in einer zentralen Datenbank. Das ist nötig, aber nicht ausreichend, denn Speichern ist noch keine Einigung.

Auf diese Unterscheidung kommt es an, und die meisten Ratgeber hören genau hier auf. Wie CX Today das Problem beschreibt: Die Single View ist eine Frage von Architektur und Governance, die neben dem CRM liegt, keine Funktion darin. Ein CRM hilft gut bei Deals, Tickets und Aufgaben. Es entscheidet nicht, wer der Kunde ist, wenn Marketing, Vertrieb und Support jeweils eine andere Antwort haben. Ein besseres CRM ändert den Speicher und lässt den Widerspruch bestehen. Deshalb scheitert die zweite Plattform meist genauso wie die erste, nur teurer.

Die Lösung ist kein Tool. Sie ist ein kleines Regelwerk, an das sich das ganze Team hält und das auf den Datensatz angewendet wird, bevor irgendeine Softwareentscheidung fällt. Vertrauen ist das Ergebnis dieser Regeln. Der Rest dieses Beitrags zeigt, wie Sie sie aufstellen.

Die drei Regeln des Operating Models

Ein vertrauenswürdiger Datensatz beruht auf drei Regeln, und jede verhindert einen bestimmten Fehler. Ein Verantwortlicher pro Feld: Jedes Feld, das eine Entscheidung steuert, hat genau eine verantwortliche Person, damit keine Information die Aufgabe aller und damit von niemandem ist. Eine Quelle pro Information: Jede Information hat ein maßgebliches System, damit es bei Widersprüchen einen festgelegten Gewinner gibt. Ein maßgeblicher Moment pro Interaktion: Jede Interaktion wird einmal in den Datensatz geschrieben, von einer Stelle aus, damit dasselbe Ereignis nicht dreimal in drei Formen auftaucht.

Dafür brauchen Sie keine Plattform. Sie brauchen eine schriftliche Einigung, die länger hält als die Menschen, die sie getroffen haben. Ein Team, das für seine zwanzig wichtigsten Felder sagen kann, wem jedes gehört und welches System dafür maßgeblich ist, hat mehr von einem einheitlichen Kundendatensatz als ein Team, das eine Customer Data Platform gekauft und diese Übung ausgelassen hat. Die Regeln sind das eigentliche Kapital. Die Tools setzen nur Regeln durch, die es schon gibt.

Der Anfang: jedem wichtigen Feld einen Verantwortlichen geben

Das Operating Model beginnt mit Verantwortung, und der erste Schritt ist, die Liste der Felder zu kürzen, bevor Sie jemanden benennen. Nicht jedes Feld braucht einen Verantwortlichen. Wer alle regeln will, endet mit einer Tabelle, die nie fertig wird. Beginnen Sie mit den Feldern, die eine Entscheidung steuern: die ein Report, eine Übergabe oder eine Automatisierung ausliest. Lifecycle Stage, Deal Stage, Einwilligungsstatus, Account Owner, Hauptkontakt und eine Handvoll weiterer tragen meist das meiste Gewicht. Der lange Rest an Feldern, die nett zu haben sind, kann ungeregelt bleiben, ohne jemandem zu schaden.

Benennen Sie für jedes Feld auf der Liste genau einen Verantwortlichen. Kein Gremium und kein Team, sondern eine Rolle, die dafür einsteht, dass dieses Feld stimmt. Diese Person muss nicht die einzige sein, die das Feld bearbeitet, aber sie legt fest, was ein gültiger Wert ist, und bemerkt, wenn er abdriftet. Der Test ist einfach. Wenn ein Feld falsch ist, gibt es dann genau eine Person, deren Aufgabe es war, es richtig zu halten? Lautet die Antwort „mehrere“ oder „wohl der CRM-Admin“, hat das Feld keinen echten Verantwortlichen und verfällt, egal wie sauber es anfängt.

An der Verantwortung entscheidet sich auch die Akzeptanz. Menschen vertrauen einem Datensatz, von dem sie sehen, dass er gepflegt wird, und sie pflegen einen Datensatz, für den sie verantwortlich sind. Ein Feld mit benannter Verantwortung wird verteidigt. Ein Feld, das allen gehört, wird aufgegeben, und ein einziges aufgegebenes Feld, auf das ein Report angewiesen ist, macht den ganzen Report fragwürdig. Das ist der leise Mechanismus hinter ungenutzten CRMs: kein großes Scheitern, sondern eine langsame Anhäufung von Feldern ohne Verantwortliche, bis niemand mehr den Reports darauf vertraut.

Eine Quelle pro Information: welches System bei Widerspruch gewinnt

Am schwersten durchzusetzen ist die Regel zur Quelle, weil Informationen selten an einem Ort liegen. Der Zahlungsstatus liegt in der Abrechnung, die Deal Stage im CRM, der Ticketstatus im Support, Engagement und Einwilligung in der Marketing-Plattform. Wenn zwei Systeme dieselbe Information halten und sich widersprechen, braucht das Operating Model eine im Voraus festgelegte Antwort, welches gewinnt. Nicht jedes Mal eine neue Diskussion, wenn die Reports auseinanderlaufen.

Die Faustregel, die die meisten Fälle löst: Das maßgebliche System für eine Information ist das, in dem sie als Nebenprodukt echter Arbeit entsteht und sich ändert, nicht das, in dem sie bequem zu lesen ist. Die Abrechnung ist für den Zahlungsstatus zuständig, weil dort das Geld fließt. Der Support ist für den Ticketstatus zuständig, weil dort das Ticket bearbeitet wird. Der Vertrieb ist für die Deal Stage zuständig, weil dort der Deal vorankommt. Das CRM liest diese Informationen dann aus den zuständigen Systemen ein, statt sie von Vertriebsmitarbeitern abtippen zu lassen. Eine abgetippte Information ist eine zweite Version, die nur darauf wartet, der ersten zu widersprechen.

Hier hat ein Entscheidungsbaum seinen Platz. Gehen Sie jede strittige Information durch: Gibt es ein System, in dem sich diese Information im Zuge der Arbeit ändert? Wenn ja, ist dieses System die Quelle, und das CRM bezieht sie von dort. Ändern zwei Systeme sie beide, muss das Modell eines als maßgeblich festlegen und das andere für diese Information schreibgeschützt machen, sonst ist der Widerspruch garantiert. Ist kein System eindeutig zuständig, ist das ein Zeichen, dass die Information erst einen festen Ort braucht, bevor man ihr irgendwo trauen kann. Der maßgebliche Moment folgt derselben Logik: Die Interaktion wird einmal erfasst, in dem System, in dem sie stattfand, und fließt von dort in den Datensatz.

Wo das Operating Model bricht

Ein Operating Model nützt nur, wenn Sie wissen, wo es versagt. Dieses hat vier ehrliche Bruchstellen, die Sie beim Entwurf einplanen sollten.

Felder ohne natürliche Zuständigkeit. Manche Felder gehören zu keinem Team, und einen Verantwortlichen zu erzwingen, ergibt eine Zuweisung auf dem Papier, an die sich niemand hält. Besser ist die Frage, ob das Feld überhaupt Entscheidungen steuern sollte. Ein Feld, das wichtig genug zum Regeln ist, aber niemandem gehört, ist meist eine Prozesslücke im Gewand eines Datenproblems.

Einwilligungsstatus, der sich zwischen Systemen widerspricht. Daten zu Einwilligungen und Präferenzen liegen oft an mehreren Stellen zugleich, und sie haben ein rechtliches Gewicht, das der Rest des Datensatzes nicht hat. Sind sich Marketing-Plattform und CRM uneinig, ob jemand eingewilligt hat, ist der sichere Standard der restriktivere Status. Das Operating Model sollte das ausdrücklich festhalten, statt es der Synchronisation zu überlassen, die zufällig zuletzt lief.

Ein Modell, das definiert, aber nicht durchgesetzt wird. Die Regeln aufzuschreiben ist die leichte Hälfte. Ein Modell in einem Dokument, das niemand öffnet, ist Governance-Theater, und es verfällt, sobald die Person, die es geschrieben hat, die Rolle wechselt. Durchsetzen heißt, dass die Regeln in die Synchronisation der Systeme und in die Anlage neuer Felder eingebaut sind, nicht in ein Richtlinien-PDF.

Überdimensionierte Tools, die Sie nicht brauchen. Im Enterprise-Segment wird dieses Problem mit Master-Data-Management-Plattformen und Customer Data Platforms gelöst, und mittelständische Teams glauben oft, sie bräuchten dasselbe. Die meisten nicht. Die Regeln sind in jeder Größenordnung gleich. Die Plattform lohnt sich erst, wenn die manuelle Durchsetzung nicht mehr mithält. Wer die Plattform kauft, bevor es die Regeln gibt, bekommt das ursprüngliche Problem mit einer höheren Rechnung zurück.

Ein Check, bevor Sie die Tools anfassen

Der kürzeste ehrliche Weg: Legen Sie die entscheidungsrelevanten Felder fest, geben Sie jedem einen Verantwortlichen, bestimmen Sie für jede strittige Information eine maßgebliche Quelle, legen Sie pro Interaktion einen Schreibpunkt fest, und wählen oder reparieren Sie erst dann die Tools, die das Beschlossene durchsetzen. Tools zuletzt, nicht zuerst. Eine Plattform, die gekauft wird, bevor es Regeln gibt, wird zum Spiegel, der dasselbe Chaos in einer saubereren Oberfläche zurückwirft.

Drei Fragen zeigen, ob das Modell wirklich existiert. Können Sie für Ihre wichtigsten Felder jeweils genau einen Verantwortlichen nennen? Können Sie für jede Information, die zwei Systeme halten, sagen, welches gewinnt? Und ist der Schreibpunkt für jede Interaktion eine einzige Stelle, oder erfassen drei Teams dasselbe Ereignis an drei Bildschirmen? Gibt es diese Antworten, ist der Datensatz vertrauenswürdig, das CRM darauf wird genutzt, und die Daten werden endlich etwas, auf das das Team echte Entscheidungen stützen kann, statt sie ständig anzuzweifeln. Gibt es sie nicht, hält keine Migration und keine Bereinigung, denn was den letzten Datensatz kaputt gemacht hat, ist noch immer nicht definiert.

Das Operating Model ist der Teil, den kein Tool mitliefert, und er entscheidet, ob das nächste CRM genutzt oder wie das letzte aufgegeben wird. Wenn Sie über eine Bereinigung, eine Migration oder eine neue Plattform nachdenken, legen Sie zuerst die Verantwortlichkeiten fest und danach die Tools. Flatline arbeitet mit B2B-Teams an HubSpot- und Kundendaten-Setups und kann Ihren aktuellen Datensatz an diesen drei Regeln messen, um zu klären, ob Sie ein Datenproblem oder ein Modellproblem haben. Ohne Zeitdruck, ohne Rabatt.

Häufig gestellte Fragen

Was ist ein Operating Model für einen einheitlichen Kundendatensatz?

Es ist das Regelwerk, das einen Kundendatensatz vertrauenswürdig macht: eine verantwortliche Person für jedes entscheidungsrelevante Feld, ein maßgebliches System für jede Information und ein fester Schreibpunkt für jede Interaktion. Es ist ein Governance-Modell, keine Software, und es wird vor jeder Tool-Entscheidung festgelegt, statt anzunehmen, dass es mit der Plattform geliefert wird.

Warum verlieren CRM-Daten das Vertrauen der Nutzer?

Weil ein CRM speichert, was jedes Team eingibt, und die Widersprüche dazwischen nicht auflöst. Ohne Verantwortliche für Felder und eine festgelegte Quelle für jede Information hat derselbe Kunde bald drei Versionen in Vertrieb, Marketing und Support. Sobald die Leute merken, dass die Reports falsch sind, vertrauen sie dem System nicht mehr und kehren zu ihren eigenen Listen zurück. Das verstärkt die Zersplitterung weiter.

Brauchen Sie eine CDP oder ein MDM für einen einheitlichen Kundendatensatz?

Meist nicht, zumindest nicht zuerst. Eine Customer Data Platform oder ein Master-Data-Management-System setzt Regeln durch, erfindet sie aber nicht. Mittelständische Teams, die Verantwortlichkeiten und Quellen sauber festlegen, kommen oft ohne beides zu einem vertrauenswürdigen Datensatz. Die Plattform rechnet sich erst, wenn die manuelle Durchsetzung nicht mehr mithält, und wer sie kauft, bevor es Regeln gibt, bekommt meist das alte Durcheinander zurück.

Wer sollte für Kundendaten im CRM verantwortlich sein?

Verantwortung gilt pro Feld, nicht pauschal. Jedes entscheidungsrelevante Feld bekommt eine verantwortliche Rolle, die festlegt, was ein gültiger Wert ist, und bemerkt, wenn er abdriftet. Ein einzelner „Data Owner“ für das ganze CRM ist zu breit, um real zu sein. Die sinnvolle Einheit ist das Feld, und die sinnvolle Verantwortung liegt bei der Rolle, die der Arbeit am nächsten ist, aus der die Information entsteht.

Das Wichtigste in Kürze

• Ein CRM wird aufgegeben, wenn niemand dem Datensatz darin vertraut, und Vertrauen ist eine Frage des Operating Models, nicht der Software. Neue Tools mit denselben fehlenden Regeln scheitern auf dieselbe Weise.

• Das Modell besteht aus drei Regeln: ein Verantwortlicher pro Feld, eine Quelle pro Information, ein maßgeblicher Moment pro Interaktion. Jede verhindert einen bestimmten, vorhersehbaren Fehler.

• Beginnen Sie mit Verantwortung und beschränken Sie sich auf Felder, die Entscheidungen steuern. Ein Feld, das allen gehört, gehört niemandem, und ein einziges Feld ohne Verantwortlichen kann einen ganzen Report fragwürdig machen.

• Halten zwei Systeme dieselbe Information, legen Sie den Gewinner vorab fest: Maßgeblich ist das System, in dem sich die Information im Zuge echter Arbeit ändert. Das CRM liest sie von dort ein, statt sie abtippen zu lassen.

• Wählen Sie die Tools zuletzt. Die meisten mittelständischen Teams brauchen keine CDP und kein MDM für einen vertrauenswürdigen Datensatz, sondern die Regeln, konsequent durchgesetzt. Wer zuerst die Plattform kauft, bekommt das Chaos in einer saubereren Oberfläche zurück.