Cadastros do CRM, ERP, billing, planilhas e atendimento
Normalizar, anular chaves genéricas e casar em cascata
Uma linha por pessoa ou empresa e o mapa de origem
Métricas por cliente, campanhas, CRM limpo e agente de IA
O que resolve
- Cada cliente é contado uma vez, mesmo com cadastros no CRM, no ERP, no billing e em planilhas.
- Pessoas diferentes que dividem telefone ou e-mail param de virar uma só.
- Cada fusão diz por qual chave foi feita e pode ser revista.
Perguntas de negócio que responde
Faça estas perguntas ao seu agente quando o caso estiver pronto.
O que você precisa
- Os sistemas que guardam cadastro de cliente conectados na Nekt
- Pelo menos uma chave forte em parte da base: CPF, CNPJ, e-mail ou o id de um sistema gravado no outro
- Um dono para revisar os casos duvidosos
O que você recebe
- Uma tabela de entidades únicas com o melhor valor de cada campo
- O mapa de cada cadastro de origem para a entidade, com método e confiança
- Uma fila de pares duvidosos para revisão humana
- Um agente de IA que encontra o cliente por qualquer documento, e-mail ou telefone
Onde ativar
LTV, cohort, churn e inadimplência leem a entidade, não o cadastro de origem.
Segmentos de reativação e cross-sell saem da base única, com opt-out respeitado por pessoa.
Fusões confirmadas voltam ao CRM por reverse ETL, com o id da entidade gravado no contato.
Regras exatas em cascata resolvem a maior parte da base. O casamento probabilístico só entra quando falta documento, e aí o trabalho passa a ser calibrar e revisar. O detalhado traz as regras de negócio, as armadilhas e o teste de aceitação. Ou mande tudo direto para o seu agente com o MCP da Nekt.
O mesmo cliente aparece com nome, telefone e documento diferentes em cada sistema, e várias vezes dentro do mesmo CRM. Numa base real, nenhum cliente da lista do contas a receber casava pelo nome com o contato do CRM. Quem cruza por nome não acha nada, e quem cruza só por telefone ou e-mail junta familiares, colegas e o número da recepção num cliente só. O resultado é LTV, inadimplência e campanha calculados sobre identidades erradas.
Como costuma ser feito, e a regra
Cada linha é um erro que já aconteceu na prática.
CPF e CNPJ só com dígitos, completados com zeros à esquerda até 11 (CPF) ou 14 (CNPJ): documento lido como número perde o zero inicial e não casa. E-mail em minúsculas, sem espaços e validado por formato. Telefone só com dígitos, sem o 55 quando sobram 12 ou 13 dígitos, ficando com 10 ou 11. Nome em maiúsculas, sem acento e sem sufixo societário (ltda, me, epp, eireli, s/a).
CPF com todos os dígitos iguais (00000000000, 11111111111), dígito verificador inválido ou em notação científica, telefone vazio, '0' ou '55' e e-mails de preenchimento (naotem@, sememail@) viram nulo. Valide o dígito verificador de CPF e CNPJ. Um placeholder usado como chave junta centenas de pessoas num cliente só.
Telefone da recepção, e-mail do financeiro, e-mail do corretor ou do vendedor interno aparecem em muitos cadastros. Mantenha uma lista de bloqueio com os endereços internos e aplique um teto de frequência: telefone ou e-mail presente em mais de 5 cadastros distintos deixa de ser chave. Nome que aparece mais de 20 vezes também não serve para agrupar candidatos.
1) Id de um sistema gravado no outro (campo customizado com o id do ERP ou do CRM antigo). 2) CPF ou CNPJ válido. 3) E-mail. 4) Telefone. Colete os matches de todas as regras e fique, para cada cadastro, com a regra de maior prioridade. Grave em cada vínculo qual regra casou.
E-mail e telefone iguais servem para achar candidatos e para corroborar. O nome decide: se o primeiro nome for muito diferente, o par não é a mesma pessoa, mesmo com e-mail e telefone idênticos, porque familiares e colegas dividem o contato. Numa base real, telefone sozinho gerava dezenas de vezes mais pares do que nome mais telefone. Só CPF ou CNPJ igual confirma sem olhar o nome.
Ao ligar evento, ticket, mensagem ou venda a um cadastro por telefone ou e-mail, use apenas as chaves que apontam para um único cadastro. Chave que aponta para dois ou mais fica sem vínculo e vai para a fila, em vez de escolher um ao acaso.
Escolha o registro principal pela completude (quantos de CPF, e-mail, telefone, nome e data de nascimento estão preenchidos), desempatando pela data de modificação mais recente e depois pelo id. Campos vazios no principal são completados pelos secundários. O desempate tem de ser determinístico, senão cada execução escolhe um vencedor diferente.
A mesma pessoa pode ser lead, cliente, proprietário, locatário, fiador, investidor ou parceiro. Crie uma entidade por pessoa e uma linha de vínculo por papel, em vez de um cadastro por papel. Quando lead e cliente coexistem, o cliente prevalece.
Para PJ, a entidade é o CNPJ completo, de 14 dígitos. A raiz do CNPJ (8 primeiros dígitos) junta matriz e filiais: guarde como coluna de grupo, nunca como chave de fusão. Documento de 11 dígitos é PF; marcadores no nome (ltda, me, s/a) ajudam a separar PF de PJ quando o documento falta.
Mantenha um mapa de cada id de origem para a entidade, atualizado por upsert, com método, confiança e data. Pares de baixa confiança (nome mais telefone, sem documento) vão para uma fila de revisão humana, e as decisões manuais ficam numa tabela com quem decidiu e por quê. Fusões já feitas na fonte, como hs_merged_object_ids do HubSpot, entram no mapa para que ids antigos continuem encontrando a entidade.
O que cada chave pode fazer
Da mais forte para a mais fraca. Grave em cada vínculo qual delas foi usada.
Definições
Armadilhas que já aconteceram
Uma planilha do ERP guardava um único registro de empresa para várias pessoas. A primeira rodada de criação de contatos no CRM gravou telefone, e-mail e CPF de uma pessoa em outra, e mais de uma centena de contatos teve de ser corrigida.
Separe pessoa de empresa antes de criar ou fundir, e nunca herde contato de um registro de empresa.
A carga de origem gravava cada cadastro duas vezes, com conteúdo idêntico. Toda contagem feita direto na tabela bruta saía em dobro.
Remova duplicatas exatas na entrada, antes de qualquer match, e compare linhas com ids distintos.
Tabelas do ERP mantinham linhas marcadas como excluídas (deleted, ou D_E_L_E_T_ no TOTVS). Elas casavam com cadastros vivos e duplicavam clientes e títulos.
Filtre registros excluídos antes de casar.
Sem CPF nem e-mail em comum, o mesmo cliente ficou espalhado em quatro cadastros, um como cliente num sistema e três como leads em outro CRM, todos com o mesmo telefone.
Use nome mais telefone como sinal para revisão humana, não como fusão automática.
A casava com B pelo telefone, B casava com C pelo e-mail, e A e C, que não tinham nada em comum, viravam a mesma pessoa.
No modelo probabilístico, gere pares com limite permissivo e forme os grupos com limite estrito (por exemplo, 0,85 e 0,95).
Dois cadastros empatados no critério de escolha eram resolvidos sem desempate, e o registro principal mudava de uma execução para outra.
Desempate fixo por data de modificação e, por último, pelo id.
Teste de aceitação
O caso está pronto quando todos os itens passam.
- Cada cadastro de origem (sistema + id) aparece em exatamente uma entidade do mapa.
- Nenhuma entidade tem dois CPFs ou dois CNPJs completos distintos.
- Nenhuma fusão usou como chave um placeholder (CPF com dígitos iguais, e-mail de preenchimento, telefone curto) ou uma chave acima do teto de frequência.
- A soma de compras ou receita por entidade é igual à soma por cadastro de origem, sem diferença.
- Rodar o processo duas vezes sobre os mesmos dados gera as mesmas entidades e os mesmos registros principais.
Pacote para o agente
Cole no Claude, ChatGPT ou outro cliente com o MCP da Nekt conectado.
Identidade de pessoas e empresas - Cliente = entidade da tabela de identidade (1 linha por pessoa ou empresa). Conte e some por ela, nunca pelo cadastro de origem. - Para achar um cliente, normalize a busca: CPF e CNPJ só dígitos (11 e 14 posições), e-mail em minúsculas, telefone só dígitos e sem 55. - Ordem de confiança dos vínculos: decisão manual > id gravado em outro sistema > CPF ou CNPJ > e-mail > telefone. Nome sozinho nunca confirma. - Telefone ou e-mail compartilhado por várias entidades é chave ambígua: não ligue evento nem venda por ele. - PJ: a entidade é o CNPJ completo. A raiz do CNPJ é o grupo econômico, em coluna separada. - Uma pessoa pode ter vários papéis (lead, cliente, proprietário, locatário, fiador, parceiro). Quando lead e cliente coexistem, vale cliente. - Contas internas, de teste e e-mails da própria empresa não são clientes. - Se o vínculo de uma resposta foi por telefone ou e-mail, diga isso. Se o cadastro não está no mapa, diga que não foi resolvido em vez de adivinhar. Exceções por cliente: - <cliente>: e-mails e telefones internos na lista de bloqueio: <lista>. - <cliente>: campo <campo> do CRM guarda o id do ERP e é a chave mais forte. - <cliente>: teto de frequência de <n> cadastros por telefone ou e-mail.
Construa no meu workspace Nekt o caso "Deduplicação e entity resolution" seguindo as regras em https://academy.nekt.com/casos/deduplicacao-de-cadastros.md. 1) Encontre as tabelas de origem e confirme as colunas usadas pelas regras. 2) Crie uma transformação no grão indicado aplicando todas as regras. 3) Rode o teste de aceitação e me mostre o resultado de cada item. 4) Crie o context document do caso no workspace, com as exceções dos meus clientes em aberto para eu preencher.
Variações
Sem documento, um modelo Fellegi-Sunter (por exemplo, com Splink) agrupa por chaves limpas e respeita uma regra negativa: nenhum grupo pode ter dois CPFs distintos.
A mesma lógica acha imóveis repetidos entre agências pelo endereço normalizado: número sem zeros à esquerda e apartamento extraído do complemento.
Para PJ, a base pública de CNPJ confirma o documento e completa razão social, CNAE e situação cadastral.