Gruppenweite HubSpot-Implementierung

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

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

• Das Neugeschäft bleibt Zufall. Neukundengewinnung und Cross-Selling entstehen, wenn sich Leute aus zwei Firmen zufällig austauschen. Einen systematischen Prozess dafür gibt es nicht.
• Das EBITDA bleibt unnötig tief. Jede Firma kauft, wartet und integriert ihre eigenen Systeme. Das Gruppenreporting setzt jemand jeden Monat von Hand aus Tabellen zusammen.
• Jeder Führungswechsel verzögert die Wertschöpfung. Neue CEOs, CROs oder CFOs rekonstruieren erst einmal Prozesse, Pipelines und Playbooks. Zum Steuern der Value Creation kommen sie erst danach.

Nach dem dritten Add-on sieht die Lage fast immer gleich aus. Firma A hat ein etabliertes CRM mit dokumentierten Prozessen, das Reporting läuft teilweise von Hand. Firma B pflegt eine Insellösung halbherzig, mit eigenen Stages und eigenen Definitionen. Firma C arbeitet in Excel, eine Pipeline-Logik gibt es nicht. Darüber liegen ein ERP je Einheit, eigene Marketing-Tools und ein Gruppenreporting, das jemand manuell zusammenbaut. Jede dieser lokalen Lösungen kann für sich sinnvoll sein. Zusammen erschweren sie genau die Steuerung, für die das Portfolio gekauft wurde.

Als Operating Partner stellst du dazu einfache Fragen: Wo entstehen Synergien, und welcher Forecast ist belastbar? Wie viele Kunden betreuen wir mehrfach, ohne es zu wissen? Welche Systeme sind redundant, und was kostet uns der nächste Führungswechsel? Aus fünf getrennten Systemen beantwortest du keine davon.

Unsere These: Das CRM ist keine Software-Entscheidung, weil es die operative Schicht ist, auf der dein Synergy Case läuft. So steht es auch auf unserer Seite zum unternehmensweiten HubSpot CRM. Dort findest du auch 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 du rechnest beide getrennt. Erst operative Kosten und Umsatzwachstum zusammen ergeben 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, was sich zwischen Märkten oder Geschäftsmodellen wirklich unterscheidet. Ziehst du diese Linie nicht bewusst, zieht sie sich selbst: in jeder Firma anders, ohne dass es jemand entschieden hat. Korrigieren lässt sie sich danach nur noch mit einer Migration.

Ein gruppenweites CRM ist kein Einheitsprozess, denn es hat einen gemeinsamen Kern und eine lokale Kante. Gestritten wird in Projekten fast immer darüber, wo die Linie zwischen beiden verläuft. Die Tabelle zeigt die Aufteilung, die sich in unseren Portfolio-Projekten bewährt hat.

Für jede Ausnahme reicht eine kurze Prüfregel. Eine lokale Abweichung gilt, wenn sich Markt, Kunde, Geschäftsmodell oder Delivery in der Sache unterscheiden. Dass es schon immer so war, reicht als Grund nicht.

Im Zielbild wird HubSpot zur gemeinsamen Entscheidungsebene der Gruppe. Dort liegen Unternehmen und Kontakte, Lifecycle und Pipelines, Ownership und Rechte. Auch Consent und DSGVO gehören dorthin, ebenso Automatisierung und Routing. Attribution, Forecast und Segmentierung laufen ebenfalls über diese Ebene. Statt die lokalen Systeme zu ersetzen, bindest du sie an, wenn sie einen klaren Wertbeitrag leisten. Websites und Formulare, ERP und Billing dürfen individuell bleiben, genauso Service-Systeme und lokale Marketing-Tools, solange sie integriert sind. Oben kommen dann die Ergebnisse heraus, die eine Gruppe braucht: ein konsolidierter Forecast und Cross-Sell-Signale. Dazu kommen Belege für den ICP, ein Management-Reporting und klare Übergaben.

Unsere These: Die Operating Company ist eine Segmentierung, keine zweite Ebene. Die Firmen trennst du nicht über duplizierte Objekte, sondern über eine Dimension, die überall gleich benutzt wird. Diese eine Dimension steuert, wem ein Account gehört und welches Team eine Übergabe bekommt. An ihr hängt, welche Fit-Definition gilt und welche Kampagne relevant ist. Und sie bestimmt, welche Sicht ein Reporting zeigt und wer sehen oder bearbeiten darf.

Woran merkst du, 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, sagt es Bescheid und schlägt den nächsten Schritt vor. Für eine Gruppe mit fünf Firmen trennt genau das sichtbare Daten von Cross-Selling, das tatsächlich Umsatz bringt.

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 dich anspricht statt umgekehrt.

