La plupart des équipes CS découvrent qu’un compte part au moment où le renewal ne se conclut pas. À ce stade, la fenêtre de sauvetage est fermée depuis des mois. Le correctif n’est pas un meilleur health score : c’est une motion fixe qui se déclenche au moment où un score franchit un seuil, pour que le CSM intervienne dès la première semaine du décrochage au lieu de réagir dans les 30 derniers jours avant le renewal. Ce SOP est cette motion : un trigger, une étape de diagnostic, une intervention par paliers, une règle d’escalade et une exigence de documentation qui tourne de la même façon pour chaque compte à risque. C’est délibérément rigide. Une motion de sauvetage qui dépend de l’improvisation par chaque CSM du bon coup quand un compte passe au rouge est une motion qui marche pour votre meilleur CSM et échoue pour tous les autres.

Le bundle de l’artifact se trouve dans apps/web/public/artifacts/churn-save-playbook-sop/. Il livre churn-save-sop.md (la procédure elle-même, prête à coller dans Notion ou dans une base de connaissances Gainsight), save-plan-template.md (le doc structuré de plan de sauvetage que le CSM remplit par compte) et slack-escalation-template.md (l’alerte canonique que le CSM publie quand un compte escalade). Adaptez les trois à vos noms de score, vos bandes de segment et vos conventions de canal avant le rollout.

Quand l’utiliser

Utilisez ce SOP quand vous faites tourner un health score dans Gainsight (ou un CSP comparable) auquel vous faites assez confiance pour agir, et que vous n’avez pas encore de motion écrite et appliquée pour ce qui se passe quand un compte passe au rouge. Le symptôme classique est un sauvetage qui a marché parce qu’un CSM l’a attrapé tôt et savait qui appeler — et le trimestre suivant un compte identique fait churn parce qu’un CSM différent a vu le même flag rouge et a attendu le QBR. Le score fait son travail ; la réponse au score est le gap que ceci comble.

Il convient le mieux aux équipes dans la bande de 100 à 2 000 clients avec un health score défini, une structure de book de CSM et un responsable CS qui peut être propriétaire des escalades. Sous ~100 comptes, un CSM lit chaque compte directement et une motion documentée est de l’overhead. Au-dessus de ~2 000, vous voulez probablement la motion de sauvetage pilotée par un CTA Gainsight avec routing natif et suivi de SLA plutôt qu’un post Slack et un doc partagé — à cette échelle, les étapes manuelles sont celles qu’on saute. Ce SOP est le bon outil dans la bande où la motion compte mais où le playbook vit dans la tête des gens.

Quand NE PAS l’utiliser

Ne l’adoptez pas si vous ne faites pas confiance à votre health score. Une motion de sauvetage déclenchée par un score qui passe au rouge sur du bruit de tagging ou un seul login manqué entraîne les CSM à ignorer le trigger en moins d’un mois. Réparez le score d’abord — le health score composite dans n8n et le constructeur de health score CS existent pour ça — puis greffez cette motion par-dessus. Une motion précise sur un trigger bruité est pire qu’aucune motion, parce qu’elle brûle la confiance de l’équipe dans le seul signal sur lequel vous avez besoin qu’elle agisse.

Ne l’utilisez pas comme outil de forecasting de renewal. Ce SOP est cadré sur le sauvetage : un compte qui était sain et qui glisse maintenant, où le but est d’inverser le décrochage avant qu’il n’atteigne le renewal. Un compte qui allait de toute façon partir pour une raison qu’aucun CSM ne peut bouger — l’acheteur est parti, l’entreprise a été acquise, le cas d’usage est mort — n’est pas un candidat au sauvetage, et le forcer à travers la motion gaspille les heures du CSM sur une perte déterministe. L’étape de diagnostic existe en partie pour prendre cette décision tôt.

Ne le faites pas tourner sans un responsable CS qui prendra les escalades. Le palier d’escalade est porteur : tout l’enjeu est qu’un compte au-delà d’une ligne de sévérité cesse d’être le problème d’un seul CSM et devienne celui de l’équipe. Si les escalades arrivent dans un canal dont personne n’est propriétaire, la motion se dégrade vers la même improvisation qu’elle était censée remplacer.

Le trigger

La motion se déclenche sur un événement de score Gainsight, pas sur l’intuition d’un CSM ni sur le calendrier. Deux triggers, l’un ou l’autre démarre le chrono :

Chute de bande vers le rouge —le health score composite franchit du jaune au rouge (dans le scoring de référence, composite sous 50). C’est le trigger primaire.
Gros delta négatif à l’intérieur d’une bande —une chute de 15 points ou plus en un seul cycle de scoring, même si le compte est encore techniquement jaune. Une chute du vert au jaune-moyen est souvent un signal plus tranchant qu’un rouge stable, parce qu’elle est nouvelle et que la cause est assez récente pour être encore réversible.

