Eine Claude Skill, die jedes Renewal in einem rollierenden Fenster nach Churn-Risiko bewertet, die Kohorte sortiert, damit der CSM weiß, welche Accounts er zuerst bearbeiten muss, und für die rot bewerteten Accounts einen Save Plan entwirft. Sie liest Health-, Engagement- und Support-Signale aus ChurnZero, erzeugt ein Risiko-Band samt der drei dahinterstehenden Driver und gibt eine priorisierte Worklist sowie einen einseitigen Save-Plan-Entwurf je gefährdetem Account aus. Die Ausgabe ist eine Prognose, die ein CSM in einem Renewal-Review verteidigen kann, und ein Ausgangspunkt, den er bearbeiten kann — weder eine Zahl noch ein fertiger Plan.

Das Artifact-Bundle liegt unter apps/web/public/artifacts/renewal-forecast-skill/ — SKILL.md plus drei Referenzdateien (references/1-risk-signal-weights.md, references/2-save-plan-format.md, references/3-sample-output.md), die die Skill bei jedem Lauf lädt.

Wann zu verwenden

Sie sind ein CSM oder ein CS-Ops-Lead, der ein Pod von CSMs unterstützt, und Sie verantworten ein Book von Renewals, deren Daten über das kommende Quartal verteilt sind. Sie wollen in das wöchentliche Renewal-Prognose-Review mit einer bereits nach Risiko sortierten Kohorte gehen, wobei jeder rote Account bereits einen Save-Plan-Entwurf trägt, statt dieses Bild am Vorabend von Hand zu bauen. Die Skill ist für das Fenster von T-120 bis T-90 Tagen gebaut: früh genug, dass eine Save Motion Anlauf hat, spät genug, dass die Signale nicht reines Rauschen sind.

Sie passt, wenn Sie ChurnZero (oder eine vergleichbare CS-Plattform, auf die der HTTP-Layer umgelenkt werden kann) haben, das Usage-, Engagement- und Support-Daten erzeugt, denen Sie auf Richtungsebene vertrauen, und wenn Ihre Renewal-Kohorte in einer gegebenen Woche bei etwa 10 bis 60 Accounts landet. Unter 10 sortieren Sie sie im Kopf; Sie brauchen keine Skill. Über 60 in einem einzigen Lauf teilen Sie nach Segment auf, damit jeder Save-Plan-Entwurf noch ein echtes Token-Budget statt eines ausgedünnten erhält.

Sie ist am nützlichsten, wenn Sie mindestens zwei Quartale gelabelter Renewal-Ergebnisse (erneuert, churned, downsold) haben, gegen die Sie die Gewichte prüfen können. Ohne das bewerten Sie auf einer als Zahl verkleideten Intuition, was schlechter ist als eine ehrliche Intuition, weil es eine falsche Autorität trägt.

Wann NICHT zu verwenden

Als Autopilot. Die Skill entwirft; der CSM entscheidet. Sie sendet nie eine Kunden-E-Mail, schreibt nie eine Prognose nach ChurnZero zurück, bucht nie selbst eine Save Play. Die Ausgabe ist internes Gerüst.
Für Punktschätzungen der Renewal-Wahrscheinlichkeit. Sie gibt vier Bänder zurück (über 70 Prozent Erneuerungswahrscheinlichkeit, 40 bis 70, 15 bis 40, unter 15), nicht „dieser Account liegt bei 63 Prozent”. Niemand handelt bei 63 anders als bei 58, und eine Punktschätzung lädt zu einer Überzuversicht ein, die die Daten nicht stützen.
Für Accounts in einem echten Auto-Renewal ohne offenes Opt-out-Fenster. Es gibt keine zu planende Save Motion; der Account erneuert sich, sofern der Kunde keinen Ausstieg einleitet. Die Skill markiert AUTO_RENEW_NO_ACTION und überspringt das Entwerfen eines Plans, statt Beschäftigung zu erfinden.
Für kommerzielle Konditionen. Rabattbeträge, Laufzeit und Preise bleiben beim CSM und beim Deal Desk. Der Skill ist es untersagt, einen bestimmten Rabatt zu empfehlen, und sie verweigert dies auf Anfrage.
Als Ersatz für einen Deep Dive je Account bei Ihren Top-drei-Renewals. Für die Accounts, die das Quartal bewegen, schlagen ein CSM und sein Leiter, die sorgfältig nachdenken, die Skill. Setzen Sie sie auf der Long Tail ein: die Accounts 4 bis 60, die sonst aus Zeitmangel übersprungen werden.

