Die meisten CS-Teams erfahren erst dann, dass ein Account abwandert, wenn das Renewal nicht abschließt. Zu diesem Zeitpunkt ist das Save-Fenster seit Monaten geschlossen. Die Lösung ist kein besserer Health Score — es ist eine feste Motion, die in dem Moment auslöst, in dem ein Score einen Schwellenwert überschreitet, damit der CSM in Woche eins des Abrutschens eingreift, statt in den letzten 30 Tagen vor dem Renewal zu reagieren. Dieses SOP ist genau diese Motion: ein Trigger, ein Diagnoseschritt, eine gestufte Intervention, eine Eskalationsregel und eine Dokumentationspflicht, die für jeden gefährdeten Account gleich abläuft. Sie ist bewusst starr. Eine Save-Motion, die davon abhängt, dass jeder CSM den richtigen Zug improvisiert, wenn ein Account rot wird, ist eine Motion, die für Ihren besten CSM funktioniert und für alle anderen versagt.

Das Artifact-Bundle liegt unter apps/web/public/artifacts/churn-save-playbook-sop/. Es liefert churn-save-sop.md (das Verfahren selbst, bereit zum Einfügen in Notion oder eine Gainsight-Knowledge-Base), save-plan-template.md (das strukturierte Save-Plan-Doc, das der CSM pro Account ausfüllt) und slack-escalation-template.md (den kanonischen Alert, den der CSM postet, wenn ein Account eskaliert). Passen Sie alle drei vor dem Rollout an Ihre Score-Namen, Segmentbänder und Kanalkonventionen an.

Wann Sie es verwenden

Verwenden Sie dieses SOP, wenn Sie einen Health Score in Gainsight (oder einem vergleichbaren CSP) betreiben, dem Sie genug vertrauen, um zu handeln, und Sie noch keine geschriebene und durchgesetzte Motion dafür haben, was passiert, wenn ein Account rot wird. Das klassische Symptom ist ein Save, der funktionierte, weil ein CSM ihn zufällig früh erwischte und wusste, wen er anrufen musste — und im nächsten Quartal macht ein identischer Account Churn, weil ein anderer CSM dasselbe rote Flag sah und auf das QBR wartete. Der Score tut seine Arbeit; die Reaktion auf den Score ist der Gap, den dies schließt.

Am besten passt es für Teams im Bereich von 100 bis 2.000 Kunden mit einem definierten Health Score, einer CSM-Book-Struktur und einem CS-Leiter, der die Eskalationen verantworten kann. Unter ~100 Accounts liest ein CSM jeden Account direkt, und eine dokumentierte Motion ist Overhead. Über ~2.000 wollen Sie die Save-Motion wahrscheinlich über eine Gainsight-CTA mit nativem Routing und SLA-Tracking steuern statt über einen Slack-Post und ein geteiltes Doc — in dieser Größenordnung sind die manuellen Schritte diejenigen, die übersprungen werden. Dieses SOP ist das richtige Tool in dem Band, in dem die Motion zählt, das Playbook aber in den Köpfen der Leute lebt.

Wann Sie es NICHT verwenden

Führen Sie es nicht ein, wenn Sie Ihrem Health Score nicht vertrauen. Eine Save-Motion, die von einem Score ausgelöst wird, der bei Tagging-Rauschen oder einem einzigen verpassten Login rot wird, trainiert die CSMs innerhalb eines Monats, den Trigger zu ignorieren. Reparieren Sie zuerst den Score — der zusammengesetzte Health Score in n8n und der CS-Health-Score-Builder existieren dafür — und setzen Sie dann diese Motion obendrauf. Eine präzise Motion auf einem verrauschten Trigger ist schlimmer als gar keine Motion, weil sie das Vertrauen des Teams in das eine Signal verbrennt, auf das es reagieren soll.

Verwenden Sie es nicht als Renewal-Forecasting-Tool. Dieses SOP ist auf den Save zugeschnitten: ein Account, der gesund war und jetzt abrutscht, wo das Ziel ist, den Abrutsch umzukehren, bevor er das Renewal erreicht. Ein Account, der ohnehin aus einem Grund gehen würde, den kein CSM bewegen kann — der Käufer ist weg, das Unternehmen wurde übernommen, der Use Case ist tot — ist kein Save-Kandidat, und ihn durch die Motion zu zwingen, verschwendet die Stunden des CSM an einen deterministischen Verlust. Der Diagnoseschritt existiert teils dafür, diese Entscheidung früh zu treffen.

