Une Claude Skill qui transforme une escalade client en une analyse de cause racine (RCA) défendable : une chronologie reconstituée de chaque action sur les tickets et chaque call, une cause racine nommée séparée de ses facteurs contributifs, et un plan d’actions correctives avec responsables et dates. Elle lit le fil du ticket Zendesk ainsi que tout ticket frère lié et les calls Gong rattachés au compte sur la fenêtre d’escalade, puis produit un unique RCA en Markdown que le CSM édite et que le support lead valide avant qu’il ne parte chez le client ou vers une revue post-incident interne. Le bundle de l’artifact inclut le SKILL.md plus trois fichiers de référence que l’équipe adapte une fois et réutilise pour chaque escalade.

Le bundle de l’artifact se trouve dans apps/web/public/artifacts/escalation-rca-skill/. Il contient SKILL.md, references/1-rca-template.md (le squelette d’output avec des sections nommées), references/2-cause-taxonomy.md (la liste figée des catégories de cause racine dans lesquelles la Skill doit classer), et references/3-sample-rca.md (un exemple travaillé anonymisé que la passe de tone-match imite). Lisez les trois avant la première exécution.

Quand l’utiliser

Vous êtes un CSM ou un support lead qui vient d’avoir un compte qui escalade — une panne sev-1 qui met le client en colère, une série de tickets mal traités, une réclamation qui menace le renewal — et vous avez besoin d’un RCA écrit rapidement, avant la réunion de postmortem ou le call d’excuses au client. La Skill est construite pour le cas où la preuve est dispersée entre un fil Zendesk, trois ou quatre tickets frères ouverts par des personnes différentes côté client, et deux ou trois calls Gong où la frustration a réellement émergé. Assembler cette chronologie à la main représente 60 à 120 minutes de changement d’onglet ; la Skill fait l’assemblage et vous remet un brouillon sur lequel raisonner.

Elle produit l’output le plus utile quand les tickets Zendesk sont liés (via le compte ou un lien explicite problem/incident) et taggés de façon cohérente, et quand au moins un call Gong dans la fenêtre a une transcription. Elle est calibrée pour un unique événement d’escalade avec une fenêtre bornée — typiquement les 14 à 30 jours autour de l’incident déclencheur — pas pour une analyse de pattern sur un trimestre entier.

Quand NE PAS l’utiliser

N’envoyez pas l’output de la Skill au client sans l’éditer. C’est un moteur de brouillon. La cause racine est une hypothèse que le CSM et le support lead confirment au regard de leur propre connaissance avant que quiconque ne signe de son nom. Un RCA envoyé à un client en colère avec une mauvaise cause racine fait plus de dégâts que pas de RCA du tout.

Ne l’utilisez pas quand la chronologie compte moins de trois événements. Avec un ticket et aucun call il n’y a rien à reconstituer, et la Skill est construite pour renvoyer insufficient data plutôt que de fabriquer un récit — mais seulement si vous respectez ce refus au lieu de forcer une exécution. Un RCA assuré construit sur deux data points se lit avec autorité et trompe tous ceux qui agissent sur lui.

Ne l’utilisez pas pour les litiges juridiques ou contractuels, les postmortems d’incident de sécurité, ou tout ce qui se dirige vers une négociation de crédit SLA où la formulation est adversariale. La Skill écrit un RCA opérationnel dans un registre neutre et responsable ; elle n’écrit pas de langage juridique défendable et sous-estimera ou surestimera la responsabilité de façons qui comptent quand de l’argent ou des termes de contrat sont en jeu. Routez ceux-là vers l’équipe qui les détient.

Ne l’utilisez pas comme prédicteur de churn ou comme health score. Elle explique un événement passé. Le workflow de composite health score est l’outil calibré pour le risque de retention prospectif ; lire la cotation de gravité de ce RCA comme une probabilité de churn vous trompera.

Setup

Environ 45 à 60 minutes la première fois, l’essentiel passé à adapter la cause taxonomy dans references/2-cause-taxonomy.md aux modes de défaillance réels de votre équipe.

