Una Claude Skill que convierte una escalación de cliente en un análisis de causa raíz (RCA) defendible: una línea de tiempo reconstruida de cada toque de ticket y llamada, una causa raíz nombrada separada de sus factores contribuyentes, y un plan de acciones correctivas con responsables y fechas. Lee el hilo del ticket de Zendesk más cualquier ticket hermano vinculado y las llamadas de Gong atadas a la cuenta durante la ventana de escalación, y luego produce un único RCA en Markdown que el CSM edita y el support lead aprueba antes de que vaya al cliente o a una revisión post-incidente interna. El bundle del artifact incluye el SKILL.md más tres archivos de referencia que el equipo adapta una vez y reusa en cada escalación.

El bundle del artifact vive en apps/web/public/artifacts/escalation-rca-skill/. Contiene SKILL.md, references/1-rca-template.md (el esqueleto de output con secciones nombradas), references/2-cause-taxonomy.md (la lista fija de categorías de causa raíz en las que la Skill debe clasificar), y references/3-sample-rca.md (un ejemplo trabajado anonimizado que la pasada de tone-match imita). Lee los tres antes de la primera corrida.

Cuándo usarla

Eres un CSM o un support lead que acaba de tener una cuenta que escaló —una caída sev-1 que enoja al cliente, una serie de tickets mal manejados, una queja que amenaza el renewal— y necesitas un RCA escrito rápido, antes de la reunión de postmortem o la llamada de disculpa al cliente. La Skill está construida para el caso donde la evidencia está dispersa entre un hilo de Zendesk, tres o cuatro tickets hermanos abiertos por distintas personas del lado del cliente, y dos o tres llamadas de Gong donde la frustración realmente salió a la superficie. Ensamblar esa línea de tiempo a mano son 60 a 120 minutos de cambiar de pestaña; la Skill hace el ensamble y te entrega un borrador sobre el que razonar.

Produce el output más útil cuando los tickets de Zendesk están vinculados (vía la cuenta o un link explícito problem/incident) y etiquetados de forma consistente, y cuando al menos una llamada de Gong en la ventana tiene transcripción. Está calibrada para un único evento de escalación con una ventana acotada —típicamente los 14 a 30 días alrededor del incidente disparador— no para un análisis de patrón de un trimestre completo.

Cuándo NO usarla

No envíes el output de la Skill al cliente sin editar. Es un motor de borrador. La causa raíz es una hipótesis que el CSM y el support lead confirman contra su propio conocimiento antes de que alguien firme con su nombre. Un RCA enviado a un cliente enojado con una causa raíz equivocada hace más daño que ningún RCA.

No la uses cuando la línea de tiempo tiene menos de tres eventos. Con un ticket y sin llamadas no hay nada que reconstruir, y la Skill está construida para devolver insufficient data en vez de fabricar una narrativa —pero solo si respetas esa negativa en vez de forzar una corrida. Un RCA confiado construido sobre dos data points se lee con autoridad y engaña a todos los que actúan sobre él.

No la uses para disputas legales o contractuales, postmortems de incidentes de seguridad, o cualquier cosa que se encamine a una negociación de crédito de SLA donde la redacción es adversarial. La Skill escribe un RCA operacional en un registro neutral y responsable; no escribe lenguaje legal defendible y subestimará o sobreestimará la responsabilidad de formas que importan cuando hay dinero o términos de contrato en juego. Enruta esos al equipo que los posee.

No la uses como predictor de churn o como health score. Explica un evento pasado. El workflow de composite health score es la herramienta calibrada para riesgo de retención hacia adelante; leer la calificación de severidad de este RCA como una probabilidad de churn te engañará.

Setup

Aproximadamente 45 a 60 minutos la primera vez, la mayoría gastada adaptando la taxonomía de causas en references/2-cause-taxonomy.md a los modos de falla reales de tu equipo.

