Quase todo software comercial promete hoje dizer ao vendedor qual é a próxima melhor ação. O dono da PME assiste à demonstração, acha razoável e assina. Seis meses depois a tela está lá, a lista carrega todo dia — e o vendedor continua ligando para os mesmos clientes de sempre.
Isso raramente é preguiça. É que ninguém nunca conseguiu explicar por que o cliente da primeira linha estava acima do da sétima. E uma ordem que não se explica não se cumpre: vira decoração no topo da tela.
O critério não é ter IA. É a régua caber numa tabela.
A pergunta certa diante de qualquer recomendação comercial não é "como isso foi calculado?" — é "onde está escrita a regra e o que acontece se eu discordar dela?".
Se a resposta for um modelo treinado ou "o algoritmo aprende com o uso", ninguém tem como brigar. E quando não dá para brigar, ninguém obedece: apenas ignora em silêncio. Se a resposta for uma tabela que o dono lê em trinta segundos e diz "aqui está errado, cobrança vem antes disso na minha empresa", então existe recomendação de verdade — porque existe algo para contestar. Próxima melhor ação vira palavra bonita exatamente no ponto em que a régua deixa de ser legível.
A régua inteira cabe em seis linhas
No zCRM, a fila de prioridades é ordenada por uma tabela fixa de urgência. Ela tem seis números, e são estes:
| Sinal | Urgência |
|---|---|
| Proposta vencida sem desfecho | 85 |
| Cliente parou de comprar (reativar) | 80 |
| Financeiro vencido (cobrar) | 75 |
| Carteira com entrega vencida (faturar) | 70 |
| Cliente em queda (recuperar) | 65 |
| Proposta em aberto aguardando desfecho | 55 |
É isso. Não há mais nada por baixo.
A lógica é discutível e por isso está exposta: proposta vencida lidera porque é o único item onde a empresa já gastou o trabalho todo — visitou, cotou, formou preço — e está prestes a jogar fora por silêncio. Cliente que parou vem logo abaixo porque a receita já sumiu, enquanto o cliente em queda (65) ainda compra. Proposta em aberto fica por último de propósito: ainda está dentro do prazo, e tratar tudo como urgente é não priorizar nada.
O empate é resolvido pelo dinheiro: itens de mesma urgência são ordenados pelo valor em jogo. Duas propostas vencidas no mesmo dia? A de R$ 60 mil aparece antes da de R$ 4 mil.
Você pode achar essa ordem errada. Um distribuidor com caixa apertado vai querer cobrança acima de proposta vencida, e tem razão — para o negócio dele. O ponto é que essa discussão é possível e é uma conversa de negócio, não um chamado de engenharia. Os pesos são heurística calibrável, não verdade do setor.
Cada linha mostra o fato, não o rótulo
Ordem legível resolve metade. A outra metade é o que cada item diz de si. Um item da fila não exibe "score 82" nem "risco alto" — exibe o fato bruto que o gerou:
- "Sem comprar há 214 dias (faturava R$ 38.000 no trimestre anterior)."
- "Caiu 46% — de R$ 52.000 para R$ 28.000 no trimestre."
- "R$ 17.400 vencido em 3 título(s), o mais antigo há 62 dias."
(Os números são ilustrativos; o formato das frases é o do produto.)
E vem com uma sugestão escrita em português: "Renovar, ganhar ou registrar a perda", "Acionar cobrança / negociar o débito", "Contato de reativação / visita". A recomendação é uma frase, não um número.
A diferença é operacional, não estética. Com "risco alto", o vendedor precisa abrir o cadastro para descobrir do que se trata — e não abre. Com "sem comprar há 214 dias, faturava R$ 38 mil no trimestre", ele já sabe para quem ligar e com que assunto.
A discordância do vendedor é uma funcionalidade
Aqui está a parte que parece defeito e é recurso. O vendedor abre a fila e diz: "esse cliente parou de comprar porque a fábrica dele fechou em março; não adianta ligar". Ótimo. A regra perdeu a discussão em dez segundos, e perdeu bem — porque a informação que a derrubou era justamente a que o banco de dados não tinha.
Isso só acontece porque a régua estava visível. Um score opaco não perde essa briga: nunca entra nela. O vendedor não tem contra o que argumentar, então não argumenta — apenas fecha a tela. O sistema nunca fica sabendo que errou, o gestor acha que a ferramenta "não pegou", e ninguém aponta onde. Uma regra que perde discussões públicas melhora; um número que ninguém entende só perde usuários.
Vale a ressalva: isso não é um argumento universal contra modelos estatísticos. É um argumento sobre esta situação — uma PME B2B com alguns milhares de contas, onde o gargalo não é o modelo, é o dado. Se o cadastro tem vendedor errado e metade das propostas nunca foi baixada, nenhum algoritmo conserta isso; só embrulha o problema numa camada a mais. Num call center com milhões de interações, a conversa é outra: depende da escala e da qualidade do dado.
Erros comuns nesse tema
- Chamar de inteligência artificial o que é uma ordenação. O dia em que o cliente descobre custa a confiança inteira.
- Esconder a régua "para não confundir o usuário". Ele não fica confuso: fica desconfiado. É pior.
- Deixar a régua imutável. Se ajustar um limiar exige abrir chamado, a régua é do fornecedor, não da empresa.
- Empilhar fatores para parecer sofisticado. Trinta variáveis com pesos invisíveis não são mais precisas que seis visíveis — são só mais difíceis de contestar.
Como isso se aplica no zCRM
A dor: listas de prioridade que o vendedor não segue porque não entende — e que o gestor não consegue defender, porque também não sabe explicar a ordem.
Os dados de hoje: os seis sinais vêm do ERP em leitura — propostas com validade, histórico de faturamento, carteira de pedidos com entrega prevista, títulos em aberto. A ordenação é a tabela acima, com desempate por valor, e cada item carrega o fato que o gerou.
O mesmo princípio vale para o resto. O health score parte de uma base 60 e mostra cada fator com o ponto que ele mexeu (+12 comprou nos últimos 90 dias, −18 sem comprar há mais de 180); cada fator é clicável e abre a evidência. Os cortes de RFM são editáveis pela interface, com sugestão por quintis da sua base — salvar recalcula na hora. A carência do financeiro e os limiares de saúde são configuração, não constante escondida no código. E a próxima ação da conta é derivada: a menor data entre a atividade a fazer, a visita planejada e o follow-up prometido. É consequência do que está pendente, não uma promessa que alguém digitou.
A decisão que muda: em vez de "por onde eu começo hoje?", a pergunta do vendedor vira "concordo com esta ordem?" — e a do gestor, "esta régua reflete como nós vendemos?". As duas têm resposta, e a segunda tem botão.
O limite honesto: o zCRM não tem IA, modelo preditivo nem criação automática de oportunidades. Nada disso existe no produto: a fila descrita aqui é uma tabela de seis números com um desempate — deliberadamente. Os pesos são ponto de partida calibrável: se a sua régua for outra, a régua está errada, não o seu negócio. E a fila ordena fatos; não decide por ninguém. Quem escolhe ligar, visitar ou deixar para depois continua sendo o vendedor.
Próxima leitura
- Prioridades do dia: como transformar dados do ERP em rotina comercial.
- Health score de cliente: quando um número ajuda e quando atrapalha.
- Follow-up comercial: por que a venda se perde depois da proposta.