Lassen Sie es nicht ohne einen CS-Leiter laufen, der die Eskalationen annimmt. Die Eskalationsstufe ist tragend: Der ganze Punkt ist, dass ein Account jenseits einer Schweregrad-Linie aufhört, das Problem eines einzelnen CSM zu sein, und das Problem des Teams wird. Wenn Eskalationen in einen Kanal laufen, den niemand verantwortet, degradiert die Motion zur selben Improvisation, die sie ersetzen sollte.

Der Trigger

Die Motion löst auf einem Gainsight-Score-Event aus, nicht auf der Ahnung eines CSM oder dem Kalender. Zwei Trigger, jeder von beiden startet die Uhr:

Bandabfall ins Rote —der zusammengesetzte Health Score wechselt von Gelb zu Rot (im Referenz-Scoring zusammengesetzt unter 50). Das ist der primäre Trigger.
Großes negatives Delta innerhalb eines Bands —ein Abfall von 15 Punkten oder mehr in einem einzigen Scoring-Zyklus, selbst wenn der Account technisch noch gelb ist. Ein Sturz von Grün auf Mittel-Gelb ist oft ein schärferes Signal als ein stabiles Rot, weil er neu ist und die Ursache jung genug, um noch umkehrbar zu sein.

Gainsight löst bei beiden Bedingungen eine CTA aus; die CTA-Zuweisung ist der CSM of Record. Das SLA: Der CSM öffnet einen Save-Plan innerhalb von zwei Werktagen nach dem Trigger. Den Start an das Score-Event statt an ein wöchentliches Review zu binden, ist der ganze Punkt — ein Review wird verschoben; eine CTA mit einem SLA wird getrackt.

Die Motion

Diagnostizieren (bis Tag 2). Vor jedem Outreach füllt der CSM den Diagnoseabschnitt von save-plan-template.md aus: welcher Sub-Score sich bewegt hat (Usage, Aktivität, Sentiment), die konkrete Zahl und ihr Baseline, und eine einzeilige Hypothese zur Ursache. Die Hypothese wird in eine feste Menge gezwungen — Adoptionsstau, Champion-Wechsel, nicht realisierter Wert, Wettbewerbsverdrängung, Budget/wirtschaftlich, oder Produkt-Gap — weil die Ursachenklasse den Zug bestimmt. Eine Diagnose wie „sie wirken unzufrieden” wird abgelehnt; der CSM benennt den Sub-Score und die wahrscheinliche Klasse oder markiert „Ursache unbekannt, Untersuchungsanruf erforderlich”.
Intervenieren (bis Tag 5), gestuft nach der Ursache. Adoptionsstau → eine Arbeitssitzung zum ungenutzten Feature, kein Check-in. Champion-Wechsel → eine Einführungs-Motion, um den neuen Stakeholder vor allem anderen zu kartieren und zu gewinnen. Nicht realisierter Wert → holen Sie den Success Plan und das ursprüngliche „warum sie gekauft haben” hervor und buchen Sie ein Value-Review gegen die Metrik, die sie beim Deal definiert haben. Wettbewerbsverdrängung → ziehen Sie den AE hinzu und eskalieren Sie, falls gerechtfertigt, sofort. Budget/wirtschaftlich → ein kommerzielles Gespräch, das der CSM möglicherweise nicht allein verantwortet. Produkt-Gap → protokollieren Sie es, setzen Sie ehrlich Erwartungen und versprechen Sie kein Roadmap-Datum, das der CSM nicht halten kann. Das Template trägt einen Default-Zug pro Klasse, sodass der CSM die Variation wählt und nicht den Zug erfindet.
Eskalieren (wenn die Schweregrad-Linie überschritten wird). Ein Account eskaliert aus der Einzel-CSM-Motion heraus, sobald eines von Folgendem zutrifft: Er ist rot UND über einem Umsatzschwellenwert, den das Team festlegt (z. B. ARR im oberen Quartil), die Ursache ist Wettbewerbsverdrängung, oder der Save-Plan läuft seit 30 Tagen ohne Banderholung. Die Eskalation postet in #cs-saves mit slack-escalation-template.md —Account, ARR, Renewal-Datum, der bewegte Sub-Score mit seiner Zahl, Ursachenklasse, der bisher gespielte Zug und die konkrete Bitte an die Führung. Der CS-Leiter bestätigt im Thread innerhalb eines Werktags und weist einen Exec Sponsor oder AE zu, falls die Bitte es rechtfertigt.
Dokumentieren (laufend und beim Abschluss). Jeder Save-Plan erfasst den Trigger, die Diagnose, den Zug und das Ergebnis — gerettet, gechurnt oder herabgestuft — an die Ursachenklasse gebunden. Das ist die Hälfte der Motion, die sich verzinst: Nach einem Quartal können Sie ablesen, welche Ursachenklassen Sie tatsächlich retten und welche nicht, und die Stunden des CSM auf die rettbaren umlenken. Ein Save, der nicht dokumentiert wird, lehrt das Team nichts.