Setup

Etwa 45 bis 60 Minuten beim ersten Mal, größtenteils für das Tuning der Gewichte gegen Ihre eigenen gelabelten Ergebnisse aufgewendet.

Installieren Sie die Skill. Legen Sie das Bundle aus apps/web/public/artifacts/renewal-forecast-skill/ nach ~/.claude/skills/renewal-forecast/. Die Skill stellt einen einzigen Befehl bereit, forecast_renewals(window_start, window_end, segment), plus interne Helper für die ChurnZero-Pulls und die zweistufige Scoring-Pipeline.
Verdrahten Sie die Credentials. Setzen Sie CHURNZERO_API_KEY und CHURNZERO_APP_KEY (Lesezugriff auf accounts, ChurnScore, activities und Support-Tickets). Die Skill liest nur; sie schreibt nie zurück. Wenn Ihre Support-Daten außerhalb von ChurnZero liegen, richten Sie stattdessen SUPPORT_SOURCE auf den CSV-Export, und die Skill validiert den Header gegen references/1-risk-signal-weights.md, bevor sie ihn nutzt.
Tunen Sie die Signal-Gewichte. Öffnen Sie references/1-risk-signal-weights.md. Die mitgelieferten Defaults gewichten den Usage-Trend mit 0.45, die Engagement-Aktualität mit 0.30 und die Support-Reibung mit 0.25, mit Overrides je Segment (PLG-Books neigen Usage zu 0.6; High-Touch-Enterprise neigt Engagement zu 0.4). Ersetzen Sie diese durch die Gewichte, die gegen Ihre letzten zwei Quartale Renewal-Ergebnisse am besten im Backtest abschneiden. Bearbeiten Sie ein Gewicht nach dem anderen und scoren Sie eine bekannte Kohorte neu, damit Sie sehen, was sich bewegt hat.
Passen Sie das Save-Plan-Template an. Öffnen Sie references/2-save-plan-format.md und ersetzen Sie das Abschnitts-Gerüst durch die Motions Ihres Teams: die Stakeholder-Asks, die Struktur des Value-Recaps, das Eskalations-Gate. Ersetzen Sie das ausgearbeitete Beispiel in references/3-sample-output.md durch drei bis fünf anonymisierte echte Save Plans, damit der Drafting-Pass die Stimme Ihres Teams statt einer generischen nachahmt.
Führen Sie für eine Kohorte aus. forecast_renewals(window_start="2026-07-01", window_end="2026-09-30", segment="mid-market"). Die Skill gibt eine sortierte Markdown-Worklist (eine Zeile je Account: Band, drei Driver, ARR, Renewal-Datum, Owner) plus einen Save-Plan-Entwurf je rotem und gelbem Account aus. Lesen Sie sie, bearbeiten Sie sie, und konvertieren Sie dann beim ersten Lauf die Motions von Hand in ChurnZero Plays oder Tasks.

Was die Skill tatsächlich tut

