Playbook de customer success

Un playbook de customer success es una secuencia definida y repetible de acciones que un CSM corre cuando se dispara un trigger específico: un kickoff de onboarding, una caída de uso, una señal de expansión, una renovación que se acerca. La unidad es el play: trigger → pasos → owner → criterio de éxito → salida. Un playbook es la biblioteca de plays; un play es una entrada. El punto es convertir lo que tu mejor CSM hace por instinto en algo que cada CSM ejecuta de la misma forma, y que una plataforma de CS puede disparar automáticamente para que un humano solo haga la parte que necesita un humano.

Lo que un playbook no es: no es un documento de proceso, y no es un artículo del help center. Un documento de proceso describe cómo funciona el onboarding en general; un play dice “cuando una cuenta llega al día 14 con menos del 30% de los seats activados, el CSM envía la secuencia de activación y agenda una llamada de enablement de 30 minutos, y el play sale cuando la activación de seats cruza el 60%”. Un play tiene un trigger, una salida medible y un owner. Si no los tiene, es documentación, no un play.

Las cuatro familias de plays

La mayoría de las motions de CS se reducen a cuatro familias basadas en triggers. Construye estas primero; todo lo demás es una variación.

• Plays de onboarding. Disparados por un deal closed-won o una fecha de go-live. Objetivo: llevar al cliente al primer valor (TTV) antes de que termine la luna de miel. Pasos: kickoff, definición del plan de éxito, enablement, check-ins de hitos. Criterio de éxito: el cliente alcanza el hito de activación definido (seats activos, primer workflow lanzado, primer outcome realizado).
• Plays de riesgo. Disparados por una caída de banda en el health score (verde→amarillo, amarillo→rojo), la salida de un champion, un declive de uso, una escalación de soporte, o un sponsor que se queda en silencio. Objetivo: diagnosticar e intervenir antes de que la señal se vuelva una no-renovación. Criterio de éxito: la señal que disparó el play se revierte (el uso se recupera, se identifica un nuevo champion).
• Plays de expansión. Disparados por un techo de utilización de seats, una señal de nuevo caso de uso, un cluster de power-users que se forma, o una fecha de ciclo de presupuesto. Objetivo: rutear una expansión calificada a sales o a self-serve. Criterio de éxito: se crea y se acepta un CSQL (customer success qualified lead).
• Plays de renovación. Disparados por una fecha de renovación menos un lead time (comúnmente 90/120/180 días por banda de ACV). Objetivo: asegurar la renovación al ARR actual o por encima. Criterio de éxito: renovación cerrada, sin churn sorpresa.

Cómo estructurar un play

Cada play tiene los mismos seis campos. Aguanta la línea en los seis: un play al que le falta el criterio de salida o el owner es el que corre para siempre o nunca se completa.

Un play de riesgo trabajado, totalmente especificado:

Play: Caída de uso — mid-market
Trigger:   weekly active users abajo >25% vs promedio de 4 semanas
Segment:   ACV $25K-$100K
Steps:     1. [auto] alerta de Slack al CSM owner + recálculo de health score
           2. [humano] el CSM revisa el uso por feature, identifica la caída
           3. [humano] el CSM envía email de re-engagement en 48h
           4. [humano] agendar sesión de trabajo si no hay respuesta en 5 días
Owner:     CSM
Success:   weekly active users se recuperan a dentro del 10% del promedio previo
Timeout:   14 días → escalar al CS manager, marcar para agenda de QBR

Qué automatizar vs. mantener humano

La regla de automatización: automatiza la detección del trigger y los pasos de bajo juicio; mantén humanos los pasos de relación. Una plataforma de CS (Gainsight, ChurnZero, Vitally, Catalyst) vigila las señales y dispara el play: esa parte nunca debería ser manual, porque vigilar señales a mano es donde se escapan las cuentas. Dentro del play, la división es por juicio:

• Automatiza: detección de triggers, recálculo de health, ruteo de alertas, creación de tareas, emails templatizados de bajo riesgo (nudges de onboarding, envíos de encuestas, follow-ups de NPS), higiene de datos.
• Mantén humano: el diagnóstico (“¿por qué cayó el uso?”), la conversación de renovación, el pitch de expansión, cualquier cosa donde un mensaje automatizado equivocado daña la confianza. Un play de cuenta roja debe crear una tarea e informar al CSM, no auto-enviar un email de “notamos que estás haciendo churn”.

Secuencia la construcción: instrumenta los triggers primero (no puedes disparar un play con una señal que no capturas), luego escribe los plays, luego automatiza los pasos mecánicos obvios, y por último mete los pasos pesados en juicio solo donde el template aguanta de verdad.

Errores comunes

• Plays sin criterio de salida. Un play que nunca se completa de forma medible llena la lista de tareas del CSM y entrena al equipo a ignorar los plays. Guardia: cada play tiene un único criterio de éxito medible y un timeout que escala; nada de “monitorear la cuenta” abierto.
• Sobre-automatización de momentos de relación. Auto-enviar un email de renovación o de save se lee como una carta forma justo en el momento en que el cliente necesita sentirse visto. Guardia: clasifica cada paso como humano o automatizado de forma explícita; por defecto, las conversaciones de relación y de dinero van a humano.
• Un playbook para todos los segmentos. Una cuenta SMB de 12 seats y una enterprise de 4,000 seats necesitan distintos lead times, distintos owners y distinta profundidad de pasos. Guardia: cada play lleva un filtro de segmento; mantén lead times por segmento (los plays de renovación especialmente: 90 días para SMB, 180 para enterprise).
• Proliferación de triggers. Cincuenta triggers superpuestos disparan constantemente, el CSM se ahoga en tareas, y la calidad de los plays colapsa en ruido. Guardia: pon un tope de plays activos por CSM y ajusta los umbrales de los triggers contra la tasa histórica de disparo; si un trigger se dispara en la mitad del book, está mal calibrado.
• Sin loop de feedback. Los plays se lanzan una vez y se osifican mientras la realidad deriva. Guardia: revisa las tasas de victoria de los plays trimestralmente (criterio de éxito cumplido dentro del timeout / disparos totales); retira los plays por debajo de ~30% de tasa de victoria y re-especifica el trigger.

Cuándo el framework se rompe

Los playbooks asumen suficiente volumen para que la repetibilidad valga la pena. Un book puro de high-touch de 8-12 cuentas estratégicas a $1M+ de ACV cada una no corre plays: corre planes de cuenta a la medida, y forzar a esos CSMs a una biblioteca de plays agrega overhead sin ningún beneficio. El modelo de playbook gana su lugar en las bandas de tech-touch y mid-touch donde un CSM tiene 40-200 cuentas y la restricción es la consistencia, no la personalización.

Relacionados

• Customer health score — la capa de señal sobre la que disparan la mayoría de los plays de riesgo y renovación
• Customer onboarding — la familia de plays con el TTV más en juego
• Customer churn y expansion revenue — lo que los plays de riesgo y expansión existen para mover
• Gainsight y ChurnZero — plataformas con automatización nativa de playbooks