Instala la Skill. Coloca el bundle de apps/web/public/artifacts/escalation-rca-skill/ en ~/.claude/skills/escalation-rca/. La Skill define un solo comando, draft_rca(account_id, escalation_window, anchor_ticket_id), más helpers internos para el pull de Zendesk, el pull de Gong, el merge de línea de tiempo y el pipeline de dos pasadas de Claude.
Conecta credenciales. Configura ZENDESK_SUBDOMAIN y ZENDESK_API_TOKEN (acceso de lectura en Tickets, Ticket Comments y Ticket Audits —los audits son los que te dan los timestamps de cambio de estado), y GONG_API_KEY (acceso de lectura en calls y transcripciones). La Skill no hace escrituras a ninguno de los dos sistemas; es read-only por diseño para poder correr contra producción sin una revisión de control de cambios.
Adapta la taxonomía de causas. Abre references/2-cause-taxonomy.md y reemplaza las categorías placeholder con las reales de tu equipo. El set por default es product-defect, config-error, documentation-gap, process-breakdown, capacity-overload, communication-failure y third-party-dependency. La Skill clasifica la causa raíz en exactamente una de estas y lista el resto como factores contribuyentes donde la evidencia los soporta; una causa raíz en texto libre es la razón más común de que dos RCAs del mismo incidente no coincidan, así que la taxonomía fija es estructural, no decoración.
Adapta la plantilla y la muestra de voz. Edita references/1-rca-template.md para que los nombres de sección coincidan con lo que tu proceso de postmortem espera (algunos equipos necesitan una sección customer-impact con conteos de usuarios afectados; algunos necesitan una sección detection). Reemplaza el ejemplo trabajado en references/3-sample-rca.md con dos o tres RCAs previos anonimizados que tu equipo haya escrito, para que la pasada de tone-match imite tu estilo de casa en vez de la muestra genérica.
Corre para una escalación. draft_rca(account_id="...", escalation_window="2026-05-20:2026-06-03", anchor_ticket_id="48213"). La Skill escribe un archivo Markdown: la línea de tiempo reconstruida, la sección de causa raíz, la lista de factores contribuyentes, la tabla de acciones correctivas y un resumen de cara al cliente de un párrafo que el CSM puede tomar o reescribir.

Qué hace la Skill en realidad

La Skill jala Zendesk y Gong en paralelo porque golpean sistemas independientes y el cuello de botella es la latencia de la API, no los tokens de Claude. De Zendesk jala el ticket ancla, cada ticket hermano vinculado a la misma cuenta o problema dentro de la ventana y —críticamente— el audit log de cada ticket, porque los audits llevan los timestamps de cambio de estado y de cambio de asignado que el hilo de comentarios por sí solo no tiene. De Gong jala las llamadas de la cuenta dentro de la ventana, limitadas a las seis más recientes, con transcripciones truncadas a 4,000 caracteres cada una. Si cualquier sistema devuelve vacío, la Skill registra el gap en la línea de tiempo en vez de llenarlo.

Después fusiona todo en una sola línea de tiempo cronológica encadenada a timestamps UTC. El merge es un paso determinista, no un paso de Claude, porque el ordenamiento de timestamps es exactamente el tipo de cosa que un modelo de lenguaje hace sutilmente mal y un sort no. Cada evento lleva su fuente (zendesk-comment, zendesk-status-change, gong-call), su actor y un resumen de una línea. Esta línea de tiempo fusionada es la columna vertebral de todo el RCA, y está en el output verbatim para que el lector pueda auditar cada afirmación downstream contra ella.

Luego dos pasadas de Claude. La pasada uno es análisis causal: Claude lee la línea de tiempo fusionada y la taxonomía de causas y produce una sola causa raíz nombrada, una lista separada de factores contribuyentes y los eventos específicos de la línea de tiempo que soportan cada uno. Separar causa raíz de factores contribuyentes en una pasada dedicada importa porque la falla de RCA más común es confundir las dos —llamar causa al síntoma más ruidoso. La pasada está instruida para citar eventos de la línea de tiempo por su timestamp en cada afirmación causal y para devolver insufficient data si existen menos de tres eventos dentro de la ventana.

