Die Nutzungsanalyse zeigt: Bei einem Kunden sinkt die Verwendung einer Funktion, die für ein vereinbartes Ziel relevant ist. Wie reagieren Customer Success Manager (CSMs)? Einer verschickt sofort Schulungsunterlagen. Ein anderer ruft den Kunden an. Ein Dritter beobachtet zunächst die weitere Entwicklung. Customer Success Playbooks schaffen für solche Situationen eine gemeinsame Handlungsgrundlage. Sie bündeln gemeinsame Prinzipien, wiederverwendbare Customer Success Plays und unterstützende Arbeitsmittel.
Für den konkreten Nutzungsrückgang greift der CSM auf ein passendes Play zurück. Dieses ordnet die beobachtete Merkmalsveränderung ein, prüft ihre Bedeutung im Kundenkontext und führt durch Analyse, Entscheidung und Handlung. Das Playbook ist somit das übergeordnete Handbuch. Das einzelne Play beschreibt, wie das Team eine bestimmte wiederkehrende Kundensituation bearbeitet.
Das Wichtigste in Kürze
- Ein Customer Success Playbook ist ein modular aufgebautes Handbuch aus mehreren Customer Success Plays, gemeinsamen Regeln und unterstützenden Arbeitsmitteln.
- Ein Customer Success Play ist ein wiederverwendbarer Handlungs- und Entscheidungsrahmen für eine konkrete, wiederkehrende Kundensituation.
- Als praxistaugliche Grundstruktur schlagen wir fünf Kernelemente vor: Kontext, Trigger, Ablauf, Zielergebnis und Eskalationspfad.
- Eine beobachtete Merkmalsveränderung kann ein Signal sein. Ein Trigger legt fest, wann ein Play oder eine vorgelagerte Prüfung startet.
- Ein Signal weist auf möglichen Handlungsbedarf hin, beweist aber weder ein Problem noch dessen Ursache.
- Checklisten und Automationen können ein Play unterstützen. Sie ersetzen weder das Play noch das Urteilsvermögen des CSM.
- Der Erfolg eines Plays zeigt sich an der veränderten Kundensituation, nicht an erledigten Aufgaben.
- Das Playbook gehört zum Customer Success Operating Model, ist aber nicht mit dem gesamten Betriebsmodell gleichzusetzen.
Was sind Customer Success Playbooks und Customer Success Plays?
Für die praktische Arbeit hilft eine einfache Unterscheidung: Das Playbook ist das gemeinsame Handbuch; die Plays sind die darin beschriebenen Vorgehensweisen für wiederkehrende Situationen. So finden Mitarbeitende Regeln und Unterstützung für konkrete Kundenfälle.
Anbieter verwenden die Begriffe unterschiedlich. Deshalb legen wir für diesen Beitrag folgende Arbeitsdefinitionen fest:
Ein Customer Success Playbook ist ein dokumentiertes, modular aufgebautes Handbuch beziehungsweise eine geordnete Sammlung miteinander verbundener Customer Success Plays, gemeinsamer Regeln und unterstützender Arbeitsmittel.
Ein Customer Success Play ist ein dokumentierter und wiederverwendbarer Handlungs- und Entscheidungsrahmen für eine konkrete, wiederkehrende Kundensituation.
Die Unterscheidung folgt derselben Logik wie bei einem B2B Sales Playbook: Das Handbuch enthält mehrere einzelne Plays. Verglichen werden also jeweils Handbuch mit Handbuch und einzelne Vorgehensweise mit einzelner Vorgehensweise. Diese Arbeitsdefinition ist keine allgemeingültige wissenschaftliche Begriffsdefinition.
| B2B Sales | Customer Success | Funktion |
|---|---|---|
| B2B Sales Playbook | Customer Success Playbook | übergeordnetes Handbuch mit Prinzipien, Plays, Rollen und Arbeitsmitteln |
| Sales Play | Customer Success Play | Handlungs- und Entscheidungsrahmen für eine konkrete wiederkehrende Situation |
Ein Customer Success Playbook kann den gesamten Customer Lifecycle abdecken. Es kann aber auch auf Onboarding, Adoption, Value Realization, Risiko, Renewal oder Expansion begrenzt sein. In beiden Fällen enthält es mehrere Plays, die nach einer nachvollziehbaren Logik geordnet und miteinander verbunden sind.
Die Praxisquellen spiegeln die unterschiedliche Verwendung der Begriffe. Der Leitfaden von Flowla zum Customer Success Management behandelt Handover, Onboarding und Success Planning im Sinne eines übergeordneten Handbuchs. HubSpot und ChurnZero zeigen dagegen sieben konkrete Abläufe, die nach der hier verwendeten Hierarchie einzelne Plays darstellen. Der öffentliche Playbook-Katalog von GitLab verbindet verschiedene Anleitungen und Anwendungsszenarien. Das Gainsight-Beispiel zum Sponsorwechsel entspricht funktional einem situativen Play.
Was gehört in Customer Success Playbooks?
Customer Success Playbooks können den gesamten Lifecycle oder einen begrenzten Handlungsbereich abdecken. Ihr genauer Umfang hängt von Organisation, Zielgruppe und Geltungsbereich ab. Ein Playbook für den gesamten Lifecycle benötigt eine andere Gliederung als ein Playbook für Adoption und Value Realization. Die grundlegenden Bausteine bleiben jedoch vergleichbar.
| Bestandteil des Playbooks | Inhalt |
|---|---|
| Zweck, Geltungsbereich und Zielgruppen | Aufgaben des Playbooks, einbezogene Kundengruppen, Lifecycle-Phasen und Abgrenzungen |
| Customer Success Prinzipien und Entscheidungsregeln | gemeinsame Wertlogik, Umgang mit Daten, Entscheidungsspielräume und Regeln für begründete Abweichungen |
| Einordnung in Lifecycle und Prozesse | Verbindung zu Customer Success Prozessen, Touchpoints und angrenzenden Funktionen |
| Katalog der Customer Success Plays | nach Lebenszyklusphasen, Kundensituationen oder Handlungsfeldern geordnete Plays |
| Rollen und Verantwortlichkeiten | Zuständigkeiten, Übergaben, Entscheidungsbefugnisse und Eskalationsrollen |
| Unterstützende Arbeitsmittel | Gesprächsleitfäden, Checklisten, Vorlagen, Datenansichten und Informationsquellen |
| Steuerung und Pflege | Dokumentation, Erfolgsmessung, Lernen, Eigentümerschaft, Prüftermine und Versionierung |
Das Playbook dokumentiert damit mehr als eine Sammlung von Abläufen. Es schafft einen gemeinsamen Rahmen, in dem die einzelnen Plays verständlich ausgewählt und konsistent angewendet werden können.
Das Playbook ist nicht das gesamte Betriebsmodell
Customer Success Playbooks dürfen nicht mit dem Customer Success Operating Model gleichgesetzt werden. Organisationsstruktur, Segmentierungsmodell, Kapazitätsplanung, Technologiearchitektur und Führungssystem beeinflussen Aufbau und Anwendung des Playbooks. Sie sind jedoch nicht automatisch Bestandteil eines Plays.
Das Operating Model legt beispielsweise fest, welche Kundengruppen persönlich betreut werden und welche Daten oder Systeme verfügbar sind. Das Playbook übersetzt diesen Rahmen in gemeinsame Prinzipien, einen geordneten Play-Katalog und nutzbare Arbeitsmittel. Das einzelne Play leitet schließlich die Bearbeitung einer konkreten Kundensituation an.
Beispiel: Play-Katalog für Adoption und Value Realization
Auch ein thematisch begrenztes Playbook kann mehrere negative und positive Entwicklungen abdecken. Tabelle 3 zeigt eine beispielhafte Auswahl ohne Anspruch auf Vollständigkeit. Dass Adoption zweimal vorkommt, ist beabsichtigt: Innerhalb desselben Handlungsfelds können unterschiedliche Situationen jeweils ein eigenes Play benötigen.
| Beispiel | Handlungsfeld | Customer Success Play | Richtung des Anlasses |
|---|---|---|---|
| 1 | Adoption | Nutzung einer wertrelevanten Kernfunktion sinkt | Risiko einordnen und Nutzung stabilisieren |
| 2 | Adoption | vereinbarter Adoptionsmeilenstein wird nicht erreicht | Hindernis klären und Fortschritt wiederherstellen |
| 3 | Skalierung | Nutzung bleibt auf eine einzelne Abteilung begrenzt | Voraussetzungen für weitere Verbreitung prüfen |
| 4 | Beziehung | zentraler Anwender oder Sponsor wird inaktiv | Beziehung und Verantwortlichkeit erneuern |
| 5 | Value Realization | Kunde erreicht einen wichtigen Value-Meilenstein | Wirkung sichtbar machen und erfolgreiche Nutzung verstärken |
| 6 | Entwicklung | zusätzlicher Anwendungsfall wird erkennbar | Kundennutzen prüfen und Potenzial strukturiert weiterentwickeln |
Customer Success Playbooks dienen folglich nicht nur der Risikobearbeitung. Sie helfen ebenso dabei, erfolgreiche Nutzung zu verstärken, Wertrealisierung sichtbar zu machen und zusätzliche Kundenpotenziale verantwortungsvoll zu entwickeln.
Warum brauchen Customer Success Teams Playbooks?
Ohne eine gemeinsame Handlungsgrundlage entwickelt jeder CSM eigene Vorgehensweisen für wiederkehrende Situationen. Dadurch hängen Qualität und Geschwindigkeit stark von individueller Erfahrung, verfügbarer Zeit und persönlicher Erinnerung ab. Erkenntnisse gehen außerdem verloren, wenn Mitarbeitende ihre Rolle wechseln oder das Unternehmen verlassen.
Feldman und Pentland (2003) zeigen, dass organisationale Routinen nicht nur Stabilität erzeugen. Ihre konkrete Ausführung kann sie zugleich verändern und weiterentwickeln. Genau diese Verbindung braucht ein Playbook: Es dokumentiert gemeinsame Orientierung und bewahrt Erfahrungswissen. Die einzelnen Plays lassen dennoch begründete Abweichungen und Lernen aus der Anwendung zu.
Auch die Untersuchung von Reinartz, Krafft und Hoyer (2004) stützt die Bedeutung systematisch gestalteter CRM-Prozesse. Sie weist keine spezifische Wirkung von Customer Success Playbooks nach. Dennoch zeigt sie, dass strukturierte Kundenprozesse mit der Unternehmensleistung zusammenhängen können.
Bitner, Ostrom und Morgan (2008) zeigen mit dem Service Blueprinting zudem, wie sich Kundenaktivitäten, sichtbare Kontakte und interne Leistungen gemeinsam abbilden lassen. Der Ansatz ist kein Wirksamkeitsnachweis für Playbooks. Er unterstützt jedoch dabei, Plays, Rollen und Übergaben aus Kundensicht zu gestalten.
Customer Success Playbooks erfüllen damit vier praktische Funktionen:
- Sie schaffen gemeinsame Prinzipien und Entscheidungsregeln.
- Sie machen Erfahrungswissen über wiederverwendbare Plays zugänglich.
- Sie klären Rollen, Übergaben, Eskalationen und unterstützende Arbeitsmittel.
- Sie bilden eine Grundlage für Einarbeitung, Coaching, Automatisierung und kontinuierliches Lernen.
Ein umfangreicher Play-Katalog verbessert die Kundenarbeit allerdings nicht automatisch. Wenn Plays nur zusätzliche Felder und Aufgaben erzeugen, erhöhen sie den administrativen Aufwand. Deshalb muss jedes Play eine relevante wiederkehrende Kundensituation bearbeiten und auf ein überprüfbares Zielergebnis ausgerichtet sein.
Welche fünf Bestandteile braucht ein Customer Success Play?
Für ein einzelnes Customer Success Play empfehlen wir die folgenden fünf Kernelemente. Sie bilden eine praktische Grundstruktur, keinen wissenschaftlich verbindlichen oder abschließenden Standard. Zusätzliche Angaben wie Datenquellen oder Kommunikationsvorlagen können direkt in den Ablauf eingebunden oder als Arbeitsmittel verlinkt werden.
| Bestandteil des Plays | Leitfrage | Inhalt |
|---|---|---|
| Kontext | Für welche Situation gilt das Play? | Kundensituation, Lifecycle-Phase, Kundengruppe und Abgrenzungen |
| Trigger | Was startet die Prüfung oder das Play? | definierte Bedingung auf Basis eines Ereignisses, Termins, Kundenhinweises oder einer Merkmalsveränderung |
| Ablauf | Wie wird die Situation bearbeitet? | Analysefragen, Entscheidungspunkte, alternative Handlungswege, Rollen, Übergaben und Dokumentation |
| Zielergebnis | Welche Veränderung soll erreicht werden? | überprüfbare Veränderung der Kundensituation oder bewusst angepasstes Zielbild |
| Eskalationspfad | Wann reicht der normale Ablauf nicht aus? | Eskalationsbedingung, einzubeziehende Rolle und benötigte Entscheidung |
Der Ablauf darf keine bloße Aufgabenliste sein. „Daten prüfen, E-Mail senden, Aufgabe schließen“ beschreibt lediglich Aktivitäten. Ein ausführbares Play erklärt zusätzlich, welche Zusammenhänge der CSM untersucht, welche Annahmen er mit dem Kunden prüft, wie er zwischen Handlungswegen entscheidet und wann eine andere Rolle übernehmen muss.
Auch das Zielergebnis muss die Kundensituation beschreiben. „Drei E-Mails versendet“ ist kein Erfolgsnachweis. „Technisches Hindernis beseitigt und wertrelevanter Workflow wieder ausführbar“ zeigt dagegen eine überprüfbare Veränderung.
Playbook, Play, Success Plan oder Prozess?
Die Instrumente können Inhalte teilen, erfüllen jedoch unterschiedliche Funktionen.
| Instrument | Zweck | Bezug |
|---|---|---|
| Customer Success Prozess | funktionsübergreifender End-to-End-Ablauf | Organisation, Rollen und Systeme über mehrere Kundensituationen hinweg |
| Customer Success Playbook | geordnete Sammlung von Plays, Regeln und unterstützenden Arbeitsmitteln | definierter Lifecycle- oder Handlungsbereich |
| Customer Success Play | Handlungs- und Entscheidungsrahmen für eine wiederkehrende Kundensituation | vergleichbare Kundenfälle |
| Success Plan | gemeinsame Steuerung konkreter Ziele, Maßnahmen, Meilensteine und Ergebnisse | ein bestimmter Kunde |
| Checkliste | Sicherung der Vollständigkeit | einzelne Aufgabe, Teilablauf oder Termin |
| Automation | technische Auslösung oder Ausführung eindeutig definierter Schritte | Systemlogik innerhalb oder außerhalb eines Plays |
| Customer Success Operating Model | übergeordnete Gestaltung von Organisation, Segmentierung, Prozessen, Kapazitäten, Technologie und Governance | gesamtes Customer Success System |
Eine Checkliste hilft beispielsweise zu prüfen, ob vor einem Kundengespräch Nutzungsdaten, offene Supportfälle und vereinbarte Ziele vorliegen. Das Play beschreibt zusätzlich, wie der CSM diese Informationen einordnet und zwischen möglichen Maßnahmen entscheidet. Eine Checkliste kann deshalb Bestandteil eines Plays sein. Eine Automation kann das Play auslösen, Daten bereitstellen oder eindeutig definierte Schritte ausführen. Weder Checkliste noch Automation ersetzen jedoch die fachliche Entscheidungslogik des Plays.
Das Ergebnis eines Plays kann in den Success Plan zurückfließen. Das Play „Sinkende wertrelevante Nutzung“ kann beispielsweise ergeben, dass sich das Kundenziel verändert hat. CSM und Kunde aktualisieren daraufhin den Success Plan. Das Play endet, während der kundenspezifische Plan fortbesteht.
Ebenso kann ein Customer Success Prozess mehrere Plays berühren. Ein Renewal-Prozess kann etwa ein Risiko-Play auslösen, wenn ein relevantes Ziel vor der Verlängerung gefährdet ist. Dadurch greifen Prozess, Playbook, Play und Success Plan ineinander, ohne dieselbe Funktion zu übernehmen.
Wie hängen Merkmal, Signal und Trigger zusammen?
Vom beobachteten Wert zur Auslösebedingung
Ein Merkmal ist eine beobachtbare Eigenschaft, etwa die Anzahl ausgeführter Workflows. Seine Ausprägung ist der konkrete Wert: beispielsweise 100 Workflows in 28 Tagen. Sinkt dieser Wert im nächsten Vergleichszeitraum auf 70, liegt eine Merkmalsveränderung vor.
Diese beobachtete Veränderung kann bereits das Signal sein. Der Begriff beschreibt ihre Funktion als Hinweis auf eine möglicherweise relevante Kundensituation. Es entsteht also nicht erst eine zweite Beobachtung. „Die Nutzung ist gesunken“ beschreibt die Veränderung; „das könnte den Fortschritt gefährden“ ist eine mögliche Interpretation, die der CSM prüfen muss.
Ein Trigger ist dagegen die festgelegte Auslösebedingung: Wann startet eine Prüfung oder ein Play? Eine entsprechende Regel kann manuell oder automatisch greifen. Die folgende Abgrenzung ist eine Arbeitsdefinition für diesen Beitrag; Softwareanbieter können die Begriffe anders verwenden.
| Begriff | Bedeutung im durchgängigen Beispiel |
|---|---|
| Merkmal | Anzahl vollständig ausgeführter, für das Kundenziel relevanter Workflows je 28 Tage |
| Merkmalsausprägung | 100 Workflows im vorherigen, 70 im aktuellen Vergleichszeitraum |
| Merkmalsveränderung | 30 Workflows weniger; Rückgang um 30 Prozent |
| Signal | Der beobachtete Rückgang dient als Hinweis auf möglicherweise beeinträchtigten Fortschritt. Ursache und Auswirkung sind noch offen. |
| Trigger | Bei mindestens 30 Prozent Rückgang gegenüber den vorherigen 28 Tagen startet das Play „Sinkende wertrelevante Nutzung“ mit einer Erstprüfung. |
| Analyse im Play | Der CSM prüft Datenqualität, Vergleichbarkeit, Kundenziel und mögliche Ursachen; danach wählt er den passenden Handlungsweg. |
Auch unveränderte Zustände können relevant sein
Ein Signal setzt keine Veränderung voraus. Bleibt die Nutzung über Wochen bei null, kann gerade der ausbleibende Fortschritt relevant sein. Auch ein Kundenhinweis oder ein Sponsorwechsel kann Anlass zur Prüfung geben. Ein Trigger kann zudem rein zeitlich greifen, etwa 120 Tage vor Vertragsende, ohne dass zuvor ein Risikosignal vorliegt.
Für das Nutzungsbeispiel gilt: Rückgang beobachten → Auslösebedingung prüfen → Play starten → Situation analysieren → Handlungsweg wählen. Die Analyse gehört hier bereits zum Play. Wenn noch unklar ist, welches Play passt, kann das Team eine kurze Prüfung zur Auswahl vorschalten.
Schwellenwerte müssen zum Kundenkontext passen. Die 30 Prozent und 28 Tage sind lediglich Beispielwerte. Teams berücksichtigen unter anderem Saisonalität, Kundengruppe und Datenqualität. Bei zuvor null Workflows ist eine prozentuale Veränderung nicht berechenbar; dafür braucht es eine eigene Regel.
Mehrere Signale können dasselbe Play anstoßen. Sinkende Nutzung und ein inaktiver Key User können beispielsweise zusammen auf ein Adoptionshindernis hinweisen. Das Playbook sollte verhindern, dass daraus doppelte Bearbeitungen oder widersprüchliche Kundenkontakte entstehen.
Praxisbeispiel: Das Play „Sinkende wertrelevante Nutzung“
Das folgende Customer Success Play gehört zum beispielhaften Playbook für Adoption und Value Realization. Es setzt die fünf Kernelemente in eine ausführbare Arbeitslogik um.
| Kernelement | Ausgestaltung im Beispiel |
|---|---|
| Kontext | laufende Nutzung nach dem Onboarding; der betrachtete Workflow ist mit einem vereinbarten Kundenziel verbunden |
| Trigger | mindestens 30 Prozent weniger ausgeführte wertrelevante Workflows innerhalb von 28 Tagen gegenüber dem vorherigen Vergleichszeitraum |
| Ablauf | Merkmalsveränderung prüfen, Kontext verstehen, Ursache klären, Handlungsweg auswählen und Wirkung bewerten |
| Zielergebnis | wertrelevante Nutzung wiederhergestellt oder ausgeweitet, Hindernis beseitigt oder Zielbild bewusst angepasst |
| Eskalationspfad | bei geschäftskritischen, ungelösten oder entscheidungsbedürftigen Hindernissen zuständige Fach- oder Führungsrolle einbeziehen |
Entscheidend ist die Wertrelevanz. Weniger Anmeldungen beweisen noch keinen gefährdeten Kundenerfolg. Der CSM betrachtet deshalb nicht nur Aktivität, sondern die Wirkungskette:
Nutzung → verändertes Verhalten oder Prozess → verbessertes Ergebnis → wahrgenommener Kundennutzen
Der Beitrag zur Product Adoption erläutert diese Verbindung ausführlicher.
1. Merkmalsveränderung und Signal prüfen
Zunächst prüft der CSM, ob das Merkmal korrekt erfasst wurde und die beobachtete Veränderung belastbar ist. Dafür betrachtet er Datenqualität, Vergleichszeitraum, Saisonalität und Ausgangsbasis. Außerdem identifiziert er betroffene Nutzergruppen, Standorte oder Prozessschritte.
Bei einer kleinen Ausgangsbasis kann bereits eine geringe absolute Veränderung einen hohen prozentualen Ausschlag erzeugen. Ebenso können Feiertage oder geplante Betriebsunterbrechungen den Rückgang erklären. Erklären solche Umstände den Rückgang hinreichend und bleibt das Kundenziel erreichbar, dokumentiert der CSM die Einordnung. Er kann das Play ohne Intervention beenden oder einen weiteren Prüftermin vereinbaren.
2. Kontext und Kundenziel verstehen
Anschließend gleicht der CSM das Signal mit dem Success Plan, offenen Supportfällen und bekannten organisatorischen Veränderungen ab. Er betrachtet außerdem weitere Nutzungs-, Prozess-, Support- und Beziehungsmerkmale. Mögliche Erklärungen formuliert er als Hypothesen, nicht als Tatsachen.
Der CSM sollte daher nicht automatisch ein Training anbieten. Sinkende Nutzung kann ebenso auf ein technisches Hindernis, fehlende Berechtigungen, veränderte Prozesse, einen inaktiven Stakeholder oder ein nicht mehr relevantes Ziel hinweisen.
3. Ursache gemeinsam klären
Nun bespricht der CSM die Beobachtung mit dem verantwortlichen Kundenkontakt. Ein möglicher Gesprächseinstieg lautet:
„Wir sehen seit einigen Wochen einen Rückgang bei dem Workflow, den wir mit Ihrem Ziel verknüpft haben. Die Daten zeigen noch nicht, warum sich die Nutzung verändert hat. Deshalb möchte ich mit Ihnen prüfen, ob sich Prozesse, Verantwortlichkeiten oder Rahmenbedingungen verändert haben.“
Der CSM verbindet Daten und Kundenwahrnehmung. Dadurch entsteht eine belastbare Ursachen- und Kontextanalyse, ohne dem Kunden vorschnell ein Problem zuzuschreiben.
4. Handlungsweg auswählen und ausführen
Nach der Analyse wählen Kunde und CSM den passenden Handlungsweg innerhalb des Plays. Tabelle 8 zeigt mögliche Analyseergebnisse und Reaktionen als Beispiele, ohne Anspruch auf Vollständigkeit. Mehrere Ursachen können zusammenwirken und entsprechend mehrere Maßnahmen erfordern.
| Beispiel | Analyseergebnis | Handlungsweg | Kundenseitiges Abschlusskriterium |
|---|---|---|---|
| 1 | technisches Hindernis | Support einbinden und Lösung nachverfolgen | Workflow wieder ausführbar |
| 2 | fehlendes Wissen | rollenbezogene Befähigung vereinbaren | relevante Nutzer führen den Workflow selbstständig aus |
| 3 | fehlende Berechtigung | Rollen und Zugriffe korrigieren | betroffene Nutzer können den Prozess vollständig durchführen |
| 4 | veränderter Kundenprozess | Zielbild und Nutzungsszenario neu abstimmen | neuer wertrelevanter Prozess dokumentiert |
| 5 | veränderte Priorität | Sponsor und Prozesseigner einbinden | verbindliche Entscheidung zu Ziel und Ressourcen getroffen |
| 6 | fehlender Wertbeitrag | Zielannahme und Lösungskonzept überprüfen | tragfähiges Ziel bestätigt oder Vorgehen bewusst beendet |
Jede vereinbarte Maßnahme erhält eine verantwortliche Person auf Kunden- und Anbieterseite, einen Termin und ein Erfolgskriterium. Die Beteiligten dokumentieren diese Angaben im bestehenden Success Plan oder im führenden Kundensystem.
5. Wirkung prüfen oder eskalieren
Zum vereinbarten Termin bewerten Kunde und CSM die Wirkung. Der CSM dokumentiert, ob das vereinbarte Abschlusskriterium erreicht ist. Eine technische Lösung allein belegt noch keine wiederhergestellte Adoption: Dafür muss sich die relevante Nutzung tatsächlich bestätigen. Ein bewusst angepasstes Ziel oder eine Übergabe kann den Fall ebenfalls abschließen, erhält aber einen eigenen Abschlussstatus.
Bleibt ein geschäftskritisches Hindernis ungelöst, beginnt der Eskalationspfad. Je nach Ursache bezieht der CSM beispielsweise den Support Lead, einen Prozesseigner, den Executive Sponsor oder die Customer Success Führungskraft ein. Der Eskalationsschritt benennt nicht nur eine Rolle, sondern auch die benötigte Entscheidung. Der CSM bleibt für die Kundenkommunikation verantwortlich, solange keine ausdrückliche Übergabe erfolgt.
Wie werden mehrere Plays zu einem Playbook?
Ein Playbook ist in der hier verwendeten Definition eine Form des Handbuchs. Es muss weder ein neues Dokumentformat noch eine neue Software sein. Entscheidend ist, ob Mitarbeitende darin wiederkehrende Situationen, passende Entscheidungen, Zuständigkeiten und überprüfbare Ergebnisse finden.
Ein Customer-Service-Handbuch kann diese Funktion bereits erfüllen. Beschreibt es etwa, wie das Team bei wiederholten Störungen oder einer Beschwerde über ein nicht eingehaltenes Leistungsversprechen vorgeht, enthält es funktional Service Plays. Dazu gehören Analysefragen, Handlungsoptionen, Befugnisse und Eskalationswege. Unter der Bezeichnung „Handbuch“ kann somit längst ein Playbook bestehen.
Eine reine Sammlung von Produktinformationen oder Bedienhinweisen ist dagegen zunächst ein Nachschlagewerk. Sie kann Arbeitsmittel für Plays liefern. Ein Handbuch kann beides verbinden: Wissensvermittlung und situationsbezogene Handlungsanleitung. Die Grenze verläuft nach der Funktion, nicht nach dem Titel.
Die strukturelle Ähnlichkeit macht ein Service Play jedoch nicht automatisch zu einem Customer Success Play. Ein Service Play kann beispielsweise die Wiederherstellung einer Leistung anleiten; ein Customer Success Play kann darauf aufbauen und die anschließende Nutzung für ein vereinbartes Kundenziel begleiten.
Bestehende Anleitungen als Ausgangspunkt nutzen
Customer Success Playbooks entstehen nicht durch eine lose Ablage einzelner Plays. Das Team muss die Plays in einen gemeinsamen fachlichen Rahmen einordnen und ihre Beziehungen sichtbar machen.
Für ein Playbook zu Adoption und Value Realization kann das Team beispielsweise so vorgehen:
- Zweck und Geltungsbereich festlegen: Das Playbook unterstützt die wertrelevante Nutzung nach dem Onboarding bis zur nachgewiesenen Wertrealisierung.
- Gemeinsame Prinzipien definieren: Kundenziel vor Aktivitätsmenge, Analyse vor Intervention und Kundenergebnis vor Aufgabenerledigung.
- Wiederkehrende Situationen als Plays dokumentieren: Das Team verwendet für jedes Play dieselben fünf Kernelemente.
- Plays ordnen und verknüpfen: Die Gliederung folgt etwa Lifecycle-Phasen, Handlungsfeldern oder typischen Kundensituationen.
- Arbeitsmittel zuordnen: Gesprächsleitfäden, Checklisten, Datenansichten und Vorlagen werden mit den passenden Plays verbunden.
- Prioritäts- und Übergaberegeln festlegen: Eine geschäftskritische Störung kann beispielsweise Vorrang vor allgemeiner Adoption-Kommunikation erhalten.
- Eigentümerschaft und Pflege regeln: Das Playbook und seine Plays erhalten Verantwortliche, Versionsstände und Prüftermine.
Orientierung und Übergaben erleichtern
Ein Lifecycle-weites Playbook kann seine Plays entlang von Handover, Onboarding, Adoption, Value Realization, Renewal und Expansion ordnen. Ein fachlich engeres Playbook kann stattdessen nach Risiko, Fortschritt, Beziehung und Potenzial gliedern. Entscheidend ist, dass CSMs die passende Situation schnell erkennen und nachvollziehen können, welches Play Vorrang besitzt oder an welches Play ein Fall übergeben wird.
Was können Systeme in Customer Success Playbooks übernehmen?
Customer Success Playbooks müssen nicht in einer Customer Success Plattform hinterlegt sein. Ein Wiki, ein digitales Handbuch oder eine gepflegte Wissensbasis kann ausreichen. Einzelne Plays lassen sich anschließend manuell, systemgestützt oder teilweise automatisiert ausführen.
Das gemeinsame Praxisdokument von HubSpot und ChurnZero stellt sieben Anwendungsbeispiele bereit. Für die eigene Umsetzung sollten Teams zunächst festlegen, welche Entscheidungen Menschen treffen und welche Schritte ein System übernehmen darf.
| Fachliche Aufgabe im Play | Mögliche Systemunterstützung |
|---|---|
| Merkmale und Veränderungen beobachten | Daten erfassen und Vergleichszeiträume bereitstellen |
| Trigger prüfen | definierte Schwellen überwachen und ein Play anstoßen |
| Kundenkontext verstehen | CRM-, Support- und Nutzungsdaten zusammenführen |
| Hypothesen im Gespräch prüfen | Gesprächsvorbereitung oder Textentwurf unterstützen |
| Handlungsweg auswählen | definierte Alternativen und Entscheidungskriterien anzeigen |
| politische oder geschäftliche Risiken abwägen | Warnung, Freigabe oder persönliche Übernahme auslösen |
| Zielergebnis bewerten | Frist überwachen und relevante Kennzahlen aktualisieren |
Automatisierung sollte auf einer fachlich erprobten Play-Logik aufbauen. Sonst vervielfältigt sie schlechte Daten, unklare Ziele oder ungeeignete Trigger. Bei widersprüchlichen Signalen, sensiblen Stakeholdern und Eskalationen braucht jedes automatisierte Teilstück eine Regel für die persönliche Übernahme.
Generative und Agentic AI können Daten zusammenfassen, Nachrichten entwerfen oder mögliche nächste Schritte vorschlagen. Die fachliche Verantwortung bleibt jedoch sichtbar: Wer prüft Kontext, Wirkung und Risiko? Der Beitrag Agentic AI im Customer Success Management vertieft diese Governance-Frage.
Wie entwickelt und pflegt ein Team Customer Success Playbooks?
Die Entwicklung von Customer Success Playbooks kann mit einem ersten Play beginnen. Zum Playbook wird der Bestand jedoch erst, wenn das Team mehrere Plays in einem gemeinsamen Geltungsbereich ordnet, verbindende Regeln festlegt und Arbeitsmittel zuordnet.
Ein pragmatisches Vorgehen umfasst sechs Schritte:
- Geltungsbereich auswählen: Das Team grenzt beispielsweise Onboarding oder Adoption und Value Realization als zusammenhängenden Bereich ab.
- Reale Fälle auswerten: Es rekonstruiert je Kundensituation mehrere Fälle und sammelt Merkmale, Signale, Ursachen, Entscheidungen und Ergebnisse.
- Plays formulieren: Kontext, Trigger, Ablauf, Zielergebnis und Eskalationspfad werden für jede wiederkehrende Situation dokumentiert.
- Playbook-Rahmen ergänzen: Prinzipien, Rollen, Katalogstruktur, Arbeitsmittel und Konfliktregeln verbinden die Plays.
- Manuell erproben: Mehrere CSMs wenden die Plays an, dokumentieren Ergebnisse und begründen sinnvolle Abweichungen.
- Verbessern und gezielt automatisieren: Das Team korrigiert Fehltrigger, fehlende Pfade und unnötige Schritte, bevor es geeignete Teile technisch umsetzt.
Das Playbook benötigt einen fachlichen Eigentümer. Zusätzlich kann jedes Play eine verantwortliche Person besitzen. Customer Success Operations koordiniert Struktur, Datenlogik, Dokumentation und technische Umsetzung. Die fachliche Verantwortung sollte jedoch bei Personen liegen, die den jeweiligen Anwendungsfall und seine Auswirkungen verstehen.
Hochstein et al. (2021) beschreiben Customer Success als proaktive, wertorientierte und funktionsübergreifend eingebundene Rolle. Ein Play darf daraus keine Sammelzuständigkeit machen. Es muss sichtbar machen, wann Customer Success führt und wann Support, Professional Services, Produkt oder Account Management übernimmt.
Wie lassen sich Plays und Playbooks messen?
Für Customer Success Playbooks sollten Teams drei Fragen beantworten: Starten wir bei den passenden Fällen? Erreichen wir das jeweilige Ziel? Erleichtert das Handbuch die Arbeit? Erledigte Aufgaben liefern ergänzende Informationen, belegen aber noch keinen Kundennutzen.
Die folgenden Zahlen sind frei gewählte Rechenbeispiele, keine Benchmarks und keine Untersuchungsergebnisse. Für den Einstieg reichen wenige Kennzahlen pro Play. Das Team legt jeweils Definition, Datenquelle, Verantwortlichkeit und Beobachtungszeitraum fest.
Beispiel: Ein Adoption-Play auswerten
Ein Softwareanbieter prüft monatlich 20 durch den Nutzungstrigger ausgelöste Kundenfälle. Bei 15 bestätigt das Team einen bearbeitungsbedürftigen Adoptionsrückgang. Fünf Auslösungen erklären sich durch Datenfehler oder erwartbare Schwankungen ohne gefährdeten Zielfortschritt.
Für jeden der 15 bestätigten Fälle vereinbaren CSM und Kunde ein überprüfbares Ziel für die nächsten 30 Tage. Ein mögliches Kriterium lautet: Mindestens acht von zehn vorgesehenen Nutzern führen den relevanten Workflow in jeder der letzten zwei Wochen selbstständig aus. Dieses Nutzungsziel muss zum vereinbarten Kundenergebnis beitragen.
Nach Ablauf aller Beobachtungsfristen ergibt sich folgende Auswertung:
| Beispiel | Kennzahl | Berechnung im Beispiel | Praktische Aussage |
|---|---|---|---|
| 1 | Anteil bestätigter Auslösungen | 15 bestätigte Fälle / 20 ausgelöste Fälle = 75 Prozent | Fünf Auslösungen geben Anlass, Datenqualität und Auslöseregel zu prüfen. |
| 2 | Rechtzeitige Erstprüfung | 18 von 20 Auslösungen innerhalb von zwei Arbeitstagen geprüft = 90 Prozent | Zwei Fälle überschreiten die intern festgelegte Reaktionsfrist. |
| 3 | Ursprüngliches Play-Ziel erreicht | 9 von 15 bestätigten Fällen innerhalb von 30 Tagen = 60 Prozent | In neun Fällen ist die jeweils vereinbarte Nutzung nachweisbar erreicht. |
| 4 | Ziel gemeinsam neu vereinbart | 3 von 15 Fällen = 20 Prozent | Diese Fälle erhalten einen eigenen Status; sie zählen nicht als ursprüngliche Zielerreichung. |
| 5 | Ziel bis zum Prüftermin nicht erreicht | 3 von 15 Fällen = 20 Prozent | Weitere Bearbeitung, Ursachenprüfung oder Eskalation ist erforderlich. |
Die erste Kennzahl zeigt nicht, wie viele relevante Fälle der Trigger übersieht. Dafür müsste das Team zusätzlich Fälle ohne Auslösung prüfen. Ebenso belegt ein Nutzungsanstieg allein noch keinen Geschäftsnutzen. Ob beispielsweise die Bearbeitungszeit beim Kunden sinkt, prüfen CSM und Kunde ergänzend im Success Plan.
Weitere Plays mit passenden Ergebnissen messen
Nicht jedes Play benötigt dieselbe Kennzahl. Entscheidend ist das zuvor festgelegte Ziel. Auch die folgenden Werte sind frei gewählte Beispiele; alle Fälle haben ihren jeweiligen Prüftermin erreicht.
| Beispiel | Play und Ziel | Beispielhafte Messung | Aussagegrenze |
|---|---|---|---|
| 1 | Onboarding: ersten nutzbaren Ergebnisbericht erzeugen | 8 von 10 Kunden erzeugen innerhalb von 21 Tagen einen Bericht mit eigenen Daten, den der fachliche Ansprechpartner als nutzbar bestätigt: 80 Prozent. | Eine absolvierte Schulung allein erfüllt dieses Kriterium nicht. |
| 2 | Sponsorwechsel: Entscheidungsfähigkeit wiederherstellen | In 6 von 8 Fällen sind innerhalb von 30 Tagen Nachfolge, Befugnisse und nächste Zielentscheidung mit dem Kunden geklärt: 75 Prozent. | Ein neuer Kontaktname im CRM genügt nicht. |
| 3 | Value-Meilenstein: Ergebnis gemeinsam überprüfen | In 7 von 10 Fällen bestätigen Kunde und CSM innerhalb von 14 Tagen Messgrundlage, erreichtes Ergebnis und nächsten Schritt: 70 Prozent. | Das dokumentiert den Wertnachweis; es beweist nicht, dass dieses Play den Wert erzeugt hat. |
Das gesamte Playbook auf Nutzbarkeit prüfen
Für die Abdeckung wertet das Team beispielsweise 40 Kundenfälle aus dem festgelegten Geltungsbereich aus. Für 30 gibt es ein passendes Play: Die fallbezogene Abdeckung beträgt 75 Prozent. Die übrigen zehn Fälle zeigen, wo Anleitungen fehlen oder bestehende Plays nicht passen. Seltene, aber besonders folgenreiche Situationen prüft das Team zusätzlich.
Zur Konsistenz untersucht es beispielsweise zehn Fälle mit mehreren ausgelösten Plays. In zwei Fällen erhielten Kunden doppelte Kontaktanfragen. Daraus folgt eine konkrete Verbesserung: Prioritäten, Zusammenführung und Übergaben klarer regeln.
Auch Aufwand gehört dazu. Benötigt die Dokumentation je Fall im Median 25 Minuten, prüft das Team, welche Angaben Entscheidungen oder Übergaben tatsächlich unterstützen. Die Zahl gepflegter Plays oder vorgenommener Änderungen ist für sich genommen kein Qualitätsnachweis.
Für den Einstieg genügt ein monatliches Fallreview: Wo half das Play? Wo musste der CSM begründet abweichen? Welche Information oder Entscheidung fehlte? Die verantwortliche Person übernimmt daraus konkrete Änderungen ins Playbook.
Ergebnisse vorsichtig interpretieren
Eine Zielerreichungsquote beschreibt zunächst das Ergebnis bearbeiteter Fälle. Sie beweist nicht, dass das Play dieses Ergebnis verursacht hat. Produktänderungen, Kundenressourcen und andere Maßnahmen können ebenfalls beitragen. Vergleiche sollten deshalb möglichst ähnliche Ausgangslagen und gleiche Beobachtungszeiträume berücksichtigen.
Risiko-Plays bearbeiten bereits gefährdete Fälle. Eine höhere Kündigungsquote als bei unauffälligen Kunden belegt daher keine schlechte Play-Qualität. Auch Vorher-nachher-Vergleiche liefern ohne geeignete Vergleichsgruppe keinen sicheren Wirkungsnachweis.
In meiner Masterarbeit habe ich Customer Success Playbooks und Plays nicht direkt untersucht. Die Befragungsdaten und offenen Antworten liefern jedoch Hinweise auf Belastungen durch operative Aufgaben und eingeschränkte Kapazitäten für proaktive Kundenarbeit (Kapitel 7.1, S. 78–79). Daraus leite ich für die Praxis ab: Playbooks sollten wiederkehrende Arbeit erleichtern und Verantwortung klären. Diese Empfehlung ist kein empirischer Wirksamkeitsnachweis für Playbooks.
Welche Fehler sollten Teams vermeiden?
Customer Success Playbooks entfalten ihren Nutzen nur, wenn das Team die Begriffsebenen trennt und das Playbook als lernende Arbeitsgrundlage behandelt. Teams sollten insbesondere folgende Fehler vermeiden:
- Playbook und Play werden synonym verwendet, sodass Geltungsbereich und Verantwortung unklar bleiben.
- Eine Sammlung einzelner Abläufe erhält keine gemeinsamen Prinzipien, Ordnung oder Konfliktregeln.
- Für jede Merkmalsveränderung wird vorschnell ein eigenes Play angelegt.
- Ein Signal gilt ohne Analyse bereits als Problem oder Ursache.
- Der Ablauf eines Plays besteht nur aus Aufgaben und enthält keine Analysefragen oder Entscheidungspunkte.
- Eine Aktivität wird zum Zielergebnis erklärt, etwa „drei E-Mails versenden“.
- Alle Kundengruppen erhalten unabhängig vom Kontext dieselbe Kontaktform und Betreuungsintensität.
- Automationen versenden Nachrichten, obwohl parallel ein Incident oder eine Eskalation läuft.
- Positive Veränderungen wie erreichte Value-Meilensteine oder neue Anwendungsfälle bleiben ohne passendes Play.
- Niemand pflegt Trigger, Plays, Arbeitsmittel und Verknüpfungen nach Produkt- oder Prozessänderungen.
Gerade ein wachsendes Playbook benötigt Prioritätsregeln. Eine geschäftskritische Störung kann beispielsweise das Pausieren allgemeiner Adoption-Kommunikation erfordern. Das Team legt den Vorrang anhand der Auswirkungen auf den Kunden fest. Andernfalls erzeugt die Standardisierung widersprüchliche Kundenkommunikation statt einer konsistenten Customer Experience.
Fazit: Das Playbook ordnet, das Play führt durch die Situation
Customer Success Playbooks übersetzen gemeinsames Erfahrungswissen in ein modular aufgebautes Handbuch. Sie verbinden Prinzipien, einen geordneten Katalog von Customer Success Plays, Rollen, Arbeitsmittel sowie Regeln für Messung und Weiterentwicklung.
Das einzelne Play ist die ausführende Einheit. Es verbindet eine wiederkehrende Kundensituation mit Kontext, Trigger, Analyse, alternativen Handlungswegen, Zielergebnis und Eskalationspfad. Damit entspricht das Customer Success Playbook dem übergeordneten B2B Sales Playbook, während das Customer Success Play funktional dem einzelnen Sales Play entspricht.
Standardisierung ersetzt dabei nicht das professionelle Urteil des CSM. Sie schafft einen gemeinsamen Entscheidungskorridor. Der Mensch ordnet Signale ein, versteht den Kundenkontext, führt das Gespräch und verantwortet kritische Entscheidungen. Systeme liefern Daten, stoßen Plays an und führen geeignete Teilschritte aus.
Der beste Ausgangspunkt ist deshalb ein klar begrenzter Handlungsbereich. Analysieren Sie mehrere wiederkehrende Kundensituationen, formulieren Sie daraus erste Plays und verbinden Sie diese anschließend durch gemeinsame Prinzipien, Rollen, Arbeitsmittel und Pflegevorgaben. So entsteht ein Customer Success Playbook, das Kundenarbeit tatsächlich verbessert.
Wissenschaftliche Quellen
- Bitner, M. J., Ostrom, A. L. & Morgan, F. N. (2008): Service Blueprinting: A Practical Technique for Service Innovation. California Management Review, 50(3), 66–94.
- Feldman, M. S. & Pentland, B. T. (2003): Reconceptualizing Organizational Routines as a Source of Flexibility and Change. Administrative Science Quarterly, 48(1), 94–118.
- Hochstein, B., Chaker, N. N., Rangarajan, D., Nagel, D. & Hartmann, N. N. (2021): Proactive Value Co-Creation via Structural Ambidexterity: Customer Success Management and the Modularization of Frontline Roles. Journal of Service Research, 24(4), 601–621.
- Reinartz, W., Krafft, M. & Hoyer, W. D. (2004): The Customer Relationship Management Process: Its Measurement and Impact on Performance. Journal of Marketing Research, 41(3), 293–305.
Eigene empirische Grundlage
- Rogall, H. M. (2025): Erfolgsfaktor Customer Success Management in B2B-SaaS-Kundenorganisationen. Unveröffentlichte Masterarbeit, FH des BFI Wien.
Praxisquellen
- Flowla: The Customer Success Playbook – Practical Guide for Handoff, Onboarding, and Continuous Success.
- Gainsight: Customer Success Playbook: What to Do When Your Sponsor Leaves.
- GitLab: Customer Success Playbooks.
- HubSpot und ChurnZero: 7 Smart Customer Success Playbooks.
Hinweis zur Quellenverwendung
Die wissenschaftlichen Quellen untersuchen organisationale Routinen, CRM-Prozesse, Servicegestaltung und die Customer Success Rolle. Sie belegen nicht die Wirksamkeit des hier entwickelten Playbook- und Play-Modells. Begriffshierarchie, Bestandteile, Kennzahlen und Praxisbeispiele sind eigene Synthesen und Vorschläge für die betriebliche Anwendung. Die Zahlenbeispiele und Schwellenwerte sind frei gewählt; sie sind weder Benchmarks noch empirische Befunde. Die Praxisquellen zeigen konkrete Begriffsverwendungen und Anwendungsformen, stellen jedoch keine unabhängigen Wirksamkeitsnachweise dar.
Comments are closed