Installez la Skill. Déposez le bundle de apps/web/public/artifacts/escalation-rca-skill/ dans ~/.claude/skills/escalation-rca/. La Skill définit une seule commande, draft_rca(account_id, escalation_window, anchor_ticket_id), plus des helpers internes pour le pull Zendesk, le pull Gong, le merge de chronologie et le pipeline à deux passes de Claude.
Câblez les identifiants. Définissez ZENDESK_SUBDOMAIN et ZENDESK_API_TOKEN (accès en lecture sur Tickets, Ticket Comments et Ticket Audits — les audits sont ce qui vous donne les timestamps de changement de statut), et GONG_API_KEY (accès en lecture sur les calls et les transcriptions). La Skill n’effectue aucune écriture sur l’un ou l’autre système ; elle est read-only par conception afin de pouvoir s’exécuter en production sans revue de change-control.
Adaptez la cause taxonomy. Ouvrez references/2-cause-taxonomy.md et remplacez les catégories placeholder par celles, réelles, de votre équipe. Le jeu par défaut est product-defect, config-error, documentation-gap, process-breakdown, capacity-overload, communication-failure et third-party-dependency. La Skill classe la cause racine dans exactement l’une d’elles et liste le reste comme facteurs contributifs là où la preuve les soutient ; une cause racine en texte libre est la raison la plus fréquente pour laquelle deux RCA du même incident divergent, donc la taxonomy figée est structurelle, pas décorative.
Adaptez le template et l’échantillon de voix. Éditez references/1-rca-template.md pour que les noms de section correspondent à ce qu’attend votre processus de postmortem (certaines équipes ont besoin d’une section customer-impact avec le nombre d’utilisateurs affectés ; certaines d’une section detection). Remplacez l’exemple travaillé dans references/3-sample-rca.md par deux ou trois RCA antérieurs anonymisés que votre équipe a écrits, afin que la passe de tone-match imite votre style maison plutôt que l’échantillon générique.
Exécutez pour une escalade. draft_rca(account_id="...", escalation_window="2026-05-20:2026-06-03", anchor_ticket_id="48213"). La Skill écrit un fichier Markdown : la chronologie reconstituée, la section de cause racine, la liste des facteurs contributifs, le tableau d’actions correctives et un résumé orienté client d’un paragraphe que le CSM peut reprendre ou réécrire.

Ce que la Skill fait réellement

La Skill pull Zendesk et Gong en parallèle parce qu’ils touchent des systèmes indépendants et que le goulot d’étranglement est la latence de l’API, pas les tokens de Claude. De Zendesk elle pull le ticket d’ancrage, chaque ticket frère lié au même compte ou problème dans la fenêtre et — de façon critique — l’audit log de chaque ticket, parce que les audits portent les timestamps de changement de statut et d’assigné que le fil de commentaires seul n’a pas. De Gong elle pull les calls du compte dans la fenêtre, plafonnés aux six plus récents, avec des transcriptions tronquées à 4 000 caractères chacune. Si l’un des systèmes renvoie vide, la Skill enregistre le gap dans la chronologie plutôt que de le combler.

Elle fusionne ensuite tout en une unique chronologie chronologique indexée sur des timestamps UTC. Le merge est une étape déterministe, pas une étape Claude, parce que l’ordonnancement des timestamps est exactement le genre de chose qu’un modèle de langage rate subtilement et qu’un tri ne rate pas. Chaque événement porte sa source (zendesk-comment, zendesk-status-change, gong-call), son acteur et un résumé d’une ligne. Cette chronologie fusionnée est l’épine dorsale de tout le RCA, et elle figure dans l’output verbatim pour que le lecteur puisse auditer chaque affirmation en aval au regard d’elle.

Puis deux passes Claude. La passe un est l’analyse causale : Claude lit la chronologie fusionnée et la cause taxonomy et produit une unique cause racine nommée, une liste séparée de facteurs contributifs et les événements de chronologie spécifiques qui soutiennent chacun. Séparer la cause racine des facteurs contributifs dans une passe dédiée importe parce que la défaillance de RCA la plus fréquente est de confondre les deux — appeler cause le symptôme le plus bruyant. La passe est instruite de citer les événements de chronologie par leur timestamp pour chaque affirmation causale et de renvoyer insufficient data s’il existe moins de trois événements dans la fenêtre.

