Die Implementierung ist die technische Arbeit, das Produkt in der Umgebung des Kunden zum Laufen zu bringen; das Onboarding ist die Wertreise, die den Kunden von „das Produkt läuft” zu „wir können nicht mehr ohne es” führt. Sie überlappen sich zeitlich und man verwechselt sie ständig, doch sie beantworten unterschiedliche Fragen, werden von unterschiedlichen Rollen verantwortet und scheitern auf unterschiedliche Weise. Die Implementierung fragt: „Ist es konfiguriert, integriert und live?” Das Onboarding fragt: „Hat der Kunde den Outcome erreicht, den er gekauft hat?” Ein Deal kann vollständig implementiert und ein totaler Onboarding-Fehlschlag sein — genau aus dieser Lücke entsteht der Churn bei der ersten Verlängerung.
Die Unterscheidung, präzise
- Implementierung ist abgegrenzt, technisch und hat einen binären Fertig-Zustand. Die Instanz bereitstellen, die Datenquellen verbinden, die Integrationen verdrahten (SSO, CRM-Sync, Webhooks), Legacy-Daten migrieren, den Workspace konfigurieren und nachweisen, dass ein echter Workflow Ende zu Ende läuft. Der Erfolg ist beobachtbar und objektiv: Die Plumbing funktioniert. Es ist ein Projekt mit einem Scope, einem Statement of Work und einem Abnahmetest.
- Onboarding ist offen, Outcome-getrieben und hat einen unscharfen Fertig-Zustand. Es umfasst die Implementierung, endet aber nicht, wenn die Plumbing funktioniert — es endet, wenn der Kunde den gekauften Outcome persönlich erreicht hat (Time-to-First-Value) und diese Nutzung sich über den Champion hinaus zur gewohnheitsmäßigen Adoption des Teams ausgebreitet hat. Der Erfolg ist, dass der Kunde sagt „das hat sich gelohnt”, instrumentiert als ein echter Wert-Meilenstein.
Anders gesagt: Die Implementierung ist zeitlich eine Teilmenge des Onboardings, kein Synonym. Die Implementierung ist eine Phase innerhalb der Onboarding-Reise — die Setup-Phase. „Implementierung abgeschlossen” als „Onboarding abgeschlossen” zu behandeln ist die häufigste Art, einen hohlen Sieg zu melden und den Account dann bei der Verlängerung zu verlieren.
Wer ist wofür verantwortlich
Die Aufteilung der Verantwortung ist der ganze Sinn der Trennung beider Konzepte. Sie zu verwechseln bedeutet, dass eine Rolle eine Aufgabe übertragen bekommt, für die sie nicht ausgerüstet ist.
| Dimension | Implementierung | Onboarding |
|---|---|---|
| Hauptverantwortung | Implementierungsspezialist / Solutions Engineer / Professional Services | CSM (oder Onboarding-Spezialist) |
| Skillset | Technisch: APIs, Datenmigration, Integrationen, Config | Beziehung + Outcome: Success Planning, Adoption, Executive Alignment |
| Fertig-Zustand | Binär — der Workflow läuft Ende zu Ende | Outcome — erster Wert erreicht, Adoption gewohnheitsmäßig |
| Gemessen an | Fristgerechte, scope-treue Lieferung; Ticket-Lösung | Time-to-Value (TTV), Austritt aus Phase 3, wöchentliche aktive Nutzung |
| Zeithorizont | Tage bis Wochen (abgegrenztes Projekt) | Wochen bis ein Quartal (bis der Account in den laufenden CS übergeht) |
In kleinen Unternehmen trägt eine Person beide Hüte — doch die Rollen bleiben getrennt, selbst wenn der Headcount eins ist, und die Arbeit sollte als zwei Workstreams nachverfolgt werden. Im Mid-Market und Enterprise teilen sie sich auf: Ein Professional-Services- oder Implementierungsteam verantwortet das technische Projekt, und der CSM verantwortet die darum gewickelte Wertreise. Der CSM bleibt die ganze Zeit für den Outcome verantwortlich, auch während der Implementierung, denn dem Kunden ist es egal, in welchem Kästchen des Organigramms die Verzögerung sitzt.
Wo die Übergabe stattfindet
Die Übergabe von der Implementierung an das Onboarding ist die risikoreichste Naht im Kundenlebenszyklus, und hier verdampft der Kontext. Das Implementierungsteam schließt das technische Projekt ab, markiert das Ticket als geschlossen und geht zum nächsten Account — und der CSM erbt ein konfiguriertes Produkt ohne jede Aufzeichnung darüber, was der Kunde eigentlich erreichen wollte. Der Kunde erklärt dann einer neuen Person seine Ziele erneut, während die Wert-Uhr weiterläuft.
Machen Sie die Übergabe explizit, nicht implizit:
- Tragen Sie den Success Plan schriftlich weiter. Der beim Kickoff vereinbarte gemeinsame Success Plan — die eigene Erfolgsdefinition des Kunden und der benannte Executive Sponsor — ist das Artefakt, das die Übergabe überlebt. Die Implementierung liest ihn beim Eintritt; der CSM verantwortet ihn beim Austritt.
- Definieren Sie den Trigger der Übergabe als Wert-Gate, nicht als Config-Gate. Die Übergabe ist nicht „Config fertig” — sie ist „Config fertig UND ein echter Workflow ist mit den eigenen Daten des Kunden Ende zu Ende gelaufen”, damit der CSM etwas erbt, worauf der Kunde tatsächlich Wert aufbauen kann, statt einer leeren Hülle.
- Führen Sie einen gemeinsamen Übergang durch, kein Fire-and-Forget. Eine kurze Überlappung, in der Implementierung und CSM beide in einem Call mit dem Kunden sind, verhindert den Kaltstart. Der CSM hört den technischen Kontext aus erster Hand; der Kunde wiederholt sich nie.
Es gibt Tools, um diese Naht für beide Seiten sichtbar zu machen. Rocketlane steuert das Implementierungsprojekt mit einem kundenseitigen Plan und verfolgt das Abnahme-Gate; Arrows und Dock halten den geteilten Onboarding-Plan und die Erfolgskriterien über die Übergabe hinweg sichtbar; eine CS-Plattform wie Gainsight instrumentiert die Phasenaustritte und löst eine Health-Score-Warnung aus, wenn ein Account zwischen „implementiert” und „adoptiert” stecken bleibt.
Häufige Fallstricke
- Den Account bei der Implementierung für fertig erklären. Die Plumbing funktioniert, das Ticket schließt, und niemand bestätigt den ersten Wert. Guard: Das Austrittskriterium des Programms ist der vom Kunden genannte Outcome (Phase 3 des Onboardings), niemals der Abnahmetest der Implementierung.
- Kein benannter Verantwortlicher während der Naht. Die Implementierung hat übergeben und der CSM hat nicht übernommen, also bleibt der Account eine Woche ohne Verantwortlichen. Guard: ein einziger rechenschaftspflichtiger Verantwortlicher zu jedem Zeitpunkt, mit schriftlich festgehaltenem Übergabedatum und Verantwortlichem, nicht angenommen.
- Der Scope Creep der Implementierung frisst die Wert-Uhr auf. Eine lange Custom-Integration schiebt den ersten Wert um Wochen hinaus, während alle das Projekt als „on track” melden. Guard: Verfolgen Sie Time-to-Value als separate Metrik, die während der Implementierung läuft, damit eine rutschende Integration als TTV-Verletzung erscheint, nicht als grüner Projektstatus.
- Das Modell auf reines Self-Serve zwingen. Ein PLG-Produkt ohne Setup mit menschlichem Kontakt hat kein Implementierungsteam, von dem übergeben wird. Guard: Falten Sie die Implementierung in die In-Product-Aktivierung und instrumentieren Sie TTV über Product Analytics — es gibt keine Naht zu verwalten, weil es keine Übergabe gibt.
Verwandt
- Customer onboarding — die vollständige vierstufige Reise, in der die Implementierung sitzt
- Time to value — die Metrik, die beide durchläuft
- Customer health score — wo eine steckengebliebene Übergabe zuerst auftaucht
- Rocketlane — Management des Implementierungsprojekts