Die meisten HubSpot-Implementations, die schiefgehen, gehen nicht schief, weil das Team das falsche Tool oder die falsche Beraterin gewählt hat. Sie gehen schief, weil jemand eine Phase komprimiert hat. Der Implementation-Bogen hat fünf: Discovery, Design, Build, Launch, Optimize, und jede endet mit einem Artefakt, das das Team verteidigt. Überspringen Sie das Artefakt, und die nächste Phase ruht auf Konversation statt Commitment. Die Kosten erscheinen zwei Monate später, wenn Build Entscheidungen wieder öffnet, die in Woche zwei hätten geschlossen sein sollen.
Warum das jetzt wichtig ist
Der HBR-Beitrag dazu, warum digitale Investitionen keinen Wert schaffen, formulierte es klar: Der Failure Mode ist nicht das Tooling, sondern das Versäumnis, neu zu gestalten, wie die kommerzielle Organisation Erkenntnisse generiert, Entscheidungen trifft und Handlungen koordiniert. Eine HubSpot-Implementation ist einer der wenigen Momente in einem B2B-SaaS-Unternehmen, in dem dieser Redesign offen auf den Tisch gezwungen wird, Schema, Pipelines, Verantwortung, Reporting, alles auf einmal. Die fünfphasige Methodik existiert, weil der Redesign die Arbeit ist. Die Plattform-Konfiguration ist das Artefakt am Ende.
Discovery
Discovery ist die Phase, die Teams am häufigsten komprimieren, und die, in der Komprimierung am teuersten ist. Die Aufgabe ist nicht, mit Leuten zu reden. Die Aufgabe ist, mit einem schriftlichen Artefakt herauszugehen, das das gesamte Team abgezeichnet hat, Pipeline-Definitionen, benannte Eigentümerinnen für jedes Objekt, eine Integrations-Karte, In-Scope- und Out-of-Scope-Use-Cases sowie die Erfolgskriterien, gegen die die Implementation gemessen wird. Zwei Wochen sind ein faires Budget. Eine Woche produziert eine Design-Phase, die Sie wiederholen müssen.
Wie schlecht aussieht, ein Discovery-Deck, das die im Einsatz befindlichen Tools auflistet, ein paar Interview-Zitate und vage Ziele. Niemand widerspricht, weil nichts spezifisch genug ist, um ihm zu widersprechen. Design entdeckt dann die Uneinigkeiten eine Entscheidung nach der anderen, vor einer Entwicklerin, die auf Richtung wartet.
Design
Design ist die Phase, in der die Schema-Entscheidungen leben. Jedes Objekt, das im Produktions-Portal existieren wird: Contact, Company, Deal, das Custom-Subscription-Objekt, gegebenenfalls das Portfolio-Objekt, wird hier definiert, schriftlich, bevor irgendetwas gebaut wird. Properties bekommen einen Datentyp, eine Picklist falls relevant, eine Eigentümerin und eine Ein-Satz-Definition. Pipeline-Stages bekommen Eintrittskriterien, Austrittskriterien und eine Definition, was die Stage tatsächlich bedeutet. Association-Labels werden ausbuchstabiert. Das Deliverable am Ende von Design ist ein Schema-Dokument plus ein Workflow-Inventar, das das Team Ende-zu-Ende lesen kann, ohne nachzufragen.
Wie schlecht aussieht, Design, das in der HubSpot-UI durch Klicken passiert. Properties werden live hinzugefügt. Pipeline-Stages werden dreimal umbenannt. Das Schema-Dokument, falls es existiert, hinkt dem Build um eine Woche hinterher. Drei Monate später erinnert sich niemand, warum die Deal-Stage „Verbal" existiert, und die einzige Person, die antworten könnte, ist gegangen.
Build
Build ist die Sprint-Phase. Gut gemacht, ist es eine Zwei-bis-Sechs-Wochen-Sequenz aus kleinen, abgegrenzten, reviewbaren Deliverables: Schema in eine Sandbox deployt, Workflows verdrahtet, Integrationen verbunden, Reports aufgesetzt, Permission Sets konfiguriert. Die Kadenz, die hält, ist wöchentlich, eine Working Session zur Bestätigung des nächsten Slices, ein Build-Sprint Mitte der Woche, eine Demo am Ende. Die Kadenz, die nicht hält, ist der Zwei-Wochen-Check-in, bei dem das Build-Team verschwindet und mit einem fertigen Portal wieder auftaucht, das niemand gesehen hat.
Build funktioniert nur, wenn Discovery und Design gehalten haben. Wenn ja, ist Build Ausführung gegen eine Liste. Wenn nicht, ist Build verkleidete Diskussion in Standup-Form. Der diagnostische Test, Wie viele Entscheidungen werden in einer beliebigen Build-Woche neu geöffnet? Wenn mehr als ein, zwei, war die vorgelagerte Arbeit nicht fertig.
Launch
Launch ist Cutover, Training und die ersten zehn Tage. Cutover ist ein Freitag: vorzugsweise einer vor einer ruhigen Woche: und wird in einer Sandbox geprobt, bevor er in Produktion passiert. Training wird gegen das Post-Build-System geliefert, nicht gegen das Legacy-System, und es wird an die Personen geliefert, die das System tatsächlich nutzen werden, nicht nur an die Leads, die es scoped haben. Die ersten zehn Tage sind ein Hypercare-Fenster, Das Build-Team ist auf Abruf, nutzerseitige Probleme werden in Stunden statt Tagen triagiert, und die kleinen Fixes, die in echter Nutzung erscheinen, landen, bevor das Team Muskelgedächtnis um Workarounds aufbaut.
Wie schlecht aussieht, ein Launch, der an einem Mittwoch passiert, weil der Kalender es vorgab, ein einmal aufgenommenes Trainings-Deck, das als Video zirkuliert, und ein Build-Team, das den Tag nach Cutover demobilisiert. Bis Woche drei sind die Workarounds Gewohnheiten, die Workarounds sind jetzt das System, und die Optimize-Phase wird sie zurückwickeln statt darauf aufbauen.
Optimize
Optimize ist die Phase, für die niemand ein Budget plant. Die Implementation wird bis Launch abgegrenzt; Optimize wird als Teilzeit-Admin-Arbeit von jemandem behandelt. Das ist der Fehler. Jede HubSpot-Instanz akkumuliert, Neue Properties werden angefragt, Workflows bekommen Edge Cases, Reporting-Bedürfnisse entwickeln sich, das Team lernt, was es tatsächlich sehen will versus was es zu sehen glaubte. Optimize ist die Phase, in der diese Signale auf einer Kadenz triagiert werden, monatlich ist für die meisten Unternehmen richtig, statt im täglichen Rauschen absorbiert zu werden.
Wie schlecht aussieht, Optimize ist, was die Senior-Ops-Person zwischen Bränden schafft. Sechs Monate später ist das System vom dokumentierten Schema gedriftet, niemand hat die Workflows seit Launch auditiert, und die nächste Person, die ins Team kommt, erbt eine Instanz, die zu zwei Dritteln Original-Design und zu einem Drittel Improvisation ist. Das Optimierungs-Budget, das niemand geplant hat, ist jetzt das Migrations-Projekt, das niemand wollte.
Muster aus der Praxis
Ein B2B-SaaS-Team am hinteren Ende von Series A kam für eine HubSpot-Implementation auf einer Sechs-Wochen-Timeline auf uns zu. Discovery war auf vier Tage abgegrenzt. Wir hielten dagegen und fuhren es zwei Wochen. Das Artefakt war ein Dokument, das Pipeline-Definitionen, Verantwortung, Integrations-Scope, Erfolgskriterien und eine Liste von Use Cases abdeckte, die das Team als Out-of-Scope für v1 akzeptierte. Design dauerte drei Wochen und produzierte ein Schema-Dokument plus ein Workflow-Inventar. Build war ein sauberer Vier-Wochen-Sprint: wöchentliche Demos, keine Entscheidungen wieder geöffnet. Launch war ein Freitag-Cutover mit einem einwöchigen Hypercare-Fenster, besetzt vom Build-Team. Optimize startete dreißig Tage nach Launch auf monatlicher Kadenz und läuft bis heute. Das Stück, das es zu nennen lohnt, Das erste Quarterly Business Review des Teams auf dem neuen System brauchte keinen manuellen Daten-Cleanup. Das ist es, was eine nicht komprimierte Discovery zehn Monate später einkauft.
Auflösung, das Engagement-Modell wählen, das auf jede Phase mappt
Die fünf Phasen müssen nicht in einem Engagement-Typ leben. Verschiedene Phasen belohnen verschiedene Formen von Support. Das Mapping, das über die meisten B2B-SaaS-Engagements hält:
- Discovery ist ein Workshop oder ein eng abgegrenztes Projekt. Es braucht Senior-Aufmerksamkeit, eine Außenperspektive und ein Deliverable, das das interne Team abzeichnet. Es braucht keinen langlaufenden Retainer.
- Design ist ein Projekt. Das Deliverable ist ein Schema- und Workflow-Dokument, das Budget ist fix, die Timeline zwei bis vier Wochen. Behandeln Sie es als solches.
- Build ist ein Projekt oder ein eingebettetes Engagement, abhängig davon, wie viel Konfigurationsarbeit das interne Team absorbieren kann. Wenn Sie eine HubSpot-Admin im Sitz haben, funktioniert die Projektform. Wenn nicht, betten Sie jemanden für die Dauer ein.
- Launch ist ein Projekt mit einem Hypercare-Schweif. Scopen Sie Cutover, Training und die ersten zehn Tage als einen Block. Verlassen Sie sich nicht auf den Goodwill des Build-Teams, um den Schweif zu besetzen.
- Optimize ist, wo Retainer- oder fraktionaler Support sich lohnt. Monatliche Kadenz, abgegrenzte Stunden, ein definierter Backlog. Der Fehler ist, einen Retainer zu kaufen, bevor Discovery fertig ist; der andere Fehler ist, ihn am Tag nach Launch auslaufen zu lassen.
- Phasenübergreifend: Wenn das interne Team noch keine Senior-RevOps-Funktion hat, ist eine fraktionale eingebettete Rolle über Discovery, Design und Optimize oft die richtige Form. Build bleibt ein Projekt.
- Stage-Check: In Seed und vor Series A ist Projektform fast immer richtig: das interne Team ist noch nicht bereit, einen Retainer zu absorbieren. Ab Series B aufwärts zahlt sich das Retainer- oder fraktionale Modell meist innerhalb von zwei Quartalen aus, weil Optimize aufhört, jemandes Nebenjob zu sein.
Wo Checkpoint ins Spiel kommt
Die fünfphasige Methodik ist das Rückgrat jedes HubSpot- und CRM-Engagements, das wir bei Checkpoint fahren. Greenfield-Implementations laufen die Phasen der Reihe nach. Brownfield-Migrationen starten Discovery mit dem Audit. Redesigns verlängern Design und verkürzen Build. Die Phasen bleiben; die Proportionen ändern sich. Wenn Sie gerade eine Implementation scopen und die Timeline nicht alle fünf nennt, sprechen Sie mit uns vor dem Kickoff. Wir machen diese Arbeit als HubSpot-Implementation, als Teil von GTM Strategy und als eingebetteten RevOps-Support über den Stack.
Quellen
- Sinha, Shastri, Lorimer. „Why Your Digital Investments Aren't Creating Value." Harvard Business Review, 16. Februar 2026. hbr.org
- Lemkin, Jason. „Which CRM Should You Use in 2026/2027? Follow the Agents." SaaStr, 6. April 2026. saastr.com