Por que esse tema virou central (e por que não é só “tirar duplicado”)
Duplicidade sempre existiu, mas o CRM moderno passou a receber entrada de dados por mais portas: formulários, WhatsApp, ligações, eventos, lojas, marketplaces, parceiros, chat e automações. O resultado é previsível: a mesma pessoa vira 3, 5, 8 registros — cada canal com um identificador diferente.
Identity resolution vai além da deduplicação “por e-mail igual”. Ela tenta montar a identidade com sinais fracos e fortes, aceita mudanças ao longo do tempo (troca de número, e-mail corporativo novo) e lida com relações: pessoa x empresa, matriz x filial, sócio x contato técnico.
Como funciona na prática: sinais, regras e níveis de confiança
Quase todo processo sério de resolução de identidade combina duas abordagens: matching determinístico (certeza alta) e matching probabilístico (hipótese com score). O CRM pode fazer isso nativamente, via integrações, ou com uma camada de dados (CDP/MDM/ETL).
O ponto editorial aqui: a tecnologia ajuda, mas a política de dados manda. Sem regra clara, o time “ganha” um CRM aparentemente limpo e perde a rastreabilidade.
| Tipo de sinal | Exemplos | Confiabilidade típica | Onde costuma dar errado |
|---|---|---|---|
| Forte (determinístico) | CPF/CNPJ, e-mail único validado, ID interno, número de contrato | Alta | Campos vazios/errados; e-mails compartilhados (ex.: financeiro@); CPFs digitados com erro |
| Médio | Telefone/WhatsApp, endereço, domínio da empresa, razão social | Média | Números reciclados; centrais telefônicas; empresas com grupos e filiais |
| Fraco (probabilístico) | Device, IP, cookies, comportamento, similaridade de nome | Baixa a média | Família usando o mesmo aparelho; redes corporativas; homônimos; abreviações |
Quando unificar (merge) e quando só vincular (linkar)
Um erro comum é tratar todo “parecido” como duplicado e fazer merge automático. Em CRM, o dano de um merge errado costuma ser maior do que o custo de dois registros que deveriam ser um.
A alternativa é trabalhar com vínculo: manter registros separados, mas relacioná-los (mesma pessoa com e-mails diferentes; mesma empresa com filiais; mesmo contato que virou fornecedor).
- Faça merge automático apenas com identificadores fortes (ex.: CPF/CNPJ + regra de validação, ou e-mail verificado).
- Para telefone/WhatsApp, prefira: sugerir merge para revisão humana ou exigir segundo fator (ex.: nome + e-mail).
- Para empresas, trate matriz/filial como hierarquia, não como duplicidade.
- Guarde trilha de auditoria: quem mesclou, quando, e quais campos prevaleceram.
Regras de ouro para não “limpar” a base e estragar o histórico
Identity resolution mexe no coração do CRM: histórico de conversas, ownership do lead, SLA, relatórios e atribuição de receita. Se o merge for agressivo, você cria um CRM que parece organizado, mas passa a contar histórias erradas.
Sem números mágicos: o limiar de confiança (score) depende do seu risco operacional. Atendimento e cobrança pedem mais rigor do que marketing.
- Defina precedência de campos (ex.: dados de faturamento prevalecem sobre formulário; dado informado pelo cliente prevalece sobre enriquecimento).
- Bloqueie merge em estágios críticos (ex.: cobrança em aberto, disputa, contrato ativo) ou exija dupla validação.
- Separe “identidade” de “contato”: uma pessoa pode ser contato em mais de uma conta (B2B).
- Crie um fluxo de exceções: registros “suspeitos” vão para fila de revisão, não para automação.
Checklist rápido: o que avaliar antes de ativar qualquer automação de identidade
Se você está considerando IA/automação para isso, comece pelo básico. A maioria dos problemas nasce de padrões de cadastro, campos livres demais e integrações que escrevem em lugares errados.
| Pergunta | Se a resposta for “não” | Risco |
|---|---|---|
| Você tem regras de nome e padrões de cadastro? | Padronize antes | Duplica por variação de escrita (ex.: José da Silva vs. J. Silva) |
| Existe um identificador mestre (ID) por contato/conta? | Crie um ID interno e preserve | Integrar vira loteria; histórico se perde em migrações |
| Há log de alterações e merge/unmerge? | Exija trilha de auditoria | Impossível corrigir erros sem apagar a verdade |
| Integrações respeitam o modelo de dados (campos certos)? | Revise mapeamento | Dados “bonitos” no lugar errado viram ruído para sempre |
Perguntas frequentes
Identity resolution é a mesma coisa que deduplicação no CRM?
Dá para fazer resolução de identidade só com e-mail e telefone?
Qual é o maior risco de automatizar merge de contatos?
Como isso se relaciona com Customer 360 e governança de dados?
Termos relacionados
O que é Customer 360 no CRM? Visão Completa do Cliente em 2026
Entenda o conceito de Customer 360 no CRM, seus benefícios práticos e os desafios para empresas brasileiras alcançarem uma visão unificada do cliente em 2026.
Ler →
Como higienizar a base do CRM: tirar duplicado e dado morto sem quebrar histórico
Passo a passo para higienizar a base do CRM sem quebrar histórico: deduplicar por e-mail/telefone, padronizar campos, marcar inativo e criar rotina trimestral.
Ler →
Governança de dados no CRM: como definir regras sem travar o time
Guia editorial para montar governança de dados no CRM: padrões de cadastro, dono do dado, permissões, qualidade e auditoria. Com passos e FAQ para não virar burocracia.
Ler →
Campo personalizado no CRM: o que criar (e o que não criar) para não sujar a base
Guia editorial sobre campo personalizado no CRM: critérios práticos para criar só o que vira decisão/segmentação, evitar texto livre, padronizar valores e manter a base limpa sem matar a adoção do time.
Ler →