Datensilos abbauen: Warum RevOps ein Datenmodell braucht

RevOps-Initiativen scheitern in der Praxis selten an fehlender Software. Sie scheitern daran, dass Marketing, Sales und Service zwar dasselbe CRM nutzen, aber unterschiedliche Definitionen für dieselben Kernbegriffe verwenden. Was zählt als Lead? Ab wann wird aus einem Kontakt ein Kunde? Wann gilt eine Opportunity als aktiv oder verloren? Ohne eine abteilungsübergreifende, schriftlich fixierte Antwort auf diese Fragen bleibt jedes Reporting angreifbar und jede Automatisierung fehleranfällig. Das wirkt sich besonders dort aus, wo RevOps-Teams versuchen, durchgängige Kennzahlen wie Customer Acquisition Cost oder Lifetime Value zu berechnen, die auf Daten aus mehreren Abteilungen aufbauen.

Warum scheitert RevOps ohne gemeinsames Datenmodell?

RevOps setzt voraus, dass Marketing, Sales und Service auf denselben Zahlen aufbauen. Sobald ein Team einen Lead zählt, sobald ein Formular ausgefüllt wurde, ein anderes Team aber erst nach einem qualifizierenden Anruf, driften Conversion-Raten und Forecasts auseinander. Das Marketing-Dashboard zeigt eine Lead-to-Customer-Rate von 4 Prozent, das Sales-Dashboard eine andere, und niemand kann erklären, welche Zahl stimmt. Das Problem liegt nicht im Reporting-Tool. Es liegt in unterschiedlichen Kriterien, die nie explizit abgestimmt wurden. Reporting kann nur so gut sein wie die Datendefinitionen darunter, und genau diese Definitionen fehlen in den meisten Unternehmen als schriftliches Dokument.

Wo Datensilos trotz gemeinsamer CRM-Nutzung entstehen

Ein einzelnes CRM-System löst dieses Problem nicht automatisch. Auch innerhalb einer einzigen HubSpot- oder Salesforce-Instanz bauen Teams eigene Silos, ohne dass eine zweite Datenbank im Spiel ist. Typische Muster:

• Marketing und Sales pflegen eigene Custom Properties mit ähnlichem Namen, aber abweichender Bedeutung, etwa zwei Felder für Lead-Status, die unabhängig voneinander gepflegt werden.
• Lifecycle-Stages werden von einem Team automatisiert gesetzt und vom anderen Team manuell überschrieben, ohne dass es eine Regel gibt, wer das letzte Wort hat.
• Service definiert Kunde über einen aktiven Vertrag, Sales über einen gewonnenen Deal, Finance über eine bezahlte Rechnung. Alle drei Definitionen können zeitgleich für dasselbe Unternehmen unterschiedliche Ergebnisse liefern.
• Deals und Tickets laufen in getrennten Pipelines, ohne dass ein gemeinsames Verständnis existiert, was auf Unternehmensebene und was auf Kontaktebene gepflegt werden soll.

Dass Daten technisch in einer Datenbank liegen, macht sie noch nicht zu einer verlässlichen Grundlage für Entscheidungen. Wie unser Artikel Single Source of Truth im CRM: Ein Mythos, der scheitert zeigt, entsteht eine belastbare Datenbasis nicht durch ein einzelnes Tool, sondern durch klare Regeln, wer welche Daten wie definiert und pflegt.

Die Kosten ignorierter Datensilos

Die Folgen bleiben selten auf ein unschönes Dashboard beschränkt. Marketing schickt Kampagnen an Kontakte, die im Service-Team längst als gekündigt geführt werden. Vertrieb kalkuliert Forecasts auf Basis von Opportunity-Kriterien, die jeder Sales-Rep etwas anders auslegt, und die Geschäftsführung erhält Zahlen, die zwei Wochen später schon nicht mehr zur Realität passen. Bei DSGVO-Löschanfragen entsteht ein handfestes Risiko, wenn ein System einen Kontakt bereits als gelöscht führt, ein zweites System denselben Kontakt aber noch aktiv weiterverarbeitet, weil die Definition von aktiv abweicht. Ein Großteil der Zeit in RevOps-Meetings geht dafür drauf, Zahlenunterschiede zu erklären, statt operative Entscheidungen zu treffen.

Die Methodik: Ein Datenmodell über Abteilungsgrenzen hinweg entwickeln

Ein gemeinsames Datenmodell entsteht nicht im CRM-Adminbereich, sondern vorher, auf dem Papier oder im Whiteboard-Tool. Erst wenn Marketing, Sales, Service und idealerweise Finance sich auf Begriffe und Kriterien geeinigt haben, folgt die technische Umsetzung. Ein Vorgehen, das sich in der Praxis bewährt hat, läuft in fünf Schritten:

