Eine Claude Skill, die vier rohe Input-Streams — Produktnutzung, Beziehungs-Engagement, Support-Last und Survey-Sentiment — in einen einzigen gewichteten Health Score pro Account, ein grünes/gelbes/rotes Tier und eine priorisierte Remediation-Queue verwandelt, die das CSM-Team von oben nach unten abarbeitet. Der Punkt ist nicht die Zahl; die meisten CSPs geben Ihnen bereits eine Zahl. Der Punkt ist, dass die Skill jedes Gewicht, jeden Schwellenwert und jede Tier-Grenze in einer Config-Datei explizit macht, die Sie bearbeiten, und dann den Score jedes Accounts in einem Satz erklärt, der den größten negativen Driver mit seinem realen Wert benennt. Ein CSM, der die Queue öffnet, sieht „Acme — 48, rot — Support-Last: 11 P1-Tickets in 30 Tagen gegen einen Baseline von 2” statt einer farbigen Pille, der niemand vertraut. Das Artifact-Bundle liefert SKILL.md plus drei Referenzdateien: ein ausfüllbares Scoring-Config-Schema, ein Tier-und-Aktion-Playbook-Template und ein ausgearbeitetes Beispiel-Output.

Das Artifact-Bundle liegt unter apps/web/public/artifacts/cs-health-score-builder-skill/. Lesen Sie SKILL.md und passen Sie alle drei Dateien in references/ vor dem ersten Lauf an.

Wann zu verwenden

Sie sind ein CSM oder CS-Ops-Lead, der ein Health-Score-Modell braucht, das Sie in einem QBR verteidigen können, und Ihr aktueller Score — sei es der Default von Vitally, Planhat oder einer Tabellenkalkulation — ist eine Blackbox, der das Team nicht mehr vertraut. Die Skill ist für die Entwurfs-und-Iterations-Phase: Sie füttern sie mit den vier Input-Streams für einen Batch von Accounts, sie berechnet Scores gegen eine explizite Config und gibt Ihnen eine Queue plus eine Erklärung pro Account zurück. Sie lesen die Erklärungen, entscheiden, ob die Gewichte der Realität entsprechen, bearbeiten die Config und lassen erneut laufen. Nach drei oder vier Iterationen gegen Accounts, die Sie bereits verstehen, haben Sie ein Modell, dessen jede Grenze Sie rechtfertigen können.

Am besten funktioniert sie, wenn Sie mindestens 50 Accounts zu scoren haben (kleinere Books liest ein CSM von Hand), ein sauberes Nutzungssignal, das Sie als CSV oder über die API Ihres CSP ziehen können, und idealerweise 12 Monate gelabelter Churn-Historie, gegen die Sie die Gewichte per Backtest prüfen. Die Remediation-Queue ist am nützlichsten, wenn das Team sich verpflichtet, sie von oben nach unten abzuarbeiten — der Score gewinnt nur dann Vertrauen, wenn die roten Accounts an der Spitze diejenigen sind, die tatsächlich churnen.

Wann NICHT zu verwenden

Verwenden Sie die Skill nicht als nächtliche Live-Scoring-Engine, die an Vitally oder Planhat verdrahtet ist. Sie ist ein Modell-Entwurfswerkzeug, keine Produktionsinfrastruktur. Sobald Sie eine Config haben, der Sie vertrauen, portieren Sie die Gewichte und Schwellenwerte in das native Scorecard Ihres CSP oder in einen n8n-Flow, der auf einem Schedule läuft — die Aufgabe der Skill ist es, die Config richtig zu treffen, nicht ewig zu laufen.

Verwenden Sie sie nicht, wenn Ihre Nutzungstelemetrie unzuverlässig ist. Ein Score, der auf inkonsistent getaggten Events aufbaut, bringt Rückgänge zutage, die eine Tagging-Änderung widerspiegeln, keine Verhaltensänderung, und der Erklärungssatz wird selbstbewusst einen falschen Driver benennen. Reparieren Sie zuerst die Daten.

Verwenden Sie sie nicht, wenn Sie keine Churn-Definition und keine gelabelte Historie haben. Ohne Backtest raten Sie die Gewichte, und ein geratenes Modell ist schlimmer als kein Modell, weil es die Autorität einer Zahl trägt. Die Skill gibt eine UNBACKTESTED-Warnung im Queue-Header zurück, wenn Sie den Backtest-Input überspringen, aber sie kann Sie nicht davon abhalten, die Vermutung auszuliefern.

Verwenden Sie sie nicht für weniger als ~50 Accounts, für Umsatz-Forecasting oder für das Scoring einzelner Nutzer (sie scort Accounts, keine Seats).

Setup