Gainsight déclenche un CTA sur l’une ou l’autre condition ; l’attribution du CTA est le CSM de record. Le SLA : le CSM ouvre un plan de sauvetage dans les deux jours ouvrés du trigger. Lier le démarrage à l’événement de score plutôt qu’à une revue hebdomadaire est tout l’enjeu — une revue se reprogramme ; un CTA avec un SLA se suit.

La motion

Diagnostiquer (avant le jour 2). Avant tout outreach, le CSM remplit la section diagnostic de save-plan-template.md : quel sub-score a bougé (usage, activité, sentiment), le chiffre concret et son baseline, et une hypothèse d’une ligne pour la cause. L’hypothèse est forcée dans un ensemble fixe — stagnation d’adoption, changement de champion, valeur non réalisée, déplacement concurrentiel, budget/économique, ou gap produit — parce que la classe de cause détermine le coup. Un diagnostic du type « ils ont l’air mécontents » est rejeté ; le CSM nomme le sub-score et la classe probable, ou marque « cause inconnue, appel d’investigation requis ».
Intervenir (avant le jour 5), par paliers selon la cause. Stagnation d’adoption → une session de travail sur la feature inutilisée, pas un check-in. Changement de champion → une motion d’introduction pour cartographier et gagner le nouveau stakeholder avant toute chose. Valeur non réalisée → sortez le success plan et le « pourquoi ils ont acheté » d’origine, et réservez une revue de valeur contre la métrique qu’ils ont définie au deal. Déplacement concurrentiel → impliquez l’AE et, si justifié, escaladez immédiatement. Budget/économique → une conversation commerciale dont le CSM n’est peut-être pas seul propriétaire. Gap produit → consignez-le, posez les attentes honnêtement, et ne promettez pas une date de roadmap que le CSM ne peut pas tenir. Le template porte un coup par défaut par classe pour que le CSM choisisse la variation, pas qu’il invente le coup.
Escalader (quand la ligne de sévérité est franchie). Un compte escalade hors de la motion à un seul CSM dès que l’un de : il est au rouge ET au-dessus d’un seuil de revenu fixé par l’équipe (ex. ARR du quartile supérieur), la cause est un déplacement concurrentiel, ou le plan de sauvetage tourne depuis 30 jours sans récupération de bande. L’escalade publie dans #cs-saves en utilisant slack-escalation-template.md —compte, ARR, date de renewal, sub-score qui a bougé avec son chiffre, classe de cause, le coup joué jusqu’ici et la demande précise au management. Le responsable CS accuse réception dans le fil dans un jour ouvré et assigne un exec sponsor ou un AE si la demande le justifie.
Documenter (en continu, et à la clôture). Chaque plan de sauvetage consigne le trigger, le diagnostic, le coup et le résultat — sauvé, churné, ou rétrogradé — rattaché à la classe de cause. C’est la moitié de la motion qui compose : après un trimestre, vous pouvez lire quelles classes de cause vous sauvez réellement et lesquelles non, et réorienter les heures du CSM vers les sauvables. Un sauvetage non documenté n’apprend rien à l’équipe.

À quoi ressemble le succès

Suivez quatre chiffres. Premièrement, le temps trigger-au-premier-contact —jours entre le déclenchement du CTA Gainsight et la première action de sauvetage consignée. Le SLA de deux jours ouvrés devrait amener la médiane sous deux jours en un mois ; un délai plus long signifie que le CTA se déclenche vers une file que personne ne traite. Deuxièmement, le taux de sauvetage par classe de cause —parmi les comptes entrés dans la motion, le pourcentage qui a récupéré au jaune-ou-mieux et renouvelé, ventilé par cause diagnostiquée. C’est le chiffre qui vous dit où la motion gagne sa place ; attendez-vous à ce que les sauvetages de stagnation d’adoption tournent bien au-dessus de ceux de déplacement concurrentiel, et dotez en personnel en conséquence. Troisièmement, la précision d’escalade —parmi les comptes escaladés, le pourcentage où l’implication du management a plausiblement changé le résultat. Si la plupart des escalades se seraient résolues sans le management, la ligne de sévérité est trop basse et vous taxez le responsable CS. Quatrièmement, le taux d’attrapé-à-temps —parmi les comptes ayant fait churn, le pourcentage qui est entré dans la motion de sauvetage. Un taux élevé de churn-sans-plan-de-sauvetage signifie que le trigger n’attrape pas les décrochages assez tôt, ce qui vous renvoie au score, pas à la motion.