• Inventur: Welche Begriffe (Lead, MQL, SQL, Kunde, Opportunity, Account) nutzt jedes Team aktuell, und wie sind sie im CRM abgebildet? Diese Bestandsaufnahme deckt meist schon die größten Widersprüche auf.
• Workshop mit Entscheidungsbefugnis: Vertreter aus allen betroffenen Teams legen gemeinsam fest, welche Kriterien für jeden Begriff gelten, zum Beispiel: Ein Lead ist ein Kontakt mit Opt-in und einem Score über einem definierten Schwellenwert.
• Glossar und Objektzuordnung: Jede Definition wird einem konkreten Objekt und einer konkreten Property im CRM zugeordnet, unabhängig davon, ob das System HubSpot, Salesforce oder ein anderes Tool ist. Das Modell soll auch dann Bestand haben, wenn irgendwann ein Toolwechsel ansteht.
• Governance: Es braucht eine Regel, wer neue Properties anlegen darf und wer Änderungen am Modell freigibt. Ohne diese Rolle verwässert das Modell innerhalb weniger Monate wieder.
• Reporting-Abgleich: Nach der Umsetzung werden die zentralen Kennzahlen aus allen Teams gegenübergestellt. Erst wenn Marketing, Sales und Service bei denselben Grundzahlen ankommen, ist das Modell tatsächlich verbindlich.

Dieser Schritt lohnt sich besonders vor größeren Systemwechseln. Wer beispielsweise eine Migration von Salesforce zu HubSpot plant, spart sich erhebliche Nacharbeit, wenn das Datenmodell vor der technischen Migration bereits dokumentiert und abgestimmt ist, statt es während der Migration ad hoc zu klären.

Checkliste für den Workshop-Einstieg

Wer den ersten Workshop zur Entwicklung eines gemeinsamen Datenmodells plant, kann mit folgenden Fragen starten:

• Welche Objekte gibt es im CRM (Kontakt, Unternehmen, Deal, Ticket), und welches Team ist für die Pflege welcher Felder verantwortlich?
• Welche Lifecycle-Stages werden aktuell genutzt, und wer darf sie ändern, automatisiert oder manuell?
• Gibt es Properties mit demselben Namen, aber unterschiedlicher Bedeutung in verschiedenen Teams?
• Nach welchen Kriterien wird ein Lead qualifiziert, und sind diese Kriterien irgendwo schriftlich fixiert?
• Wie ist Kunde definiert, über den Vertragsstatus, den Zahlungsstatus oder den Deal-Status?
• Wer ist nach dem Workshop verantwortlich für die laufende Pflege und Weiterentwicklung des Modells?

Was das für RevOps-Reporting konkret bedeutet

Sobald ein Datenmodell über alle Teams hinweg verbindlich ist, verändert sich die Qualität der Reportings spürbar. Conversion-Raten zwischen Marketing und Sales werden vergleichbar, weil beide Teams denselben Lead-Begriff verwenden. Forecasts werden belastbarer, weil Opportunity-Kriterien nicht mehr von der Auslegung des einzelnen Sales-Reps abhängen. Automatisierungen, die auf Lifecycle-Stage-Wechseln basieren, laufen zuverlässiger, weil klar ist, wer eine Stage setzen darf und nach welcher Regel. Das ist keine einmalige Aufgabe. Ein Datenmodell muss gepflegt werden, wenn neue Produkte, neue Vertriebskanäle oder neue Reporting-Anforderungen dazukommen. Wer die Governance dafür von Anfang an einplant, spart sich, dieselbe Diskussion in zwei Jahren erneut führen zu müssen.

Häufig gestellte Fragen

Reicht ein einheitliches CRM-System aus, um Datensilos zu vermeiden?

Nein. Ein CRM-System schafft eine gemeinsame Datenbank, aber keine gemeinsamen Definitionen. Solange Teams unterschiedliche Kriterien für Begriffe wie Lead oder Kunde verwenden, entstehen Silos auch innerhalb einer einzigen Instanz.

Wie lange dauert die Entwicklung eines gemeinsamen Datenmodells?

Das hängt von der Anzahl der beteiligten Teams und der Komplexität der bestehenden Struktur ab. Die Kernabstimmung lässt sich oft in zwei bis drei Workshops über wenige Wochen erreichen, die technische Umsetzung und der Reporting-Abgleich brauchen zusätzliche Zeit.

Wer sollte an der Entwicklung des Datenmodells beteiligt sein?

Mindestens ein Vertreter aus Marketing, Sales und Service mit Entscheidungsbefugnis, dazu bei Bedarf Finance, wenn Umsatz- oder Vertragsdaten betroffen sind. Eine moderierende Person ohne Eigeninteresse an einer bestimmten Definition hilft, Konflikte zu lösen, statt sie zu verschleppen.

Muss das Datenmodell 1:1 in neue CRM-Felder übersetzt werden?

Nicht zwingend. In vielen Fällen lassen sich bestehende Properties umwidmen oder klarer definieren, statt neue Felder anzulegen. Wichtiger als die technische Umsetzung ist, dass die Definitionen dahinter abteilungsübergreifend abgestimmt sind.