1. 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.

      Posted in ,

      Deixe um comentário