La pasada dos es el plan de acciones correctivas y el tone-match. Claude toma la causa raíz confirmada más los factores contribuyentes y propone una tabla de acciones correctivas —cada fila una acción, un rol responsable (no una persona nombrada; el equipo asigna nombres), un offset de fecha de vencimiento y el factor contribuyente que cierra. Luego reescribe todo el RCA en la voz del equipo usando las muestras en references/3-sample-rca.md, y escribe el resumen de cara al cliente de un párrafo en un registro más conservador que nombra impacto y remediación sin admitir responsabilidad que el equipo no ha acordado. Separar acciones y tono en su propia pasada mantiene el razonamiento causal de la pasada uno sin contaminar por la suavización que el resumen de cara al cliente requiere.

Realidad de costos

Una corrida completa cuesta aproximadamente 15,000 a 30,000 tokens de input y 2,000 a 4,000 tokens de output con Claude Sonnet —llámalo 6 a 12 centavos por RCA a precios actuales de Sonnet. La variable de input dominante es el volumen de transcripciones de Gong; una cuenta muy escalada con seis llamadas registradas en la ventana aterriza cerca del tope, una escalación solo de tickets sin llamadas cerca del piso. El diseño de dos pasadas comparte contexto prefijo, así que la segunda pasada es más barata que la primera.

El tiempo de reloj es dos a cuatro minutos, dominado por los pulls del audit log de Zendesk (una llamada de API extra por ticket) y el fetch de transcripciones de Gong. Las dos pasadas de Claude agregan 40 a 70 segundos después de que el pull paralelo termina.

Un CSM o support lead escribiendo un RCA desde cero típicamente gasta 60 a 120 minutos —jalando tickets, leyendo audits, reescuchando llamadas, reconstruyendo la línea de tiempo y luego escribiendo. La Skill lleva eso a 20 a 35 minutos de edición, así que el ahorro es aproximadamente una hora por escalación. Una organización de soporte que corre 15 a 25 escalaciones formales por trimestre recupera 15 a 25 horas de tiempo de IC senior, que es donde el costo se siente más porque las escalaciones aterrizan en la gente más experimentada.

Métrica de éxito

Rastrea el tiempo desde “escalación declarada” hasta “RCA circulado para sign-off interno”. La Skill debe jalar la mediana bajo 90 minutos dentro del primer trimestre de uso, contra una línea base desde cero de medio día o más. También rastrea la tasa a la que la causa raíz propuesta sobrevive la revisión del support lead sin cambios —apunta a 60% o más. Más bajo que eso y la taxonomía de causas necesita recortarse para coincidir con cómo fallan realmente tus incidentes; más alto que 85% y el lead probablemente está aprobando sin leer en vez de revisar, lo que derrota la guarda de human-in-the-loop.

Un segundo número que vale la pena observar: la proporción de acciones correctivas de RCAs pasados que de hecho fueron cerradas en su fecha de vencimiento. La Skill no fuerza esto —solo propone las acciones— pero si esa proporción se queda bajo 50%, el proceso de RCA es teatro y un motor de borrador más rápido no lo arreglará. La métrica te dice si la organización está actuando sobre las causas raíz o solo documentándolas.

Versus las alternativas

Versus un RCA manual en un Google Doc. El status quo de la mayoría de los equipos. Los RCAs manuales son de más fidelidad cuando el autor estuvo personalmente en el loop del incidente, porque llevan contexto que los sistemas nunca registraron —el hilo de Slack, la conversación de pasillo, la lectura visceral de la queja real del cliente. El trade-off es la hora-y-pico de ensamble de línea de tiempo, que es puro trabajo mecánico que la Skill elimina. Usa manual para la rara escalación de nivel de board donde cada palabra se pesa; usa la Skill para el volumen constante de escalaciones operacionales donde la restricción es el tiempo de IC senior, no el oficio narrativo. Incluso para el caso de nivel de board la línea de tiempo reconstruida de la Skill es un artifact de partida útil.

Versus las funciones nativas de merge de tickets y side-conversation de Zendesk. Zendesk puede vincular y fusionar tickets relacionados y mostrar una vista unificada, y si todo lo que necesitas es el historial de tickets consolidado eso es menos trabajo que instalar una Skill. Pero Zendesk muestra los tickets; no reconstruye una línea de tiempo cross-system que incluya llamadas de Gong, y no nombra una causa raíz ni propone acciones correctivas. Te da la materia prima; la Skill escribe el análisis. Usa el linking de Zendesk para mantener los tickets hermanos descubribles —la Skill depende de ese linking para encontrarlos— y la Skill para convertir el set vinculado en un RCA.

