Une Claude Skill qui transforme quatre streams d’entrée bruts — usage produit, engagement relationnel, charge de support et sentiment des enquêtes — en un health score pondéré unique par compte, un tier vert/jaune/rouge et une file de remédiation priorisée que l’équipe CSM traite de haut en bas. L’enjeu n’est pas le chiffre ; la plupart des CSP vous donnent déjà un chiffre. L’enjeu est que la Skill rend explicite chaque poids, seuil et coupure de tier dans un fichier de config que vous éditez, puis explique le score de chaque compte en une phrase qui nomme le driver négatif le plus important avec sa valeur réelle. Un CSM qui ouvre la file voit « Acme — 48, rouge — charge de support : 11 tickets P1 en 30 jours contre un baseline de 2 » plutôt qu’une pastille colorée à laquelle personne ne fait confiance. Le bundle d’artifact comprend SKILL.md plus trois fichiers de référence : un schéma de config de scoring à remplir, un template de playbook tier-et-action et un output d’exemple travaillé.

Le bundle d’artifact se trouve dans apps/web/public/artifacts/cs-health-score-builder-skill/. Lisez SKILL.md et adaptez les trois fichiers de references/ avant la première exécution.

Quand l’utiliser

Vous êtes un CSM ou un lead CS Ops qui a besoin d’un modèle de health score défendable en QBR, et votre score actuel — qu’il s’agisse du défaut de Vitally, de Planhat ou d’un tableur — est une boîte noire à laquelle l’équipe a cessé de faire confiance. La Skill est faite pour la phase de conception-et-itération : vous lui fournissez les quatre streams d’entrée pour un lot de comptes, elle calcule les scores contre une config explicite et vous rend une file plus une explication par compte. Vous lisez les explications, décidez si les poids correspondent à la réalité, éditez la config et relancez. Après trois ou quatre itérations contre des comptes que vous comprenez déjà, vous avez un modèle dont chaque coupure est justifiable.

Elle fonctionne le mieux quand vous avez au moins 50 comptes à scorer (les books plus petits, un CSM les lit à la main), un signal d’usage propre que vous pouvez extraire en CSV ou via l’API de votre CSP et, idéalement, 12 mois d’historique de churn étiqueté contre lequel faire le backtest des poids. La file de remédiation est la plus utile quand l’équipe s’engage à la traiter de haut en bas — le score ne gagne en confiance que lorsque les comptes rouges en tête sont ceux qui font réellement churn.

Quand NE PAS l’utiliser

N’utilisez pas la Skill comme un moteur de scoring nocturne en direct câblé sur Vitally ou Planhat. C’est un outil de conception de modèle, pas une infrastructure de production. Une fois que vous avez une config de confiance, portez les poids et les seuils dans le scorecard natif de votre CSP ou dans un flow n8n qui tourne sur un schedule — le travail de la Skill est d’établir la bonne config, pas de tourner indéfiniment.

Ne l’utilisez pas si votre télémétrie d’usage n’est pas fiable. Un score bâti sur des événements étiquetés de manière incohérente fait remonter des baisses qui reflètent un changement d’étiquetage, pas un changement de comportement, et la phrase d’explication nommera avec assurance un driver erroné. Corrigez d’abord les données.

Ne l’utilisez pas si vous n’avez ni définition de churn ni historique étiqueté. Sans backtest, vous devinez les poids, et un modèle deviné est pire que pas de modèle car il porte l’autorité d’un chiffre. La Skill renvoie un avertissement UNBACKTESTED dans l’en-tête de la file quand vous sautez l’entrée de backtest, mais elle ne peut pas vous empêcher d’expédier la devinette.

Ne l’utilisez pas pour moins de ~50 comptes, pour le forecasting de revenu ou pour le scoring d’utilisateurs individuels (elle score des comptes, pas des sièges).

Setup

Environ 45 à 90 minutes la première fois, presque entièrement consacrées à remplir la config de scoring pour qu’elle corresponde à vos données, pas à câbler quoi que ce soit.

