La mayoría de los postmortems de churn se escriben una vez, los lee nadie, y agregan a “se fue el champion, gap de producto, pricing” porque eso es a lo que las notas de texto libre del CSM siempre se reducen cuando las grepeas a fin de trimestre. Este workflow entrega una Claude Skill que toma una cuenta que churneó y produce un análisis estructurado de causa raíz: una línea de tiempo de 180 días, un análisis en dos pasadas evidencia-luego-clasifica, una categorización contra una taxonomía fija, y una recomendación de prevención elegida desde una librería fija. El output es lo suficientemente consistente entre CSMs como para que RevOps pueda agregarlo trimestralmente sin recodificar nada.
El bundle del artifact vive en apps/web/public/artifacts/churn-analysis-skill/. Contiene SKILL.md (la Claude Skill en sí, con soft-wrap, con secciones explícitas de when-to-invoke y watch-outs), references/1-churn-taxonomy.md (las 5-10 categorías que tu equipo está autorizado a asignar), references/2-prevention-action-library.md (el menú de acciones de prevención que la Skill está autorizada a recomendar), y references/3-sample-output.md (la forma literal del markdown para que los revisores sepan qué van a recibir).
Cuándo usarlo
Corre esta Skill una vez por cada churn confirmado, después de que el evento de close-lost o no-renovación esté registrado en el CRM y el CSM haya tenido al menos 24 horas para agregar sus notas finales. El output es un documento de post-mortem que el CSM revisa, RevOps guarda en un folder compartido de Notion o Drive, y leadership agrega a fin de trimestre para detectar patrones a través de las categorías.
La población correcta es cuentas mid-market y enterprise donde el contract value es lo suficientemente grande como para justificar un ciclo de revisión de 30 minutos y donde los datos de timeline son lo suficientemente ricos como para analizarse (eventos de CRM, health scores, casos de soporte, idealmente llamadas de Gong). Por debajo de ~$25k ARR, la relación entre el costo del análisis y los aprendizajes cae por debajo de la línea.
Cuándo NO usarlo
Sáltate esta Skill en cuatro casos, cada uno tiene una respuesta correcta distinta:
- Scoring de riesgo preventivo sobre cuentas saludables. Usa un modelo de health-score o una Skill separada de risk-scoring. Correr esta Skill con forma de post-mortem hacia adelante — sobre una cuenta viva que no ha churneado — ancla al CSM en una narrativa de churn y sesga su próxima conversación.
- Predicción de churn en tiempo real durante un ciclo de renovación. Mismo problema. El análisis de timeline en dos pasadas asume que el resultado es fijo; usarlo hacia adelante genera señales de falsa confianza.
- Análisis de win/loss sobre new logos cerrados-perdidos. Esos necesitan un encuadre distinto — narrativa del deal, desplazamiento por competidor, fit con ICP — y una taxonomía distinta. Usa una Skill separada de win-loss en vez de forzar categorías de churn sobre un deal que nunca arrancó.
- Explicaciones de evento único que el CSM ya sabe. Si ya sabes “se fue el champion y no hubo reemplazo”, edita el campo del CRM directamente. Esta Skill es para los casos donde el CSM aún no puede atribuir limpiamente el churn, o donde el equipo necesita una forma estructurada para agregar de todos modos.
Setup
- Define la taxonomía. Edita
references/1-churn-taxonomy.mdcon las 5-10 categorías de causa raíz de tu equipo. La plantilla viene conproduct-gap,champion-departure,pricing,consolidation,service-failure,adoption-failure,restructure, ycompetitive-displacement. Aprieta el requisito de evidencia en cada slug para que coincida con qué tan estricto quiere ser tu equipo — esos requisitos son los que la pasada de clasificación impone. Mantén la lista en 10 o menos; el punto entero es la agregación. - Llena la librería de prevención. Edita
references/2-prevention-action-library.md. La Skill está restringida a elegir una acción de este archivo por análisis — no puede inventar una nueva. La plantilla cubre las ocho comunes (detección de cambio de sponsor, alertas de salud, escalación sobre patrones sev-1, etc.). Agrega las jugadas de tu equipo. - Instala la Skill. Pega el bundle en
~/.claude/skills/churn-analysis/. ConfiguraHUBSPOT_TOKENyGAINSIGHT_TOKENcomo variables de entorno. Si usas Gong, configuraGONG_API_KEYpara que la pasada de evidencia pueda traer transcripts de llamadas; de lo contrario la Skill corre sin evidencia de Gong y nota ese gap en el output. - Córrelo sobre el churn. Desde Claude Code:
analyze_churn(account_id="HUB-5523-ACME", churn_date="2026-04-15", taxonomy="churn-taxonomy"). La Skill trae la línea de tiempo de 180 días, corre las dos pasadas y emite el análisis estructurado a stdout (o a./out/churn-{account_id}-{YYYY-MM-DD}.mdsi configurasCHURN_OUT_DIR). - Enrutar a revisión del CSM. El output termina con un checklist de cuatro ítems que el CSM completa: confirmar que el análisis se leyó, corregir errores factuales, confirmar o anular la clasificación (el juicio del CSM gana), y aceptar/modificar/rechazar la recomendación de prevención con una razón.
Lo que la Skill realmente hace
Cuatro pasos, en este orden, con las decisiones de ingeniería a las que el bundle se compromete.
Paso 1 — construir la línea de tiempo de 180 días. Traer los deltas de health-score, los cambios de contacto (con fechas de salida en LinkedIn cuando el CRM se queda atrás), casos de soporte, resúmenes de llamadas de Gong, métricas de uso de producto y resultados de QBR. Anclar en churn_date - 180 days. Si existen menos de 3 eventos de timeline dentro de los 30 días inmediatamente anteriores a churn_date, la Skill devuelve el estatus literal insufficient data — fewer than 3 timeline events in the 30-day pre-churn window; manual CSM postmortem required y se detiene. Líneas de tiempo cortas y dispersas invitan a narrativas con sesgo de retrospectiva que se leen confiadas pero no sobreviven a la revisión.
Paso 2 — pasada de evidencia. Una primera pasada de Claude que SOLO extrae evidencia: citas textuales, extractos de tickets, deltas de métricas con su fuente (CRM, Gainsight, Zendesk, Gong) y fecha. Sin clasificación, sin recomendación de prevención. El output es una lista plana de filas de evidencia que se mantiene como artefacto intermedio.
Paso 3 — pasada de clasificación. Una segunda pasada de Claude que recibe la lista de evidencia y la taxonomía y nada más. El diseño de dos pasadas es la decisión explícita de ingeniería: un modelo de una sola pasada confunde “qué pasó” con “a qué categoría pertenece esto”, lo que sesga la selección de evidencia hacia cualquiera que sea la categoría que el modelo ya sospecha. Forzar a que la pasada de clasificación trabaje desde una lista de evidencia congelada es la guardia contra eso. La pasada asigna una categoría primaria y hasta dos categorías contribuyentes — estrictamente desde la taxonomía, sin etiquetas nuevas — y cita las filas de evidencia que respaldan cada asignación. Si ninguna categoría supera 3 filas de evidencia, la primaria se convierte en insufficient-evidence.
Paso 4 — recomendación de prevención. Lee la librería de acciones de prevención. Elige UNA acción que, si hubiera estado en marcha 60 días antes de la fecha del churn, habría sacado a la superficie la causa raíz primaria como una señal observable. La Skill no puede inventar una nueva acción — si ninguna entrada de la librería encaja, devuelve no library match — prevention action requires human design y un humano extiende la librería de manera deliberada.
La forma de dos pasadas y la restricción de la librería son las partes que importan. La mayoría de los análisis de churn ad-hoc fallan no porque el modelo no pueda razonar sobre la evidencia — fallan porque al modelo se le permite razonar sobre evidencia, categoría y recomendación en una sola respiración, lo que deja que gane la narrativa que suene más plausible sin importar qué tan delgada sea.
Realidad de costos
Un análisis individual corre con ~12k tokens de input (línea de tiempo de 180 días más archivos de referencia más notas del CSM) y ~3k tokens de output. Sobre Claude Sonnet eso cae en aproximadamente $0,05 por análisis. Sobre Opus cae en ~$0,30. Un equipo corriendo 40 churns por trimestre paga $2 a $12 por trimestre en costos de modelo.
La cuenta del tiempo es el número más interesante. Un postmortem escrito por un CSM toma 45-90 minutos para una cuenta significativa y se saltea por completo en cuentas más pequeñas. La Skill produce un borrador revisable en ~3 minutos; la revisión del CSM toma ~15 minutos. Neto: ~30 minutos ahorrados por análisis, más cobertura que se extiende a cuentas que antes no recibían postmortem alguno. Para un equipo de 8 CSMs manejando 40 churns por trimestre, eso es aproximadamente 20 horas de tiempo de CSM liberadas por trimestre, más ~2x la cobertura de postmortem.
El costo que no aparece en la factura es el trabajo de curación de taxonomía y librería: espera 4-6 horas al inicio para llenar ambos archivos de referencia con entradas específicas del equipo, luego ~1 hora por trimestre para revisar los casos de insufficient-evidence y decidir si extender alguno de los dos archivos. Sáltate la curación y la Skill produce output genérico que agrega mal.
Métrica de éxito
La métrica agregada que vigilar trimestralmente: porcentaje de churns con una causa raíz categorizada defendible que el CSM no anuló en la revisión. Apunta a 70-80% en estado estacionario. Arriba de 90% sugiere que la taxonomía se volvió demasiado permisiva (demasiadas categorías, requisitos de evidencia demasiado flojos) — Claude está encontrando una etiqueta para todo porque las cubetas son anchas. Por debajo de 60% sugiere que los datos de timeline son demasiado delgados o que la taxonomía no coincide con las formas reales de churn que el equipo ve.
La contra-métrica diagnóstica: porcentaje de retornos insufficient-evidence y no library match. Estos no son fallas — son la Skill siendo honesta. Su tendencia al alza significa gaps de instrumentación (más cuentas con líneas de tiempo delgadas) o gaps de librería (más formas de churn para las cuales el equipo aún no codificó una jugada de prevención). Ambas son señales útiles para actuar de manera deliberada.
vs alternativas
- vs. los Churn Dashboards de Gainsight. Gainsight es excelente en la capa descriptiva — health scores, eventos de timeline, qué pasó cuándo. Es débil en la capa analítica: extraer evidencia de llamadas de Gong y notas de CSM no estructuradas, luego clasificar contra una taxonomía del equipo. La Skill no reemplaza a Gainsight; consume datos de Gainsight y agrega la capa de clasificación estructurada que Gainsight no produce nativamente.
- vs. postmortems escritos manualmente por CSMs. El default actual para la mayoría de los equipos. Mayor calidad por postmortem cuando el CSM está invertido, pero inconsistente entre CSMs, frecuentemente saltado en cuentas más pequeñas, e inútil para agregación trimestral porque la forma de texto libre de cada CSM es ligeramente distinta. La Skill produce un borrador lo suficientemente consistente como para agregar; la revisión del CSM mantiene la barra de calidad.
- vs. Catalyst, ChurnZero, y otras plataformas de CS con flujos de postmortem nativos. Esas entregan plantillas estructuradas que el CSM llena. Resuelven el problema de consistencia pero no el problema de extracción de evidencia — el CSM aún tiene que leer 180 días de llamadas y notas él mismo. La Skill hace la lectura; el CSM hace el juicio.
La Skill es más adecuada para equipos que ya tienen Gainsight o instrumentación equivalente de timeline, quieren la propiedad de agregación estructurada, y tienen la disciplina para curar los archivos de taxonomía y librería. Los equipos sin instrumentación de timeline deberían arreglar eso primero; la Skill está downstream de tener los datos.
Cuidados
- Sesgo de retrospectiva. Es trivial construir una narrativa limpia después del hecho, especialmente con 180 días de timeline. Guardia: la pasada de evidencia (paso 2) está estructuralmente separada de la pasada de clasificación (paso 3), y la pasada de clasificación se rehúsa a asignar una categoría sin al menos 3 filas de evidencia que citen explícitamente fechas y fuentes. El cortocircuito de
insufficient dataal final del paso 1 (menos de 3 eventos de timeline en la ventana de 30 días pre-churn) es la segunda guardia. El juicio del CSM gana en la revisión y el override queda registrado. - Creep de taxonomía. La tentación después de cada análisis es agregar una nueva categoría que capture el sabor único de este churn. Guardia: la pasada de clasificación está restringida al archivo de taxonomía existente y rechaza etiquetas nuevas — la Skill devuelve
insufficient-evidenceen vez de acuñar una nueva categoría. Las nuevas categorías requieren una edición deliberada dereferences/1-churn-taxonomy.mdfuera de la Skill, con tres churns históricos que habrían encajado, antes de que se agreguen. - Sobre-atribución a la salida del champion. “Se fue el champion” es la narrativa más fácil y la categoría más sobreusada en postmortems de CSM sin asistencia. Guardia: el slug
champion-departurerequiere o una fecha de salida en LinkedIn O un registro de cambio de contacto en CRM con fecha dentro de 90 días del churn — la pasada de clasificación no la asignará sobre una señal solo de Gong. - Atribución alucinada desde datos dispersos. Líneas de tiempo cortas invitan a ficción confiada. Guardia: el mínimo de ventana de 30 días / 3 eventos al final del paso 1 cortocircuita el análisis con
insufficient dataen vez de producir un output pulido que no merece existir. Esta guardia intencionalmente se activa más seguido de lo que se siente cómodo — esa es la señal de que la instrumentación de timeline necesita trabajo, no de que la guardia es demasiado estricta. - Recomendación de prevención como ejercicio de creatividad. Cada recomendación a medida hace inútil el agregado trimestral. Guardia: el paso 4 elige del archivo de librería fija y se rehúsa a inventar. Si ninguna entrada encaja, la Skill lo dice y un humano diseña la nueva entrada deliberadamente, con un trigger detectable mecánicamente y un único dueño nombrado.
Stack
- HubSpot — registro de churn, historial de contactos, razones de close-lost del deal
- Gainsight — health scores, eventos de timeline, hitos del success-plan
- Gong — transcripts de llamadas para la pasada de evidencia (opcional pero mejora materialmente la calidad del output)
- Claude — síntesis de timeline, extracción de evidencia, clasificación contra taxonomía
- Notion o Google Drive — almacenamiento para los análisis revisados, organizados por trimestre para la revisión agregada