Gruppenweite HubSpot-Implementierung

Warum ist ein gruppenweites CRM ein Wachstumshebel und kein IT-Projekt?

Solange jede Portfoliofirma ihr eigenes CRM betreibt, bleibt der Umsatz zwischen den Firmen unsichtbar. Cross-Selling hängt an persönlichen Netzwerken, jede Einheit verhandelt eigene Softwareverträge, und ein neuer Group-CRO rekonstruiert im ersten Quartal Pipelines statt den Value Creation Plan umzusetzen. Das ist kein Werkzeugproblem. Es ist ein Steuerungsproblem mit drei Preisschildern.

• Das Neugeschäft bleibt zufällig. Neukundengewinnung und Cross-Selling entstehen aus zufälligem Austausch zwischen den Firmen, nicht aus einem systematischen Prozess.
• Das EBITDA bleibt unnötig tief. Jede Firma kauft, wartet und integriert ihre eigenen Systeme, und das Gruppenreporting wird jeden Monat von Hand in Tabellen zusammengesetzt.
• Jeder Leadership-Wechsel verzögert die Wertschöpfung. Neue CEOs, CROs oder CFOs rekonstruieren Prozesse, Pipelines und Playbooks, statt Value Creation zu steuern.

Die Ausgangslage sieht nach dem dritten Add-on fast immer gleich aus. Firma A hat ein etabliertes CRM mit dokumentierten Prozessen und teilweise manuellem Reporting. Firma B pflegt eine Insellösung halb, mit eigenen Stages und eigenen Definitionen. Firma C arbeitet in Excel und ohne Pipeline-Logik. Darüber liegen ein ERP je Einheit, eigene Marketing-Tools und ein Gruppenreporting, das manuell entsteht. Jede dieser lokalen Lösungen kann für sich zielführend sein. Zusammen erschweren sie genau die Steuerung, für die das Portfolio gekauft wurde.

Die Fragen, die ein Operating Partner dazu stellt, sind einfach. Wo entstehen Synergien? Welcher Forecast ist belastbar? Wie viele Kunden betreuen wir mehrfach, ohne es zu wissen? Welche Systeme sind redundant? Was kostet uns der nächste Leadership-Wechsel? Keine dieser Fragen lässt sich aus fünf getrennten Systemen beantworten.

Unsere These: Das CRM ist keine Software-Entscheidung. Es ist die operative Schicht, auf der der Synergy Case läuft. So steht es auch auf unserer Seite zum unternehmensweiten HubSpot CRM, und dort steht die Grössenordnung, die wir in Portfolios regelmässig sehen.

• 5–10 Verträge pro Unternehmen, kein Cross-Sell zwischen Marken
• Marketingausgaben 2–4× dupliziert
• Group-Reporting monatlich in Excel neu aufgebaut

Der Business Case hat deshalb zwei Ebenen, und beide werden getrennt gerechnet. Erst die Gesamtbetrachtung aus operativen Kosten und Umsatzwachstum ergibt die Zahl, auf deren Basis eine Gruppe entscheidet.

Webinar-Deck · PDF · 29 Folien · Deutsch

Ein CRM für 5+ Portfolio-Firmen effizient aufsetzen

Die Präsentation zum Webinar von Erik Steffen (HubSpot Service Lead) und Eric Mattner (HubSpot Marketing Service Lead), an einem realen Fall mit 5+ Portfoliofirmen aufgebaut.

• Operating Model und Architektur: gemeinsamer Kern, lokale Kante, Shared Account Model
• Rollout in sechs Phasen, mit MVP-Grenzen und Fallback für fehlende Integrationen
• Governance, Adoption und die zwölf Punkte, die vor dem Rollout entschieden sein müssen

Präsentation herunterladen (PDF)

Was muss in der Gruppe gleich sein, und was darf lokal bleiben?

Gleich sein muss alles, was die Gruppe vergleichen, zusammenrechnen oder von einer Firma an die andere übergeben will. Lokal bleiben darf alles, was ein Markt oder ein Geschäftsmodell wirklich anders macht. Wird diese Linie nicht bewusst gezogen, zieht sie sich von selbst, in jeder Firma anders und ohne dass jemand es entschieden hat. Danach ist sie nur noch mit einer Migration korrigierbar.

