ooligo
TIPO · framework

Playbook de customer success

Por Marius Bughiu Última atualização 2026-06-06 Customer Success

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.

CampoO que responde
TriggerA condição exata que dispara o play (um limiar, uma data, um evento)
Filtro de segmentoA quais contas se aplica (banda de ACV, produto, região)
PassosAs ações ordenadas, cada uma marcada como humana ou automatizada
OwnerO papel único responsável (CSM, CS Ops, AE)
Critério de sucessoA condição mensurável que encerra o play como vitória
Timeout / escalaçãoO 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