Un processus d’escalade est le chemin documenté qu’un problème client parcourt depuis « le CSM l’a remarqué » jusqu’à « un responsable identifié le corrige contre la montre ». Sans lui, chaque incendie est traité à la vitesse de qui se trouve par hasard dans le canal Slack, et la perception de sévérité du client s’éloigne de la vôtre. Ceci est un how-to : construisez les quatre pièces — niveaux de sévérité, routage, cadence de communication et suivi de cause racine — dans cet ordre, car chacune dépend de la précédente.
Prérequis
- Une plateforme de ticketing ou de CS capable de stocker un champ de sévérité et d’horodater les changements d’état. Zendesk, Pylon ou Gainsight conviennent ; le champ compte plus que le tool.
- Un workspace Slack capable de créer des canaux par incident.
- Une rotation on-call nommée pour l’ingénierie, ou au minimum un responsable identifié par domaine produit.
- Un signal de health-score ou de tier de compte pour qu’une assignation de Sev puisse intégrer la valeur du compte, et pas seulement l’impact technique.
Étape 1 — Définir les niveaux de sévérité avec des SLA de réponse et de résolution
La sévérité est une décision à deux axes : impact métier multiplié par poids du compte. Écrivez la matrice une fois et appliquez-la mécaniquement, pour qu’une décision de Sev ne soit pas un débat à 16h un vendredi.
| Sev | Déclencheur | SLA de réponse | Cadence de mise à jour | Cible de résolution |
|---|---|---|---|---|
| Sev 1 | Production en panne, perte de données ou exposition de sécurité pour un compte payant | 15 min | Toutes les 30 min | 4 heures |
| Sev 2 | Feature majeure cassée, sans workaround, ou tout problème sur un compte top-tier/à risque | 1 heure | Toutes les 2 heures | 1 jour ouvré |
| Sev 3 | Fonction dégradée avec un workaround | 1 jour ouvré | Quotidien | 5 jours ouvrés |
| Sev 4 | Cosmétique, question, ou feature request mal étiquetée comme bug | 2 jours ouvrés | Au changement | Backlog |
L’axe de poids du compte est ce que le CS ajoute et que le triage de support pur manque : un problème technique Sev 3 sur un compte en trimestre de renouvellement à 70 % de health est un Sev 2 en pratique. Encodez-le — si account_tier = strategic ou health_score < 60, montez le Sev d’un cran. Ne laissez pas chaque CSM monter à la main ; la règle le fait.
Étape 2 — Router vers un responsable nommé, pas vers une file
Une file est l’endroit où les escalades vieillissent. Router signifie que chaque Sev a un responsable préconvenu et un canal préconvenu avant que l’incident n’existe.
- À l’assignation du Sev, créez automatiquement un canal Slack dédié nommé
#esc-<compte>-<date>. Les canaux par incident l’emportent sur une seule lance partagée, car l’historique reste cherchable et le résumé côté client tient en un seul scroll, pas en une reconstruction. - Invitez automatiquement le responsable identifié de la rotation on-call, le CSM du compte et — pour Sev 1/2 — le manager CS. Pour Sev 1, faites un page, pas un @-mention : une mention est une notification, un page est une obligation.
- Ouvrez un issue de tracking dans Linear (ou votre tracker d’ingénierie) lié au canal, avec le Sev, le compte et l’horloge SLA dans la description. L’enregistrement côté CS (dans Gainsight ou votre CRM) renvoie au même issue pour que le contexte de renouvellement et du CSM voyage avec lui.
- Le CSM est propriétaire de la relation client tout du long ; le responsable d’ingénierie est propriétaire du fix. Séparer ces deux rôles explicitement évite l’échec où le CSM se tait parce qu’il attend l’ingénierie, et le client n’entend rien.
Étape 3 — Exécuter la cadence de communication
L’anxiété du client est une fonction du silence, pas de la sévérité. Un Sev 1 avec une mise à jour toutes les 30 minutes semble pris en charge ; un Sev 3 avec trois jours de silence ressemble à un Sev 1.
- Accusez réception dans le SLA de réponse avec un message humain : ce que vous comprenez du problème, le Sev que vous avez assigné, et quand arrive la prochaine mise à jour. Nommer l’heure de la prochaine mise à jour est le mouvement à plus fort levier — il convertit l’attente sans fin en promesse tenue.
- Mettez à jour selon la cadence même sans nouvelle. « Toujours en investigation, cause racine pas encore isolée, prochaine mise à jour à 15h » est une mise à jour valide. La sauter parce que rien n’a changé est l’escalade-de-l’escalade évitable la plus courante.
- Séparez le langage interne de l’externe. Le canal interne peut dire « la tempête de retries martèle la file » ; le client entend « nous avons identifié la cause et déployons un fix ». Ne collez jamais le chatter d’ingénierie brut au client.
- Clôturez explicitement. Indiquez ce qui a été corrigé, confirmez que le client le voit résolu, et demandez sa confirmation avant de marquer comme clôturé. Une clôture unilatérale se lit comme méprisante et rouvre fréquemment.
Étape 4 — Suivi de cause racine
Clôturer le ticket n’est pas fermer le loop. Chaque Sev 1 et Sev 2 reçoit une revue post-incident sans blâme dans les cinq jours ouvrés.
- Timeline. Reconstruisez à partir des horodatages du canal et du tracker : détection, accusé de réception, mitigation, résolution. Mesurez le temps-pour-accuser et le temps-pour-résoudre par rapport au SLA.
- Cinq pourquoi jusqu’à une cause systémique. Arrêtez-vous à la lacune de processus ou de système, pas à la personne. « Le CSM n’a pas vu l’alerte » n’est pas une cause racine ; « les alertes sont routées vers l’email, que le CSM ne surveille pas pendant les heures EU » l’est.
- Actions correctives avec responsables et dates. Chaque action est un issue tracké, pas une note de réunion. Les actions sans responsable n’existent pas.
- Réinjectez à l’Étape 1. Si le même Sev se répète, la matrice ou le routage sont faux — corrigez le système, pas l’instance suivante.
Pièges courants
- Inflation de sévérité. Tout devient Sev 1, donc rien ne l’est. Garde : la matrice est la seule autorité ; un override exige le nom du manager CS dans le canal et une raison d’une ligne.
- Router vers une file plutôt que vers une personne. Les tickets vieillissent dans des inbox partagés. Garde : chaque Sev auto-assigne un responsable nommé à la création ; un Sev sans responsable plus vieux que son SLA de réponse fait un page au manager.
- Silence entre les mises à jour. Garde : la cadence de mise à jour est imposée par un bot de rappel dans le canal d’incident, pas par la mémoire du responsable.
- Clôturer sans cause racine. La même panne se répète parce que personne n’a corrigé le système. Garde : un Sev 1/2 ne peut pas être marqué « résolu » tant qu’un issue post-incident lié, avec actions correctives et responsables, n’existe pas.
- Pas de facteur de poids du compte. Le triage purement technique sous-priorise un petit bug sur une baleine en train de churn. Garde : la règle de montée du Sev par tier et health score s’exécute automatiquement.
Connexes
- NRR vs GRR — ce que des escalades répétées vous coûtent en rétention
- Gainsight — health scores et contexte de compte pour la règle de montée du Sev
- Pylon — tooling de support B2B qui stocke la sévérité et le contexte par compte
- Linear — l’issue de tracking côté ingénierie