A maioria dos times de CS descobre que uma conta está saindo quando o renewal não fecha. A essa altura a janela de save já está fechada há meses. A solução não é um health score melhor —é uma motion fixa que dispara no momento em que um score cruza um threshold, para que o CSM esteja intervindo na semana um da queda em vez de reagir nos últimos 30 dias antes do renewal. Este SOP é essa motion: um trigger, um passo de diagnóstico, uma intervenção em níveis, uma regra de escalation e um requisito de documentação que roda igual para cada conta em risco. É deliberadamente rígido. Uma motion de save que depende de cada CSM improvisar a jogada certa quando uma conta fica vermelha é uma motion que funciona para o seu melhor CSM e falha para todos os outros.

O bundle do artifact fica em apps/web/public/artifacts/churn-save-playbook-sop/. Ele entrega churn-save-sop.md (o procedimento, pronto para colar no Notion ou numa base de conhecimento do Gainsight), save-plan-template.md (o doc estruturado de plano de save que o CSM preenche por conta) e slack-escalation-template.md (o alerta canônico que o CSM publica quando uma conta escala). Adapte os três aos seus nomes de score, faixas de segmento e convenções de canal antes do rollout.

Quando usar

Use este SOP quando você roda um health score no Gainsight (ou um CSP comparável) no qual confia o suficiente para agir, e ainda não tem uma motion escrita e enforçada para o que acontece quando uma conta fica vermelha. O sintoma clássico é um save que funcionou porque um CSM o pegou cedo e sabia para quem ligar —e no trimestre seguinte uma conta idêntica dá churn porque um CSM diferente viu o mesmo flag vermelho e esperou o QBR. O score está fazendo o trabalho dele; a resposta ao score é o gap que isto fecha.

Encaixa melhor para times na faixa de 100 a 2.000 clientes com um health score definido, uma estrutura de book de CSM e um líder de CS que possa ser dono dos escalations. Abaixo de ~100 contas um CSM lê cada conta diretamente e uma motion documentada é overhead. Acima de ~2.000 você provavelmente quer a motion de save dirigida por um CTA do Gainsight com routing nativo e tracking de SLA em vez de um post do Slack e um doc compartilhado —nessa escala os passos manuais são os que ficam de fora. Este SOP é a ferramenta certa na faixa onde a motion importa mas o playbook vive na cabeça das pessoas.

Quando NÃO usar

Não adote isto se você não confia no seu health score. Uma motion de save disparada por um score que fica vermelho por ruído de tagging ou um único login perdido treina os CSMs a ignorar o trigger em menos de um mês. Conserte o score primeiro —o health score composto no n8n e o construtor de health score de CS existem para isso— e depois encaixe esta motion por cima. Uma motion precisa sobre um trigger ruidoso é pior que motion nenhuma, porque queima a confiança do time no único sinal que você precisa que eles acionem.

Não use isto como ferramenta de forecasting de renewal. Este SOP está escopado ao save: uma conta que estava saudável e agora está deslizando, onde o objetivo é reverter a queda antes que ela chegue ao renewal. Uma conta que sempre ia sair por um motivo que nenhum CSM pode mover —o comprador saiu, a empresa foi adquirida, o caso de uso morreu— não é candidata a save, e forçá-la pela motion desperdiça as horas do CSM numa perda determinística. O passo de diagnóstico existe em parte para tomar essa decisão cedo.

Não rode sem um líder de CS que vá pegar os escalations. O nível de escalation é estrutural: o ponto inteiro é que uma conta passada de uma linha de severidade deixa de ser problema de um único CSM e passa a ser do time. Se os escalations vão para um canal que ninguém é dono, a motion se degrada para a mesma improvisação que pretendia substituir.

O trigger

A motion dispara em um evento de score do Gainsight, não no palpite de um CSM nem no calendário. Dois triggers, qualquer um deles inicia o relógio:

Queda de faixa para vermelho —o health score composto cruza de amarelo para vermelho (no scoring de referência, composto abaixo de 50). Este é o trigger primário.
Delta negativo grande dentro de uma faixa —uma queda de 15 pontos ou mais em um único ciclo de scoring, mesmo que a conta ainda esteja tecnicamente em amarelo. Uma queda de verde para amarelo-médio é muitas vezes um sinal mais agudo que um vermelho estável, porque é novo e a causa é recente o suficiente para ainda ser reversível.