Ein gruppenweites CRM ist kein Einheitsprozess. Es hat einen gemeinsamen Kern und eine lokale Kante, und der Streit in Projekten geht fast immer darum, wo die Linie zwischen beiden liegt. Die Tabelle ist die Antwort, die sich in unseren Portfolio-Projekten bewährt hat.

Die Prüfregel für jede Ausnahme ist kurz. Eine lokale Abweichung ist gültig, wenn Markt, Kunde, Geschäftsmodell oder Delivery wirklich anders sind. Sie ist nicht gültig, weil es immer so war.

Im Zielbild wird HubSpot zur gemeinsamen Entscheidungsebene der Gruppe. Dort liegen Unternehmen und Kontakte, Lifecycle und Pipelines, Ownership und Rechte, Consent und DSGVO, Automatisierung und Routing, Attribution, Forecast und Segmentierung. Die lokalen Systeme werden nicht ersetzt, sondern angebunden, wenn sie einen klaren Wertbeitrag leisten. Websites und Formulare, ERP und Billing, Service-Systeme und lokale Marketing-Tools können individuell bleiben, solange sie integriert sind. Oben kommen dann die Ergebnisse heraus, die eine Gruppe wirklich braucht. Ein konsolidierter Forecast. Cross-Sell-Signale. Belege für den ICP. Management-Reporting. Klare Übergaben.

Unsere These: Die Operating Company ist eine Segmentierung, keine zweite Ebene. Trennung wird nicht durch duplizierte Objekte gelöst, sondern durch eine Dimension, die überall gleich benutzt wird. Diese eine Dimension steuert, wem ein Account gehört, welches Team eine Übergabe bekommt, welche Fit-Definition gilt, welche Kampagne relevant ist, welche Sicht ein Reporting zeigt und wer sehen oder bearbeiten darf.

Woran merkt man, dass das CRM arbeitet und nicht nur speichert?

Ein Datenlager zeigt Pipeline und Historie, wenn jemand nachsieht. Ein System, das Geschäft auslöst, meldet sich von selbst, sobald eine zweite Einheit denselben Account schon betreut, und schlägt den nächsten Schritt vor. Für eine Gruppe mit fünf Firmen ist das der Unterschied zwischen sichtbaren Daten und tatsächlich gehobenem Cross-Selling.

Die meisten Konsolidierungsprojekte enden als System of Record. Das ist nicht wertlos, aber es ist die kleinere Hälfte des Business Case. Der grössere Teil entsteht erst, wenn das CRM den Nutzer anspricht statt umgekehrt.

• System of Record, das Datenlager mit Go-to-Market-Oberfläche. Kontakte und Companies sind erfasst. Pipeline ist sichtbar. Historie ist abgelegt. Reporting ist konsolidiert. Der Nutzer fragt das System.
• System of Action, das System, das Geschäft auslöst. Meldet ungefragt, wenn ein Account bereits von einer anderen Einheit betreut wird. Schlägt die nächste Aktion auf offenen Deals vor. Steuert, welcher Kontakt welche Kommunikation bekommt. Liefert Kontext zum Kunden, bevor der Call beginnt. Das System spricht den Nutzer an.

Drei Vorteile muss das System nach dem Go-live liefern, sonst war es nur eine Migration.

1. Cross-Sell-Flag. Ein Hinweis auf dem Account, sobald eine zweite Einheit dort bereits Geschäft macht.
2. Next Best Action. Ein konkreter nächster Schritt auf offenen Deals, nicht nur ein Fälligkeitsdatum.
3. Differenzierte Ansprache. Eine Segmentierung, die verändert, welche E-Mail ein Kontakt tatsächlich erhält.