Installez la Skill. Déposez le bundle de apps/web/public/artifacts/cs-health-score-builder-skill/ dans ~/.claude/skills/cs-health-score/. Aucune credential n’est requise — la Skill lit les fichiers que vous fournissez, elle n’appelle pas Vitally ni Planhat directement. Vous exportez les données ; la Skill les score.
Remplissez la config de scoring. Ouvrez references/1-scoring-config.md et définissez, par segment de compte, les quatre poids d’entrée (ils doivent sommer à 1.0), la fenêtre de baseline pour l’usage et les coupures vert/jaune/rouge. Le template est livré avec des valeurs de départ — Enterprise pondère l’engagement à 0.35 et l’usage à 0.30 car la santé de la relation pilote le renewal ; PLG pondère l’usage à 0.55 car le produit est le deal. Ce sont des points de départ à éditer contre votre propre backtest, pas des recommandations.
Adaptez le playbook d’action. Ouvrez references/2-tier-playbook.md et remplacez les plays placeholder par les motions réelles de votre équipe — ce qu’un CSM fait quand un compte atterrit rouge sur la charge de support contre rouge sur l’usage sont des motions différentes, et la file n’est utile que si chaque ligne rouge en pointe une.
Fournissez les données. Exportez par compte : un CSV d’usage (account_id, nombre d’événements des 28 derniers jours, nombre d’événements baseline, utilisateurs actifs distincts), un CSV d’engagement (jours depuis le dernier contact significatif, nombre de réunions des 90 derniers jours), un CSV de support (nombre de P1 ouverts, nombre de tickets vs période précédente, temps médian de résolution) et une entrée de sentiment (dernier score NPS/CSAT/CES, ou verbatims d’enquête récents que la Skill classera). Optionnellement, fournissez un CSV de churn étiqueté pour le backtest.
Lancez. Invoquez la Skill avec le path de la config et le répertoire de données. Elle écrit un fichier de file (comptes priorisés pire-d’abord, avec score, tier et le driver en une phrase) plus un rapport de calibration par segment. Lisez les explications, éditez 1-scoring-config.md, relancez. Répétez jusqu’à ce que les comptes rouges correspondent à votre intuition sur les comptes que vous connaissez.

Ce que la Skill fait réellement

La Skill tourne en quatre étapes. Étape un — normaliser. Chacun des quatre streams d’entrée est mappé sur un sous-score de 0 à 100 contre la config. L’usage est le ratio des événements actuels sur 28 jours par rapport au propre baseline du compte, linéaire de 0 (ratio ≤ 0.5) à 100 (ratio ≥ 1.0), avec un plafond dur à 40 si les utilisateurs actifs distincts tombent sous trois — la dépendance à un seul utilisateur est un risque de churn que le volume brut d’événements ne peut pas voir. L’engagement applique une décroissance à demi-vie de 21 jours à la récence du dernier contact. Le support inverse la charge de tickets (plus de P1 ouverts, score plus bas) normalisée contre le propre baseline de la période précédente du compte, pas une moyenne globale, car un compte à 10 tickets et un compte à 200 ont des normales différentes. Le sentiment mappe le dernier score d’enquête ou — quand vous passez des verbatims au lieu d’un chiffre — Claude classe le texte selon une rubrique stricte qui renvoie un neutre 50 à une confiance sous 0.4 plutôt que de deviner.

Étape deux — composite. Les quatre sous-scores se combinent en utilisant les poids par segment de la config. Le tier est attribué par les coupures de la config (vert ≥ 75, jaune ≥ 50, rouge sous 50 par défaut). Calculer les sous-scores avant de pondérer, plutôt que de mélanger les entrées brutes, est ce qui permet à la phrase d’explication de nommer un seul driver : la Skill choisit le sous-score le plus éloigné en dessous du composite du compte et le rapporte avec son chiffre réel.

Étape trois — expliquer et mettre en file. Les comptes sont triés pire-d’abord dans la file de remédiation. Chaque ligne reçoit un driver en une phrase (« usage 22% sous le baseline malgré quatre réunions ce trimestre ») généré uniquement à partir des entrées de sous-score — le prompt interdit la spéculation au-delà des chiffres qu’il a reçus, donc la phrase ne peut pas inventer une cause que les données ne soutiennent pas. Un fallback numérique déterministe tourne si Claude renvoie vide, donc la file ne se bloque jamais.

Étape quatre — backtest (optionnel). Si vous avez fourni un historique de churn étiqueté, la Skill score les comptes historiques à la date de 90 jours avant leur date de churn et rapporte combien ont atterri rouge — les chiffres de lead-time et de recall qui vous disent si les poids sont réels ou illusoires.

Réalité des coûts

L’appel coûteux est la classification de sentiment, et uniquement quand vous passez des verbatims au lieu d’un NPS/CSAT numérique. Classer le texte d’enquête tourne à environ 600 tokens d’entrée et 80 de sortie par compte sur Claude Sonnet ; la phrase de driver par compte ajoute environ 300 d’entrée et 40 de sortie. Pour un lot de 200 comptes avec sentiment verbatim, c’est moins de $1.50 par exécution complète aux prix actuels de Sonnet. Passez plutôt des scores de sentiment numériques et les seuls appels à Claude sont les phrases de driver — moins de 40 centimes pour le même lot. Une exécution de plus de 200 comptes se termine en deux à quatre minutes ; la Skill traite les comptes par lots de 25 pour rester dans les limites de rate.

Le coût réel, c’est votre temps sur l’itération, pas les tokens. Prévoyez deux à trois tours d’édition de config — disons deux à trois heures au total sur une semaine — avant que la file corresponde à la lecture de l’équipe. C’est moins cher que l’alternative : un CSM qui trie manuellement un book de 200 comptes prend une journée par passe et ne peut pas le faire chaque semaine.

À quoi ressemble le succès

