- Sem chave única, cada canal vira uma fábrica de duplicatas (formulário, WhatsApp, importação, ERP, SDR).
- A melhor chave depende do objeto: Contato raramente é só e-mail; Empresa raramente é só CNPJ (e depende do seu modelo).
- Integração saudável faz upsert (atualiza se existe), não criação cega.
- Normalização (E.164 para telefone, e-mail em lowercase, remoção de máscaras) costuma valer mais do que “campo obrigatório”.
- Decisão de identidade é governança: precisa de dono, regra escrita e exceções previstas.
1) Separe “identidade” de “atributos”
Antes de mexer no CRM, liste quais campos provam que é a mesma pessoa/empresa (identidade) e quais só descrevem o registro (atributos). Ex.: identidade de Contato pode incluir e-mail e telefone normalizado; cargo e empresa onde trabalha são atributos (mudam com o tempo).
2) Escolha a estratégia por objeto (Contato, Empresa, Negócio)
Defina uma chave por objeto. Não copie a regra de Contato para Empresa. Em muitos CRMs, Contato e Empresa têm comportamentos diferentes de mesclagem, busca e associação. Para Negócio/Deal, normalmente a chave não é um documento; é uma combinação do contexto (ex.: Empresa + Produto + Período) para evitar negócios duplicados do mesmo ciclo.
3) Padronize formatos antes de comparar (normalização)
Crie regras técnicas simples: e-mail sempre em lowercase e sem espaços; telefone sempre em E.164 (com DDI + DDD); documentos sem máscara (só dígitos); nomes com trim (sem espaços duplos). Comparar dado “sujo” é o principal motivo de duplicidade silenciosa.
4) Defina precedência quando houver conflito
Decida quem manda quando dois sistemas discordam. Ex.: telefone vindo do WhatsApp pode ser mais confiável do que um campo digitado à mão; razão social e CNPJ podem vir do ERP; e-mail pode vir do formulário. Sem precedência, a integração vira ‘cabo de guerra’ e o CRM oscila dados.
5) Configure regra de criação: bloquear, alertar ou permitir com revisão
Há três modelos comuns: (a) bloquear criação se a chave existir; (b) permitir mas alertar e sugerir mesclagem; (c) permitir e mandar para uma fila de revisão (data steward/RevOps). O certo depende do volume e do custo do erro: bloquear demais trava vendas; permitir demais vira lixão.
6) Ajuste integrações para fazer UPSERT (criar-ou-atualizar)
Integrações devem procurar o registro pela chave e atualizar se encontrar. Quando a plataforma não suporta upsert nativo, a integração precisa implementar busca + atualização de forma consistente. Evite múltiplas chaves diferentes por canal (ex.: um sistema usando e-mail, outro usando telefone) sem uma regra central.
7) Trate exceções reais (e não finja que não existem)
Exemplos comuns: e-mail compartilhado (financeiro@), telefone de central, CPF ausente em lead, CNPJ de matriz usado para filiais, pessoa com dois números. Documente a exceção e defina o que fazer: criar como ‘contato genérico’, associar como ‘ponto de contato’, ou exigir verificação humana.
8) Crie rotina de monitoramento e correção (contínua)
Estabeleça um relatório recorrente de suspeitas de duplicidade (mesma chave, chaves parecidas, coincidência parcial). Não precisa inventar meta numérica: acompanhe tendência e impacto operacional (tempo perdido, erros de roteamento, mensagens duplicadas). A rotina vale mais do que uma “faxina anual”.
O que é “chave única” no CRM (e o que ela não é)
Chave única é o critério que garante unicidade de um registro: se já existe, não nasce outro igual. Em CRM, isso pode ser um campo único (unique) ou uma regra composta (e-mail OU telefone, por exemplo), dependendo das limitações da ferramenta.
Ela não é sinônimo de “campo obrigatório”. Tornar telefone obrigatório não impede duplicidade se o time digitar em formatos diferentes, se o WhatsApp chegar com DDI ausente, ou se o lead usar outro número no segundo contato.
Como escolher a chave de Contato: e-mail, telefone ou documento?
No Brasil, e-mail sozinho é frágil em B2C e em operações com WhatsApp forte: muita gente troca e-mail, usa mais de um, ou nem preenche. Telefone costuma ser mais estável — mas só funciona bem com normalização (E.164) e regras para números compartilhados.
Documento (CPF) é ótimo para unicidade, mas nem sempre você pode coletar no primeiro contato (por LGPD, fricção de conversão e pelo tipo de lead). Quando não dá para usar CPF, a abordagem prática é uma chave composta com priorização: tentar CPF; se não houver, usar telefone; se não houver, usar e-mail.
| Opção de chave | Quando funciona bem | Onde costuma quebrar | Mitigação prática |
|---|---|---|---|
| B2B, inbound com formulários completos, vendas consultivas | E-mails genéricos (contato@), troca de e-mail, typos | Validação de formato, sugestão de mesclagem, evitar e-mail genérico como chave única | |
| Telefone (normalizado) | Operação WhatsApp/telefone, B2C, SDR com discador | Número compartilhado, DDI ausente, números temporários | E.164, regras para números de central, permitir múltiplos telefones por contato |
| CPF | Cadastro mais avançado, crédito, contratos, pós-venda | Não disponível no topo do funil, restrições de coleta/uso | Coletar só quando necessário, guardar consentimento e finalidade, trilha de auditoria |
| Chave composta (CPF > telefone > e-mail) | Jornadas mistas e omnichannel | Conflitos quando dados chegam em ordem diferente | Regra de precedência + fila de revisão para colisões |
Empresa/Conta: por que CNPJ nem sempre resolve sozinho
Para Empresa, CNPJ parece a resposta perfeita — até aparecerem matriz/filiais, unidades de negócio, franquias, revendas e grupos econômicos. Dependendo do seu modelo comercial, você pode querer uma ‘Conta’ por CNPJ, ou pode querer uma conta por grupo (com vários CNPJs associados).
A recomendação editorial aqui é: decida primeiro como sua operação vende e atende (território, contrato, faturamento, suporte). Só depois fixe a chave. Caso contrário, você cria unicidade técnica e bagunça operacional.
- Se o contrato e o atendimento são por CNPJ: use CNPJ (sem máscara) como chave forte.
- Se o relacionamento e a negociação são por grupo econômico: crie “Grupo” como objeto/nível e relacione CNPJs abaixo.
- Se o pipeline é por unidade (ex.: filial compra independente): trate filial como conta separada, mesmo dentro do grupo.
Regras de integração: o detalhe que evita duplicata ‘invisível’
Duplicidade raramente nasce do usuário; nasce da integração que não encontra o registro existente e cria outro. Por isso, a regra central é: integração precisa buscar pela chave e fazer upsert.
Quando há múltiplas fontes (site, WhatsApp, ERP, plataforma de pagamento), defina também qual fonte pode criar registros novos. Em muitos cenários, faz sentido restringir “create” a 1–2 fontes e obrigar o resto a “match + update”.
Perguntas frequentes
Posso usar só e-mail como chave única no CRM?
Telefone como chave única dá problema com números compartilhados?
Como evitar que uma integração crie duplicatas mesmo com chave definida?
Mesclar registros (merge) é sempre seguro?
Leia também
Como evitar duplicidade de contatos no CRM: regras e rotina (sem travar o time)
Guia prático para reduzir contatos/empresas duplicados no CRM com regras de cadastro, validações, deduplicação e uma rotina leve de higiene de dados.
Ler →
Governança de integrações no CRM: como evitar dados duplicados e automações conflitantes
Guia prático para organizar integrações do CRM (WhatsApp, e-mail, ERP, formulários e automação), definir dono, versionar mudanças e impedir contatos duplicados e fluxos que brigam entre si.
Ler →
Data lineage no CRM: como mapear origem, transformações e destino dos dados (sem parar a operação)
Guia prático de data lineage no CRM: como descobrir de onde vêm os dados, por onde passam (integrações/ETL) e onde são usados em relatórios e automações.
Ler →
Integração do CRM em tempo real vs. em lote (batch): quando escolher e como evitar caos de dados
Comparativo prático entre integrar o CRM em tempo real (eventos/webhooks) ou em lote (batch): latência, custo, confiabilidade, governança e como decidir sem criar duplicidade e conflitos.
Ler →