---
id: saas/health-score-risco-churn
industria: SaaS e tecnologia
uso: muito usado
esforco: médio
grao: 1 linha por conta pagante ativa por dia, mais um histórico de mudanças de severidade
---

# Health score e fila de risco de churn por conta

Uma fila diária de contas em risco, com o motivo e o MRR de cada uma, feita de sinais que de fato antecedem o cancelamento.

## Resumo executivo

**Para quem:** Times de CS e retenção de SaaS que hoje descobrem o churn quando o cliente já cancelou.

**O que resolve**

- O CS recebe uma fila curta de contas com motivo concreto e MRR em risco.
- O alerta só usa sinais que se provaram ligados a churn, sem falso conforto.
- Cada mudança de risco fica registrada, então dá para medir se o score acerta.

**Por que importa:** Os sinais de saída estão espalhados: fatura vencida no billing, pedido de cancelamento no suporte, contrato vencendo no CRM e reclamação num e-mail. Um score bonito que marca a maior parte da receita como saudável é pior que nenhum, porque tira a atenção de quem está saindo. O valor está em acertar quem vai cancelar, não em ter uma nota para todos.

**Perguntas de negócio que responde**

- Quais contas estão em risco crítico de churn hoje e quanto MRR elas somam?
- Quais contratos vencem nos próximos 90 dias sem renovação em negociação?
- Quem pediu cancelamento ou downgrade nesta semana?
- Das contas que marcamos como risco no trimestre passado, quantas cancelaram?
- Monte a ficha do cliente X para a reunião de retenção.

**O que você precisa**

- Billing e CRM ou ferramenta de suporte conectados na Nekt
- O cliente único entre billing, CRM, produto e suporte
- Um histórico de churns para testar cada sinal antes de usar

**O que você recebe**

- Uma tabela diária com severidade, motivo e MRR em risco por conta
- Um histórico de mudanças de severidade para medir acerto
- Uma fila de ação do CS ordenada por MRR em risco
- Um agente de IA que monta a ficha da conta com as evidências

## Detalhado

### O problema

O health score típico soma uso, login e engajamento numa nota de 0 a 100 e pinta quase toda a base de verde. Numa base real, quase nenhum dos clientes que cancelaram tinha sinal de uso baixo, e a maioria estava ativa nos dias antes de sair. Enquanto isso, os sinais que de fato avisam (pedido de cancelamento, fatura vencida, contrato sem renovação) ficam em sistemas que o CS não olha todo dia.

### Regras de negócio

