O dono abre o relatório e vê a Metalúrgica São Jorge com R$ 180 mil no ano. Cliente médio, comportado, sem risco. O que ele não vê é a segunda ficha — "Metalurgica S. Jorge Ltda", cadastrada por outro vendedor em 2023 — com mais R$ 240 mil. O cliente real fatura R$ 420 mil e é o terceiro maior da casa. Ninguém desconfia, porque os dois números estão certos. Cada um deles, sozinho, está certo.
É por isso que cadastro duplicado é pior do que cadastro faltando. Cadastro faltando dá erro: alguém procura, não acha, reclama. Cadastro duplicado dá resposta — só que a resposta é metade da verdade, e vem com cara de relatório.
O que a duplicidade destrói não é a digitação
O argumento contra duplicar cadastro costuma vir como higiene: "evita retrabalho, evita erro fiscal, poupa digitação". Tudo verdade, e tudo secundário.
O que um CRM integrado tem de único é a junção: ele amarra na mesma conta a nota fiscal, o pedido, o título vencido, a proposta parada, a visita de terça e a conversa de ontem. Todo o valor — RFM, recência, ticket, risco de perda, potencial não comprado — nasce dessa amarração.
Duplique o cadastro e a junção quebra na raiz. Dois cadastros do mesmo cliente são dois clientes que não somam:
- O RFM erra duas vezes. Uma ficha parece "sumida há oito meses" e entra na reativação; a outra compra todo mês. O vendedor liga oferecendo volta, e o comprador responde que fez pedido semana passada.
- O potencial mente. O cliente comprou abrasivos pela ficha A e ferramentas pela ficha B. Cada ficha mostra uma lacuna que não existe.
- A carteira se parte. Duas fichas, dois responsáveis, dois vendedores ligando no mesmo dia com discursos diferentes.
Nada disso aparece como erro na tela. Aparece como sistema funcionando.
A linha de propriedade: quem é dono de quê
A regra que evita isso não é "não digite duas vezes". É uma decisão sobre propriedade do dado, e ela se decide pela natureza do dado, não pelo sistema que é mais bonito ou mais novo.
O ERP é dono do que é fato oficial. Entidades, produtos, propostas, pedidos, notas fiscais e financeiro. Esses dados existem porque houve uma transação, têm consequência fiscal e contábil, e já têm um lugar onde nascem, são corrigidos e auditados. Nenhum deles melhora por ser recadastrado do lado de fora.
O CRM é dono do que é relacionamento. Contatos complementares, atividades, oportunidades, funil, conversas e histórico comercial. Esses dados não existem em lugar nenhum hoje — vivem na cabeça do vendedor e no caderno dele. Aqui o CRM não duplica ninguém: ele cria.
O teste: se o dado tem consequência fiscal ou contábil, é do ERP. Se só existe porque alguém conversou com alguém, é do CRM. E a linha tem uma implicação que assusta no começo: o CRM não corrige o cadastro do ERP. Nome errado, CNPJ errado, endereço velho — arruma-se lá, onde nasce. O CRM lê e mostra. Ele não é um cadastro melhor; é o outro lado do cliente.
O caso chato: quando o próprio ERP duplica
Às vezes a duplicidade não é culpa de ninguém no comercial. Muitos ERPs de grupo cadastram o mesmo cliente uma vez por empresa ou filial: a São Jorge tem ficha na matriz e outra na filial de Caxias, porque o ERP amarra cadastro à empresa que fatura. Se o CRM aceitar isso como está, importa a duplicidade e a torna oficial — o faturamento se parte ao meio como na abertura, agora com a bênção da integração.
E aqui vale dizer o que costuma ser escondido: a normalização não é automática. Ninguém tem um botão que adivinha que duas fichas são a mesma empresa. Quem resolve é a camada de leitura, definida na implantação: a visão de cliente é montada no nível do grupo, sem dimensão de empresa, unificando por código. A empresa continua existindo nas transações, que é onde ela é verdade — a nota é da filial de Caxias; o cliente não é. É trabalho humano, feito uma vez, por quem conhece o ERP daquela casa.
O outro dono disputado: o vendedor
Um campo dá briga toda vez, e mostra por que "quem é dono" se responde pela natureza do dado. O vendedor da nota fiscal é o vendedor daquela transação: histórico, imutável, base de comissão. A nota de março de 2024 foi vendida pelo Marcos e continua sendo do Marcos para sempre, mesmo que ele tenha saído da empresa. O vendedor do cadastro do cliente é o responsável atual: é carteira, muda quando a carteira muda, e decide quem enxerga a conta.
Dois donos, duas perguntas: "quem ganha a comissão desta venda?" e "quem cuida deste cliente hoje?". Confundi-las cria um bug clássico: o vendedor abre a conta que é dele e faltam as notas antigas, as que o antecessor vendeu. O 360 do cliente vira o 360 do vendedor. A regra que funciona: o acesso segue o responsável atual — quem vê a conta vê todo o histórico dela, inclusive o vendido por quem já saiu. Comissão é outro relatório.
Erros comuns nessa decisão
- Criar cadastro "só para essa oportunidade". Uma conta avulsa para não esperar o cadastro do ERP sair. Ninguém reconcilia depois, e o cliente passa a ter duas histórias.
- Usar o nome como chave. "Metalúrgica São Jorge" e "Metalurgica S. Jorge Ltda" não casam por texto, e nunca vão casar. A junção só é confiável por chave estável, tratada como identificador opaco.
- Deixar o campo aberto para digitação livre. Se o vendedor consegue digitar um cliente novo em vez de escolher um existente, ele vai fazer isso — não por má vontade, mas porque é mais rápido às 17h50. Vincular tem que ser mais fácil que criar.
- Tratar o nome exibido no CRM como cadastro. Guardar o nome para exibir é conveniência de tela, não posse do dado. Se virar campo editável, nasceu o segundo cadastro.
Como isso se aplica no zCRM
Tudo começa com uma conta que não soma: o cliente que parece médio e é grande, a reativação disparada para quem comprou ontem, os dois vendedores ligando no mesmo dia.
O zCRM guarda do cliente muito pouco, de propósito: a chave (erp_entity_id), o código, um cache do nome para exibição (erp_name) e os campos que são realmente dele — status comercial, temperatura, potencial e observações. Todo o resto é lido do ERP, sempre pelas visões de integração, que são somente leitura. O CRM nunca toca em tabela real do ERP.
A conta nasce vinculada: POST /crm/accounts/link-erp valida a entidade pela porta do ERP e cria a conta ou atualiza o vínculo, sem permitir dois cadastros com a mesma chave. A página de Contatos mostra a mesma linha: contatos do ERP e do CRM aparecem juntos, com filtro de origem (Todos, CRM, ERP) — o do ERP é leitura; o complementar, o celular do comprador que ninguém cadastrou oficialmente, é do CRM.
Daí sai decisão de verdade: quando o gestor abre um cliente, o número que ele vê é o número inteiro daquela empresa — e dá para decidir preço, crédito e prioridade em cima dele.
O limite, e ele é o preço desta regra: o zCRM não tem Lead. Não existe cadastro de prospect independente do ERP — por desenho, cliente e prospect vêm de lá. O topo do funil, o contato que ainda não é ninguém no sistema oficial, não existe no zCRM hoje. Quem vive de prospecção fria precisa saber disso antes de comprar. É consequência direta de ter escolhido uma única fonte oficial, e a escolha foi consciente: para uma PME B2B de carteira, a junção vale mais que o cadastro livre. Mas é um preço, não um detalhe.
Próxima leitura
- CRM integrado ao ERP: como carregar histórico no primeiro dia.
- Quais dados do ERP fazem diferença em um CRM comercial.
- Integrar CRM ao ERP sem trocar o ERP: o que a PME precisa saber.