La plupart des post-mortems de churn sont rédigés une fois, lus par personne, et se résument à « le champion est parti, lacune produit, tarification » parce que c’est ce à quoi les notes CSM en texte libre réduisent toujours quand on les grep en fin de trimestre. Ce workflow livre un Claude Skill qui prend un compte churné et produit une analyse structurée des causes profondes : une chronologie de 180 jours, une analyse en deux passes preuve-puis-classification, une catégorisation par rapport à une taxonomie fixe, et une recommandation de prévention choisie depuis une bibliothèque fixe. Le résultat est suffisamment cohérent entre les CSM pour que RevOps puisse l’agréger trimestriellement sans rien recoder.
Le bundle d’artefact se trouve dans apps/web/public/artifacts/churn-analysis-skill/. Il contient SKILL.md (le Claude Skill lui-même, en soft-wrap, avec des sections explicites quand-invoquer et points-de-vigilance), references/1-churn-taxonomy.md (les 5-10 catégories que votre équipe est autorisée à assigner), references/2-prevention-action-library.md (le menu d’actions de prévention que le Skill est autorisé à recommander), et references/3-sample-output.md (la forme markdown littérale pour que les reviewers sachent ce qu’ils recevront).
Quand utiliser
Lancez ce Skill une fois par churn confirmé, après que l’événement de fermeture-perdue ou de non-renouvellement est enregistré dans le CRM et que le CSM a eu au moins 24 heures pour ajouter ses notes finales. La sortie est un document post-mortem que le CSM révise, que RevOps stocke dans un dossier Notion ou Drive partagé, et que la direction agrège en fin de trimestre pour repérer les patterns entre catégories.
La bonne population est les comptes mid-market et enterprise où la valeur du contrat est suffisamment importante pour justifier un cycle de révision de 30 minutes et où les données de chronologie sont assez riches à analyser (événements CRM, scores de santé, cas support, idéalement des appels Gong). En dessous de ~25 000 USD ARR, le ratio coût d’analyse / apprentissages passe sous le seuil.
Quand NE PAS utiliser
Ignorez ce Skill dans quatre cas, chacun ayant une bonne réponse différente :
- Scoring de risque préventif sur des comptes sains. Utilisez un modèle de score de santé ou un Skill de scoring de risque séparé. Lancer ce Skill en forme de post-mortem en avant — sur un compte vivant qui n’a pas churné — ancre le CSM sur un récit de churn et biaise sa prochaine conversation.
- Prédiction de churn en temps réel pendant un cycle de renouvellement. Même problème. L’analyse chronologique en deux passes suppose ici que le résultat est fixé ; l’utiliser en avant génère des signaux de fausse confiance.
- Analyse win/loss sur de nouveaux logos fermés-perdus. Ceux-ci nécessitent un cadrage différent — récit du deal, déplacement concurrentiel, adéquation ICP — et une taxonomie différente. Utilisez un Skill win-loss séparé plutôt que de forcer des catégories de churn sur un deal qui n’a jamais commencé.
- Explications à événement unique que le CSM connaît déjà. Si vous savez déjà « le champion est parti et il n’y avait pas de remplaçant », éditez le champ CRM directement. Ce Skill est pour les cas où le CSM ne peut pas encore clairement attribuer le churn, ou où l’équipe a besoin d’une forme structurée pour l’agrégation quelles que soient les circonstances.
Configuration
- Définissez la taxonomie. Éditez
references/1-churn-taxonomy.mdavec les 5-10 catégories de causes profondes de votre équipe. Le modèle est livré avecproduct-gap,champion-departure,pricing,consolidation,service-failure,adoption-failure,restructureetcompetitive-displacement. Resserrez l’exigence de preuve sur chaque slug pour correspondre à la rigueur que votre équipe souhaite — ces exigences sont ce que la passe de classification applique. Gardez la liste à 10 ou moins ; tout l’enjeu est l’agrégation. - Remplissez la bibliothèque de prévention. Éditez
references/2-prevention-action-library.md. Le Skill est contraint de choisir une action depuis ce fichier par analyse — il ne peut pas en inventer une nouvelle. Le modèle couvre les huit courantes (détection de changement de sponsor, alertes de santé, escalade sur les patterns sev-1, etc.). Ajoutez les plays de votre équipe. - Installez le Skill. Déposez le bundle dans
~/.claude/skills/churn-analysis/. DéfinissezHUBSPOT_TOKENetGAINSIGHT_TOKENcomme variables d’environnement. Si vous utilisez Gong, définissezGONG_API_KEYpour que la passe de preuves puisse extraire les transcriptions d’appels ; sinon le Skill s’exécute sans preuves Gong et note cette lacune dans la sortie. - Lancez sur le churn. Depuis Claude Code :
analyze_churn(account_id="HUB-5523-ACME", churn_date="2026-04-15", taxonomy="churn-taxonomy"). Le Skill extrait la chronologie de 180 jours, exécute les deux passes, et émet l’analyse structurée vers stdout (ou vers./out/churn-{account_id}-{YYYY-MM-DD}.mdsi vous définissezCHURN_OUT_DIR). - Routez vers la révision CSM. La sortie se termine par une checklist de quatre éléments que le CSM complète : confirmer que l’analyse est lue, corriger les erreurs factuelles, confirmer ou infirmer la classification (le jugement CSM l’emporte), et accepter/modifier/rejeter la recommandation de prévention avec une raison.
Ce que le Skill fait réellement
Quatre étapes, dans cet ordre, avec les choix d’ingénierie que le bundle engage.
Étape 1 — construire la chronologie de 180 jours. Extraire les déltas de score de santé, les changements de contact (avec les dates de départ LinkedIn quand le CRM est en retard), les cas support, les résumés d’appels Gong, les métriques d’usage produit et les résultats QBR. Ancrer à churn_date - 180 jours. Si moins de 3 événements de chronologie existent dans les 30 jours précédant immédiatement churn_date, le Skill renvoie le statut littéral insufficient data — fewer than 3 timeline events in the 30-day pre-churn window; manual CSM postmortem required et s’arrête. Les chronologies courtes et clairsemées invitent des récits rétrospectifs qui semblent confiants mais ne résistent pas à l’examen.
Étape 2 — passe de preuves. Une première passe Claude qui UNIQUEMENT extrait des preuves : citations verbatim, extraits de tickets, déltas de métriques avec leur source (CRM, Gainsight, Zendesk, Gong) et date. Pas de classification, pas de recommandation de prévention. La sortie est une liste plate de lignes de preuves conservée comme artefact intermédiaire.
Étape 3 — passe de classification. Une deuxième passe Claude qui reçoit la liste de preuves et la taxonomie et rien d’autre. Le design en deux passes est le choix d’ingénierie explicite : un modèle en une passe confond « ce qui s’est passé » avec « à quelle catégorie ça appartient », ce qui biaise la sélection de preuves vers la catégorie que le modèle suspecte déjà. Forcer la passe de classification à travailler depuis une liste de preuves figée est le garde contre ça. La passe assigne une catégorie primaire et jusqu’à deux catégories contributives — strictement depuis la taxonomie, pas de nouveaux labels — et cite les lignes de preuves qui supportent chaque assignment. Si aucune catégorie n’atteint 3 lignes de preuves, la primaire devient insufficient-evidence.
Étape 4 — recommandation de prévention. Lire la bibliothèque d’actions de prévention. Choisir UNE action qui, si elle avait été en place 60 jours avant la date de churn, aurait fait remonter la cause profonde primaire comme signal observable. Le Skill ne peut pas inventer une nouvelle action — si aucune entrée de bibliothèque ne correspond, il renvoie no library match — prevention action requires human design et un humain étend délibérément la bibliothèque.
La forme en deux passes et la contrainte de bibliothèque sont les parties qui comptent. La plupart des analyses de churn ad hoc échouent non pas parce que le modèle ne peut pas raisonner sur des preuves — elles échouent parce que le modèle est autorisé à raisonner sur les preuves, la catégorie et la recommandation en une seule respiration, ce qui laisse le récit le plus plausible gagner indépendamment de sa minceur.
Réalité des coûts
Une seule analyse requiert ~12 000 tokens d’entrée (chronologie de 180 jours plus fichiers de référence plus notes CSM) et ~3 000 tokens de sortie. Sur Claude Sonnet, ça représente environ 0,05 USD par analyse. Sur Opus, c’est ~0,30 USD. Une équipe gérant 40 churns par trimestre paie 2 à 12 USD par trimestre en coûts de modèle.
Le calcul du temps est le chiffre plus intéressant. Un post-mortem rédigé par un CSM prend 45 à 90 minutes pour un compte significatif et est entièrement sauté sur les comptes plus petits. Le Skill produit un brouillon révisable en ~3 minutes ; la révision CSM prend ~15 minutes. Net : ~30 minutes économisées par analyse, plus la couverture s’étend aux comptes qui n’obtenaient auparavant aucun post-mortem. Pour une équipe de 8 CSM gérant 40 churns par trimestre, c’est environ 20 heures de temps CSM libérées par trimestre, plus ~2x la couverture des post-mortems.
Le coût qui n’apparaît pas sur la facture est le travail de curation de la taxonomie et de la bibliothèque : comptez 4 à 6 heures au départ pour remplir les deux fichiers de référence avec des entrées spécifiques à l’équipe, puis ~1 heure par trimestre pour réviser les cas insufficient-evidence et décider d’étendre l’un ou l’autre fichier. Sautez la curation et le Skill produit une sortie générique qui s’agrège mal.
Métrique de succès
La métrique agrégée à surveiller trimestriellement : pourcentage de churns avec une cause profonde catégorisée défendable que le CSM n’a pas infirmé à la révision. Cible 70-80 % en régime stable. Au-dessus de 90 %, la taxonomie est devenue trop permissive (trop de catégories, exigences de preuves trop lâches) — Claude trouve un label pour tout parce que les buckets sont larges. En dessous de 60 %, les données de chronologie sont trop minces ou la taxonomie ne correspond pas aux formes de churn réelles que l’équipe observe.
La contre-métrique de diagnostic : pourcentage de retours insufficient-evidence et no library match. Ce ne sont pas des échecs — c’est le Skill qui est honnête. Une tendance à la hausse signifie des lacunes d’instrumentation (plus de comptes avec des chronologies minces) ou des lacunes de bibliothèque (plus de formes de churn pour lesquelles l’équipe n’a pas encore codifié de play de prévention). Les deux sont des signaux utiles sur lesquels agir délibérément.
Par rapport aux alternatives
- vs. Tableaux de bord Churn de Gainsight. Gainsight est excellent sur la couche descriptive — scores de santé, événements de chronologie, ce-qui-s’est-passé-quand. Il est faible sur la couche analytique : extraire des preuves à partir d’appels Gong et de notes CSM non structurés, puis classifier par rapport à une taxonomie d’équipe. Le Skill ne remplace pas Gainsight ; il consomme les données Gainsight et ajoute la couche de classification structurée que Gainsight ne produit pas nativement.
- vs. post-mortems manuels rédigés par les CSM. La valeur par défaut actuelle pour la plupart des équipes. Meilleure qualité par post-mortem quand le CSM est investi, mais incohérent entre les CSM, fréquemment sauté sur les comptes plus petits, et inutile pour l’agrégation trimestrielle parce que la forme en texte libre de chaque CSM est légèrement différente. Le Skill produit un brouillon suffisamment cohérent pour agréger ; la révision CSM maintient le niveau de qualité.
- vs. Catalyst, ChurnZero et autres plateformes CS avec des flux de post-mortem intégrés. Ceux-ci livrent des modèles structurés que le CSM remplit. Ils résolvent le problème de cohérence mais pas le problème d’extraction de preuves — le CSM doit encore lire 180 jours d’appels et de notes lui-même. Le Skill fait la lecture ; le CSM fait le jugement.
Le Skill est le mieux adapté aux équipes qui ont déjà Gainsight ou une instrumentation équivalente de chronologie, veulent la propriété d’agrégation structurée, et ont la discipline de curer les fichiers de taxonomie et de bibliothèque. Les équipes sans instrumentation de chronologie devraient d’abord régler ça ; le Skill est en aval d’avoir les données.
Points de vigilance
- Biais rétrospectif. Il est trivial de construire un récit propre après coup, surtout avec 180 jours de chronologie. Garde : la passe de preuves (étape 2) est structurellement séparée de la passe de classification (étape 3), et la passe de classification refuse d’assigner une catégorie sans au moins 3 lignes de preuves qui citent explicitement des dates et des sources. Le court-circuit
insufficient dataen fin d’étape 1 (moins de 3 événements de chronologie dans la fenêtre de 30 jours pré-churn) est le deuxième garde. Le jugement CSM l’emporte à la révision et l’infirmation est enregistrée. - Créep de taxonomie. La tentation après chaque analyse est d’ajouter une nouvelle catégorie qui capture la saveur unique de ce churn. Garde : la passe de classification est contrainte au fichier de taxonomie existant et refuse les nouveaux labels — le Skill renvoie
insufficient-evidenceplutôt que de créer une nouvelle catégorie. Les nouvelles catégories nécessitent une édition délibérée dereferences/1-churn-taxonomy.mdhors du Skill, avec trois churns historiques qui auraient correspondu, avant d’être ajoutées. - Sur-attribution du départ du champion. « Le champion est parti » est le récit le plus facile et la catégorie la plus surexploitée dans les post-mortems CSM sans assistance. Garde : le slug
champion-departurenécessite soit une date de départ LinkedIn SOIT un enregistrement de changement de contact CRM daté dans les 90 jours du churn — la passe de classification ne l’assignera pas sur un signal Gong uniquement. - Attribution hallucinée à partir de données clairsemées. Les chronologies courtes invitent des fictions confiantes. Garde : le minimum 30-jours-fenêtre / 3-événements en fin d’étape 1 court-circuite l’analyse avec
insufficient dataplutôt que de produire une sortie soignée qui ne mérite pas d’exister. Ce garde se déclenche intentionnellement plus souvent qu’il ne semble confortable — c’est le signal que l’instrumentation de la chronologie a besoin de travail, pas que le garde est trop strict. - Recommandation de prévention comme exercice de créativité. Chaque recommandation bespoke rend l’agrégat trimestriel inutile. Garde : l’étape 4 choisit depuis le fichier de bibliothèque fixe et refuse d’inventer. Si aucune entrée ne correspond, le Skill le dit et un humain conçoit délibérément la nouvelle entrée, avec un déclencheur mécaniquement détectable et un propriétaire nommé unique.
Stack
- HubSpot — enregistrement de churn, historique des contacts, raisons de fermeture-perdue
- Gainsight — scores de santé, événements de chronologie, jalons de plan de succès
- Gong — transcriptions d’appels pour la passe de preuves (optionnel mais améliore matériellement la qualité de la sortie)
- Claude — synthèse de la chronologie, extraction de preuves, classification par rapport à la taxonomie
- Notion ou Google Drive — stockage pour les analyses révisées, organisées par trimestre pour la revue agrégée