O Gainsight dispara um CTA em qualquer das duas condições; a atribuição do CTA é o CSM de record. O SLA: o CSM abre um plano de save dentro de dois dias úteis do trigger. Amarrar o início ao evento de score em vez de a uma revisão semanal é o ponto inteiro —uma revisão é remarcada; um CTA com um SLA é trackeado.

A motion

Diagnostique (até o dia 2). Antes de qualquer outreach, o CSM preenche a seção de diagnóstico de save-plan-template.md: qual sub-score se moveu (uso, atividade, sentiment), o número concreto e seu baseline, e uma hipótese de uma linha para a causa. A hipótese é forçada a um de um conjunto fixo —estagnação de adoção, troca de champion, valor não realizado, deslocamento competitivo, orçamento/econômico ou gap de produto— porque a classe de causa determina a jogada. Um diagnóstico de “eles parecem infelizes” é rejeitado; o CSM nomeia o sub-score e a classe provável ou marca “causa desconhecida, requer call de investigação”.
Intervenha (até o dia 5), em níveis conforme a causa. Estagnação de adoção → uma sessão de trabalho sobre a feature não usada, não um check-in. Troca de champion → uma motion de introdução para mapear e ganhar o novo stakeholder antes de qualquer coisa. Valor não realizado → puxe o success plan e o “por que compraram” original, e marque uma revisão de valor contra a métrica que definiram no deal. Deslocamento competitivo → envolva o AE e, se justificado, escale de imediato. Orçamento/econômico → uma conversa comercial que o CSM talvez não seja dono sozinho. Gap de produto → registre, defina expectativas com honestidade e não prometa uma data de roadmap que o CSM não possa cumprir. O template carrega uma jogada default por classe para que o CSM esteja escolhendo a variação, não inventando a jogada.
Escale (quando a linha de severidade é cruzada). Uma conta escala para fora da motion de um único CSM quando qualquer um de: está em vermelho E acima de um threshold de receita que o time define (ex. ARR do quartil superior), a causa é deslocamento competitivo, ou o plano de save rodou 30 dias sem recuperação de faixa. O escalation publica em #cs-saves usando slack-escalation-template.md —conta, ARR, data de renewal, sub-score que se moveu com seu número, classe de causa, a jogada rodada até agora e o pedido específico à liderança. O líder de CS reconhece na thread dentro de um dia útil e atribui um exec sponsor ou AE se o pedido justificar.
Documente (continuamente, e no fechamento). Cada plano de save registra o trigger, o diagnóstico, a jogada e o resultado —salva, churnada ou rebaixada— encadeado à classe de causa. Esta é a metade da motion que compõe: depois de um trimestre você consegue ler quais classes de causa você realmente salva e quais não, e re-apontar as horas do CSM para as salváveis. Um save que não é documentado não ensina nada ao time.

Como é o sucesso

Acompanhe quatro números. Primeiro, tempo de trigger-ao-primeiro-toque —dias desde que o CTA do Gainsight dispara até a primeira ação de save registrada. O SLA de dois dias úteis deve levar a mediana abaixo de dois dias dentro de um mês; um atraso maior significa que o CTA dispara para uma fila que ninguém trabalha. Segundo, taxa de save por classe de causa —das contas que entraram na motion, a porcentagem que se recuperou para amarelo-ou-melhor e renovou, dividida pela causa diagnosticada. Este é o número que diz onde a motion ganha seu sustento; espere que saves de estagnação de adoção rodem bem acima dos de deslocamento competitivo, e dimensione a equipe de acordo. Terceiro, precisão de escalation —das contas escaladas, a porcentagem onde o envolvimento da liderança plausivelmente mudou o resultado. Se a maioria dos escalations teria resolvido sem liderança, a linha de severidade está baixa demais e você está taxando o líder de CS. Quarto, taxa de pego-a-tempo —das contas que deram churn, a porcentagem que algum dia entrou na motion de save. Uma alta taxa de churn-sem-plano-de-save significa que o trigger não pega as quedas cedo o suficiente, o que te manda de volta ao score, não à motion.

Versus as alternativas

