- Usar atividade como proxy de valor
Login frequente não significa que o cliente está obtendo resultado. Um usuário pode entrar todo dia, olhar o dashboard por dois minutos e não fazer nada relevante. Atividade sem resultado é ruído – e contar isso como sinal positivo mascara clientes em risco real.
2. Não calibrar o modelo com dados históricos
Definir pesos por intuição (“uso deve valer 40%, NPS 30%…”) sem validar se esses pesos realmente predizem comportamento é construir sobre areia. O modelo precisa ser testado retroativamente: clientes que cancelaram tinham score baixo antes? Se não, o modelo está errado.
3. Score único para todos os perfis de cliente
O que “saudável” significa para uma startup de 10 pessoas é completamente diferente do que significa para uma empresa de 500. Um cliente SMB que usa 3 módulos pode estar em ótima saúde. Um enterprise usando os mesmos 3 módulos de 15 disponíveis está em risco. Modelo único para todos gera falsos positivos e falsos negativos em escala.
4. Nenhum protocolo de ação associado ao score
O score mudou de verde para amarelo. E agora? Se a resposta for “o CSM vai ver e decidir o que fazer”, o modelo não vai funcionar. Cada faixa de score precisa de um playbook claro: quem age, em quanto tempo, com qual abordagem. Sem isso, o número é decorativo.
5. Não revisitar o modelo quando ele erra
Um health score não é uma entrega – é um sistema vivo. Quando um cliente marcado como verde cancela, isso é dado. Quando um vermelho renova e expande, isso também é dado. Sem revisão periódica (no mínimo trimestral) o modelo vai se degradar silenciosamente até virar irrelevante.
As zonas de saúde: o que cada faixa exige do time
Um health score só funciona operacionalmente se cada faixa estiver associada a um comportamento claro do time. Não uma sugestão – um protocolo. Veja como estruturar:

Note que a zona “Crítico” exige uma decisão que a maioria dos times evita: às vezes, o melhor movimento não é tentar salvar a conta a qualquer custo – é gerenciar a saída com dignidade e manter a porta aberta para um win-back quando o produto evoluir. Tentar reter um cliente que fundamentalmente não tem fit é caro, desgastante e raramente funciona.
Como construir um modelo que o time adota
A adoção do health score pelo time de CS é tão importante quanto a precisão do modelo. Um score tecnicamente perfeito que o time não confia ou não sabe usar não vai funcionar. A construção precisa envolver quem vai operar o sistema desde o início.
1. Comece pelos churns – não pela planilha
Antes de definir qualquer métrica, mapeie os últimos 10 a 15 churns em detalhe. O que esses clientes tinham em comum 60, 45 e 30 dias antes de sair? Esse exercício quase sempre revela os sinais preditivos reais – e frequentemente surpreende o time com o que não estava sendo monitorado.
2. Limite o modelo inicial a 4 a 6 variáveis
Modelos complexos com 15 variáveis são difíceis de calibrar, difíceis de explicar para o time e difíceis de auditar quando erram. Comece simples. Um modelo com 5 variáveis bem escolhidas e bem ponderadas é mais útil do que um modelo sofisticado que ninguém entende.
3. Valide retroativamente antes de lançar
Aplique o modelo à base histórica: os clientes que cancelaram nos últimos 6 meses teriam score baixo 60 dias antes? Se o modelo não detecta churn no passado, não vai detectar no futuro. Ajuste os pesos até que a correlação faça sentido – e documente as premissas.
4. Crie playbooks por zona antes de lançar o score
O time precisa saber o que fazer antes de ver o primeiro score vermelho – não depois. Defina: quem age, em quanto tempo, com qual abordagem, com qual escalada. Se o playbook não existir no lançamento, o score vai ficar esperando por uma resposta que nunca vem.
5. Revise o modelo a cada trimestre com dados reais
Todo trimestre, compare: clientes que pioraram de score – o que aconteceu? Clientes que melhoraram – o que mudou? Churns que o modelo não previu – o que o modelo estava ignorando? Essa revisão é o que separa um health score vivo de um sistema que apodrece em silêncio.
O que muda quando o score realmente funciona
Quando um health score está calibrado e o time opera a partir dele com consistência, três coisas mudam na prática:

O resultado agregado é o que toda liderança de CS busca: NRR mais alto, com o mesmo headcount. Não porque o time trabalhou mais – mas porque o time trabalhou no lugar certo, com o cliente certo, na hora certa.
“Health score não é uma solução de tecnologia. É uma mudança de cultura operacional.
O número é só o gatilho – o que importa é o que o time faz quando ele dispara.“
A pergunta que fica…
Se o seu health score mudasse de verde para vermelho em 10 contas amanhã – o time saberia exatamente o que fazer, com quem falar e em quanto tempo? Se a resposta envolver algum grau de “depende” ou “cada CSM decide”, o problema não é o modelo. É o que está em volta dele.
Deixe um comentário