Die Skill zieht je Account im Fenster drei Signalfamilien aus ChurnZero: den Usage-Trend (aktuelles Aktiv-Event-Volumen der letzten 28 Tage gegen das eigene 90-Tage-Baseline des Accounts, nicht gegen einen globalen Durchschnitt), die Engagement-Aktualität (vom CSM protokollierte Meetings, QBRs und Exec Touches mit einem exponentiellen Aktualitäts-Decay, Halbwertszeit 21 Tage) und die Support-Reibung (Anzahl offener Tickets, Schweregrad-Mix und mediane Lösungszeit über die letzten 90 Tage). Der Bezug auf das eigene Baseline des Accounts statt auf einen Kohorten-Durchschnitt ist die tragende Entscheidung: ein Usage-Rückgang von 40 Prozent zählt, ob der Account ein Heavy- oder Light-User ist, und ein globaler Durchschnitt begräbt das.

Dann führt sie zwei Claude-Passes aus. Pass eins ist das Scoring. Claude nimmt die drei normalisierten Sub-Scores und die Gewichte je Segment und erzeugt einen Composite, ein Band und die drei konkreten Driver hinter dem Band — jeder Driver nennt eine echte Zahl („aktive Nutzer um 38 Prozent unter dem 90-Tage-Baseline”, „seit 74 Tagen kein Exec Touch protokolliert”, „zwei Sev-1-Tickets seit 9 Tagen offen”), nie ein Bauchgefühl. Das Scoring ist ein dedizierter Pass, damit die Driver aus den tatsächlichen Sub-Scores hergeleitet werden, statt nach der Wahl des Bands rückwärts gerechtfertigt zu werden. Eine Guard deckelt das Band: lassen sich weniger als drei unabhängige Driver nennen, sinkt das Band um eine Stufe, denn eine zuversichtliche Prognose auf einem einzigen Signal ist der Fehlermodus, der das Vertrauen am schnellsten erodiert.

Pass zwei ist das Entwerfen des Save Plans, und er läuft nur für Accounts in den Bändern Rot (unter 15 und 15 bis 40) und Gelb (40 bis 70). Claude liest die Driver aus Pass eins plus das Save-Plan-Template in references/2-save-plan-format.md und erzeugt einen einseitigen Entwurf: den wahrscheinlichen Churn-Archetyp, die an ein 30/60/90-Tage-Tempo gebundenen Stakeholder-Motions, die zwei oder drei angesichts der Driver wahrscheinlichsten Einwände und ein Eskalations-Gate. Accounts im grünen Band (über 70) erhalten eine einzeilige „Monitor”-Notiz, keinen Plan — einen Save Plan für einen nicht gefährdeten Account zu schreiben, sind verschwendete Tokens und verschwendete CSM-Lesezeit.

Die Sortierung, die alles zusammenhält, ordnet die Kohorte nach Band aufsteigend (das gefährdetste zuerst), dann nach ARR absteigend innerhalb jedes Bands, dann nach Renewal-Datum aufsteigend. Diese Reihenfolge ist bewusst gewählt: sie setzt die größten nahen Verluste an die Spitze der Worklist, was die Reihenfolge ist, in der ein CSM das Book tatsächlich abarbeiten sollte.

Kostenrealität

Ein vollständiger Lauf über eine Quartals-Kohorte von 40 Accounts kostet etwa 20.000 bis 35.000 Input-Tokens für das Scoring (Account-JSON, Signal-Pulls, die Gewichts-Referenz) plus 3.000 bis 6.000 Input- und 2.000 bis 4.000 Output-Tokens je Save-Plan-Entwurf. Mit Claude Sonnet zu aktuellen Listenpreisen (etwa 3 $ pro Million Input, 15 $ pro Million Output) landet eine Kohorte von 40 Accounts, von denen ein Drittel rot oder gelb scort, bei rund 25 bis 45 Cent pro Lauf. Führen Sie ihn wöchentlich über ein rollierendes Quartal aus, und die Anthropic-Ausgaben betragen wenige Dollar pro Monat — ein Rundungsfehler gegen ein einziges gerettetes Mid-Market-Renewal.