• System of Record, das Datenlager mit Go-to-Market-Oberfläche. Kontakte und Companies sind erfasst. Die Pipeline ist sichtbar. Die Historie ist abgelegt. Das Reporting ist konsolidiert. Du fragst das System.
• System of Action, das System, das Geschäft auslöst. Es meldet ungefragt, wenn eine andere Einheit den Account bereits betreut. Es schlägt die nächste Aktion auf offenen Deals vor. Es steuert, welcher Kontakt welche Kommunikation bekommt. Und es liefert Kontext zum Kunden, bevor der Call beginnt. Das System spricht dich an.

Nach dem Go-live muss das System drei Vorteile 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: ein Kundenunternehmen mit einer Historie und mehreren 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. Obwohl alle vier denselben Account sehen, bleiben Beziehungen, Deals und Zuständigkeiten je Firma steuerbar.

Damit das funktioniert, klärst du sechs Fragen vor der Automatisierung, 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 löst du nicht, indem alle dieselben Daten sehen. Gelöst ist es erst, wenn das System die Chance aktiv meldet und ein benannter Owner sie verantwortet.

Jung von Matt ist zwar keine Private-Equity-Gruppe, die Ausgangslage war aber dieselbe. Jede Agentur verkaufte für sich, mit mehreren Systemen und mehreren Sales Funnels. Eine Gesamtsicht auf die Neugeschäfts-Pipeline der Gruppe hatte niemand. Genau dieses Muster findest du nach dem dritten Add-on in fast jedem Portfolio.

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

Wo MQL und Lead dasselbe bedeuten, streiten Marketing und Vertrieb in jeder Firma neu darüber, wer wann übernimmt. Der Group-Forecast zählt dann Verschiedenes zusammen. Dabei ist ein MQL nur eine Bewertung durch das Marketing, ein Lead dagegen eine aktive Übergabe an den Vertrieb. Leg die Lifecycle-Sprache deshalb gruppenweit fest, während die Übergabeschwelle je Firma verschieden sein darf.

Der Weg eines Kontakts ist in allen Firmen derselbe. Er kommt über ein Formular, einen Import, eine Kampagne oder ein Event herein. Zum MQL wird er, sobald sein Engagement eine Schwelle erreicht, die gruppenweit gleich definiert ist. Dann prüft der lokale ICP, ob der Kontakt zu dieser Firma passt: Branche und Grösse, Geografie und Rolle, dazu der Use Case. Erst danach entsteht ein Lead, also eine aktive Übergabe: Der Vertrieb übernimmt das Follow-up und trägt dafür klar die Verantwortung. 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 und 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. Bei Firma A mit viel Inbound-Volumen erzeugen Engagement und Fit-Schwelle automatisch einen Sales-Lead. Bei Firma B mit wenig, dafür strategischem Volumen 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. Das ist eine bewusste Entscheidung, keine historische.

Unsere These: Erst validieren, dann automatisieren. 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?

Darüber entscheiden zwei Fragen, 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 dagegen nicht, weil sich Zielmärkte, Dealgrössen und Rollen zwischen den Firmen unterscheiden.

Deshalb standardisierst du das Verhaltenssignal und lässt den kommerziellen Fit lokal. Ein gruppenweiter Engagement Score bewertet nach einer einheitlichen Logik, was ein Kontakt tut. Dazu zählen E-Mail-Klicks und relevante Öffnungen, Schlüssel-Formulare und Content-Downloads sowie Event- und Webinar-Teilnahmen. Auch High-Intent-Aktivität auf der Website fliesst ein, ebenso das Engagement mit Ads und auf Social Media. Der ICP- oder Fit-Score je Firma bewertet dagegen, wer der Kontakt ist. Er schaut auf Unternehmensgrösse und Mitarbeiterzahl, Branche und Geografie sowie Umsatz, Funding und Technologie. Dazu kommen Rolle und Seniorität und der konkrete Bedarf. Eine KI-gestützte ICP-Prüfung kann diese Bewertung anreichern und priorisieren. Workflow, Routing und Lead-Erstellung bleiben aber deterministisch, damit du jede Übergabe erklären kannst.

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 dringendsten braucht: ob ein aktiver Kontakt auch geschäftlich passt oder nur aktiv ist.

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

