ooligo
TIPO · definition

Previsão de churn

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

Previsão de churn é a prática de pontuar cada cliente conforme o quão provável é que ele cancele ou faça downgrade antes de ele de fato fazer isso, para que um CSM possa intervir enquanto ainda há tempo de mudar o resultado. Ela transforma a retenção de uma função reativa — reagir depois que o email de cancelamento chega — em uma proativa — trabalhar a conta em risco com 60 a 90 dias de antecedência.

Não é a mesma coisa que um health score, e não é a mesma coisa que a taxa de churn. Um health score é um retrato composto do estado da conta; a taxa de churn é um input retrospectivo de GRR/NRR que diz o que já aconteceu. Previsão de churn é uma probabilidade antecipada: “esta conta tem 38% de chance de não renovar nos próximos 90 dias”. Um health score pode ser um input dessa probabilidade, mas os dois são objetos diferentes.

Os indicadores antecedentes que de fato movem o modelo

Um modelo de churn vale o que valem suas features. Os sinais que carregam mais peso, mais ou menos em ordem:

  • Decaimento de uso do produto. O indicador antecedente mais forte. Não o uso absoluto — a tendência. Uma contagem de logins que cai 40% trimestre contra trimestre prevê churn muito melhor do que uma baixa-mas-estável. Acompanhe usuários ativos semanais por conta, profundidade de adoção de features, e seats provisionados vs. seats ativos.
  • Saída do champion. Quando seu economic buyer ou power user deixa a empresa, o risco de renovação dispara. Detecte isso por emails que voltam, mudanças de cargo no LinkedIn, ou uma queda repentina na atividade daquele contato.
  • Sinal de suporte. Volume de tickets subindo, CSAT caindo, escalações repetidas, ou — contraintuitivamente — uma queda para zero (a conta parou de tentar).
  • Engajamento com CS. QBR perdidas, taxas de abertura de email em queda, respostas lentas, faltas nas calls.
  • Sinais comerciais. Pagamentos atrasados, pedidos de downgrade, procurement pedindo termos mês a mês, contração no nível da linha de item.
  • Onboarding malsucedido. Contas que nunca chegam ao primeiro valor (TTV) fazem churn em múltiplos das que chegam. A janela de onboarding de 90 dias é o input de previsão de maior alavancagem que você tem.

Um modelo que se apoia só no uso vai perder por completo as classes de saída-do-champion e comercial, e é por isso que scores puramente de telemetria de produto sub-preveem em enterprise.

Modelos de scoring, do mais barato ao mais defensável

  1. Modelo de regras / limiares. Regras escritas à mão: “uso abaixo >30% E uma QBR perdida E menos de 90 dias para renovar → em risco”. Transparente, explicável ao CSM, barato de construir, fácil de burlar. Por onde a maioria dos times deve começar.
  2. Scorecard ponderado. Atribua pontos por sinal, some, faça a banda em verde/amarelo/vermelho. É isso que a maioria das features de health score em Gainsight, ChurnZero e Vitally trazem de fábrica. Melhor que nada; os pesos costumam ser chutados, não ajustados.
  3. ML supervisionado (regressão logística, gradient boosting). Treine sobre churn histórico rotulado. É aqui que vem o lift real — o modelo aprende os pesos e interações em vez de você chutar. Requer um dataset rotulado limpo: no mínimo algumas centenas de eventos de churn com histórico de features no momento do risco, não no momento do cancelamento (ou você vaza o rótulo).

Avalie com precision/recall e uma matriz de confusão, não com “accuracy”. Sobre uma taxa-base de churn anual de 8%, um modelo que prevê “ninguém faz churn” tem 92% de accuracy e é completamente inútil. O que importa é: das contas que o modelo marcou em vermelho, quantas de fato fizeram churn (precision), e das contas que fizeram churn, quantas o modelo marcou a tempo (recall).

Onde a IA ajuda — e onde ela promete demais

Onde ela ajuda de verdade: o ML ganha de scorecards ajustados à mão quando você tem histórico rotulado suficiente, porque encontra interações não óbvias (uso baixo está ok para uma conta que sempre entra mensalmente para exportar um relatório; é um alarme de cinco sinos para uma que antes era diária). Os LLM são bons na camada não estruturada que os scorecards ignoram — resumir a tendência de sentiment ao longo de um ano de tickets de suporte e emails, ou sinalizar “o champion parece desligado” a partir de transcrições de calls. Use o LLM para enriquecer features, não para ser o classificador.

Onde ela promete demais: três modos de falha se repetem. Primeiro, o problema de cold-start — um modelo precisa de churn rotulado do qual aprender, e uma empresa em estágio Seed com 40 clientes e 3 eventos de churn não tem nada para treinar. Comprar uma feature de “previsão de churn com IA” ali é puro teatro; use regras. Segundo, confusão de taxa-base vendida como accuracy — os vendors citam “90% de accuracy” contra uma taxa-base de churn baixa onde o modelo ingênuo já está em 92%. Sempre peça precision e recall sobre os flags vermelhos. Terceiro, previsão sem prescrição — uma probabilidade sobre a qual ninguém age é decoração de dashboard. O modelo tem que alimentar um playbook (auto-criar uma tarefa de save, disparar um outreach executivo, escalar para o renewal manager), ou não muda nada.

Erros comuns

  • Vazamento de rótulo (label leakage). Features de treino capturadas no momento do cancelamento (uso já em zero, tickets de suporte já fechados) em vez de no horizonte de previsão. O modelo parece brilhante offline e falha ao vivo. Guarda: tire o retrato das features a 90 dias antes do evento de churn, nunca no dia.
  • Agir tarde demais. Uma janela de previsão de 30 dias é curta demais para salvar uma renovação enterprise — a decisão foi tomada meses atrás. Preveja a 60-90 dias em enterprise, onde a motion de save tem pista.
  • Um único modelo para todos os segmentos. O churn de SMB self-serve (preço, uso baixo) e o churn enterprise (perda do champion, desalinhamento executivo) têm drivers diferentes. Um único modelo mistura tudo num mingau. Segmente primeiro, depois modele.
  • Scoring sem ownership. Um flag vermelho sem um CSM nomeado e sem um SLA para agir morre no dashboard. Emparelhe cada conta vermelha com um dono e uma regra de “responder em X dias”.

Relacionados