Um playbook de customer success é uma sequência definida e repetível de ações que um CSM roda quando um trigger específico dispara: um kickoff de onboarding, uma queda de uso, um sinal de expansão, uma renovação se aproximando. A unidade é o play: trigger → passos → owner → critério de sucesso → saída. Um playbook é a biblioteca de plays; um play é uma entrada. O ponto é converter o que o seu melhor CSM faz por instinto em algo que cada CSM executa da mesma forma, e que uma plataforma de CS consegue disparar automaticamente para que um humano só faça a parte que precisa de um humano.
O que um playbook não é: não é um documento de processo, e não é um artigo de help center. Um documento de processo descreve como o onboarding funciona em geral; um play diz “quando uma conta chega ao dia 14 com menos de 30% dos seats ativados, o CSM envia a sequência de ativação e agenda uma call de enablement de 30 minutos, e o play sai quando a ativação de seats cruza 60%”. Um play tem um trigger, uma saída mensurável e um owner. Se não tem, é documentação, não um play.
As quatro famílias de plays
A maioria das motions de CS se reduz a quatro famílias baseadas em triggers. Construa estas primeiro; todo o resto é uma variação.
- Plays de onboarding. Disparados por um deal closed-won ou uma data de go-live. Objetivo: levar o cliente ao primeiro valor (TTV) antes da lua de mel acabar. Passos: kickoff, definição do plano de sucesso, enablement, check-ins de marcos. Critério de sucesso: o cliente atinge o marco de ativação definido (seats ativos, primeiro workflow lançado, primeiro outcome realizado).
- Plays de risco. Disparados por uma queda de banda no health score (verde→amarelo, amarelo→vermelho), a saída de um champion, um declínio de uso, uma escalação de suporte, ou um sponsor que fica em silêncio. Objetivo: diagnosticar e intervir antes do sinal virar uma não-renovação. Critério de sucesso: o sinal que disparou o play se reverte (o uso se recupera, um novo champion é identificado).
- Plays de expansão. Disparados por um teto de utilização de seats, um sinal de novo caso de uso, um cluster de power-users se formando, ou uma data de ciclo de orçamento. Objetivo: rotear uma expansão qualificada para sales ou self-serve. Critério de sucesso: um CSQL (customer success qualified lead) é criado e aceito.
- Plays de renovação. Disparados por uma data de renovação menos um lead time (comumente 90/120/180 dias por banda de ACV). Objetivo: garantir a renovação no ARR atual ou acima. Critério de sucesso: renovação fechada, sem churn surpresa.
Como estruturar um play
Cada play tem os mesmos seis campos. Segure a linha nos seis: um play sem o critério de saída ou o owner é o que roda para sempre ou nunca completa.
| Campo | O que responde |
|---|---|
| Trigger | A condição exata que dispara o play (um limiar, uma data, um evento) |
| Filtro de segmento | A quais contas se aplica (banda de ACV, produto, região) |
| Passos | As ações ordenadas, cada uma marcada como humana ou automatizada |
| Owner | O papel único responsável (CSM, CS Ops, AE) |
| Critério de sucesso | A condição mensurável que encerra o play como vitória |
| Timeout / escalação | O que acontece se o critério não for atingido em N dias |
Um play de risco trabalhado, totalmente especificado:
Play: Queda de uso — mid-market
Trigger: weekly active users abaixo de >25% vs média de 4 semanas
Segment: ACV $25K-$100K
Steps: 1. [auto] alerta de Slack ao CSM owner + recálculo de health score
2. [humano] o CSM revisa o uso por feature, identifica a queda
3. [humano] o CSM envia email de re-engagement em 48h
4. [humano] agendar sessão de trabalho se não houver resposta em 5 dias
Owner: CSM
Success: weekly active users se recuperam para dentro de 10% da média anterior
Timeout: 14 dias → escalar para o CS manager, marcar para a pauta do QBR
O que automatizar vs. manter humano
A regra de automação: automatize a detecção do trigger e os passos de baixo julgamento; mantenha humanos os passos de relacionamento. Uma plataforma de CS (Gainsight, ChurnZero, Vitally, Catalyst) vigia os sinais e dispara o play: essa parte nunca deveria ser manual, porque vigiar sinais na mão é onde as contas escapam. Dentro do play, a divisão é por julgamento:
- Automatize: detecção de triggers, recálculo de health, roteamento de alertas, criação de tarefas, emails templatizados de baixo risco (nudges de onboarding, envios de pesquisas, follow-ups de NPS), higiene de dados.
- Mantenha humano: o diagnóstico (“por que o uso caiu?”), a conversa de renovação, o pitch de expansão, qualquer coisa onde uma mensagem automatizada errada danifica a confiança. Um play de conta vermelha deve criar uma tarefa e informar o CSM, não auto-enviar um email de “notamos que você está dando churn”.
Sequencie a construção: instrumente os triggers primeiro (você não consegue disparar um play em um sinal que não captura), depois escreva os plays, depois automatize os passos mecânicos óbvios, e por último coloque os passos pesados de julgamento só onde o template realmente segura.
Erros comuns
- Plays sem critério de saída. Um play que nunca completa de forma mensurável entope a lista de tarefas do CSM e treina a equipe a ignorar os plays. Guarda: cada play tem um único critério de sucesso mensurável e um timeout que escala; nada de “monitorar a conta” em aberto.
- Superautomação de momentos de relacionamento. Auto-enviar um email de renovação ou de save soa como uma carta de formulário justo no momento em que o cliente precisa se sentir visto. Guarda: classifique cada passo como humano ou automatizado de forma explícita; por padrão, as conversas de relacionamento e de dinheiro vão para humano.
- Um playbook para todos os segmentos. Uma conta SMB de 12 seats e uma enterprise de 4.000 seats precisam de lead times diferentes, owners diferentes e profundidade de passos diferente. Guarda: cada play carrega um filtro de segmento; mantenha lead times por segmento (os plays de renovação especialmente: 90 dias para SMB, 180 para enterprise).
- Proliferação de triggers. Cinquenta triggers sobrepostos disparam constantemente, o CSM se afoga em tarefas, e a qualidade dos plays colapsa em ruído. Guarda: coloque um teto de plays ativos por CSM e ajuste os limiares dos triggers contra a taxa histórica de disparo; se um trigger dispara em metade do book, está mal calibrado.
- Sem loop de feedback. Os plays são lançados uma vez e se ossificam enquanto a realidade deriva. Guarda: revise as taxas de vitória dos plays trimestralmente (critério de sucesso atingido dentro do timeout / disparos totais); aposente os plays abaixo de ~30% de taxa de vitória e re-especifique o trigger.
Quando o framework quebra
Playbooks pressupõem volume suficiente para que a repetibilidade compense. Um book puro de high-touch de 8-12 contas estratégicas a $1M+ de ACV cada uma não roda plays: roda planos de conta sob medida, e forçar esses CSMs a uma biblioteca de plays adiciona overhead sem nenhum ganho. O modelo de playbook ganha o seu lugar nas bandas de tech-touch e mid-touch onde um CSM tem 40-200 contas e a restrição é a consistência, não a personalização.
Relacionados
- Customer health score — a camada de sinal sobre a qual a maioria dos plays de risco e renovação dispara
- Customer onboarding — a família de plays com o TTV mais em jogo
- Customer churn e expansion revenue — o que os plays de risco e expansão existem para mover
- Gainsight e ChurnZero — plataformas com automação nativa de playbooks