Versus una herramienta dedicada de gestión de incidentes (un incident.io o un FireHydrant). Estas son excelentes para respuesta a incidentes liderada por ingeniería con rotaciones on-call, status pages y andamiaje automatizado de postmortem. Si tus escalaciones son incidentes de infraestructura y ya corres una, usa su flujo de postmortem. Pero esas herramientas están construidas alrededor del ciclo de vida del incidente de ingeniería, no del de relación con el cliente; no leen tus llamadas de Gong ni escriben en la voz de cara al cliente de tu equipo de CSM. Para una escalación propiedad de CS que es tanto sobre una relación como sobre un defecto, esta Skill encaja en la costura que esas herramientas dejan abierta.

A vigilar

Sesgo de retrospectiva en la pasada causal. Leer una línea de tiempo hacia atrás desde un resultado conocido-malo hace que cada decisión anterior parezca un error obvio, y Claude lo narrará así si no está guardado. Guarda: la pasada uno está instruida para distinguir lo que era conocible en cada evento de lo que solo es conocible en retrospectiva, y para marcar cualquier afirmación que dependa de la retrospectiva. También devuelve insufficient data en vez de adivinar cuando existen menos de tres eventos de línea de tiempo dentro de la ventana —no se construye ninguna narrativa sobre una base demasiado delgada para soportar una.
Audit logs faltantes colapsan la línea de tiempo. Si el token de Zendesk carece de scope de lectura de audit, la Skill silenciosamente obtiene comentarios sin timestamps de cambio de estado, y la línea de tiempo pierde los eventos de “el ticket estuvo en pending por nueve días” que a menudo son la verdadera historia. Guarda: la Skill checa el acceso a audit en el ticket ancla durante la verificación de setup y rehúsa correr con un error ZENDESK_AUDIT_SCOPE_MISSING en vez de producir una línea de tiempo que omite los eventos más importantes.
Causa raíz confundida con el síntoma más ruidoso. El evento del que el cliente se quejó más rara vez es la causa raíz; usualmente es un síntoma downstream. Un modelo sin guarda se ancla en el volumen. Guarda: la taxonomía de causas en references/2-cause-taxonomy.md fuerza una sola categoría clasificada, y la pasada uno debe citar el evento específico de la línea de tiempo que es el punto más temprano en que la causa estuvo en juego —no el más ruidoso, el más temprano. Los síntomas que vinieron después se archivan como factores contribuyentes.
Sentimiento de Gong sobre-leído en transcripciones delgadas. Una sola llamada corta se sobrepondera como “el cliente está furioso” cuando la transcripción es un voicemail de 90 segundos. Guarda: la Skill limita la influencia de Gong en la pasada causal a evidencia corroborante —una llamada puede soportar un evento de línea de tiempo pero no puede por sí sola ser la causa raíz nombrada, porque una queja registrada es un síntoma, no una causa. Las transcripciones bajo 200 palabras se marcan como baja-confianza y se excluyen de la lectura de sentimiento.
Resumen de cara al cliente admitiendo responsabilidad que el equipo no ha acordado. La pasada dos escribe un resumen que el cliente puede leer, y un LLM dejado a su propio registro pedirá disculpas por cosas que la empresa no ha decidido poseer. Guarda: el prompt del resumen de cara al cliente nombra solo impacto y remediación, prohíbe explícitamente asignar culpa o prometer compensación, y prefija el párrafo con un marcador REVIEW BEFORE SENDING que el CSM debe quitar a mano —no hay camino donde el texto de cara al cliente salga de la Skill sin un toque humano.

Stack

Zendesk —hilo de tickets, tickets hermanos y los audit logs que llevan los timestamps de cambio de estado (REST API, read-only)
Gong —transcripciones y metadata de llamadas de la cuenta dentro de la ventana de escalación (Gong API, read-only)
Claude —análisis de dos pasadas: análisis causal contra la taxonomía, luego plan de acciones correctivas más tone-match (Sonnet recomendado por costo; Opus solo si el resumen de cara al cliente lleva sensibilidad inusual)

Editar esta página en GitHub