Die Grundlage dafür ist das Shared Account Model. Eine Firma, eine Historie, mehrere Beziehungen. Für Firma A ist der Account ein Bestandskunde mit aktivem Vertrag und Service-Historie. Für Firma B ist er Cross-Sell-Potenzial mit Fit, aber ohne Kontaktverlauf. Firma C führt dort einen aktiven Deal mit eigenem Owner und eigener Pipeline-Stage. Firma D hat eine Partnerbeziehung ohne Verkaufschance. Alle vier sehen denselben Account, und trotzdem bleiben Beziehungen, Deals und Zuständigkeiten je Firma steuerbar.

Damit das funktioniert, müssen sechs Fragen vor der Automatisierung geklärt sein, nicht danach.

• Wer besitzt den Account?
• Wer besitzt den einzelnen Deal?
• Wer darf sehen, wer darf bearbeiten?
• Wie läuft die Übergabe zwischen den Firmen?
• Wie wird Revenue Credit verteilt?
• Wie werden Konflikte entschieden?

Unsere These: Das Cross-Sell-Problem wird nicht dadurch gelöst, dass alle dieselben Daten sehen. Gelöst ist es, wenn das System die Chance aktiv meldet und ein benannter Owner sie verantwortet.

Jung von Matt ist keine Private-Equity-Gruppe, aber die Ausgangslage war dieselbe. Der Vertrieb lief in den einzelnen Agenturen unabhängig, mit mehreren Systemen und mehreren Sales Funnels, und niemand hatte eine Gesamtsicht auf die Neugeschäfts-Pipeline der Gruppe. Genau dieses Muster trifft man nach dem dritten Add-on in fast jedem Portfolio.

Wie sprechen Marketing und Vertrieb in fünf Firmen dieselbe Sprache?

Ein MQL ist eine Marketing-Bewertung. Ein Lead ist eine aktive Übergabe an den Vertrieb. Wo beides dasselbe Wort trägt, streiten Marketing und Vertrieb in jeder Firma neu darüber, wer wann übernimmt, und der Group-Forecast zählt Verschiedenes zusammen. Die Lifecycle-Sprache gehört deshalb gruppenweit festgelegt. Die Übergabeschwelle darf je Firma verschieden sein.

Der Weg eines Kontakts ist in allen Firmen derselbe. Er tritt über ein Formular, einen Import, eine Kampagne oder ein Event ein. Er wird zum MQL, sobald sein Engagement eine gruppenweit gleich definierte Schwelle erreicht. Dann prüft der lokale ICP, ob Branche, Grösse, Geografie, Rolle und Use Case zu dieser Firma passen. Erst danach entsteht ein Lead, also eine aktive Übergabe, für die der Vertrieb das Follow-up mit klarer Verantwortung übernimmt. Bestätigt der Vertrieb das Kaufpotenzial, wird daraus ein SQL und ein Deal.

In HubSpot ist das Lead-Objekt der operative Übergabepunkt an den Vertrieb. Es verbindet Contact und Company im Sales Workspace. Laut HubSpots eigener Dokumentation hat das Lead-Objekt eine eigene Pipeline-Stage, getrennt von der Lifecycle Stage auf Contact und Company. Ein Contact kann also MQL sein, ohne dass bereits ein Lead im Sales Workspace existiert. Genau diese Trennung macht die Übergabe messbar.

Die Übergabeschwelle darf dagegen lokal sein. Firma A hat hohes Inbound-Volumen, dort erzeugen Engagement plus Fit-Schwelle automatisch einen Sales-Lead. Firma B hat geringes, strategisches Volumen, dort prüft ein Mensch die Inbox, bevor ein Lead an den Vertrieb geht. Beide nutzen dieselbe Lifecycle-Sprache und dasselbe Lead-Objekt. Nur die Schwelle unterscheidet sich, und das ist eine bewusste Entscheidung, keine historische.

Unsere These: Prozesse werden manuell validiert, bevor sie automatisiert werden. In einem Portal für eine Firma ist ein unsauberes Scoring ein Ärgernis. In einem Portal für fünf Firmen vererbt es sich auf alle gleichzeitig.

Wer entscheidet, wann der Vertrieb übernimmt?

Zwei Fragen entscheiden darüber, und sie werden regelmässig vermischt. Zeigt der Kontakt Interesse? Und passt seine Firma zu dieser Einheit? Interesse lässt sich gruppenweit gleich messen, weil ein Klick in Hamburg dasselbe ist wie in Zürich. Passung nicht, weil sich Zielmärkte, Dealgrössen und Rollen zwischen den Firmen unterscheiden.