Wie Erfolg aussieht

Verfolgen Sie vier Zahlen. Erstens, die Zeit von Trigger zu Erstkontakt —Tage vom Auslösen der Gainsight-CTA bis zur ersten protokollierten Save-Aktion. Das SLA von zwei Werktagen sollte den Median innerhalb eines Monats unter zwei Tage drücken; eine längere Verzögerung bedeutet, dass die CTA in eine Warteschlange auslöst, die niemand bearbeitet. Zweitens, die Save-Rate nach Ursachenklasse —von den Accounts, die in die Motion eintraten, der Prozentsatz, der sich auf Gelb-oder-besser erholt und verlängert hat, aufgeschlüsselt nach diagnostizierter Ursache. Das ist die Zahl, die Ihnen sagt, wo sich die Motion verdient macht; erwarten Sie, dass Adoptionsstau-Saves deutlich über Wettbewerbsverdrängungs-Saves liegen, und besetzen Sie entsprechend. Drittens, die Eskalationspräzision —von den eskalierten Accounts der Prozentsatz, bei dem die Beteiligung der Führung das Ergebnis plausibel verändert hat. Wenn sich die meisten Eskalationen ohne Führung gelöst hätten, ist die Schweregrad-Linie zu niedrig gesetzt und Sie besteuern den CS-Leiter. Viertens, die Rechtzeitig-erwischt-Rate —von den Accounts, die Churn machten, der Prozentsatz, der überhaupt jemals in die Save-Motion eintrat. Eine hohe Churn-ohne-Save-Plan-Rate bedeutet, dass der Trigger die Abrutsche nicht früh genug erwischt, was Sie zurück zum Score schickt, nicht zur Motion.

Versus die Alternativen

Versus ein Ad-hoc-Save aus dem QBR-Zyklus. Der Status quo bei den meisten Teams ist, dass das Risiko im Quartals-Review auftaucht und der CSM eine Reaktion improvisiert. Es kostet nichts beim Aufsetzen und verliert bei Timing und Konsistenz: Das QBR kann 80 Tage nach Beginn des Abrutschens liegen, und die Reaktionsqualität schwankt damit, welcher CSM den Account verantwortet. Dieses SOP kostet das Aufsetzen einer Gainsight-CTA und dreier Templates und verschiebt die Reaktion auf innerhalb einer Woche nach dem Trigger. Wählen Sie die Ad-hoc-Variante nur, wenn Ihre Account-Zahl niedrig genug ist (unter ~100), sodass ein CSM ohnehin jeden Account wöchentlich liest.

Versus ein nativ gebautes Gainsight-Playbook / CTA ohne ein geschriebenes SOP dahinter. Gainsight kann die CTA auslösen und eine Aufgaben-Checkliste anhängen, und in der Größenordnung ist das der richtige Zustellmechanismus. Aber eine CTA-Checkliste ohne die Diagnose-zu-Zug-Logik dahinter produziert Aufgaben-Abhak-Theater — der CSM hakt die Kästchen ab und improvisiert trotzdem den eigentlichen Save. Nutzen Sie die Gainsight-CTA als Trigger und SLA-Timer und nutzen Sie die Diagnoseklassen und gestuften Züge dieses SOP als den Inhalt, auf den die CTA verlinkt. Die beiden sind komplementär: Gainsight ist die Mechanik, das SOP ist das Urteil.

