Un playbook de customer success est une séquence définie et répétable d’actions qu’un CSM exécute lorsqu’un trigger spécifique se déclenche : un kickoff d’onboarding, une baisse d’usage, un signal d’expansion, un renouvellement qui approche. L’unité est le play : trigger → étapes → owner → critère de réussite → sortie. Un playbook est la bibliothèque de plays ; un play est une entrée. L’objectif est de convertir ce que votre meilleur CSM fait à l’instinct en quelque chose que chaque CSM exécute de la même façon, et qu’une plateforme de CS peut déclencher automatiquement pour qu’un humain ne fasse que la partie qui nécessite un humain.
Ce qu’un playbook n’est pas : ce n’est pas un document de processus, et ce n’est pas un article de help center. Un document de processus décrit comment l’onboarding fonctionne en général ; un play dit « lorsqu’un compte atteint le jour 14 avec moins de 30 % des seats activés, le CSM envoie la séquence d’activation et planifie un appel d’enablement de 30 minutes, et le play se termine quand l’activation des seats dépasse 60 % ». Un play a un trigger, une sortie mesurable et un owner. S’il ne les a pas, c’est de la documentation, pas un play.
Les quatre familles de plays
La plupart des motions de CS se réduisent à quatre familles basées sur des triggers. Construisez celles-ci en premier ; tout le reste est une variation.
- Plays d’onboarding. Déclenchés par un deal closed-won ou une date de go-live. Objectif : amener le client à la première valeur (TTV) avant la fin de la lune de miel. Étapes : kickoff, définition du plan de réussite, enablement, points de contrôle des jalons. Critère de réussite : le client atteint le jalon d’activation défini (seats actifs, premier workflow lancé, premier outcome réalisé).
- Plays de risque. Déclenchés par une baisse de bande du health score (vert→jaune, jaune→rouge), le départ d’un champion, un déclin d’usage, une escalade de support, ou un sponsor qui devient silencieux. Objectif : diagnostiquer et intervenir avant que le signal ne devienne un non-renouvellement. Critère de réussite : le signal déclencheur s’inverse (l’usage se rétablit, un nouveau champion est identifié).
- Plays d’expansion. Déclenchés par un plafond d’utilisation des seats, un signal de nouveau cas d’usage, un cluster de power-users qui se forme, ou une date de cycle budgétaire. Objectif : router une expansion qualifiée vers sales ou self-serve. Critère de réussite : un CSQL (customer success qualified lead) est créé et accepté.
- Plays de renouvellement. Déclenchés par une date de renouvellement moins un lead time (couramment 90/120/180 jours selon la bande d’ACV). Objectif : sécuriser le renouvellement à l’ARR actuel ou au-dessus. Critère de réussite : renouvellement conclu, sans churn surprise.
Comment structurer un play
Chaque play comporte les mêmes six champs. Tenez la ligne sur les six : un play sans critère de sortie ou sans owner est celui qui tourne indéfiniment ou ne se termine jamais.
| Champ | Ce à quoi il répond |
|---|---|
| Trigger | La condition exacte qui déclenche le play (un seuil, une date, un événement) |
| Filtre de segment | À quels comptes cela s’applique (bande d’ACV, produit, région) |
| Étapes | Les actions ordonnées, chacune marquée humaine ou automatisée |
| Owner | Le rôle unique responsable (CSM, CS Ops, AE) |
| Critère de réussite | La condition mesurable qui clôt le play comme une victoire |
| Timeout / escalade | Ce qui se passe si le critère n’est pas atteint en N jours |
Un play de risque travaillé, entièrement spécifié :
Play: Usage decline — mid-market
Trigger: weekly active users down >25% vs trailing 4-week avg
Segment: ACV $25K-$100K
Steps: 1. [auto] Slack alert to owning CSM + health score recompute
2. [human] CSM reviews usage by feature, identifies the drop
3. [human] CSM sends re-engagement email within 48h
4. [human] book a working session if no reply in 5 days
Owner: CSM
Success: weekly active users recover to within 10% of prior avg
Timeout: 14 days → escalate to CS manager, flag for QBR agenda
Quoi automatiser vs. garder humain
La règle d’automatisation : automatisez la détection du trigger et les étapes à faible jugement ; gardez humaines les étapes de relation. Une plateforme de CS (Gainsight, ChurnZero, Vitally, Catalyst) surveille les signaux et déclenche le play : cette partie ne devrait jamais être manuelle, car surveiller les signaux à la main est l’endroit où les comptes glissent. À l’intérieur du play, la répartition se fait par jugement :
- Automatisez : détection des triggers, recalcul du health, routage des alertes, création de tâches, emails templatisés à faible enjeu (nudges d’onboarding, envois d’enquêtes, relances NPS), hygiène des données.
- Gardez humain : le diagnostic (« pourquoi l’usage a-t-il baissé ? »), la conversation de renouvellement, le pitch d’expansion, tout ce où un message automatisé erroné endommage la confiance. Un play de compte rouge doit créer une tâche et briefer le CSM, pas envoyer automatiquement un email « nous avons remarqué que vous êtes en train de churner ».
Séquencez la construction : instrumentez d’abord les triggers (vous ne pouvez pas déclencher un play sur un signal que vous ne capturez pas), puis écrivez les plays, puis automatisez les étapes mécaniques évidentes, et enfin ajoutez les étapes à fort jugement uniquement là où le template tient vraiment.
Pièges courants
- Plays sans critère de sortie. Un play qui ne se termine jamais de façon mesurable encombre la liste de tâches du CSM et entraîne l’équipe à ignorer les plays. Garde : chaque play a un unique critère de réussite mesurable et un timeout qui escalade ; pas de « surveiller le compte » ouvert.
- Sur-automatisation des moments de relation. Envoyer automatiquement un email de renouvellement ou de save se lit comme une lettre type au moment précis où le client a besoin de se sentir vu. Garde : classez chaque étape humaine ou automatisée explicitement ; par défaut, les conversations de relation et d’argent vont à l’humain.
- Un playbook pour tous les segments. Un compte SMB de 12 seats et un compte enterprise de 4 000 seats nécessitent des lead times différents, des owners différents et une profondeur d’étapes différente. Garde : chaque play porte un filtre de segment ; maintenez des lead times par segment (les plays de renouvellement surtout : 90 jours pour SMB, 180 pour enterprise).
- Prolifération des triggers. Cinquante triggers qui se chevauchent se déclenchent en permanence, le CSM se noie sous les tâches, et la qualité des plays s’effondre en bruit. Garde : plafonnez les plays actifs par CSM et ajustez les seuils des triggers contre le taux de déclenchement historique ; si un trigger se déclenche sur la moitié du book, il est mal calibré.
- Pas de boucle de feedback. Les plays sont lancés une fois et s’ossifient pendant que la réalité dérive. Garde : passez en revue les taux de victoire des plays chaque trimestre (critère de réussite atteint dans le timeout / déclenchements totaux) ; retirez les plays sous ~30 % de taux de victoire et respécifiez le trigger.
Quand le framework se brise
Les playbooks supposent un volume suffisant pour que la répétabilité soit rentable. Un book pur high-touch de 8 à 12 comptes stratégiques à $1M+ d’ACV chacun n’exécute pas de plays : il exécute des plans de compte sur mesure, et forcer ces CSM dans une bibliothèque de plays ajoute de l’overhead sans aucun bénéfice. Le modèle de playbook gagne sa place dans les bandes tech-touch et mid-touch où un CSM gère 40 à 200 comptes et où la contrainte est la cohérence, pas la personnalisation.
Connexes
- Customer health score — la couche de signal sur laquelle se déclenchent la plupart des plays de risque et de renouvellement
- Customer onboarding — la famille de plays où le TTV est le plus en jeu
- Customer churn et expansion revenue — ce que les plays de risque et d’expansion existent pour faire bouger
- Gainsight et ChurnZero — des plateformes avec automatisation native des playbooks