Deshalb wird das Verhaltenssignal standardisiert und der kommerzielle Fit bleibt lokal. Ein gruppenweiter Engagement Score bewertet E-Mail-Klicks und relevante Öffnungen, Schlüssel-Formulare und Content-Downloads, Event- und Webinar-Teilnahme, High-Intent-Aktivität auf der Website sowie Ads- und Social-Engagement nach einer Logik. Ein ICP- oder Fit-Score je Firma bewertet Unternehmensgrösse und Mitarbeiterzahl, Branche und Geografie, Umsatz, Funding und Technologie, Rolle und Seniorität sowie den konkreten Bedarf. Eine KI-gestützte ICP-Prüfung kann diese Bewertung anreichern und priorisieren. Workflow, Routing und Lead-Erstellung bleiben deterministisch, damit jede Übergabe erklärbar ist.

Wie die Übergabe dann konkret läuft, richtet sich nach Volumen und Datenqualität, nicht nach technischer Machbarkeit.

Unsere These: Wer Engagement und Fit in eine Zahl presst, verliert genau die Information, die der Vertrieb am meisten braucht. Ob ein aktiver Kontakt auch geschäftlich passt, oder nur aktiv ist.

Was standardisiert das Marketing zentral, und was bleibt bei den Firmen?

Zentral gehört alles, was später verglichen wird. Lokal bleibt alles, was ein Kunde in seinem Markt sieht. Das Kampagnen-Framework, die Formulare, das Scoring und die Attribution werden einmal gebaut. Inhalte, Marke, Events und Sprache setzt jede Firma selbst um. So entsteht ein Reporting über alle Marken, ohne dass eine Zentrale jede Kampagne freigeben muss.

Zentral standardisiert werden das Kampagnen-Framework mit fester Naming Convention, die Formulare und Subscription-Typen, das Engagement-Scoring, Attribution und Reporting sowie der Filter nach Operating Company. Lokal verantwortet werden Content und Kampagnen-Execution, Brand-Umsetzung und Templates, Events und lokale Aktivitäten, Nurture-Inhalte je Markt sowie Sprache und Marktansprache. Eine Naming Convention kann Operating Company, Sprache, Kanal, Kampagnentyp, Zielgruppe, Thema und Zeitraum kombinieren, zum Beispiel OPCO-A | DE | E-Mail | Lead Generation | CRM Leads | 2026. Formulare entstehen pro Sprache statt pro Firma, mit standardisierten Pflichtfeldern und lokalen Übersetzungen, und werden aus Templates dupliziert statt neu gebaut. Das allein verhindert die meisten überflüssigen Properties.

HubSpot bringt für Multi-Marken-Konten das Brands-Add-on mit, früher Business Units. Damit lassen sich Formulare, Seiten, Marketing-E-Mails, Kampagnen und eine zusätzliche Brand-Domain je Marke zuordnen, und auf Contacts entsteht automatisch eine Brand-Property zum Filtern. Für Companies und Deals beschreibt die offizielle HubSpot-Dokumentation keine native Brand-Zuordnung. Genau diese Lücke schliesst die eigene Operating-Company-Property. Sie funktioniert über alle relevanten Objekte hinweg, also auf Contacts, Companies, Deals und Leads, und trägt damit auch das Reporting. Ein gruppenweites Dashboard zeigt Kontakt- und Lead-Entwicklung, Kampagnen- und E-Mail-Performance, Deal- und Revenue-Attribution sowie den Engagement Score, und dieselbe Struktur lässt sich auf eine einzelne Firma einschränken, ohne zwei Dashboards zu pflegen.

Ein Punkt wird in Gruppen regelmässig zu spät entschieden, und er lässt sich nachträglich kaum reparieren. Ein Kontakt interagiert mit mehreren Portfoliofirmen. Vor dem Build muss deshalb geklärt sein, ob Consent gruppenweit oder pro Firma gilt, ob pro Firma abgemeldet werden kann, welche Subscription-Typen geteilt sind und wie Legacy-Opt-ins und Double-Opt-in migriert werden.