Ungefähr 45 bis 90 Minuten beim ersten Mal, fast vollständig damit verbracht, die Scoring-Config so auszufüllen, dass sie zu Ihren Daten passt, nicht damit, irgendetwas zu verdrahten.

Installieren Sie die Skill. Legen Sie das Bundle von apps/web/public/artifacts/cs-health-score-builder-skill/ in ~/.claude/skills/cs-health-score/ ab. Es sind keine Credentials erforderlich — die Skill liest Dateien, die Sie bereitstellen, sie ruft Vitally oder Planhat nicht direkt auf. Sie exportieren die Daten; die Skill scort sie.
Füllen Sie die Scoring-Config aus. Öffnen Sie references/1-scoring-config.md und legen Sie pro Account-Segment die vier Input-Gewichte (müssen sich zu 1.0 summieren), das Baseline-Fenster für die Nutzung und die grünen/gelben/roten Grenzen fest. Das Template kommt mit Startwerten — Enterprise gewichtet Engagement mit 0.35 und Nutzung mit 0.30, weil die Beziehungsgesundheit das Renewal treibt; PLG gewichtet Nutzung mit 0.55, weil das Produkt der Deal ist. Das sind Ausgangspunkte zum Bearbeiten gegen Ihren eigenen Backtest, keine Empfehlungen.
Passen Sie das Aktions-Playbook an. Öffnen Sie references/2-tier-playbook.md und ersetzen Sie die Platzhalter-Plays durch die echten Motions Ihres Teams — was ein CSM tut, wenn ein Account auf Support-Last rot landet, im Vergleich zu rot auf Nutzung, sind unterschiedliche Motions, und die Queue ist nur nützlich, wenn jede rote Zeile auf eine zeigt.
Stellen Sie die Daten bereit. Exportieren Sie pro Account: eine Nutzungs-CSV (account_id, Event-Anzahl der letzten 28 Tage, Baseline-Event-Anzahl, eindeutige aktive Nutzer), eine Engagement-CSV (Tage seit dem letzten bedeutsamen Kontakt, Meeting-Anzahl der letzten 90 Tage), eine Support-CSV (Anzahl offener P1, Ticket-Anzahl vs. Vorperiode, mediane Lösungszeit) und einen Sentiment-Input (letzter NPS/CSAT/CES-Score oder aktuelle Survey-Verbatims, die die Skill klassifiziert). Optional stellen Sie eine gelabelte Churn-CSV für den Backtest bereit.
Lassen Sie laufen. Rufen Sie die Skill mit dem Config-Path und dem Datenverzeichnis auf. Sie schreibt eine Queue-Datei (Accounts schlechtester-zuerst priorisiert, mit Score, Tier und dem Ein-Satz-Driver) plus einen Kalibrierungsbericht pro Segment. Lesen Sie die Erklärungen, bearbeiten Sie 1-scoring-config.md, lassen Sie erneut laufen. Wiederholen Sie, bis die roten Accounts bei den Accounts, die Sie kennen, mit Ihrem Bauchgefühl übereinstimmen.

Was die Skill tatsächlich tut

Die Skill läuft in vier Stufen. Stufe eins — normalisieren. Jeder der vier Input-Streams wird gegen die Config auf einen Sub-Score von 0 bis 100 abgebildet. Die Nutzung ist das Verhältnis der aktuellen 28-Tage-Events zum eigenen Baseline des Accounts, linear von 0 (Verhältnis ≤ 0.5) bis 100 (Verhältnis ≥ 1.0), mit einer harten Deckelung bei 40, wenn die eindeutigen aktiven Nutzer unter drei fallen — die Abhängigkeit von einem einzelnen Nutzer ist ein Churn-Risiko, das das rohe Event-Volumen nicht sehen kann. Das Engagement wendet einen Zerfall mit 21-Tage-Halbwertszeit auf die Aktualität des letzten Kontakts an. Der Support invertiert die Ticket-Last (mehr offene P1, niedrigerer Score), normalisiert gegen den eigenen Vorperioden-Baseline des Accounts, nicht gegen einen globalen Durchschnitt, weil ein 10-Ticket-Account und ein 200-Ticket-Account unterschiedliche Normalwerte haben. Das Sentiment bildet den letzten Survey-Score ab oder — wenn Sie Verbatims statt einer Zahl übergeben — klassifiziert Claude den Text nach einer strikten Rubrik, die bei einer Konfidenz unter 0.4 ein neutrales 50 zurückgibt, anstatt zu raten.

