SOP de playbook de churn-save

La mayoría de los equipos de CS se enteran de que una cuenta se va cuando el renewal no cierra. Para entonces la ventana de salvación lleva meses cerrada. El arreglo no es un mejor health score —es una motion fija que se dispara en el momento en que un score cruza un umbral, para que el CSM esté interviniendo en la semana uno de la caída en vez de reaccionar en los últimos 30 días antes del renewal. Este SOP es esa motion: un trigger, un paso de diagnóstico, una intervención por niveles, una regla de escalamiento y un requisito de documentación que corre igual para cada cuenta en riesgo. Es deliberadamente rígido. Una motion de salvación que depende de que cada CSM improvise la jugada correcta cuando una cuenta se pone roja es una motion que funciona para tu mejor CSM y falla para todos los demás.

El bundle del artifact vive en apps/web/public/artifacts/churn-save-playbook-sop/. Incluye churn-save-sop.md (el procedimiento, listo para pegar en Notion o en una base de conocimiento de Gainsight), save-plan-template.md (el doc estructurado de plan de salvación que el CSM llena por cuenta) y slack-escalation-template.md (la alerta canónica que el CSM publica cuando una cuenta escala). Adapta los tres a tus nombres de score, bandas de segmento y convenciones de canal antes del rollout.

Cuándo usarlo

Usa este SOP cuando corres un health score en Gainsight (o un CSP comparable) en el que confías lo suficiente como para actuar, y todavía no tienes una motion escrita y enforzada para lo que pasa cuando una cuenta se pone roja. El síntoma clásico es una salvación que funcionó porque un CSM la atrapó temprano y supo a quién llamar —y al trimestre siguiente una cuenta idéntica hace churn porque un CSM distinto vio el mismo flag rojo y esperó al QBR. El score está haciendo su trabajo; la respuesta al score es el gap que esto cierra.

Encaja mejor para equipos en el rango de 100 a 2,000 clientes con un health score definido, una estructura de book de CSM y un líder de CS que pueda dueñar los escalamientos. Por debajo de ~100 cuentas un CSM lee cada cuenta directamente y una motion documentada es overhead. Por encima de ~2,000 probablemente quieres la motion de salvación manejada por un CTA de Gainsight con routing nativo y tracking de SLA en vez de un post de Slack y un doc compartido —a esa escala los pasos manuales son los que se saltan. Este SOP es la herramienta correcta en la banda donde la motion importa pero el playbook vive en la cabeza de la gente.

Cuándo NO usarlo

No lo adoptes si no confías en tu health score. Una motion de salvación disparada por un score que se pone rojo por ruido de tagging o un solo login perdido entrena a los CSMs a ignorar el trigger en menos de un mes. Arregla el score primero —el health score compuesto en n8n y el constructor de health score de CS existen para eso— y luego pon esta motion encima. Una motion precisa sobre un trigger ruidoso es peor que ninguna motion, porque quema la confianza del equipo en la única señal que necesitas que accionen.

No lo uses como herramienta de forecasting de renewal. Este SOP está acotado a la salvación: una cuenta que estaba sana y ahora se desliza, donde la meta es revertir la caída antes de que llegue al renewal. Una cuenta que siempre se iba a ir por una razón que ningún CSM puede mover —el comprador se fue, la empresa fue adquirida, el caso de uso murió— no es candidata a salvación, y forzarla por la motion desperdicia las horas del CSM en una pérdida determinista. El paso de diagnóstico existe en parte para tomar esa decisión temprano.

No lo corras sin un líder de CS que tome los escalamientos. El nivel de escalamiento es portante: el punto entero es que una cuenta pasado un límite de severidad deja de ser problema de un solo CSM y pasa a ser del equipo. Si los escalamientos van a un canal que nadie dueña, la motion se degrada a la misma improvisación que pretendía reemplazar.

El trigger

La motion se dispara con un evento de score de Gainsight, no con la corazonada de un CSM ni con el calendario. Dos triggers, cualquiera de los dos arranca el reloj:

• Caída de banda a rojo —el health score compuesto cruza de amarillo a rojo (en el scoring de referencia, compuesto bajo 50). Este es el trigger primario.
• Delta negativo grande dentro de una banda —una caída de 15 puntos o más en un solo ciclo de scoring, aun si la cuenta sigue técnicamente en amarillo. Una caída de verde a amarillo-medio es a menudo una señal más aguda que un rojo estable, porque es nueva y la causa es lo bastante reciente como para ser todavía reversible.