Unsere These: Marketing ist Teil des Revenue-Operating-Models, nicht dessen Kampagnen-Execution. Deshalb wird das Marketing-Framework zusammen mit dem CRM designt und nicht danach angeflanscht.

In welcher Reihenfolge baut man das gruppenweite CRM auf?

Nicht mit der Software. Zuerst wird entschieden, welche Entscheidungen besser werden sollen und wo in der Gruppe Wert entsteht. Dann folgen Prozessdesign, Architektur und ein kleiner Pilot mit einer Firma. Migration und Automatisierung kommen zuletzt. Wer die Reihenfolge umdreht, übersetzt bestehende Unklarheit in neue Prozesse und baut sie damit fest.

Der Rollout läuft in sechs Phasen.

1. Zielbild und Value Creation. Welche Entscheidungen sollen besser werden, wo entsteht Wert, was bleibt lokal.
2. Prozessdesign. Customer Journey, Pipelines, ICPs, Gemeinsamkeiten und Unterschiede, Segmentierung, Ownership, Übergabe.
3. Architektur und Daten. Objekte, Datenfelder, Pipeline-Phasen, Rechte, Routing, Reporting-Ebene, Migrationsregeln.
4. MVP und Pilot. Kleiner Scope für ein erstes Unternehmen als Pilot.
5. Sequenzieller Rollout. Unternehmen nach Unternehmen, jede Teilmigration verbessert das Gesamtsystem.
6. Enablement und Governance. Power-User-Modell, Change-Prozess, Akzeptanz-Messung, Nutzung im Tagesgeschäft.

Bevor der MVP gebaut wird, müssen fünf Entscheidungen gefallen sein. Sonst übersetzt das CRM bestehende Unklarheit nur in neue Prozesse. Das Value-Creation-Ziel, also Forecast, Cross-Sell, Neugeschäft, Kosten, Verkaufszeit oder Datenqualität. Die gemeinsamen Definitionen von Account bis Revenue Credit. Die Decision Rights, also was die Gruppe entscheidet, was die Firmen und was der CRM-Admin. Ownership und Übergabe für Company, Contact, Lead, nächste Aktivität, Deal und Forecast. Und ein messbarer MVP mit den drei bis fünf Bereichen, die nach dem Pilot besser sein sollen. Die Leitfrage dazu lautet, welche Entscheidung durch das gemeinsame CRM schneller, belastbarer oder günstiger wird. Fehlt die Antwort, ist der Use Case noch nicht bereit für den Build.

Der MVP standardisiert den Kern, nicht jede Ausnahme im einzelnen Unternehmen. Im Workshop werden Prozesse und Felder beschrieben, bevor jemand im System gearbeitet hat. Sobald der Kern live ist, liefern die Power User aus dem Tagesgeschäft konkrete Präzisierungen und neue Use Cases. Der Scope wächst danach gezielt weiter, auf Basis realer Entscheidungen statt Annahmen.

Big-Bang-Rollouts scheitern an derselben Stelle. Wer alles vor dem ersten Test lösen will, erzeugt Verzögerung statt Erkenntnisse. Zu viele Abhängigkeiten laufen gleichzeitig, Entscheidungen bleiben theoretisch, die Datenqualität verschlechtert sich weiter, Tests und Adoption starten zu spät, Feedback kommt nach dem Architektur-Freeze, und die Teams verlieren das Vertrauen, weil nichts live ist. Die bessere Sequenz ist kurz. Kern bauen. Pilot mit einem Unternehmen. Priorisierte Daten migrieren. Training und Feedback. Verfeinern und skalieren. In unseren Portfolio-Projekten heisst das 3–9 Monate Plattformaufbau plus erste Portfolio-Wellen, und ab Woche 8 stehen Group-Dashboards für Operating Partner live.

Unsere These: Ein verzögerter Feinschliff des MVP ist kein Grund, den Rollout zu stoppen. Eine unklare Definition ist einer.

Welche Historie zieht um, und was passiert, wenn ERP und Billing noch nicht angebunden sind?

