Como construo o Customer Health Score de uma empresa B2B usando IA

Por que a maioria dos health scores B2B é inútil

Quando entrei pela primeira vez em um projeto de Customer Success Analytics para uma empresa de software B2B, me deparei com um health score que tinha sido construído com base em feeling. Literalmente: o time de CS havia atribuído pesos às métricas com base na intuição de quem estava há mais tempo na empresa. O resultado era um score que oscilava tanto que ninguém confiava nele — e que não previa absolutamente nada.

Esse problema é mais comum do que parece. A maioria das empresas B2B tem alguma versão de health score, mas pouquíssimas têm um health score que realmente funciona como ferramenta preditiva. O que aprendi ao longo de vários projetos — e especialmente ao estudar o framework da Trilion para Customer Analytics — é que um bom health score não é uma opinião formalizada. É um modelo estatístico calibrado com dados reais de comportamento.

Neste artigo vou mostrar exatamente como construo um Customer Health Score B2B usando IA, desde a definição das variáveis até a integração com o workflow do time de CS.

O que um health score realmente precisa prever

Antes de construir qualquer modelo, defino o que quero prever. Parece óbvio, mas esse passo é onde a maioria dos projetos já falha. O health score pode ser projetado para prever:

• Churn: probabilidade de o cliente não renovar no próximo ciclo.
• Expansão: probabilidade de o cliente aumentar o contrato nos próximos 90 dias.
• Satisfação futura: probabilidade de o NPS melhorar ou piorar na próxima pesquisa.
• Risco de escalada: probabilidade de o cliente abrir um ticket crítico nas próximas duas semanas.

Para cada empresa, o objetivo prioritário é diferente. Em empresas com alta taxa de churn, o foco é previsão de cancelamento. Em empresas em fase de expansão, o foco é identificar contas com maior potencial de upsell. Definir isso antes de construir o modelo é o que garante que o score vai ser usado — e não vai virar mais um dashboard decorativo.

As três camadas de dados que uso

Camada 1 — Dados de produto (comportamento de uso)

Essa é a camada mais rica e a mais subutilizada pela maioria das empresas. Aqui capturo:

• Frequência de login por usuário e por conta
• Profundidade de uso — quantas features são utilizadas regularmente
• Volume de dados processados ou transações realizadas
• Trend de uso nas últimas 4 a 8 semanas — está crescendo, estável ou em queda?
• Usuários ativos como percentual do total de licenças

O dado de trend é especialmente poderoso. Uma conta com uso absoluto alto mas trend negativo é muito mais preocupante do que uma conta com uso médio e trend positivo. Esse padrão — que aprendi analisando cases da Trilion — é contraintuitivo para muitos times de CS que só olham para o número absoluto.

Camada 2 — Dados de relacionamento

A camada de relacionamento captura a qualidade da interação entre o cliente e a empresa:

• Tempo de resposta do cliente em comunicações
• Presença em reuniões de QBR e check-ins
• Engajamento com conteúdo de enablement e treinamento
• Histórico de tickets: volume, severidade, tempo de resolução e satisfação pós-resolução
• Participação em programas de beta e comunidade

Uma métrica que descobri ser extremamente preditiva — e que raramente vejo em health scores genéricos — é o tempo de resposta do champion: quanto tempo o contato principal leva para responder emails do CSM. Quando esse tempo começa a aumentar consistentemente, é sinal de que o champion está perdendo interesse ou enfrentando problemas internos. Esse sinal aparece em média 6 semanas antes do churn.

Camada 3 — Dados financeiros e contratuais

• Histórico de pagamentos — atrasos recorrentes são leading indicator de churn
• Tamanho do contrato e margem de expansão possível
• Data de renovação e tempo restante
• Histórico de negociação — descontos agressivos na última renovação indicam menor percepção de valor
• Evolução do ARR da conta ao longo do tempo

'Um health score construído só sobre dados de produto ignora 60% do que realmente determina a saúde de uma conta B2B. A tríade produto-relacionamento-financeiro é o que diferencia modelos preditivos de modelos decorativos.' — Princípio que aprendi nos frameworks da Trilion

O processo de construção do modelo

Passo 1 — Coleta e normalização dos dados

Começo unificando as três camadas em um dataset de conta, com granularidade semanal para os dados comportamentais e mensal para os financeiros. Uso Python com pandas para a transformação, e dbt para documentar e versionar o pipeline.

Uma regra que aplico sempre: nunca uso dados mais antigos do que 12 meses para treinar o modelo inicial, e reavaliado com uma janela de 6 meses para capturar mudanças de comportamento mais recentes. Dados muito antigos capturam padrões que podem não ser mais válidos.

Passo 2 — Engenharia de features

Aqui é onde o trabalho técnico fica mais interessante. As features brutas raramente são as mais preditivas. As features derivadas — que capturam tendências, acelerações e anomalias — são muito mais poderosas.

Algumas das features derivadas que costumo construir:

