O relatório por produto fecha em R$ 380 mil. O faturamento do mês fecha em R$ 383 mil. Mesmos dados, mesmo ERP, mesmo período — e a diferença de R$ 3 mil não tem explicação. O dono desconfia do CRM, o gerente desconfia do dono, todo mundo volta para a planilha.
O CRM não errou a conta. Existem oito notas em que o total do cabeçalho não bate com a soma dos itens. O defeito estava lá antes de qualquer integração — só faltava uma pergunta que o forçasse a aparecer.
Defeito de cadastro é uma coisa concreta
"Qualidade de dados" soa como assunto de auditoria. Na PME, é bem mais chão de fábrica:
Documento com dígito verificador errado. Alguém digitou o CNPJ com um número trocado. O ERP aceitou, porque a maioria aceita. O cadastro parece perfeito na tela — quatorze dígitos, pontuação certa — e é inválido. Descobre-se na hora de emitir.
Zero à esquerda comido. O documento está certo. Só que em algum ponto da vida ele passou por um sistema que o tratou como número, e número não começa com zero. Um CNPJ iniciado em 0 virou treze dígitos.
Documento duplicado. O mesmo comprador foi cadastrado duas vezes — filial nova, vendedor diferente, código diferente. Agora ele é dois clientes pela metade.
Nota que não fecha com os itens. Cabeçalho diz um valor, a soma das linhas diz outro. Origem quase sempre banal: desconto lançado no total e não rateado, item cancelado que não voltou para a soma.
Essas quatro coisas não são o mesmo problema com nomes diferentes. A primeira quebra a emissão. A segunda quebra comparação de texto. A terceira quebra o histórico. A quarta quebra a soma. Um remédio não serve para as outras três.
O zero à esquerda merece parágrafo próprio
Dos quatro, esse é o mais cruel, e é o que quase nenhuma empresa procura.
O documento é válido: mostre para o contador e ele dirá que está certo — e está. Mas quando outro sistema compara o texto 1234567000189 com o texto 01234567000189, são duas strings diferentes. Deduplicação não pega. Conciliação não pega. Nenhuma integração que case cliente por documento pega.
O efeito prático: o cliente que você jura ter um cadastro só tem dois, e nenhuma consulta visual revela isso, porque os dois documentos estão certos. Só aparece para quem calcula os dígitos verificadores e testa completar o zero.
Duplicado não infla só a carteira — ele divide o histórico
Todo mundo entende que cadastro duplicado incha a contagem de clientes. Poucos param para pensar no resto.
Um cliente que compra todo mês, dividido em dois cadastros, vira dois clientes que compram a cada dois meses. A recência de cada metade fica pior do que a verdade; a frequência e o valor, pela metade.
O indicador não fica só impreciso: ele mente na direção errada, para os dois. Um cliente saudável aparece como dois clientes mornos — e nenhum dos dois entra na lista de quem merece atenção, porque nenhum dos dois parece grande o bastante.
Integrar não conserta, e não deveria
Aqui está a parte que costuma decepcionar na reunião: ligar o CRM no ERP não melhora nada disso. Nenhuma integração adivinha qual dos dois cadastros é o bom, nem decide se o desconto era do cabeçalho ou da linha. São decisões de negócio, e quem tem contexto para tomá-las é gente, não software.
O que um CRM honesto faz é diferente, e é útil: ele nomeia o defeito, conta quantos são e mostra quem são. Cura é trabalho humano dentro do ERP. Diagnóstico é o que dá para automatizar — e é o que faltava.
Diagnóstico só vira trabalho com nome e contagem
Um diagnóstico que diz "seu cadastro tem problemas" não gera ação nenhuma. Três coisas transformam constatação em tarefa.
Contagem sobre uma base real. "43 clientes sem vendedor" é diferente de "43 clientes sem vendedor em 1.200 ativos". O primeiro assusta, o segundo dimensiona. Sem denominador, todo número é grande ou pequeno conforme o humor de quem olha.
Nome, não código. Lista de identificadores internos é ruído — ninguém corrige o que não reconhece. "Tintas Aurora Ltda · doc 12.345.678/0001-95" é lista de trabalho: quem lê já sabe quem ligar.
Uma saída para fora. A correção não acontece na tela do diagnóstico, e sim no ERP, por uma pessoa, com a lista do lado. Se a lista não sai da tela, o diagnóstico morre ali.
Erros comuns com qualidade de cadastro
- Esperar o cadastro ficar bom para começar. Ele nunca fica: entra cliente novo toda semana. O que funciona é medir, corrigir o que dói e voltar a medir.
- Tratar todos os defeitos como iguais. Cliente sem cidade atrapalha roteirização de visita. Documento duplicado corrompe indicador. Os dois são "cadastro incompleto"; só um justifica parar a semana.
- Corrigir sem entender a origem. Se o zero some porque uma rotina de importação trata documento como número, você corrige os mesmos cadastros no mês que vem.
- Confundir schema com conteúdo. Que a view existe e tem as colunas certas não diz nada sobre o que está dentro delas.
- Usar o diagnóstico como acusação. A lista serve para corrigir, não para descobrir quem digitou errado em 2019.
Como isso se aplica no zCRM
O ponto de ruptura é este: quando um número do CRM destoa da percepção de alguém, a discussão vira opinião — e o CRM perde, porque é o novato na sala.
O zCRM tem uma tela de saúde dos dados do ERP que roda 18 checagens em dois blocos. Buracos de cadastro: clientes sem vendedor, sem CNPJ/CPF, documento inválido, documento sem zeros à esquerda, sem contato, contato com e-mail inválido, item de pedido em aberto sem data de entrega, produto sem descrição, produto sem unidade. Consistência e integridade: nota com total diferente da soma dos itens, documento duplicado, vendedor referenciado que não existe, entidade inativa com carteira aberta, nota sem vendedor, proposta aberta e vencida, cliente sem segmento, sem UF, sem cidade.
Cada checagem devolve severidade, a consequência comercial em texto, a contagem, uma amostra de dez registros e a população-base — o resultado é "% ok" sobre um denominador real, não um número solto. A amostra vem com nome, nunca com identificador cru. A validação de documento calcula os dígitos de verdade e separa "inválido" de "sem zeros à esquerda", porque são defeitos distintos com causas distintas. Empresas do exterior ficam fora do teste de documento de propósito: não têm CNPJ mesmo, seriam falso positivo. A comparação de notas olha os últimos 90 dias com tolerância de um centavo e mostra os dois valores lado a lado — "cabeçalho R$ X vs itens R$ Y". Se uma view faltar, degrada só aquela linha e o relatório continua de pé. As listas saem em CSV.
A frase que trava o projeto ganha destino: "o número do CRM está errado" vira "o dado do ERP está assim, e são estes N cadastros, com nome" — e alguém no ERP corrige, com prazo.
O limite honesto: o zCRM não escreve no ERP. Não existe botão de corrigir, deduplicar ou completar zeros — a lista sai, a correção acontece lá. Também não há enriquecimento externo: nada de consultar base de CNPJ, higienizar e-mail ou completar endereço por CEP. E as 18 checagens não são um retrato completo da qualidade do seu cadastro: são as que afetam decisão comercial nas views que o CRM usa. O produto torna o problema visível e contável. Isso não é a mesma coisa que melhorar o dado — e chamar de melhoria seria mentira.
Coisa diferente e complementar: o comando de validação checa o contrato das 17 views da integração (existência, colunas, tipos). Schema é uma coisa. Qualidade do conteúdo é outra.
Próxima leitura
- Gestão comercial orientada por dados: o que medir além do faturamento.
- Checklist do primeiro dia: quais dados do ERP carregar no CRM.
- Como implantar CRM em 30 dias sem tentar resolver tudo de uma vez.