Quando a PME decide levar o ERP para o CRM, a primeira reunião costuma terminar com uma lista de trinta e poucos campos. Limite de crédito, segmento, cidade, data de cadastro, condição de pagamento, transportadora preferida, código do vendedor antigo. Tudo parece importante, porque tudo custou alguém para digitar. Seis meses depois, a tela do cliente está linda e o vendedor continua atendendo na ordem em que o telefone toca.
O problema não é volume. É que a maior parte do ERP é excelente para relatório e inerte para decisão: um dado que só serve para conferir depois não muda nada agora.
O teste de corte é uma pergunta só
Antes de puxar qualquer coluna, faça a ela uma pergunta: esse dado faz você atender esse cliente antes ou depois?
Se a resposta for "nenhum dos dois, mas é bom saber", o dado não entra no cálculo — no máximo aparece na tela. Se a resposta for "antes, porque ele parou de comprar" ou "depois, porque está com título vencido alto", ele entra.
Repare que a pergunta é sobre ordem, não sobre completude. O cadastro mais completo da base não move ninguém uma posição na fila. Já uma data de última nota, sozinha, reorganiza o dia inteiro.
Os cinco sinais que mudam a ordem
No zCRM, a saúde da conta sai de cinco sinais e nada mais. Começa numa base 60 — o "neutro" — e cada fator soma ou subtrai:
- Recência: comprou nos últimos 90 dias, +12. Passou de 180 dias sem comprar, −18. Sem faturar no ano e sem carteira em aberto, −25.
- Tendência: crescendo contra a janela anterior comparável, +12. Caiu mais de 40%, −15. Estava zerado e voltou a comprar, +8.
- Financeiro: sem títulos vencidos, +8. Com vencidos, −10. Se o vencido passa de 10% do faturamento de 12 meses, −18.
- Carteira a faturar: tem pedido em aberto, +10.
- Propostas: em aberto, +6. Vencida sem desfecho, −5.
O total fica entre 0 e 100: ≥75 saudável, 50–74 atenção, <50 crítico.
Cinco sinais. Nenhum deles é opinião, nenhum precisa de digitação nova, e cada um responde ao teste de corte. Um cliente que caiu 40% e tem vencido pesado desce de 60 para 35 e aparece antes do cliente que só tem cadastro bonito.
E cada fator é clicável: você abre a evidência atrás do número — carteira leva aos pedidos e entregas, vencido leva ao financeiro. Nota que não abre evidência vira placar, e placar todo mundo aprende a ignorar.
O RFM inteiro cabe em três informações
Aqui está a prova mais direta de que peso de dado não é quantidade de dado. Recência, frequência e valor — a classificação que segmenta a carteira inteira — saem de três informações de uma view só, v_crm_invoices: a data da nota, o total da nota e a contagem de notas.
Com isso se monta recência (≤30 dias = 5, até >180 = 1), frequência (≥12 notas em 12 meses = 5, zero = 1) e monetário (≥100 mil = 5, zero = 1). Três colunas produzem a segmentação; trinta colunas de cadastro produzem uma ficha.
O que fica de fora do cálculo — e continua útil
Limite de crédito, bloqueio, segmento, cidade/UF, data de cadastro. Tudo isso existe e o zCRM lê. Nada disso entra na conta da saúde.
Não é desprezo pelo dado: é o teste de corte funcionando. Saber que o cliente é de Caxias não faz você ligar para ele antes. Mas quando você já decidiu ligar, saber que ele está bloqueado muda a conversa — você trata a liberação antes de oferecer o mix novo.
A regra prática: dado que ordena a fila entra no cálculo; dado que prepara o atendimento fica na tela. É misturando os dois que o painel enche de indicador e esvazia de decisão.
Três lentes que a PME confunde o tempo todo
Este é o erro conceitual mais caro do tema, e ele não é de sistema — é de vocabulário:
- Vendas = quanto o cliente comprou, pela data do pedido (
v_crm_order_sales). É demanda. - Faturamento = quanto virou nota, pela data da nota (
v_crm_invoices). É receita. - Carteira = quanto falta faturar, um retrato de agora (
v_crm_orders, saldo em aberto). Não tem período, tem saldo.
Não são intercambiáveis e não fecham entre si. Um pedido de R$ 80 mil em março com entrega em agosto é venda de março, carteira hoje e faturamento de agosto. Quem pergunta "quanto vendemos em março?" e recebe faturamento recebe outra resposta — tecnicamente correta, e errada para a pergunta.
A data certa importa mais que o dado bonito
Duas decisões pequenas mudam quem aparece na fila:
Entrega vencida usa a data de entrega do item, não a data do pedido. Um pedido de janeiro para entregar em agosto não está atrasado. Ordenar por idade do pedido enche a lista de falso atraso e treina o vendedor a ignorá-la.
Vencido tem carência configurável (padrão: 3 dias). Título só conta como vencido depois disso — porque boleto pago ontem e ainda não baixado não é inadimplência, é rotina do financeiro. Sem essa folga, você liga cobrando quem já pagou.
Erros comuns na escolha do dado
- Somar o total da nota na view de itens. O total do cabeçalho se repete em cada linha; somar infla o faturamento em silêncio, e ninguém percebe até alguém conferir com o contador. Por isso cada coluna numérica precisa ser declarada aditiva ou não-aditiva — e a de itens nem carrega o total do documento.
- Somar as três lentes achando que fecham. Vendas + faturamento + carteira não é o "total do cliente". É o mesmo dinheiro contado em momentos diferentes.
- Trazer o campo porque existe. Cada coluna sem uso decisório é manutenção futura e ruído na tela.
- Confundir "dado escolhido" com "dado correto". Escolher a coluna certa não conserta cadastro duplicado nem vendedor errado no cliente. São dois problemas, e o segundo é assunto de checklist.
Como isso se aplica no zCRM
A dor: o ERP tem tudo e não diz nada sobre por onde começar a segunda-feira.
Hoje o zCRM ordena a carteira com o que passou no teste de corte — notas (data, valor, contagem), pedidos em aberto com a data de entrega do item, títulos vencidos com carência, e propostas em aberto ou vencidas. Cadastro, limite, bloqueio e segmento aparecem no contexto do atendimento, fora do cálculo.
A decisão que muda: em vez de "quem me ligou hoje", o vendedor abre uma fila já ordenada e sabe por que cada nome está ali — clicando no fator até a evidência.
Os limites, explícitos. Devolução parcial não é abatida: a nota original continua somada integralmente, então o faturamento fica superestimado nesse valor (só devolução de nota inteira sai, marcada como cancelada). Preferimos declarar isso a fingir precisão. Saúde e RFM são heurísticas transparentes, não ciência: os pesos acima são ponto de partida calibrável — os cortes de frequência e valor já foram recalibrados pelos quintis reais de uma base. Não há score preditivo nem oportunidade criada por IA: são regras somadas, auditáveis, que você pode contestar linha a linha. Custo e margem só trafegam para quem tem a permissão específica; sem ela, os campos nem saem do servidor. E escolher o dado certo não garante que ele esteja certo — isso é outro trabalho.
Próxima leitura
- Checklist do primeiro dia: quais dados do ERP carregar no CRM.
- O que significa valor no primeiro dia em um CRM.
- CRM integrado ao ERP: como carregar histórico no primeiro dia.