La passe deux est le plan d’actions correctives et le tone-match. Claude prend la cause racine confirmée plus les facteurs contributifs et propose un tableau d’actions correctives — chaque ligne une action, un rôle responsable (pas une personne nommée ; l’équipe attribue les noms), un offset de date d’échéance et le facteur contributif qu’elle clôt. Elle réécrit ensuite tout le RCA dans la voix de l’équipe en utilisant les échantillons de references/3-sample-rca.md, et écrit le résumé orienté client d’un paragraphe dans un registre plus conservateur qui nomme l’impact et la remédiation sans admettre une responsabilité que l’équipe n’a pas convenue. Séparer les actions et le ton dans leur propre passe garde le raisonnement causal de la passe un non contaminé par l’adoucissement que le résumé orienté client exige.

Réalité des coûts

Une exécution complète coûte environ 15 000 à 30 000 tokens d’input et 2 000 à 4 000 tokens d’output sur Claude Sonnet — disons 6 à 12 cents par RCA aux prix actuels de Sonnet. La variable d’input dominante est le volume de transcriptions Gong ; un compte fortement escaladé avec six calls enregistrés dans la fenêtre atterrit près du haut, une escalade uniquement par tickets sans calls près du bas. La conception à deux passes partage le contexte préfixe, donc la deuxième passe est moins chère que la première.

Le temps d’horloge est de deux à quatre minutes, dominé par les pulls de l’audit log Zendesk (un appel d’API supplémentaire par ticket) et le fetch des transcriptions Gong. Les deux passes Claude ajoutent 40 à 70 secondes après la fin du pull parallèle.

Un CSM ou un support lead écrivant un RCA de zéro passe typiquement 60 à 120 minutes — à pull les tickets, lire les audits, réécouter les calls, reconstituer la chronologie, puis écrire. La Skill ramène cela à 20 à 35 minutes d’édition, donc l’économie est d’environ une heure par escalade. Une organisation de support traitant 15 à 25 escalades formelles par trimestre récupère 15 à 25 heures de temps d’IC senior, ce qui est là où le coût se ressent le plus parce que les escalades retombent sur les personnes les plus expérimentées.

À quoi ressemble le succès

Suivez le temps de « escalade déclarée » à « RCA diffusé pour sign-off interne ». La Skill devrait ramener la médiane sous 90 minutes dans le premier trimestre d’usage, contre une base de référence de zéro d’une demi-journée ou plus. Suivez aussi le taux auquel la cause racine proposée survit à la revue du support lead sans changement — visez 60 % ou plus. Plus bas que cela et la cause taxonomy a besoin d’être recoupée pour correspondre à la façon dont vos incidents défaillent réellement ; plus haut que 85 % et le lead tamponne probablement au lieu de réviser, ce qui défait la garde du human-in-the-loop.

Un second chiffre à surveiller : la part des actions correctives des RCA passés qui ont effectivement été closes à leur date d’échéance. La Skill n’impose pas cela — elle ne fait que proposer les actions — mais si cette part reste sous 50 %, le processus de RCA est du théâtre et un moteur de brouillon plus rapide ne le réparera pas. La métrique vous dit si l’organisation agit sur les causes racines ou se contente de les documenter.

Face aux alternatives

Face à un RCA manuel dans un Google Doc. Le status quo de la plupart des équipes. Les RCA manuels sont de plus haute fidélité quand l’auteur était personnellement dans le loop de l’incident, parce qu’ils portent un contexte que les systèmes n’ont jamais enregistré — le fil Slack, la conversation de couloir, la lecture instinctive de la vraie doléance du client. Le compromis est l’heure et plus d’assemblage de chronologie, qui est du pur labeur mécanique que la Skill élimine. Utilisez le manuel pour la rare escalade au niveau board où chaque mot est pesé ; utilisez la Skill pour le volume régulier d’escalades opérationnelles où la contrainte est le temps d’IC senior, pas l’art narratif. Même pour le cas board, la chronologie reconstituée de la Skill est un artifact de départ utile.

Face aux fonctions natives de merge de tickets et de side-conversation de Zendesk. Zendesk peut lier et fusionner des tickets liés et faire émerger une vue unifiée, et si tout ce dont vous avez besoin est l’historique de tickets consolidé, c’est moins de travail qu’installer une Skill. Mais Zendesk fait émerger les tickets ; il ne reconstitue pas une chronologie cross-system incluant les calls Gong, et il ne nomme pas de cause racine ni ne propose d’actions correctives. Il vous donne la matière première ; la Skill écrit l’analyse. Utilisez le linking de Zendesk pour garder les tickets frères découvrables — la Skill s’appuie sur ce linking pour les trouver — et la Skill pour transformer l’ensemble lié en un RCA.