In die Zentrale gehört alles, was später verglichen wird. Lokal bleibt, was ein Kunde in seinem Markt sieht. Kampagnen-Framework, Formulare, Scoring und Attribution baust du deshalb nur einmal. 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 standardisierst du das Kampagnen-Framework mit einer festen Naming Convention. Dazu kommen Formulare und Subscription-Typen, das Engagement-Scoring und die Attribution. Auch das Reporting und der Filter nach Operating Company liegen zentral. Die Firmen verantworten dagegen den Content und die Umsetzung ihrer Kampagnen, die Marke und ihre Templates. Events und lokale Aktivitäten bleiben ebenfalls bei ihnen, genauso Nurture-Inhalte je Markt, die Sprache und die Marktansprache. Eine Naming Convention kann Operating Company, Sprache und Kanal enthalten, dazu Kampagnentyp und Zielgruppe, Thema und Zeitraum. Ein Beispiel: OPCO-A | DE | E-Mail | Lead Generation | CRM Leads | 2026. Formulare entstehen pro Sprache statt pro Firma, mit standardisierten Pflichtfeldern und lokalen Übersetzungen. Du duplizierst sie aus Templates, statt sie neu zu bauen. Das allein verhindert die meisten überflüssigen Properties.

Für Konten mit mehreren Marken bringt HubSpot das Brands-Add-on mit, das früher Business Units hiess. Damit ordnest du Formulare, Seiten und Marketing-E-Mails einer Marke zu. Das gilt auch für Kampagnen und für eine zusätzliche Brand-Domain je Marke. Auf Contacts entsteht dabei automatisch eine Brand-Property, nach der du filtern kannst. Für Companies und Deals beschreibt die offizielle HubSpot-Dokumentation keine native Brand-Zuordnung. Genau diese Lücke schliesst die eigene Operating-Company-Property. Diese Property funktioniert über alle relevanten Objekte hinweg, auf Contacts und Companies ebenso wie auf Deals und Leads. Damit trägt sie auch das Reporting. Ein gruppenweites Dashboard zeigt die Entwicklung von Kontakten und Leads, die Performance von Kampagnen und E-Mails, die Attribution von Deals und Revenue sowie den Engagement Score. Dieselbe Struktur lässt sich auf eine einzelne Firma einschränken, ohne dass du zwei Dashboards pflegst.

Einen Punkt entscheiden Gruppen regelmässig zu spät, und nachträglich lässt er sich kaum reparieren. Ein Kontakt interagiert mit mehreren Portfoliofirmen. Vor dem Build klärst du deshalb, ob Consent gruppenweit oder pro Firma gilt und ob sich jemand pro Firma abmelden kann. Ebenso klärst du, welche Subscription-Typen geteilt sind und wie du Legacy-Opt-ins und Double-Opt-in migrierst.

Unsere These: Marketing ist Teil des Revenue-Operating-Models und nicht bloss die Abteilung, die Kampagnen ausführt. Deshalb entsteht das Marketing-Framework zusammen mit dem CRM und wird nicht hinterher angeflanscht.

In welcher Reihenfolge baust du das gruppenweite CRM auf?

Fang nicht mit der Software an, sondern klär zuerst, 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 schreibt 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. Du legst Customer Journey, Pipelines und ICPs fest und klärst Gemeinsamkeiten und Unterschiede. Dazu kommen Segmentierung, Ownership und Übergabe.
3. Architektur und Daten. Du definierst Objekte, Datenfelder und Pipeline-Phasen. Dann folgen Rechte und Routing, die Reporting-Ebene und die Migrationsregeln.
4. MVP und Pilot. Ein kleiner Scope für ein erstes Unternehmen, das als Pilot startet.
5. Sequenzieller Rollout. Unternehmen nach Unternehmen. Jede Teilmigration verbessert das Gesamtsystem.
6. Enablement und Governance. Power-User-Modell, Change-Prozess und Akzeptanz-Messung, damit das System im Tagesgeschäft genutzt wird.

Bevor du den MVP baust, müssen fünf Entscheidungen gefallen sein, sonst bekommt die alte Unklarheit nur eine neue Oberfläche. Erstens das Value-Creation-Ziel: Geht es um Forecast, Cross-Sell oder Neugeschäft oder um Kosten, Verkaufszeit oder Datenqualität? Zweitens die gemeinsamen Definitionen, von Account bis Revenue Credit. Drittens die Decision Rights: was die Gruppe entscheidet, was die Firmen und was der CRM-Admin. Viertens Ownership und Übergabe: Wer verantwortet Company, Contact und Lead? Wer die nächste Aktivität, den Deal und den Forecast? Fünftens ein messbarer MVP mit den drei bis fünf Bereichen, die nach dem Pilot besser sein sollen.

Die Leitfrage dazu: Welche Entscheidung wird durch das gemeinsame CRM schneller, belastbarer oder günstiger? 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. Danach wächst der Scope gezielt weiter, auf Basis echter Entscheidungen statt Annahmen.