Historie ist wertvoll, wenn sie Entscheidungen stützt. Eine unklare Migration vernichtet Kontext, eine ungefilterte überträgt Altlasten in das neue System. Deshalb wird priorisiert statt kopiert, und das Marketing darf erst anschreiben, wenn Consent geprüft ist. Fehlt noch eine Integration, überbrückt ein kontrollierter manueller Übergabeprozess die Lücke, statt den Go-live zu verschieben.

Vor jedem Import stehen dieselben Qualitätschecks. Feld-Mapping, Counts, Zuordnungen, Eigentümer, offene Deals, Stage-Mapping, Consent und Opt-outs, Deduplizierung, Testdurchläufe und ein Fallback-Plan. Historische Quellsysteme erlauben selten eine direkte 1:1-Zuordnung zu HubSpot-Status, deshalb braucht es eine dokumentierte Mapping-Logik. Wo Quelldaten lückenhaft sind, dokumentiert das Team die Einschränkung, statt sie stillschweigend zu glätten.

Für das Marketing gilt eine strikte Trennung zwischen Datenmigration und Aktivierung. Marketingkontakte werden erst angeschrieben, wenn Consent validiert und Subscription-Typen zugewiesen sind, nie automatisch mit dem technischen Import. Acht Schritte in fester Reihenfolge machen das überprüfbar.

1. Datenquellen der einzelnen Firmen analysieren.
2. Property-Mapping zwischen Quellsystemen und dem gemeinsamen HubSpot-Datenmodell definieren.
3. Dubletten und fehlerhafte Datensätze vor dem Import bereinigen.
4. Consent-Informationen validieren, statt sie ungeprüft zu übernehmen.
5. Kontakte importieren.
6. Subscription-Typen pro Kommunikationszweck zuweisen.
7. Suppression-Listen für nicht mehr kontaktierbare Datensätze erstellen.
8. Marketingaktivitäten erst danach aktivieren.

Und wenn ERP, Billing oder das Projektsystem noch nicht angebunden sind? Dann kommt zuerst der Soft Handover und danach der System Handover. In Stufe A entsteht bei einer definierten Deal-Stage ein Ticket oder eine Aufgabe, das zuständige Team wird benachrichtigt, Deal- und Kundenkontext werden mitgegeben, und Projekt oder Auftrag werden downstream manuell angelegt. In Stufe B läuft der Datensatz über die Integrationsebene, die richtige Entität im Zielsystem wird gematcht, Projekt, Kunde oder Auftrag werden erzeugt, und ID und Status kommen ins CRM zurück.

Unsere These: Eine Integration, die den Go-live blockiert, ist ein Planungsfehler. Der Fallback-Betrieb wird vor der Automation entworfen, nicht danach improvisiert.

Wer darf was ändern, und wie bleibt das System nach dem Go-live in Benutzung?

Sichtbarkeit und Bearbeitungsrecht sind zwei getrennte Entscheidungen. Der Vertrieb braucht gruppenweite Sicht und darf bearbeiten, weil Cross- und Upsell sonst nicht stattfinden. Gemeinsame Marketing-Assets brauchen enge Rechte, weil ein Fehler dort in allen Firmen gleichzeitig wirkt. Und benutzt wird ein CRM nur, wenn Führung, Anreize und Abläufe daran hängen.

Die Governance braucht drei Rollen. Ein Executive Sponsor verantwortet Zielbild, Priorisierung und Konfliktentscheidung. Ein Group CRM Owner oder RevOps Owner verantwortet Architektur, Standards und die Freigabe von Änderungen. Lokale Power User je Firma verantworten Adoption, First-Line-Fragen, Tests und Feedback. Zentrale Standards gelten für Datenfelder, Bezeichnungen, Pipelines, Workflows, Integrationen und Änderungsanfragen. Für den Vertrieb ist ein Audit Trail besser als eine Sperre. Für das Marketing gilt das Gegenteil, weil ein falsch geändertes Template breit wirkt.

Der Änderungsweg ist immer derselbe.