Gainsight dispara un CTA en cualquiera de las dos condiciones; la asignación del CTA es el CSM de record. El SLA: el CSM abre un plan de salvación dentro de los dos días hábiles del trigger. Atar el arranque al evento de score en vez de a una revisión semanal es el punto entero —una revisión se reagenda; un CTA con un SLA se trackea.

La motion

1. Diagnostica (para el día 2). Antes de cualquier outreach, el CSM llena la sección de diagnóstico de save-plan-template.md: qué sub-score se movió (uso, actividad, sentiment), el número concreto y su baseline, y una hipótesis de una línea para la causa. La hipótesis se fuerza a uno de un conjunto fijo —estancamiento de adopción, cambio de champion, valor no realizado, desplazamiento competitivo, presupuesto/económico o gap de producto— porque la clase de causa determina la jugada. Un diagnóstico de “parecen infelices” se rechaza; el CSM nombra el sub-score y la clase probable o marca “causa desconocida, requiere llamada de investigación”.
2. Interviene (para el día 5), por niveles según la causa. Estancamiento de adopción → una sesión de trabajo sobre la feature sin usar, no un check-in. Cambio de champion → una motion de introducción para mapear y ganar al nuevo stakeholder antes que nada. Valor no realizado → jala el success plan y el “por qué compraron” original, y agenda una revisión de valor contra la métrica que definieron en el deal. Desplazamiento competitivo → involucra al AE y, si se justifica, escala de inmediato. Presupuesto/económico → una conversación comercial que el CSM puede no dueñar solo. Gap de producto → regístralo, fija expectativas con honestidad y no prometas una fecha de roadmap que el CSM no pueda cumplir. La plantilla carga una jugada default por clase para que el CSM esté eligiendo la variación, no inventando la jugada.
3. Escala (cuando se cruza el límite de severidad). Una cuenta escala fuera de la motion de un solo CSM cuando cualquiera de: está en rojo Y por encima de un umbral de ingreso que el equipo fija (ej. ARR del cuartil superior), la causa es desplazamiento competitivo, o el plan de salvación lleva 30 días sin recuperación de banda. El escalamiento publica en #cs-saves usando slack-escalation-template.md —cuenta, ARR, fecha de renewal, sub-score que se movió con su número, clase de causa, la jugada corrida hasta ahora y el pedido específico al liderazgo. El líder de CS reconoce en el hilo dentro de un día hábil y asigna un exec sponsor o AE si el pedido lo amerita.
4. Documenta (continuamente, y al cierre). Cada plan de salvación registra el trigger, el diagnóstico, la jugada y el resultado —salvada, churneada o degradada— encadenado a la clase de causa. Esta es la mitad de la motion que compone: después de un trimestre puedes leer qué clases de causa realmente salvas y cuáles no, y re-apuntar las horas del CSM a las salvables. Una salvación que no se documenta no le enseña nada al equipo.

Cómo se ve el éxito

Rastrea cuatro números. Primero, tiempo de trigger-a-primer-contacto —días desde que el CTA de Gainsight se dispara hasta la primera acción de salvación registrada. El SLA de dos días hábiles debería llevar la mediana bajo dos días dentro de un mes; un retraso mayor significa que el CTA se dispara hacia una cola que nadie trabaja. Segundo, tasa de salvación por clase de causa —de las cuentas que entraron a la motion, el porcentaje que se recuperó a amarillo-o-mejor y renovó, dividido por la causa diagnosticada. Este es el número que te dice dónde la motion gana su sustento; espera que las salvaciones de estancamiento de adopción corran bastante por encima de las de desplazamiento competitivo, y dota personal en consecuencia. Tercero, precisión de escalamiento —de las cuentas escaladas, el porcentaje donde la participación del liderazgo plausiblemente cambió el resultado. Si la mayoría de los escalamientos se habrían resuelto sin liderazgo, el límite de severidad está fijado muy bajo y estás cobrándole impuestos al líder de CS. Cuarto, tasa de atrapado-a-tiempo —de las cuentas que hicieron churn, el porcentaje que alguna vez entró a la motion de salvación. Una alta tasa de churn-sin-plan-de-salvación significa que el trigger no atrapa las caídas lo bastante temprano, lo que te manda de vuelta al score, no a la motion.

Versus las alternativas

