O vendedor abre a lista de clientes em risco na segunda-feira e encontra quarenta nomes. Como conhece a carteira, faz a triagem de cabeça: "esse é normal, sempre compra em março"; "esse parou de verdade"; "esse a gente perdeu para o concorrente ano passado e ninguém teve coragem de dar baixa". Em quinze minutos, quarenta viram seis — e os outros trinta e quatro voltam iguais na segunda seguinte, porque a triagem morreu na cabeça dele.
Esse é o problema real do cliente inativo na PME. Não é falta de sinal: o sinal existe e está certo dentro do que mede. É que ele mede uma coisa só, e a decisão depende de três.
O sistema só conhece uma variável: dias desde a última nota
Quase toda frustração com lista de inativo nasce daqui. Quando um sistema diz que um cliente está inativo, ele olha a data da última nota fiscal e conta os dias. É isso. Nada sobre o motivo, sobre o ciclo daquele comprador, sobre o estoque que ele ainda tem no galpão.
E a contagem vai contra uma régua global — a mesma para quem compra toda semana e para quem compra três vezes por ano. Noventa dias é o corte padrão do zCRM. Para quem compra a cada 30 dias, noventa dias de silêncio é alarme legítimo. Para quem compra a cada 120, é terça-feira. A régua é uma; os ciclos são muitos.
"Em risco" é a única das três que é conta
Das três palavras do título, só esta o software calcula sozinho, e vale entender exatamente o que ele faz.
O cálculo compara duas janelas do faturamento realizado: os últimos 90 dias contra os 90 anteriores. Quem faturou na janela anterior e nada na recente entra como parou. Quem faturou nas duas, mas caiu mais de 40%, entra como em queda. Cada um recebe um valor em risco estimado a partir do que faturava antes — porque "cliente sumindo" sem cifra ao lado não move ninguém.
Repare no que esse cálculo é honesto o bastante para não fazer: ele não pergunta por quê. Detecta silêncio e queda em cima de nota emitida. Bom detector de anomalia contra o passado recente do próprio cliente — péssimo juiz do que a anomalia significa.
"Sazonal" não é conta — é conhecimento que só está com quem vende
A resposta honesta é desconfortável: o zCRM não sabe o ciclo de compra individual do seu cliente. Não existe curva de compra por mês, não existe comparação com o mesmo período do ano anterior no sinal de risco, não existe um perfil de "este compra a cada 120 dias" aprendido do histórico.
O que existe é o vendedor que sabe: a revenda de piscina some de maio a agosto; a construtora compra por obra, não por mês; aquele cliente fez um pedido gigante em janeiro e não volta antes de abril, porque o galpão dele está cheio do seu produto.
O ponto prático não é ensinar o sistema a saber isso — não dá. É perceber que essa informação vive exclusivamente na cabeça de uma pessoa. E o custo disso aparece de dois jeitos: quando ela sai de férias e quando ela pede demissão.
"Perdido" não é conta nem palpite — é uma decisão que alguém precisa tomar
Cliente perdido é a categoria mais mal resolvida das três, porque ninguém gosta de dar a baixa. Enquanto o nome fica na lista, ainda há esperança e ninguém precisa explicar nada para a diretoria.
Nenhum cálculo produz "perdido". O que existe é um desaparecimento silencioso: a janela de análise do sinal de risco tem 365 dias, então quem não emite nota há mais de um ano simplesmente para de aparecer na tela "Em risco". Não é classificação — é o fim do assunto por decurso de prazo. O cliente não foi marcado como perdido; foi esquecido com aparência de organizado.
Por isso "perdido" tem que ser um ato: alguém olha, decide e grava. Se ninguém grava, o próximo vendedor da carteira vai gastar semanas redescobrindo o que já se sabia.
Onde o julgamento humano fica guardado
O sistema não distingue sazonalidade. Mas tem um lugar para você distinguir — e é o que resolve o problema da segunda-feira lá do começo.
Na conta 360, quem gerencia a conta edita temperatura (frio, morno, quente) e observações livremente. O terceiro campo, status comercial, escolhe de uma lista — e vale ser exato sobre ela. De fábrica vêm seis opções operacionais: Novo, Em contato, Em negociação, Cliente ativo, Cliente inativo e Em risco. Nenhuma delas é "sazonal". Distinções como "sazonal", "perdido para concorrente" ou "encerrou atividade" existem se você as cadastrar — a lista é editável, mas cadastrar exige perfil de configuração (crm.settings.manage), não é o vendedor que cria no meio do atendimento. Vale a pena fazer isso uma vez, com o time junto, antes de cobrar a triagem de alguém: sem status próprio, o vendedor só tem "Cliente inativo" para descrever coisas muito diferentes entre si.
Feito isso, é a diferença entre "esse é sazonal, volta em março" ser um pensamento e ser um registro. O gerente filtra a carteira por status comercial e a lista de quarenta vira seis sem depender da memória de ninguém. Toda alteração fica gravada na linha do tempo da conta, com data — dá para reabrir em março e ver que a previsão de janeiro estava lá, e se ela se confirmou.
Dois limites dessa gravação, para você não contar com o que ela não faz. A linha do tempo registra a conta, não o editor: o evento sai atribuído ao dono da carteira, então se o gerente marcar "sazonal" na conta de um vendedor, o histórico mostra o vendedor. Serve para responder o que foi decidido e quando, não quem decidiu. E quando a alteração é só na observação, o evento aparece sem detalhar o que mudou — o texto da observação vale por si; o evento é o carimbo de data. Nada disso apaga o ganho, que é tirar o julgamento da cabeça de uma pessoa. Mas se a sua discussão é sobre autoria — quem mandou parar de visitar este cliente —, o campo de observação, escrito e assinado por quem escreveu, é hoje o lugar honesto para isso.
Erros comuns com cliente inativo
- Baixar o corte para "pegar mais cedo". Move de 90 para 60 e a lista dobra, cheia de gente em ciclo normal. Alarme que toca demais é alarme desligado.
- Subir o corte para "limpar a lista". O mesmo erro ao contrário: some o cliente de ciclo curto que sumiu de verdade — justamente o que dava para salvar.
- Confundir "não aparece mais" com "resolvido". Sair da tela por decurso de um ano é o pior desfecho: perdeu o cliente e não aprendeu nada.
- Tratar o cliente de ciclo longo como defeito do cálculo. Ele é atípico; régua nenhuma vai acomodá-lo. Exige anotação.
- Ligar para o sazonal fora da janela dele. Queima tempo e ensina o cliente que sua ligação não tem conteúdo.
Como isso se aplica no zCRM
Onde isso machuca: uma lista de inativos que mistura três coisas diferentes e obriga o vendedor a refazer a mesma triagem mental toda semana.
O que o zCRM usa hoje, e só isso: notas fiscais autorizadas do ERP. A tela "Em risco" compara a janela recente (90 dias por padrão, ajustável no seletor da própria tela) com a anterior comparável, marca parou ou em queda e estima o valor em risco. O RFM pontua recência nos cortes de 30, 60, 90 e 180 dias, classifica Sem compra recente quando não houve compra em 12 meses e expõe nível de risco alto acima de 180 dias sem comprar, médio acima de 90.
Essa régua é calibrável pela interface: os quatro cortes de cada eixo do RFM ficam guardados na configuração do sistema, e você move a recência para o ciclo típico do seu negócio. Se sua PME vende para construtoras e o ciclo natural é trimestral, chumbar 30 dias como "excelente recência" só produz ruído. Mas seja claro sobre o que a calibração faz: ela move o corte para a base inteira. Ajusta a régua ao seu negócio; não cria uma régua por cliente.
E aí a discussão vira outra: em vez de brigar sobre se a lista está certa, o time trabalha em dois movimentos. Calibrar o corte uma vez para o ciclo dominante do negócio — e tratar cada exceção que sobrar como o que ela é: um julgamento gravado no status comercial e na observação da conta, não repetido de cabeça toda semana.
O limite honesto, sem rodeio: o zCRM não detecta sazonalidade. Não há ciclo de compra por cliente, não há curva por mês, não há comparação com o mesmo período do ano anterior no sinal de risco. Não existe status "perdido" calculado — perdido é decisão de pessoa, gravada à mão. E o sistema não pergunta ao vendedor se o cliente é sazonal nem aprende com a resposta: esse laço não existe. O que ele entrega é a régua calibrável, o sinal em cima do dado real do ERP e o lugar certo para o julgamento parar de morar só na memória de quem vende.
Próxima leitura
- Clientes em risco: como descobrir quem está sumindo antes de perder faturamento.
- RFM para PMEs: recência, frequência e valor sem complicação.
- Passado vs presente: como comparar períodos para entender a saúde do cliente.