• Slope de uso nas últimas 4 semanas: a inclinação da curva de uso, não o valor absoluto.
• Desvio em relação à média da coorte: o cliente está acima ou abaixo do uso médio de contas similares?
• Índice de breadth de uso: quantas das features 'core' do produto o cliente usa regularmente?
• Score de engajamento do champion: índice composto de responsividade e participação em reuniões.
• Indicador de risco financeiro: presença de atraso de pagamento nos últimos 90 dias.

Passo 3 — Treinamento e validação do modelo

Uso um ensemble de gradient boosting (XGBoost ou LightGBM) com validação temporal — treino com dados do passado e valido na janela mais recente. Validação temporal é crítica para evitar data leakage, que é o principal responsável por modelos que funcionam no notebook mas falham na produção.

Métricas que uso para validar:

• AUC-ROC: capacidade discriminativa do modelo
• Precision-Recall AUC: mais relevante quando a classe positiva (churn) é minoritária
• Lift nas decis superiores: o modelo identifica os clientes de maior risco nos primeiros decis?
• Calibração: um score de 70% significa que 70% das contas com esse score de fato churnam?

Esse último ponto — calibração — é frequentemente ignorado, mas é o que permite usar o score como probabilidade real e não apenas como ranking.

Passo 4 — Interpretabilidade com SHAP

Uso SHAP (SHapley Additive exPlanations) para entender quais features mais contribuem para o score de cada conta. Isso transforma o modelo de uma caixa-preta em uma ferramenta de diagnóstico.

Quando apresento o health score para o time de CS, não mostro apenas o número — mostro os três principais fatores que estão puxando o score para baixo. Isso dá ao CSM um ponto de partida claro para a intervenção.

'O health score sem interpretabilidade é uma bússola sem pontos cardeais. Você sabe que algo está errado, mas não sabe o que fazer.' — Lição aprendida em projetos com a metodologia Trilion

Integração com o workflow de Customer Success

Um modelo que fica no notebook do analista não serve para nada. A parte mais importante do projeto é garantir que o score chegue no lugar certo, no momento certo, com o contexto certo.

Meu processo de integração:

• Atualização automática semanal: o score é recalculado toda segunda-feira com os dados da semana anterior, via pipeline automatizado.
• Alertas de degradação: contas cujo score cai mais de 15 pontos em uma semana geram um alerta automático para o CSM responsável, com os principais fatores da queda.
• Integração com CRM: o score e os fatores SHAP são escritos diretamente no Salesforce ou HubSpot, visíveis no registro da conta.
• Priorização de carteira: gero uma lista priorizada das contas que precisam de atenção naquela semana, ordenada por combinação de risco e potencial de receita.

Essa última camada — priorização por receita em risco — é o que a Trilion chama de 'triage de carteira inteligente'. Não basta saber quais contas estão em risco. É preciso saber quais delas, se salvas, representam maior impacto de receita para a empresa.

Refinamento contínuo e feedback loop

O modelo não é um projeto com início, meio e fim. É um sistema vivo que precisa de alimentação contínua. Implemento dois mecanismos de feedback:

• Revisão mensal de acurácia: comparo as previsões do mês anterior com o que realmente aconteceu. Se a acurácia cair, investigo as causas e recalibro.
• Feedback qualitativo dos CSMs: periodicamente entrevisto os CSMs para entender se o score está alinhado com a percepção deles de campo. Quando há divergência, o CSM frequentemente tem informações que os dados não capturam — e isso me diz onde o modelo precisa evoluir.

'O melhor modelo de health score é aquele que o time de CS confia. E confiança se constrói com acurácia demonstrada, interpretabilidade e feedback incorporado.' — Filosofia de trabalho que adotei a partir das diretrizes da Trilion

Resultados típicos que observo

Nos projetos onde implementei esse processo, os resultados foram consistentes:

• Identificação de 75% a 85% dos churns que ocorreram nos 60 dias seguintes, com 4 a 8 semanas de antecedência.
• Redução de 20% a 35% da taxa de churn nas empresas onde o CS passou a usar o score como ferramenta primária de priorização.
• Aumento de 15% a 25% na taxa de upsell bem-sucedido ao identificar contas com alta probabilidade de expansão e acionar playbooks específicos.

Esses resultados não são mágicos. São o produto de um processo metodológico que coloca dados comportamentais reais no centro das decisões de Customer Success — e que garante que o modelo chegue até quem precisa usá-lo.

Conclusão

Construir um Customer Health Score B2B de verdade é um trabalho que combina ciência de dados, entendimento profundo de negócio e design de processos. Não é um projeto de uma semana — mas também não precisa ser um projeto de um ano.

Com o framework que aprendi nos cases da Trilion e refinei em projetos reais, consigo entregar um modelo funcional em quatro a seis semanas e iterar rapidamente com base nos resultados. O segredo é começar com o que você quer prever, usar as três camadas de dados, e garantir que o modelo chegue onde a decisão é tomada.

Se você quer implementar um health score preditivo na sua empresa e precisa de um ponto de partida, comece pelo template que disponibilizei abaixo.

Baixe o Template de Health Score da Trilion — estrutura completa com definição de variáveis, pipeline de dados, modelo base em Python e guia de integração com CRM. Gratuito e pronto para adaptar ao seu contexto.