Suivez trois chiffres. Premièrement, l’accord sur la file — pour les 20 comptes rouges du haut, sondez les CSM propriétaires sur le fait que le classement corresponde à leur lecture. Visez plus de 70% d’accord à la troisième itération de config ; moins de 50% signifie que les poids sont faux, pas le modèle. Deuxièmement, le lead time de churn du backtest et de l’usage en direct — jours médians où le score est resté rouge avant l’avis de churn. Visez une médiane de plus de 30 jours. Troisièmement, la précision de la phrase de driver — échantillonnez 20 phrases et notez-les actionnables, exactes-mais-vagues ou fausses. Visez plus de 80% actionnables ; un taux élevé de « fausses » pointe vers des données d’entrée sales, pas vers le prompt.

Face aux alternatives

Face au scorecard natif de votre CSP (Vitally, Planhat, Gainsight, Catalyst, ChurnZero). Chaque CSP livre un health score et vous devriez faire tourner le vôtre là-bas en production. Ce qu’ils ne font pas bien, c’est la phase de conception : les scorecards natifs vous font régler les poids à l’aveugle, sans boucle de backtest ni explication par compte de la raison pour laquelle un chiffre a bougé. La Skill est l’établi où vous résolvez la config ; le CSP est où vous la déployez. Ils sont séquentiels, pas concurrents — utilisez la Skill pour concevoir, puis transcrivez les poids dans le scorecard de votre CSP.

Face à un modèle sur tableur. Un tableur est là où la plupart des équipes commencent et il convient pour le calcul. Là où il casse, c’est l’explication : un tableur vous donne une cellule composite, pas une phrase sur laquelle un CSM peut agir, et faire le backtest dans un tableur signifie des VLOOKUP manuels contre des dates de churn que personne ne maintient. La Skill automatise l’explication et le backtest. Si votre modèle est stable et que l’équipe fait déjà confiance au tableur, ne changez pas — la Skill gagne sa place pendant la conception et l’itération, pas après.

Face à l’achat d’un produit dédié de churn prédictif. Les produits prédictifs promettent un modèle que vous n’avez pas à concevoir. Le compromis, c’est que vous ne pouvez pas défendre une boîte noire en QBR, et qu’un modèle que vous ne pouvez pas expliquer est un modèle que les CSM contournent. Construisez d’abord la version explicite ; si elle plafonne et que vous avez le volume pour justifier le ML, achetez la couche prédictive par-dessus une config que vous comprenez déjà.

Points de vigilance

Des poids qui somment à autre chose que 1.0. Une config où les quatre poids totalisent 0.9 ou 1.1 redimensionne silencieusement chaque score et rend la comparaison entre segments dénuée de sens. Garde : la Skill valide la somme des poids par segment au chargement et refuse de scorer, en imprimant le segment fautif et son total, plutôt que de produire une file fausse d’apparence plausible.
Hallucination de sentiment sur des verbatims minces. Claude produira un chiffre de sentiment assuré sur un commentaire d’enquête de deux mots s’il n’est pas contraint. Garde : le prompt de classification exige une confiance 0 sur les entrées de moins de 15 mots ou les fragments d’une seule proposition, et la Skill réduit tout ce qui est sous 0.4 de confiance à un neutre 50, donc le sentiment mince contribue son poids comme « inconnu » plutôt que comme signal fabriqué.
La phrase de driver invente une causalité. Un composite pondéré a un plus grand mouvement, pas une cause. Garde : le prompt d’explication ne reçoit que les quatre valeurs de sous-score et il lui est interdit de référencer quoi que ce soit en dehors ; il doit citer le chiffre réel. Un CSM qui lit « usage en baisse de 22% » peut le vérifier ; une phrase qui aurait deviné « le champion est parti » ne pourrait pas être vérifiée et n’est jamais produite.
Expédier un modèle sans backtest. Sauter l’entrée de backtest produit un modèle qui a l’air faisant autorité et qui peut être aléatoire. Garde : l’en-tête de la file porte une bannière UNBACKTESTED jusqu’à ce qu’un CSV de churn étiqueté soit fourni et que l’étape de backtest tourne, donc quiconque reçoit la file voit que le modèle n’est pas validé.
Baseline calculé contre des événements qui dérivent. Si le baseline d’usage est recalculé à chaque exécution contre des définitions d’événements qui ont changé en amont, chaque compte a l’air d’avoir baissé. Garde : la config prend le baseline comme une colonne d’entrée figée que vous calculez et auditez une fois, pas une valeur que la Skill recalcule, donc un changement d’étiquetage apparaît comme un flag de qualité de données plutôt qu’un rouge sur toute la flotte.

Stack

Claude — classification de sentiment (Sonnet, avec une rubrique stricte de plancher de confiance) et la phrase de driver par compte ; le calcul du scoring lui-même est déterministe
Vitally — source de données d’usage, d’engagement et de support ; le foyer de production du score fini
Planhat — source CSP alternative et cible de production ; la Skill est agnostique au CSP et lit les CSV exportés de l’un ou l’autre
Un fichier de config de scoring — les quatre poids par segment, la fenêtre de baseline et les coupures de tier, édités au fil des itérations ; ce fichier est le véritable livrable

Modifier cette page sur GitHub