Versus um save ad-hoc rodado a partir do ciclo de QBR. O status quo na maioria dos times é que o risco aflora na revisão trimestral e o CSM improvisa uma resposta. Não custa nada montar e perde em timing e consistência: o QBR pode ser 80 dias depois de a queda ter começado, e a qualidade da resposta oscila com qual CSM é dono da conta. Este SOP custa o setup de um CTA do Gainsight e três templates e move a resposta para dentro de uma semana do trigger. Escolha a versão ad-hoc só se sua contagem de contas for baixa o suficiente (abaixo de ~100) para que um CSM leia cada conta semanalmente de qualquer jeito.

Versus um Playbook / CTA do Gainsight construído de forma nativa, sem um SOP escrito por trás. O Gainsight pode disparar o CTA e anexar um checklist de tarefas, e em escala esse é o mecanismo de entrega certo. Mas um checklist de CTA sem a lógica de diagnóstico-a-jogada por trás produz teatro de completar-tarefas —o CSM marca as caixinhas e mesmo assim improvisa o save de verdade. Use o CTA do Gainsight como o trigger e o timer de SLA, e use as classes de diagnóstico e jogadas em níveis deste SOP como o conteúdo ao qual o CTA linka. Os dois são complementares: o Gainsight é a mecânica, o SOP é o julgamento.

Versus não fazer nada estruturado. Viável só se seu churn genuinamente não é acionável por CS —uma motion pura de PLG sem toque humano, ou um segmento onde saves nunca pagam as horas do CSM. Para qualquer time com um renewal dirigido por relacionamento, a resposta não estruturada a uma conta vermelha é a maior fonte isolada de churn evitável: o save que um CSM teria feito e outro perdeu, decidido por quem por acaso era dono da conta.

A vigiar

O trigger dispara por ruído de score. Se o health score fica vermelho por tagging de uso inconsistente ou uma única semana quieta, o CSM trabalha um não-problema e aprende a desconfiar do CTA. Guarda: condicione o trigger ao composto, não a um único sub-score, e exija que o trigger de delta grande persista por dois ciclos de scoring antes de disparar um CTA —um blip de uma noite se autocorrige e nunca chega à fila do CSM.
O diagnóstico colapsa em um rótulo genérico de “em risco”. Se o passo de diagnóstico é opcional ou de texto livre, os CSMs o pulam e saltam para uma call de check-in, que é a jogada para toda causa e a jogada certa para nenhuma. Guarda: o plano de save não avança para o passo de intervir até que uma classe de causa seja selecionada da lista fixa ou “causa desconhecida” seja escolhida explicitamente com uma call de investigação marcada —a classe é o que seleciona a jogada.
Escalation como lixeira. Se escalar é mais fácil que rodar a jogada, os CSMs escalam tudo e o líder de CS vira o gargalo. Guarda: o template de escalation exige o campo de jogada-rodada-até-agora e um pedido específico antes de publicar; um escalation sem jogada prévia e sem pedido concreto é devolvido ao CSM na thread pelo líder de CS.
Saves que não são documentados no fechamento. Um CSM que salva uma conta e segue em frente sem registrar a causa e a jogada não ensina nada ao time, e a próxima queda idêntica é improvisada do zero. Guarda: o CTA do Gainsight não fecha até que o campo de resultado (salva / churnada / rebaixada) e a classe de causa estejam definidos, então cada plano de save fechado alimenta o relatório de taxa-de-save-por-causa.
A motion sobrevive ao score com o qual foi afinada. Um health score re-ponderado ou um sub-score renomeado quebra silenciosamente os thresholds do trigger e as referências de sub-score do diagnóstico. Guarda: revise os thresholds do trigger no CTA do Gainsight e os nomes de sub-score em save-plan-template.md contra o score ao vivo uma vez por trimestre, na mesma revisão que re-afina os pesos do score.

Stack

Gainsight —o health score, o CTA que dispara o trigger, o timer de SLA e o relatório de resultados por-causa
Slack —o canal de escalation #cs-saves e a thread de reconhecimento do líder
O doc de plano de save —save-plan-template.md, armazenado onde seu time guarda os docs de conta (Gainsight, Notion ou um custom object do Salesforce), uma única localização canônica por conta

Editar esta página no GitHub