Face à un outil dédié de gestion d’incidents (un incident.io ou un FireHydrant). Ceux-ci sont excellents pour la réponse à incident menée par l’ingénierie avec rotations on-call, status pages et échafaudage de postmortem automatisé. Si vos escalades sont des incidents d’infrastructure et que vous en exploitez déjà un, utilisez son flux de postmortem. Mais ces outils sont construits autour du cycle de vie de l’incident d’ingénierie, pas de celui de la relation client ; ils ne lisent pas vos calls Gong et n’écrivent pas dans la voix orientée client de votre équipe CSM. Pour une escalade détenue par le CS qui porte autant sur une relation que sur un défaut, cette Skill s’insère dans l’interstice que ces outils laissent ouvert.

Points de vigilance

Biais rétrospectif dans la passe causale. Lire une chronologie à rebours depuis un résultat connu comme mauvais fait paraître chaque décision antérieure comme une erreur évidente, et Claude la racontera ainsi sans garde. Garde : la passe un est instruite de distinguer ce qui était connaissable à chaque événement de ce qui n’est connaissable qu’avec le recul, et de marquer toute affirmation qui dépend du recul. Elle renvoie aussi insufficient data plutôt que de deviner quand il existe moins de trois événements de chronologie dans la fenêtre — aucun récit n’est construit sur une fondation trop mince pour en soutenir un.
Des audit logs manquants effondrent la chronologie. Si le token Zendesk manque du scope de lecture d’audit, la Skill obtient silencieusement les commentaires sans timestamps de changement de statut, et la chronologie perd les événements « le ticket est resté en pending pendant neuf jours » qui sont souvent la vraie histoire. Garde : la Skill vérifie l’accès audit sur le ticket d’ancrage pendant la vérification de setup et refuse de s’exécuter avec une erreur ZENDESK_AUDIT_SCOPE_MISSING plutôt que de produire une chronologie qui omet les événements les plus importants.
Cause racine confondue avec le symptôme le plus bruyant. L’événement dont le client s’est le plus plaint est rarement la cause racine ; c’est généralement un symptôme en aval. Un modèle sans garde s’ancre sur le volume. Garde : la cause taxonomy dans references/2-cause-taxonomy.md impose une seule catégorie classée, et la passe un doit citer l’événement de chronologie spécifique qui est le point le plus précoce où la cause était en jeu — pas le plus bruyant, le plus précoce. Les symptômes venus plus tard sont classés en facteurs contributifs.
Sentiment Gong sur-interprété sur des transcriptions minces. Un unique call court est sur-pondéré comme « le client est furieux » alors que la transcription est une messagerie vocale de 90 secondes. Garde : la Skill plafonne l’influence de Gong dans la passe causale à une preuve corroborante — un call peut soutenir un événement de chronologie mais ne peut à lui seul être la cause racine nommée, parce qu’une plainte enregistrée est un symptôme, pas une cause. Les transcriptions sous 200 mots sont marquées faible-confiance et exclues de la lecture de sentiment.
Résumé orienté client admettant une responsabilité que l’équipe n’a pas convenue. La passe deux écrit un résumé que le client peut lire, et un LLM laissé à son propre registre s’excusera pour des choses que l’entreprise n’a pas décidé d’assumer. Garde : le prompt du résumé orienté client ne nomme que l’impact et la remédiation, interdit explicitement d’attribuer un blâme ou de promettre une compensation, et préfixe le paragraphe d’un marqueur REVIEW BEFORE SENDING que le CSM doit retirer à la main — il n’existe aucun chemin où un texte orienté client quitte la Skill sans une touche humaine.

Stack

Zendesk — fil de tickets, tickets frères et les audit logs qui portent les timestamps de changement de statut (REST API, read-only)
Gong — transcriptions et metadata des calls du compte dans la fenêtre d’escalade (Gong API, read-only)
Claude — analyse à deux passes : analyse causale contre la taxonomy, puis plan d’actions correctives plus tone-match (Sonnet recommandé pour le coût ; Opus seulement si le résumé orienté client porte une sensibilité inhabituelle)

Modifier cette page sur GitHub