HubSpot sanieren oder neu aufsetzen: die Entscheidung

Wie sieht ein verwahrlostes HubSpot eigentlich aus?

Ein verwahrlostes HubSpot sieht selten leer aus — es sieht aus wie ein System, das seit Jahren technisch vorhanden ist, aber niemandem gehört: unübersichtliche Daten, fehlende Segmentierung und Dashboards, denen niemand mehr vertraut, obwohl das Werkzeug selbst nie wirklich kaputt war.

Selten wie ein leeres Portal. Meist wie ein System, das seit Jahren technisch "vorhanden" ist, ohne dass es je jemandem gehörte. Das HubSpot von Platformatic war laut eigener Case Study "vorhanden, aber nicht wirksam genutzt" — mit "unübersichtlichen, unorganisierten Daten" und ohne "klare Segmentierungs- und Qualifizierungskriterien". Perspective beschreibt dieselbe Lücke aus Gründersicht: "das hatten wir damals einfach nicht" — gemeint waren Basis-Dashboards, Deal-Grösse, Sales-Cycle und Conversion-Rate. Beide Unternehmen waren nicht CRM-unerfahren. Beide hatten schlicht nie jemanden, dessen Aufgabe es war, das System bei jeder Veränderung des Geschäfts ehrlich zu halten.

Sanieren, Governance nachrüsten oder neu aufsetzen — was braucht ihr wirklich?

Welche Lösung passt, entscheidet sich daran, was unter der Oberfläche tatsächlich kaputt ist, nicht daran, wie chaotisch es aussieht: eine intakte Struktur mit chaotischen Daten braucht eine Bereinigung, ein fehlender Eigentümer braucht Governance, und nur ein echter Methodik-Wechsel — etwa durch eine Finanzierungsrunde — rechtfertigt ein vollständiges Rebuild.

Vier Situationen wiederholen sich über unsere Kundenbasis hinweg oft genug, um als Entscheidungsregeln zu funktionieren. Keine davon hängt daran, wie chaotisch es an der Oberfläche aussieht — sondern daran, was darunter tatsächlich kaputt ist.

Diese vier Regeln schliessen sich nicht aus — die meisten echten Mandate kombinieren mindestens zwei davon. START GLOBAL ist dafür das Paradebeispiel: eine Organisation, bei der laut Case Study "jedes Jahr über 50 % des Teams wechseln". Jahre dieser Fluktuation bedeuteten Deals aus verschiedenen Epochen in denselben Pipelines, Dubletten und einen Prozess, der komplett davon abhing, wer gerade zuständig war — genau die Art von Drift, die kein einmaliger Bereinigungs-Sprint löst, weil die Ursache bei jeder neuen Übergabe wieder frisches Chaos erzeugt. Das ist ein Governance-Problem, kein Daten- und kein Methodik-Problem. Was tatsächlich hielt, waren Namenskonventionen, Pflichtfelder auf den Objekten, die wirklich zählen, und klar dokumentierte Übergabepunkte zwischen den Vertriebler:innen — kein Neuaufsetzen, und auch keine einmalige Dublettenbereinigung. Der Unterschied zwischen beiden Wegen zeigt sich erst nach einigen Monaten: eine Bereinigung ist nach dem nächsten Teamwechsel wieder hinfällig, eine dokumentierte Übergabe nicht.

Fünf Case Studies, fünf verschiedene Ausgangslagen, und nur eine davon brauchte ein strukturelles Rebuild. Dieses Verhältnis ist der eigentliche Befund hier — nicht eine einzelne Zahl in der Tabelle.

Warum geht das Einfrieren des Vertriebs für ein "richtiges" Rebuild nach hinten los?

Das Einfrieren des Vertriebs für ein Rebuild geht nach hinten los, weil die offene Verkaufschancen nicht auf einen Migrationszeitplan wartet — ein monatelanger Stopp kostet mehr Umsatz, als das Rebuild je einspart, während eine phasenweise Migration Deals in der alten Struktur weiterlaufen lässt, während die neue darunter entsteht.

Auch wenn ein Rebuild die richtige Entscheidung ist: die Reihenfolge entscheidet, ob es Geld spart oder verbrennt.

Wie sieht eine phasenweise Sanierung konkret aus?

Eine phasenweise Sanierung trennt Daten-, Governance- und Strukturprobleme, behebt fehlende Governance zuerst, damit dasselbe Chaos nicht wieder auftaucht, repariert die Struktur vor den Daten darin, und migriert in Etappen gegen die laufende offene Verkaufschancen — nie in einem einzigen Schnitt, der den aktiven Vertrieb anhält.

Die Reihenfolge zählt mehr als die einzelnen Fixes. Zuerst die Ebene angehen, die aktuell am meisten Vertrauen kostet — nicht die, die am einfachsten zu fixen ist. Bei Möhrle Happ Luther hat André Ketzel den Ausgangspunkt präzise zusammengefasst: "There was a CRM without there being a CRM… they wanted to have some kind of well-dosed growth that they could steer." Das ist zuerst ein Strukturproblem, erst danach ein Datenproblem — solange die offene Verkaufschancen-Stages nicht widerspiegeln, wie Deals tatsächlich laufen, behebt keine Dublettenbereinigung ein falsches Reporting.

1. Erst diagnostizieren, dann anfassen. Trennen, was Daten-, Governance- und Strukturproblem ist — jedes braucht eine andere Reihenfolge.
2. Fehlende Governance zuerst nachrüsten. Namenskonventionen, Pflichtfelder und Objekt-Eigentümerschaft verhindern, dass dasselbe Chaos hinter jedem anderen Fix wieder auftaucht.
3. Struktur vor Daten reparieren. Saubere Daten in falschen offene Verkaufschancen-Stages liefern immer noch falsche Reports.
4. Phasenweise gegen die laufende offene Verkaufschancen migrieren. Nie den aktiven Vertrieb für die Reparatur anhalten — siehe der teure Fehler oben.

Nichts davon ersetzt HubSpots eigene Werkzeuge — die Knowledge-Base-Artikel zur Dublettenzusammenführung und zu den Datenqualitäts-Tools decken die Mechanik ab: Dubletten zusammenführen, Formatierungsfehler beheben. Was sie nicht beantworten, ist die Reihenfolge-Frage von oben — ob diese Tools überhaupt sinnvoll sind, bevor die Governance-Ebene steht.

Genau deshalb laufen unsere HubSpot-Sanierungsmandate mit Fixed Scope und Fixed Price statt offenen Stunden: Die Diagnose legt den Umfang vorher fest — es gibt keinen Anreiz, während der Uhr noch mehr zu finden, das zu reparieren wäre.