1. **Sinal declarado vale mais que sinal inferido.** Entram no veredito, por padrão, o que o cliente ou o billing afirma: ticket ou caso de cancelamento ou downgrade, assinatura marcada para não renovar (cancel_at_period_end no Stripe, non_renewing no Chargebee), fatura vencida há mais de N dias e contrato vencendo sem negociação de renovação aberta. Uso, login e engajamento são inferências e precisam de prova. (Evite: Score de uso e engajamento como base do risco.)
2. **Teste cada sinal contra churns reais antes de usar.** Para cada sinal, meça em quantos dos churns dos últimos meses ele estava presente antes do cancelamento e em quantas contas que não cancelaram ele também aparecia. Numa base real, o sinal de recência de uso estava registrado em menos de 1% dos churns, taxa de resposta e ativação em nenhum, e quem tinha o sinal estava ativo nos 5 dias antes de cancelar. O eixo de uso foi removido do veredito. (Evite: Escolher sinais pela intuição e nunca medir o acerto.)
3. **Sem alerta não é o mesmo que saudável.** Chame o estado sem problema de algo como cobrança em dia, sem pedido de saída. Nunca reporte o percentual da base nesse estado como percentual saudável. Uma regra cujas únicas saídas possíveis eram saudável ou ótimo carimbou a maior parte do MRR como bom sem nada que pudesse contradizer. (Evite: Dizer que 80% da base está saudável porque não tem alerta.)
4. **Uso vale pela trajetória, não pelo valor.** Se uso entrar, compare com a própria conta: base de 6 meses completos antes do mês atual (do mês -7 ao mês -2). Exija queda em percentual e em valor absoluto ao mesmo tempo (por exemplo, -15% e pelo menos 3 unidades), para conta pequena não alertar por ruído. Sem foto diária guardada não há tendência: o banco do produto costuma apagar dados antigos. (Evite: Alertar toda conta com adesão abaixo de 50%.)
5. **Sem fonte, sem alerta.** Componente nulo por falta de dado não significa ausência de risco, e zero engajamento sem fonte validada não significa risco. Marque a conta como sem dado daquele componente e não emita alerta por ele. (Evite: Tratar ausência de evento como cliente parado.)
6. **Em e-mail, só o texto novo conta.** No CRM, cada resposta de e-mail carrega a conversa inteira citada. Antes de mandar para a IA ou contar sinais, corte o histórico nos marcadores de citação: "On ... wrote:", "Em ... escreveu:", o cabeçalho do Outlook em português "De: ... Enviada em:", linhas iniciadas por ">" e citações aninhadas. Evidência só vale se estiver no texto novo; duplicata exata na mesma thread não é reanalisada. (Evite: Mandar o corpo inteiro de cada e-mail para a IA.)
7. **Universo: só contas pagantes ativas.** O score cobre contas com MRR maior que zero, incluindo as que vão sair no fim do ciclo. Saem contas internas, de teste, demo e em trial. Inadimplência não é inatividade: o cliente inadimplente com acesso continua na base e entra com o sinal de cobrança. (Evite: Calcular score para trial, demo e contas internas.)
8. **Uma linha por conta, com motivo e próxima ação.** A fila tem a conta, a severidade, o motivo legível (qual sinal disparou e quando), o MRR em risco, o dono no CS e a próxima ação. Ordene por severidade e MRR. Um critério que lota a fila sozinho (por exemplo, só estar sem call há 30 dias) deve sair do OU e virar componente. (Evite: Uma nota de 0 a 100 sem dizer o porquê.)
9. **Fórmula versionada e histórico de severidade.** Grave a versão da fórmula em cada linha e, quando ela mudar, guarde o score original e o recalculado. Mantenha um histórico de transições (só acrescenta, 1 linha quando a severidade de uma conta muda) para contar contas e MRR em risco em qualquer dia e medir acerto. (Evite: Sobrescrever o score todo dia sem guardar o anterior.)
10. **Churn precoce é outra fila.** Cliente que cancela pouco depois da venda (por exemplo, até 45 dias, ou 90 dias em contas grandes) é problema de venda ou implantação, não de CS. Separe esse motivo para não misturar com risco de carteira. (Evite: Contar cancelamento no primeiro mês como falha do CS.)

### Sinais de risco e quanto confiar neles

Declarações e cobrança entram direto. Inferências entram só depois de testadas contra churns reais.

- **Ticket ou caso de cancelamento ou downgrade** → Declaração: entra direto
- **Assinatura marcada para não renovar** → Declaração: entra direto (`cancel_at_period_end, non_renewing`)
- **Fatura vencida há mais de N dias** → Cobrança: entra direto (`past_due, unpaid`)
- **Contrato vence em até 90 dias sem renovação aberta** → Contrato: entra direto
- **Queda de uso contra a própria base** → Inferência: só com prova
- **Integração desconectada ou credencial inválida** → Inferência: só com prova
- **Fala de saída em e-mail ou call** → Inferência: só no texto novo
- **Dias sem contato do CS** → Componente, nunca critério isolado

### Definições

| Métrica | Definição |
|---|---|
| Conta no universo | conta pagante com MRR > 0 no dia, incluindo não renovação, sem contas internas, teste, demo ou trial |
| Severidade | nível de risco da conta no dia (por exemplo: sem alerta, atenção, risco, crítico), calculado pela fórmula da versão vigente |
| MRR em risco | soma do MRR atual das contas com severidade risco ou crítico no dia |
| MRR em não renovação | soma do MRR das assinaturas marcadas para encerrar no fim do ciclo |
| Fatura vencida | fatura em aberto com vencimento anterior à data de referência há mais de N dias (por exemplo, atenção a 30 e risco a 60) |
| Contrato vencendo | data de fim de contrato vencida ou em até 90 dias sem negócio de renovação aberto |
| Acerto do alerta | contas que entraram em risco no período e cancelaram em até 90 dias / contas que entraram em risco no período |
| Cobertura do alerta | churns do período que estavam em risco antes do cancelamento / churns do período |

### Armadilhas