Die Wanduhrzeit liegt bei zwei bis fünf Minuten je Kohorte, dominiert von den ChurnZero-Pulls; die zwei Claude-Passes fügen vielleicht eine Minute hinzu. Die Kosten, die zählen, sind menschlich: ein CSM, der ein Book von 40 Accounts von Hand prognostiziert, verbringt 60 bis 90 Minuten damit, ChurnScores zu ziehen, Aktivitäts-Timelines zu lesen und Accounts vor dem Review zu sortieren. Die Skill bringt das auf etwa 20 Minuten Lesen und Bearbeiten, also beträgt die Ersparnis etwa eine Stunde je wöchentlichem Review je CSM.

Wie Erfolg aussieht

Verfolgen Sie über das erste Quartal drei Zahlen. Erstens, die Prognose-Übereinstimmung: befragen Sie das CSM-Pod nach jedem Review, welcher Anteil der Bänder ihrer eigenen Einschätzung entsprach, nachdem sie den Account bearbeitet hatten. Zielen Sie auf über 70 Prozent bis Woche vier; unter 50 Prozent heißt, die Gewichte sind falsch, nicht das Modell, und die Korrektur liegt in references/1-risk-signal-weights.md, nicht im Prompt. Zweitens, die Save-Plan-Konversion: welcher Anteil der entworfenen Motions binnen 48 Stunden zu nachverfolgten ChurnZero Plays oder Tasks wird. Zielen Sie auf über 80 Prozent; niedriger heißt, die Entwürfe sind zu generisch, um zu handeln. Drittens, das verzögerte Signal, das am meisten zählt: die Renewal-Rate bei gelben und roten Accounts, bei denen die Skill genutzt wurde, gegen eine vergleichbare Kohorte, bei der sie es nicht wurde, Quartal für Quartal. Die Skill ist nicht die einzige Variable, aber wenn sich die Renewal-Rate gefährdeter Accounts überhaupt nicht bewegt, werden die Prognosen erzeugt und ignoriert.

vs Alternativen

ChurnZeros native Renewal-Prognose und ChurnScore. ChurnZero erzeugt bereits einen Health Score und eine Renewal-Wahrscheinlichkeits-Einschätzung, und wenn Ihr Team diesen vertraut und danach handelt, brauchen Sie diese Skill nicht. Was es nicht tut, ist, den Score in drei konkreten Drivern zu erklären, die ein CSM in einem Review verteidigen kann, noch den Save Plan für die schlecht scorenden Accounts zu entwerfen. Nutzen Sie ChurnZero als System of Record und Signalquelle; nutzen Sie die Skill für die Erklärung und den Plan-Entwurf. Sie sind komplementär — die Skill liest die Daten von ChurnZero, sie ersetzt nicht dessen Scoring-Engine.
Die Skill Renewal-Playbook-Generator. Jene Skill geht bei einem einzelnen, bereits markierten Account in die Tiefe — vollständige Stakeholder-Motion-Matrix, Talk-Track-Gerüst, Eskalations-Gates. Diese Skill macht den Schritt davor: sie sagt Ihnen, welche Accounts der gesamten Kohorte überhaupt zu markieren sind, und gibt jedem einen leichteren Plan-Entwurf. Führen Sie diese aus, um das Book zu triagieren, und führen Sie dann den Playbook-Generator auf den zwei oder drei Roten aus, die die tiefere Behandlung rechtfertigen.
Der tägliche Churn-Risiko-Digest. Jener Digest ist event-getriggert und auf die letzten 24 Stunden bezogen — er sagt Ihnen, was sich über Nacht geändert hat. Diese Skill ist fensterbasiert und nach vorn gerichtet — sie sortiert eine Renewal-Kohorte über ein Quartal nach Risiko. Anderer Zeithorizont, andere Aufgabe. Viele Teams führen beide aus: den Digest für die tägliche Reaktion, diese für die wöchentliche Prognose.
Eine manuelle Tabellenkalkulations-Prognose. Was die meisten Pods heute tun: ein CSM zieht ChurnScores in ein Sheet, beäugt die Aktivitäts-Timeline und färbt nach Gefühl. Maximaler Kontext, minimale Konsistenz — jeder CSM erfindet sein eigenes Framing, und die Zahlen sind über das Pod hinweg nicht vergleichbar. Die Skill tauscht etwas von diesem Kontext gegen ein geteiltes Framing, das das ganze Pod durch Bearbeiten der Gewichtsdatei bestreiten kann. Behalten Sie das Sheet, wenn Sie ein Zwei-Personen-Team sind; setzen Sie die Skill ab vier CSMs ein, wo Konsistenz zu greifen beginnt.