Versus les alternatives

Versus un sauvetage ad-hoc lancé depuis le cycle de QBR. Le status quo dans la plupart des équipes est que le risque émerge à la revue trimestrielle et que le CSM improvise une réponse. Ça ne coûte rien à mettre en place et ça perd sur le timing et la cohérence : le QBR peut être 80 jours après le début du décrochage, et la qualité de la réponse oscille selon le CSM propriétaire du compte. Ce SOP coûte la mise en place d’un CTA Gainsight et de trois templates et déplace la réponse à moins d’une semaine du trigger. Ne choisissez la version ad-hoc que si votre nombre de comptes est assez bas (sous ~100) pour qu’un CSM lise chaque compte chaque semaine de toute façon.

Versus un Playbook / CTA Gainsight construit nativement, sans SOP écrit derrière. Gainsight peut déclencher le CTA et y attacher une checklist de tâches, et à l’échelle c’est le bon mécanisme de livraison. Mais une checklist de CTA sans la logique diagnostic-vers-coup derrière produit du théâtre de cases cochées — le CSM coche les cases et improvise quand même le sauvetage réel. Utilisez le CTA Gainsight comme le trigger et le minuteur de SLA, et utilisez les classes de diagnostic et les coups par paliers de ce SOP comme le contenu vers lequel le CTA pointe. Les deux sont complémentaires : Gainsight est la mécanique, le SOP est le jugement.

Versus ne rien faire de structuré. Viable seulement si votre churn n’est véritablement pas actionnable par le CS — une motion PLG pure sans contact humain, ou un segment où les sauvetages ne remboursent jamais les heures du CSM. Pour toute équipe avec un renewal piloté par la relation, la réponse non structurée à un compte rouge est la plus grande source unique de churn évitable : le sauvetage qu’un CSM aurait fait et qu’un autre a manqué, décidé par celui qui se trouvait être propriétaire du compte.

À surveiller

Le trigger se déclenche sur du bruit de score. Si le health score passe au rouge sur du tagging d’usage incohérent ou une seule semaine calme, le CSM travaille un non-problème et apprend à se méfier du CTA. Garde : conditionnez le trigger au composite, pas à un seul sub-score, et exigez que le trigger de gros delta persiste sur deux cycles de scoring avant de déclencher un CTA — un blip d’une nuit s’autocorrige et n’atteint jamais la file du CSM.
Le diagnostic s’effondre en une étiquette générique « à risque ». Si l’étape de diagnostic est optionnelle ou en texte libre, les CSM la sautent et bondissent vers un appel de check-in, qui est le coup pour toute cause et le bon coup pour aucune. Garde : le plan de sauvetage n’avance pas à l’étape d’intervention tant qu’une classe de cause n’est pas sélectionnée dans la liste fixe ou que « cause inconnue » n’est pas choisie explicitement avec un appel d’investigation réservé — la classe est ce qui sélectionne le coup.
L’escalade comme dépotoir. Si escalader est plus facile que jouer le coup, les CSM escaladent tout et le responsable CS devient le goulot. Garde : le template d’escalade exige le champ coup-joué-jusqu’ici et une demande précise avant de publier ; une escalade sans coup préalable et sans demande concrète est renvoyée au CSM dans le fil par le responsable CS.
Des sauvetages non documentés à la clôture. Un CSM qui sauve un compte et passe à autre chose sans consigner la cause et le coup n’apprend rien à l’équipe, et le prochain décrochage identique est improvisé de zéro. Garde : le CTA Gainsight ne se clôt pas tant que le champ résultat (sauvé / churné / rétrogradé) et la classe de cause ne sont pas renseignés, donc chaque plan de sauvetage clos alimente le rapport de taux-de-sauvetage-par-cause.
La motion survit au score sur lequel elle a été calée. Un health score repondéré ou un sub-score renommé casse silencieusement les seuils du trigger et les références de sub-score du diagnostic. Garde : revoyez les seuils du trigger dans le CTA Gainsight et les noms de sub-score dans save-plan-template.md contre le score en direct une fois par trimestre, dans la même revue qui recale les poids du score.

Stack

Gainsight —le health score, le CTA qui déclenche le trigger, le minuteur de SLA et le rapport de résultats par-cause
Slack —le canal d’escalade #cs-saves et le fil d’accusé de réception du responsable
Le doc de plan de sauvetage —save-plan-template.md, stocké là où votre équipe garde les docs de compte (Gainsight, Notion, ou un custom object Salesforce), un seul emplacement canonique par compte

Modifier cette page sur GitHub