Versus una salvación ad-hoc corrida desde el ciclo de QBR. El status quo en la mayoría de los equipos es que el riesgo aflora en la revisión trimestral y el CSM improvisa una respuesta. No cuesta nada montarlo y pierde en timing y consistencia: el QBR puede ser 80 días después de que empezó la caída, y la calidad de la respuesta oscila con qué CSM dueña la cuenta. Este SOP cuesta el montaje de un CTA de Gainsight y tres plantillas y mueve la respuesta a dentro de una semana del trigger. Elige la versión ad-hoc solo si tu conteo de cuentas es lo bastante bajo (bajo ~100) como para que un CSM lea cada cuenta semanalmente de todos modos.

Versus un Playbook / CTA de Gainsight construido de forma nativa, sin un SOP escrito detrás. Gainsight puede disparar el CTA y adjuntar un checklist de tareas, y a escala ese es el mecanismo de entrega correcto. Pero un checklist de CTA sin la lógica de diagnóstico-a-jugada detrás produce teatro de completar-tareas —el CSM marca las casillas y aun así improvisa la salvación real. Usa el CTA de Gainsight como el trigger y el timer de SLA, y usa las clases de diagnóstico y jugadas por niveles de este SOP como el contenido al que el CTA enlaza. Los dos son complementarios: Gainsight es la mecánica, el SOP es el juicio.

Versus no hacer nada estructurado. Viable solo si tu churn genuinamente no es accionable por CS —una motion pura de PLG sin toque humano, o un segmento donde las salvaciones nunca pagan las horas del CSM. Para cualquier equipo con un renewal manejado por relación, la respuesta no estructurada a una cuenta roja es la única fuente más grande de churn prevenible: la salvación que un CSM habría hecho y otro perdió, decidida por quién resultó dueñar la cuenta.

A vigilar

• El trigger se dispara por ruido de score. Si el health score se pone rojo por tagging de uso inconsistente o una sola semana tranquila, el CSM trabaja un no-problema y aprende a desconfiar del CTA. Guarda: condiciona el trigger al compuesto, no a un solo sub-score, y exige que el trigger de delta grande persista a través de dos ciclos de scoring antes de disparar un CTA —un blip de una noche se autocorrige y nunca llega a la cola del CSM.
• El diagnóstico colapsa en una etiqueta genérica de “en riesgo”. Si el paso de diagnóstico es opcional o de texto libre, los CSMs lo saltan y brincan a una llamada de check-in, que es la jugada para toda causa y la jugada correcta para ninguna. Guarda: el plan de salvación no avanza al paso de intervenir hasta que se seleccione una clase de causa de la lista fija o se elija “causa desconocida” explícitamente con una llamada de investigación agendada —la clase es lo que selecciona la jugada.
• Escalamiento como basurero. Si escalar es más fácil que correr la jugada, los CSMs escalan todo y el líder de CS se vuelve el cuello de botella. Guarda: la plantilla de escalamiento exige el campo de jugada-corrida-hasta-ahora y un pedido específico antes de publicar; un escalamiento sin jugada previa y sin pedido concreto es devuelto al CSM en el hilo por el líder de CS.
• Salvaciones que no se documentan al cierre. Un CSM que salva una cuenta y sigue adelante sin registrar la causa y la jugada no le enseña nada al equipo, y la siguiente caída idéntica se improvisa desde cero. Guarda: el CTA de Gainsight no cierra hasta que el campo de resultado (salvada / churneada / degradada) y la clase de causa estén fijados, así cada plan de salvación cerrado alimenta el reporte de tasa-de-salvación-por-causa.
• La motion sobrevive al score con el que fue afinada. Un health score re-ponderado o un sub-score renombrado rompe silenciosamente los umbrales del trigger y las referencias de sub-score del diagnóstico. Guarda: revisa los umbrales del trigger en el CTA de Gainsight y los nombres de sub-score en save-plan-template.md contra el score en vivo una vez por trimestre, en la misma revisión que re-afina los pesos del score.

Stack

• Gainsight —el health score, el CTA que dispara el trigger, el timer de SLA y el reporte de resultados por-causa
• Slack —el canal de escalamiento #cs-saves y el hilo de reconocimiento del líder
• El doc de plan de salvación —save-plan-template.md, almacenado donde tu equipo guarde los docs de cuenta (Gainsight, Notion o un custom object de Salesforce), una sola ubicación canónica por cuenta