← Central de conteúdo

Histórico comercial: por que memória de vendedor não escala

O vendedor pede demissão numa sexta. Na segunda, o gerente assume a carteira e descobre uma coisa curiosa: sabe tudo sobre aqueles clientes e não sabe nada.

Ilustração editorial sobre Histórico comercial: por que memória de vendedor não escala
Conversas, visitas e mensagens formam uma história compartilhada da relação comercial.

O vendedor pede demissão numa sexta. Na segunda, o gerente assume a carteira e descobre uma coisa curiosa: sabe tudo sobre aqueles clientes e não sabe nada.

Sabe tudo porque o ERP está lá: quanto cada um comprou nos últimos doze meses, quais notas saíram, o que está em aberto, quem está devendo. Nada disso foi embora na sexta — a nota fiscal não depende de ninguém lembrar dela.

E não sabe nada porque falta a outra metade. Por que a fábrica de biscoitos caiu de quatro pedidos por mês para um. Que prazo foi prometido para fechar o pedido grande de abril. Que o comprador da distribuidora detesta ser ligado antes das dez. Essa metade foi embora dentro da cabeça de uma pessoa.

A PME não tem um problema de histórico. Tem dois.

O custo de cada um é diferente, e a solução também.

O transacional é involuntário. Acontece como subproduto de faturar: o pedido virou nota, a nota virou linha, a linha ficou. É completo, datado, auditável e grátis — a empresa já pagou por ele quando comprou o ERP. Quando o vendedor sai, esse histórico fica.

O narrativo é voluntário. Só existe se alguém parar e escrever; nenhum processo o produz de brinde. É incompleto por natureza, depende de disciplina e sai pela porta junto com quem o guardava.

"A memória do vendedor não escala" costuma ser dito como se a empresa perdesse o histórico inteiro quando alguém pede as contas. Não perde: perde a metade que ninguém registrou — justamente a que explica o porquê da outra.

A Conta 360 reúne histórico do ERP, relacionamento, saúde e potencial antes do atendimento.

O ERP sabe o quê. Não sabe o porquê.

O ERP registra que a compra da fábrica de biscoitos caiu 40% no trimestre. É um fato, está na base, não depende da opinião de ninguém.

O que ele não tem como saber é que o comprador avisou em março que a fábrica ia parar para reformar uma linha de produção e só voltaria a puxar volume em maio. Sem essa frase, a queda vira um alerta perseguido à toa — ou, pior, uma conta marcada como "em risco" e trabalhada com um desconto que ela não precisava.

O inverso também acontece: uma queda igual que ninguém explicou pode ser o concorrente entrando pela porta dos fundos. Mesmo número, ação oposta — e a diferença está numa anotação de três linhas que alguém fez ou não fez.

Os dois históricos não são substitutos. O transacional é a pergunta. O narrativo é a resposta.

O que a memória não guarda (e nem o melhor vendedor guardaria)

Existe uma classe de fato que a memória humana não registra por limitação estrutural, não por preguiça: a ausência.

Um vendedor bom lembra de conversas, de promessas, do nome do filho do comprador — é excelente em eventos. Mas ninguém lembra do que não aconteceu: ninguém acorda pensando "faz cinco meses que aquele cliente parou de levar a linha de vedação, que ele comprava todo mês". Não há evento para lembrar, há um vazio, e vazio não gera lembrança. Por isso "comprava e parou" quase nunca sai da memória do time. Sai da comparação entre duas janelas de tempo, que é trabalho de máquina.

O dia 1: por que um CRM que começa vazio começa errado

Um CRM genérico chega vazio. No primeiro dia, pede que a empresa digite o que ela já tem: alguém exporta clientes para uma planilha, alguém importa, e sai um cadastro sem histórico de compra, sem valor por cliente, sem recência, sem pedido em aberto. O vendedor abre a ferramenta e vê um formulário. Ele já tinha um — chamava-se caderno.