- **Uso deu falso conforto.** Numa base real, quase nenhum churn tinha sinal de uso registrado e quem tinha estava ativo dias antes de sair. A regra de uso marcava a maior parte do MRR como saudável sem poder contradizer. Como evitar: Meça cada sinal contra churns reais e tire do veredito o que não antecede cancelamento.
- **E-mail citado inflou os sinais.** Mais de 80% do texto dos e-mails era histórico repetido. A IA reencontrava as mesmas falas a cada resposta e os sinais de churn ficaram quase três vezes maiores que o real. Como evitar: Mande só o texto novo de cada e-mail e só aceite evidência que esteja nele.
- **Corte de citação incompleto.** Mesmo depois do corte, cerca de 7% das respostas ainda vinham com histórico, por causa do cabeçalho do Outlook em português e de citações aninhadas. Como evitar: Teste os marcadores numa amostra e inclua os formatos em português e aninhados.
- **Um critério lotou a fila.** Ficar mais de 30 dias sem call com o CS, sozinho, colocava na fila contas que estavam bem. Como evitar: Use inatividade de contato como componente, nunca como critério isolado.
- **Nulo lido como seguro.** Contas sem dado de uso apareciam sem risco porque o componente vinha nulo. Como evitar: Marque o componente como sem dado e mostre isso na ficha da conta.
- **Score mudou e o passado também.** A fórmula foi ajustada e o histórico de risco passou a contar outra coisa, sem como comparar. Como evitar: Grave a versão da fórmula e o histórico de transições de severidade.

Validado em dados reais: Nos e-mails registrados no HubSpot da própria Nekt, 61% do texto é histórico citado de mensagens anteriores. Nos e-mails recebidos de clientes, 9 em cada 10 trazem a conversa anterior e 89% do texto é repetido. Sem cortar a citação, a mesma frase de um cliente seria contada a cada resposta da thread.

### Teste de aceitação

- [ ] Toda conta pagante ativa tem exatamente uma linha por dia, e nenhuma conta interna, de teste ou em trial aparece.
- [ ] Toda conta com severidade risco ou crítico tem pelo menos um motivo com data e fonte.
- [ ] Toda assinatura marcada para não renovar e todo ticket de cancelamento aberto aparecem na fila no dia seguinte.
- [ ] Nos últimos 3 meses fechados, a cobertura do alerta (churns que estavam em risco antes de cancelar) é medida e publicada junto com o acerto.
- [ ] Nenhuma evidência de e-mail usada pelo score vem de texto citado de mensagem anterior.

### Context document

```text
Health score e risco de churn
- O universo são contas pagantes com MRR > 0, incluindo as que não vão renovar. Contas internas, teste, demo e trial ficam fora.
- Risco vem primeiro de declarações e cobrança: ticket de cancelamento ou downgrade, assinatura marcada para não renovar, fatura vencida há mais de <N> dias, contrato vencendo em até 90 dias sem renovação aberta.
- Sinais de uso só entram se estiverem na fórmula vigente. Não use uso para dizer que uma conta está saudável.
- O estado sem alerta significa cobrança em dia e sem pedido de saída. Nunca reporte como percentual de clientes saudáveis.
- Componente sem dado não é ausência de risco. Diga que falta dado.
- Em e-mails, use só o texto novo de cada mensagem. Texto citado de mensagens anteriores não é evidência.
- Sempre diga o motivo, a data do sinal e o MRR em risco de cada conta.
- Churn precoce (cancelamento até <N> dias após a venda) é analisado à parte, como problema de venda ou implantação.
- Para perguntas sobre o passado, use o histórico de severidade, não a tabela do dia.
Exceções por cliente:
- <cliente>: contrato anual com aviso prévio de <N> dias; o aviso conta como pedido de saída.
- <cliente>: conta em implantação até <data>, fora do score.
```

### Variações

- **Score por pontos:** Componentes somados com faixas fixas (por exemplo, 0 a 12 pontos em cinco faixas), útil quando o CS quer ver o peso de cada sinal.
- **IA sobre conversas:** Calls e e-mails classificados por IA em risco, insatisfação e oportunidade, só com texto novo e evidência citada.
- **Previsão de NRR:** Regras de aviso prévio e fatura vencida combinadas com um modelo, auditando todo mês a taxa prevista contra a realizada.