1. Bedarf melden.
2. Business-Zweck dokumentieren.
3. Bestehende Logik prüfen.
4. Gruppenwirkung bewerten.
5. Freigeben, ablehnen oder neu designen.
6. Bauen, dokumentieren, kommunizieren.

Adoption entsteht danach im Tagesgeschäft, nicht im Training. Pipeline Reviews und Forecasts laufen nur noch aus dem CRM. Was nicht im System steht, erhält keinen Revenue Credit. Automatisierung spart dem Team Follow-up, Recherche und Reporting, und genau das ist der Nutzerwert, der Akzeptanz erzeugt. Die Power User spiegeln Optimierungspotenziale zurück, während das Kernsystem bestehen bleibt. Gemessen wird Adoption an Pflichtfeld-Vollständigkeit, Phasen-Hygiene, gepflegten nächsten Aktivitäten, Forecast-Nutzung, Qualität der Zuordnungen und der Zahl manueller Übergaben, in einem CRM Review in der Wochenauswertung.

Was in der Praxis regelmässig schiefgeht, lässt sich in acht Zeilen zusammenfassen.

Unsere These: Training erklärt das System. Ob es genutzt wird, entscheiden Führung, Anreize und Abläufe.

Wo entsteht der Wertbeitrag, und woran erkennt ihn der CFO?

Nicht im Datenmodell, sondern in besseren Entscheidungen und weniger operativer Reibung. Der Wert zeigt sich in vier Feldern gleichzeitig. Top-Line durch systematisches Cross-Selling über alle Einheiten. EBITDA durch weniger doppelte Lizenzen und Tools. Steuerbarkeit durch einen konsolidierten Forecast. Produktivität durch weniger Kontext-Rekonstruktion je Vertriebler. Wer nur eines davon misst, unterschätzt den Case.

• Top-Line. Systematisches Cross-Selling über alle Einheiten, schnelleres Follow-up auf offene Chancen, gemeinsame Account-Intelligenz.
• EBITDA. Weniger doppelte Lizenzen, weniger redundante Tools, weniger manuelles Reporting.
• Steuerbarkeit. Konsolidierter Forecast über alle Einheiten, gemeinsame KPI-Sprache, vergleichbare Pipelines, Win-Loss-Evidenz aus echten Abschlussdaten.
• Produktivität. Weniger Kontext-Rekonstruktion, weniger Tabellen-Konsolidierung, mehr Verkaufszeit je Vertriebler, ein datenbasierter ICP statt Annahmen.

Bevor ein Rollout startet, sollten zwölf Punkte beantwortet sein. Sie sind die Kurzfassung dieses Artikels und zugleich die Agenda für das erste Gespräch zwischen Operating Partner, Group-CRO und Marketing.

1. Value-Creation-Ziel. Welches Ergebnis soll besser werden?
2. Gemeinsame Definitionen. Von Account bis Revenue Credit.
3. Shared vs. Local. Was bleibt bewusst unterschiedlich?
4. Ownership. Accounts, Leads, Deals, Übergaben.
5. Governance. Wer ändert Properties und Pipelines?
6. Berechtigungen. Wer sieht, wer bearbeitet?
7. Datenmigration. Welche Historie ist entscheidungsrelevant?
8. Integrationsgrenzen. Welche Systeme bleiben lokal?
9. MVP. Welche Entscheidungen prüft der Pilot?
10. Pilot-Einheiten. Wer ist repräsentativ und bereit?
11. Enablement. Welche Power User, welches Timing?
12. Operating Rhythm. Laufen Forecast und Reviews im CRM?

Der nächste Schritt ist selten eine neue Automatisierung. Es ist die Entscheidung, welche drei bis fünf Bereiche eurer Gruppe ab morgen zentral gelten sollen, und welche bewusst bei den Firmen bleiben.

SalesPlaybook ist HubSpot Diamond Solutions Partner mit 39+ 5-Sterne-Bewertungen im HubSpot Solutions Directory und setzt gruppenweite Implementierungen von der Governance her auf. Bei Jung von Matt entstand daraus in 2 Monaten das „CRM als Single Source of Truth für den Vertrieb" einer Agenturgruppe mit 140+ Mitarbeitenden.