Repare no absurdo: o sistema pede digitação da metade involuntária, a que era de graça. Enquanto isso, a metade cara — a narrativa, a única que exigia gente — continua não sendo escrita, porque o time gastou a boa vontade digitando o que o ERP já sabia.

A estratégia correta é diferente para cada metade:

  • Transacional: integrar, nunca digitar. Se está no ERP, deve chegar sozinho. Pedir que alguém redigite é cobrar duas vezes pelo mesmo dado e criar uma segunda versão da verdade, que vai divergir em três meses.
  • Narrativo: cobrar pouquíssimo. Cada campo obrigatório a mais reduz a chance de o registro existir. Um histórico narrativo pobre e real vale mais que um rico e imaginário.

Erros comuns

  • Achar que o CRM "preserva a memória do vendedor". Nenhum software preserva memória; preserva registro. O que não foi escrito sai pela porta na sexta.
  • Tratar o ERP como se guardasse relacionamento. Ele guarda transação. Confiar que "está tudo no sistema" é descobrir tarde que está tudo, menos o motivo.
  • Cobrar o registro narrativo no momento errado. Exigir relatório de visita no fim do mês produz ficção. O registro precisa ser barato e imediato.
  • Deixar a anotação privada por padrão. Se a conversa é visível só para quem escreveu, a empresa pagou pelo registro e não ficou com ele.

Como isso se aplica no zCRM

A dor: quando alguém sai, a carteira volta ao zero. E o CRM comprado para resolver isso costuma cobrar digitação do que já existia.

O que o zCRM usa hoje. As contas nascem vinculadas ao ERP (crm_accounts.erp_entity_id): no primeiro dia o vendedor abre uma conta e já encontra doze meses de notas, pedidos em aberto, propostas e títulos, sem ninguém ter digitado nada. Sobre esses dados o produto calcula o que a memória não calcularia. O RFM sai das notas não canceladas numa janela de 12 meses, gravado por conta em crm_account_metrics por job de sincronização — a recência pontua 5 até 30 dias, 3 até 90, e cai para 1 acima de 180 dias ou sem compra. A tendência de receita compara a janela recente com a anterior comparável: queda maior que 40% subtrai 15 pontos da saúde; voltar a comprar depois de uma janela zerada soma 8. E a aba Produtos identifica o "comprava e parou" comparando janela atual com a anterior — a ausência que ninguém lembra.

A metade narrativa mora em crm_interactions, com resumo, detalhes, participantes, resultado, sentimento e próximo passo, preenchidos à mão. A timeline da Conta 360 registra eventos com tipo, data, descrição e vínculo com oportunidade ou atividade — interaction_recorded, visit_updated, account_updated —, para que um terceiro reconstrua a história sem entrevistar quem saiu. E a interação tem visibility com três valores: private, team e manager. Marcar como privada é legítimo, e é também escolher manter aquilo como memória de uma pessoa.

A decisão que muda. Em vez de "o que eu lembro deste cliente", a pergunta vira "o que aconteceu aqui e o que foi dito sobre isso" — e a primeira metade da resposta já está pronta antes de alguém abrir o sistema.

O limite honesto. O zCRM não preserva a memória do vendedor: preserva o que foi registrado. Não há captura automática de canal — o campo channel é preenchido à mão, e nenhuma integração registra WhatsApp, e-mail ou ligação sozinha. Isso se discute no mercado de CRM; no zCRM, ainda não se faz. E, por desenho, conta vem do ERP: não existe model de Lead, então o histórico de quem ainda não comprou não existe no produto. Metade do histórico continua dependendo de gente. O que o produto faz é não desperdiçar essa gente digitando a metade que já era de graça.

Próxima leitura

  • CRM integrado ao ERP: como carregar histórico no primeiro dia.
  • Conversas no CRM: o que registrar sem transformar o vendedor em digitador.
  • Conta 360: tudo que a PME precisa saber antes de atender um cliente.