Stufe zwei — Composite. Die vier Sub-Scores werden mit den Gewichten pro Segment aus der Config kombiniert. Das Tier wird durch die Config-Grenzen zugewiesen (grün ≥ 75, gelb ≥ 50, rot unter 50 per Default). Sub-Scores vor dem Gewichten zu berechnen, statt rohe Inputs zu vermischen, ist das, was es dem Erklärungssatz erlaubt, einen einzelnen Driver zu benennen: Die Skill wählt den Sub-Score, der am weitesten unter dem Composite des Accounts liegt, und meldet ihn mit seiner realen Zahl.

Stufe drei — erklären und in die Queue stellen. Accounts werden schlechtester-zuerst in die Remediation-Queue sortiert. Jede Zeile erhält einen Ein-Satz-Driver („Nutzung 22% unter Baseline trotz vier Meetings dieses Quartal”), generiert ausschließlich aus den Sub-Score-Inputs — der Prompt verbietet Spekulation über die ihm gegebenen Zahlen hinaus, sodass der Satz keine Ursache erfinden kann, die die Daten nicht stützen. Ein deterministischer numerischer Fallback läuft, wenn Claude leer zurückgibt, sodass die Queue nie blockiert.

Stufe vier — Backtest (optional). Wenn Sie gelabelte Churn-Historie bereitgestellt haben, scort die Skill die historischen Accounts zum Datum von 90 Tagen vor ihrem Churn-Datum und meldet, wie viele rot gelandet sind — die Lead-Time- und Recall-Zahlen, die Ihnen sagen, ob die Gewichte real oder Wunschdenken sind.

Kostenrealität

Der teure Call ist die Sentiment-Klassifikation, und nur, wenn Sie Verbatims statt eines numerischen NPS/CSAT übergeben. Survey-Text zu klassifizieren läuft mit ungefähr 600 Input- und 80 Output-Tokens pro Account auf Claude Sonnet; der Driver-Satz pro Account fügt etwa 300 Input und 40 Output hinzu. Für einen Batch von 200 Accounts mit Verbatim-Sentiment sind das unter $1.50 pro vollständigem Lauf zu aktuellen Sonnet-Preisen. Übergeben Sie stattdessen numerische Sentiment-Scores, und die einzigen Claude-Calls sind die Driver-Sätze — unter 40 Cent für denselben Batch. Ein Lauf über 200 Accounts ist in zwei bis vier Minuten abgeschlossen; die Skill verarbeitet Accounts in Batches von 25, um innerhalb der Rate-Limits zu bleiben.

Die echten Kosten sind Ihre Zeit für die Iteration, nicht die Tokens. Veranschlagen Sie zwei bis drei Runden Config-Bearbeitung — nennen wir es zwei bis drei Stunden insgesamt über eine Woche — bevor die Queue mit der Lesart des Teams übereinstimmt. Das ist billiger als die Alternative: Ein CSM, der ein Book von 200 Accounts manuell triagiert, braucht einen Tag pro Durchlauf und kann es nicht wöchentlich tun.

Wie Erfolg aussieht

Verfolgen Sie drei Zahlen. Erstens, Queue-Übereinstimmung — befragen Sie für die obersten 20 roten Accounts die zuständigen CSMs, ob das Ranking ihrer Lesart entspricht. Zielen Sie auf über 70% Übereinstimmung bis zur dritten Config-Iteration; unter 50% bedeutet, dass die Gewichte falsch sind, nicht das Modell. Zweitens, Churn-Lead-Time aus dem Backtest und der Live-Nutzung — mediane Tage, die der Score rot stand, bevor die Churn-Benachrichtigung kam. Zielen Sie auf einen Median über 30 Tage. Drittens, Genauigkeit des Driver-Satzes — ziehen Sie 20 Sätze als Stichprobe und bewerten Sie sie als umsetzbar, korrekt-aber-vage oder falsch. Zielen Sie auf über 80% umsetzbar; eine hohe „falsch”-Rate zeigt auf schmutzige Input-Daten, nicht auf den Prompt.

Gegenüber den Alternativen

Gegenüber dem nativen Scorecard Ihres CSP (Vitally, Planhat, Gainsight, Catalyst, ChurnZero). Jeder CSP liefert einen Health Score, und Sie sollten Ihren dort in Produktion betreiben. Was sie nicht gut machen, ist die Entwurfsphase: Native Scorecards lassen Sie die Gewichte blind einstellen, ohne Backtest-Schleife und ohne Erklärung pro Account, warum sich eine Zahl bewegt hat. Die Skill ist die Werkbank, an der Sie die Config lösen; der CSP ist der Ort, an dem Sie sie deployen. Sie sind sequenziell, nicht konkurrierend — verwenden Sie die Skill zum Entwerfen, dann übertragen Sie die Gewichte in das Scorecard Ihres CSP.