Worauf zu achten ist

Schmutziges Usage-Tagging erzeugt ein zuversichtlich falsches Band. Sind ChurnZero-Events über die Produktflächen hinweg inkonsistent getaggt, ist das Baseline je Account bedeutungslos, und die Skill bringt Rückgänge zum Vorschein, die eine Tagging-Änderung statt einer Verhaltensänderung widerspiegeln. Guard: vor dem Go-live führt die Skill einmalig eine Prüfung der Event-Namen-Verteilung je Account über 90 Tage durch und verweigert das Scoren jedes Accounts, dessen Top-fünf-Event-Typen nicht stabil sind, und markiert ihn BASELINE_UNTRUSTWORTHY, statt zu raten.
Überzuversichtliche Bänder auf einem einzigen starken Signal. Eine rote Support-Situation kann einen sonst gesunden Account allein ins Gelbe ziehen, oder ein kürzliches QBR kann einen stillen Usage-Kollaps verdecken. Guard: das Band muss von drei unabhängigen Drivern gestützt sein; lassen sich nur einer oder zwei nennen, sinkt das Band um eine Stufe, und die Worklist-Zeile wird THIN_SIGNAL getaggt, damit der CSM sie als Hypothese behandelt, nicht als Prognose.
Veraltete ChurnZero-Daten als frisch gescort. Ein ChurnScore, der seit Tagen nicht neu berechnet wurde, wird gescort, als wäre er aktuell. Guard: die Skill liest den Last-Updated-Zeitstempel jedes Signals, und ist das frischeste Signal eines Accounts älter als 7 Tage, stellt sie der Zeile DATA_STALE (n Tage) voran, statt ein veraltetes Band als live zu präsentieren.
Save Plans, die in kommerzielle Konditionen abdriften. Der Drafting-Pass greift, wenn nicht eingeschränkt, nach „einen Rabatt anbieten”, was genau das Territorium ist, das zum Deal Desk gehört. Guard: der Save-Plan-Prompt verbietet jede Erwähnung von Rabattbeträgen, Laufzeit oder Preisen, und das Ausgabe-Template hat keinen Slot dafür; kommerzielle Schritte werden als „an den Deal Desk eskalieren” markiert, nie entworfen.
Die Worklist als die Arbeit behandeln. Eine sortierte Liste, die niemand in nachverfolgte Motions konvertiert, ändert nichts. Guard: jeder Save-Plan-Entwurf endet mit der expliziten Erinnerung, dass Motions nichts wert sind, bis sie wöchentlich geprüfte ChurnZero Plays oder Tasks sind, und der Setup-Schritt bindet die Generierung an einen Konversionsschritt.

Stack

ChurnZero — Usage-Trend, ChurnScore, Engagement-Activities und Support-Signale (schreibgeschützt via API); Ziel für die Plays, die der CSM aus den Entwürfen erstellt
Claude (Sonnet empfohlen) — zweistufige Pipeline: Scoring mit konkreten Drivern, dann Save-Plan-Entwurf für rote und gelbe Accounts
Artifact-Bundle unter apps/web/public/artifacts/renewal-forecast-skill/ (SKILL.md, references/1-risk-signal-weights.md, references/2-save-plan-format.md, references/3-sample-output.md)

Diese Seite auf GitHub bearbeiten