Versus nichts Strukturiertes tun. Nur dann tragfähig, wenn Ihr Churn echt nicht durch CS adressierbar ist — eine reine PLG-Motion ohne menschlichen Touch, oder ein Segment, in dem Saves nie die CSM-Stunden zurückzahlen. Für jedes Team mit einem beziehungsgetriebenen Renewal ist die unstrukturierte Reaktion auf einen roten Account die größte einzelne Quelle vermeidbaren Churns: der Save, den ein CSM gemacht hätte und ein anderer verpasste, entschieden dadurch, wer zufällig den Account verantwortete.

Worauf zu achten ist

Der Trigger löst auf Score-Rauschen aus. Wenn der Health Score bei inkonsistentem Usage-Tagging oder einer einzigen ruhigen Woche rot wird, bearbeitet der CSM ein Nicht-Problem und lernt, der CTA zu misstrauen. Guard: Konditionieren Sie den Trigger auf den zusammengesetzten Score, nicht auf einen einzelnen Sub-Score, und verlangen Sie, dass der Großes-Delta-Trigger über zwei Scoring-Zyklen anhält, bevor er eine CTA auslöst — ein Eine-Nacht-Blip korrigiert sich selbst und erreicht nie die Warteschlange des CSM.
Die Diagnose kollabiert zu einem generischen „gefährdet”-Etikett. Wenn der Diagnoseschritt optional oder Freitext ist, überspringen die CSMs ihn und springen zu einem Check-in-Anruf, der der Zug für jede Ursache und der richtige Zug für keine ist. Guard: Der Save-Plan rückt nicht zum Interventionsschritt vor, bis eine Ursachenklasse aus der festen Liste gewählt oder „Ursache unbekannt” explizit mit gebuchtem Untersuchungsanruf gewählt ist — die Klasse ist es, die den Zug auswählt.
Eskalation als Abladeplatz. Wenn Eskalieren leichter ist als den Zug zu spielen, eskalieren die CSMs alles und der CS-Leiter wird zum Flaschenhals. Guard: Das Eskalations-Template verlangt das Feld bisher-gespielter-Zug und eine konkrete Bitte, bevor es postet; eine Eskalation ohne vorherigen Zug und ohne konkrete Bitte wird vom CS-Leiter im Thread an den CSM zurückgegeben.
Saves, die beim Abschluss nicht dokumentiert werden. Ein CSM, der einen Account rettet und weitermacht, ohne die Ursache und den Zug zu erfassen, lehrt das Team nichts, und der nächste identische Abrutsch wird von Grund auf improvisiert. Guard: Die Gainsight-CTA schließt nicht, bis das Ergebnisfeld (gerettet / gechurnt / herabgestuft) und die Ursachenklasse gesetzt sind, sodass jeder geschlossene Save-Plan den Save-Rate-nach-Ursache-Report speist.
Die Motion überlebt den Score, auf den sie abgestimmt wurde. Ein neugewichteter Health Score oder ein umbenannter Sub-Score bricht still die Trigger-Schwellenwerte und die Sub-Score-Referenzen der Diagnose. Guard: Überprüfen Sie die Trigger-Schwellenwerte in der Gainsight-CTA und die Sub-Score-Namen in save-plan-template.md einmal pro Quartal gegen den Live-Score, im selben Review, das die Score-Gewichte nachjustiert.

Stack

Gainsight —der Health Score, die CTA, die den Trigger auslöst, der SLA-Timer und der Ergebnis-nach-Ursache-Report
Slack —der Eskalationskanal #cs-saves und der Bestätigungs-Thread des Leiters
Das Save-Plan-Doc —save-plan-template.md, gespeichert dort, wo Ihr Team die Account-Docs hält (Gainsight, Notion, oder ein Salesforce Custom Object), ein einziger kanonischer Ort pro Account

Diese Seite auf GitHub bearbeiten