Big-Bang-Rollouts scheitern an derselben Stelle: Wer alles vor dem ersten Test lösen will, erzeugt Verzögerung statt Erkenntnisse. Während zu viele Abhängigkeiten gleichzeitig laufen und Entscheidungen theoretisch bleiben, wird die Datenqualität weiter schlechter. Tests und Adoption starten zu spät, und das Feedback kommt erst nach dem Architektur-Freeze. Am Ende verlieren die Teams das Vertrauen, weil nichts live ist.

Die bessere Sequenz ist kurz: Du baust den Kern und startest einen Pilot mit einem Unternehmen. Dann migrierst du priorisierte Daten, und nach Training und Feedback verfeinerst und skalierst du. 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. Weil eine unklare Migration Kontext vernichtet und eine ungefilterte Altlasten ins neue System schleppt, priorisierst du, statt zu kopieren. Das Marketing schreibt erst an, wenn der Consent geprüft ist. Fehlt noch eine Integration, überbrückt ein kontrollierter manueller Übergabeprozess die Lücke, sodass du den Go-live nicht verschieben musst.

Vor jedem Import stehen dieselben Qualitätschecks: Geprüft werden Feld-Mapping, Counts und Zuordnungen. Ebenso prüfst du Eigentümer, offene Deals und das Stage-Mapping, dazu Consent und Opt-outs sowie die Deduplizierung. Am Ende stehen Testdurchläufe und ein Fallback-Plan. Historische Quellsysteme lassen sich selten 1:1 auf HubSpot-Status abbilden, deshalb brauchst du eine dokumentierte Mapping-Logik. Wo Quelldaten lückenhaft sind, dokumentiert das Team die Einschränkung, statt sie stillschweigend zu glätten.

Im Marketing trennst du Datenmigration und Aktivierung strikt: Marketingkontakte schreibst du erst an, wenn der Consent validiert ist und die Subscription-Typen zugewiesen sind. Automatisch mit dem technischen Import passiert das nie, und 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, danach der System Handover. In Stufe A entsteht bei einer definierten Deal-Stage ein Ticket oder eine Aufgabe. Das zuständige Team wird benachrichtigt und bekommt den Deal- und Kundenkontext mit. Projekt oder Auftrag legt es im nachgelagerten System von Hand an. In Stufe B läuft der Datensatz über die Integrationsebene und wird der richtigen Entität im Zielsystem zugeordnet. Dort entstehen Projekt, Kunde oder Auftrag, und ID und Status kommen ins CRM zurück.

Unsere These: Eine Integration, die den Go-live blockiert, ist ein Planungsfehler. Den Fallback-Betrieb entwirfst du vor der Automation, statt ihn hinterher zu improvisieren.

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 Bearbeitungsrechte, weil Cross- und Upsell sonst nicht stattfinden. Gemeinsame Marketing-Assets brauchen enge Rechte, weil ein Fehler dort in allen Firmen gleichzeitig wirkt. Und im Alltag lebt 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 und Pipelines. Das Gleiche gilt für Workflows, Integrationen und Änderungsanfragen. Im Vertrieb ist ein Audit Trail besser als eine Sperre. Im Marketing gilt das Gegenteil, weil ein falsch geändertes Template überall durchschlägt.

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, und was nicht im System steht, bekommt keinen Revenue Credit. Die Automatisierung nimmt dem Team Follow-up, Recherche und Reporting ab, und genau dieser Nutzen schafft Akzeptanz. Die Power User melden zurück, wo sich etwas verbessern lässt, während das Kernsystem bestehen bleibt.

Adoption misst du im CRM Review der Wochenauswertung. Dort schaust du auf die Vollständigkeit der Pflichtfelder, die Phasen-Hygiene und gepflegte nächste Aktivitäten. Dazu kommen die Forecast-Nutzung, die Qualität der Zuordnungen und die Zahl manueller Übergaben.

Was in der Praxis regelmässig schiefgeht, passt in acht Zeilen.

Unsere These: Training erklärt das System, doch über seine Nutzung entscheiden Führung, Anreize und Abläufe.

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

Der Wertbeitrag entsteht nicht im Datenmodell, sondern in besseren Entscheidungen und weniger operativer Reibung. Er zeigt sich in vier Feldern gleichzeitig. Bei der Top-Line kommt er aus systematischem Cross-Selling über alle Einheiten, beim EBITDA aus weniger doppelten Lizenzen und Tools. Bei der Steuerbarkeit kommt er aus einem konsolidierten Forecast, bei der Produktivität aus 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 dein Rollout startet, sollten zwölf Punkte beantwortet sein. Die Liste ist 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?

Dein nächster Schritt ist selten eine neue Automatisierung. Es ist die Entscheidung, welche drei bis fünf Bereiche deiner 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.