Gegenüber einem Tabellenkalkulations-Modell. Eine Tabellenkalkulation ist der Ort, an dem die meisten Teams beginnen, und sie taugt für die Rechnung. Wo sie bricht, ist die Erklärung: Eine Tabellenkalkulation gibt Ihnen eine Composite-Zelle, keinen Satz, auf den ein CSM handeln kann, und Backtesting in einer Tabellenkalkulation bedeutet manuelle VLOOKUPs gegen Churn-Daten, die niemand pflegt. Die Skill automatisiert die Erklärung und den Backtest. Wenn Ihr Modell stabil ist und das Team der Tabellenkalkulation bereits vertraut, wechseln Sie nicht — die Skill verdient sich ihren Platz während Entwurf und Iteration, nicht danach.

Gegenüber dem Kauf eines dedizierten Predictive-Churn-Produkts. Predictive-Produkte versprechen ein Modell, das Sie nicht entwerfen müssen. Der Trade-off ist, dass Sie eine Blackbox in einem QBR nicht verteidigen können, und ein Modell, das Sie nicht erklären können, ist ein Modell, um das CSMs herumarbeiten. Bauen Sie zuerst die explizite Version; wenn sie ein Plateau erreicht und Sie das Volumen haben, ML zu rechtfertigen, kaufen Sie die Predictive-Schicht auf eine Config, die Sie bereits verstehen.

Worauf zu achten ist

Gewichte, die sich zu etwas anderem als 1.0 summieren. Eine Config, bei der die vier Gewichte 0.9 oder 1.1 ergeben, reskaliert stillschweigend jeden Score und macht den Vergleich zwischen Segmenten bedeutungslos. Guard: Die Skill validiert die Gewichtssumme pro Segment beim Laden und verweigert das Scoring, indem sie das beanstandete Segment und seine Summe ausgibt, statt eine plausibel aussehende falsche Queue zu produzieren.
Sentiment-Halluzination bei dünnen Verbatims. Claude wird eine selbstbewusste Sentiment-Zahl bei einem Zwei-Wort-Survey-Kommentar produzieren, wenn er nicht eingeschränkt wird. Guard: Der Klassifikations-Prompt verlangt Konfidenz 0 bei Inputs unter 15 Wörtern oder Einzelsatz-Fragmenten, und die Skill reduziert alles unter 0.4 Konfidenz auf ein neutrales 50, sodass dünnes Sentiment sein Gewicht als „unbekannt” beiträgt statt als fabriziertes Signal.
Der Driver-Satz erfindet Kausalität. Ein gewichtetes Composite hat einen größten Bewegen, keine Ursache. Guard: Der Erklärungs-Prompt erhält nur die vier Sub-Score-Werte, und es ist ihm verboten, irgendetwas außerhalb davon zu referenzieren; er muss die reale Zahl zitieren. Ein CSM, der „Nutzung um 22% gesunken” liest, kann es verifizieren; ein Satz, der „der Champion ist gegangen” geraten hätte, könnte nicht verifiziert werden und wird nie produziert.
Ein Modell ohne Backtest ausliefern. Den Backtest-Input zu überspringen produziert ein Modell, das autoritativ aussieht und zufällig sein kann. Guard: Der Queue-Header trägt ein UNBACKTESTED-Banner, bis eine gelabelte Churn-CSV bereitgestellt wird und die Backtest-Stufe läuft, sodass jeder, mit dem die Queue geteilt wird, sieht, dass das Modell nicht validiert ist.
Baseline gegen driftende Events berechnet. Wenn der Nutzungs-Baseline bei jedem Lauf gegen Event-Definitionen neu berechnet wird, die sich stromaufwärts geändert haben, sieht jeder Account so aus, als wäre er gefallen. Guard: Die Config nimmt den Baseline als eingefrorene Input-Spalte, die Sie einmal berechnen und auditieren, nicht als Wert, den die Skill neu berechnet, sodass eine Tagging-Änderung als Datenqualitäts-Flag erscheint statt als flottenweites Rot.

Stack

Claude — Sentiment-Klassifikation (Sonnet, mit einer strikten Konfidenz-Boden-Rubrik) und der Ein-Satz-Driver pro Account; die Scoring-Rechnung selbst ist deterministisch
Vitally — Datenquelle für Nutzung, Engagement und Support; das Produktions-Zuhause für den fertigen Score
Planhat — alternative CSP-Quelle und Produktionsziel; die Skill ist CSP-agnostisch und liest exportierte CSVs von beiden
Eine Scoring-Config-Datei — die vier Gewichte pro Segment, das Baseline-Fenster und die Tier-Grenzen, über die Iterationen hinweg bearbeitet; diese Datei ist das eigentliche Liefergut

Diese Seite auf GitHub bearbeiten