Mesmo nome, mesmo contato? Peça evidências antes de mesclar o CRM

Dois contatos chamados Alex Chen trabalham na mesma empresa. O agente os mescla e combina históricos de vendedores diferentes. A lista fica menor; a relação com o cliente fica errada.

Nome ou campo igual não comprova uma pessoa única. A deduplicação de CRM com IA deve começar com candidatos, regras explícitas, contraevidências e lacunas. A pessoa que conhece a relação mantém a decisão.

O guia de CRM que você pode criar com Buda começa pela detecção. Uma chave que impede tarefas repetidas não resolve identidade de contatos.

Preserve oito linhas antes de tentar obter quatro

Todos os dados são fictícios. .example é reservado e não representa destino de contato. Não houve teste em CRM de produção. A data da fonte é 18 de outubro de 2026; na prática, preserve sistema e atualização de cada linha.

A:101 e B:101 têm o mesmo número em namespaces distintos. Não são o mesmo registro. Cite fonte e ID; não elimine uma linha como chave duplicada. Gerar candidatos, verificar identidade e mesclar são etapas distintas. Não há obrigação de produzir quatro pares.

Normalize só o valor de comparação

Guarde email_raw. Em uma cópia, remova espaços externos e converta o domínio para minúsculas, preservando a parte local. Ignorar maiúsculas da parte local exige regra explícita da fonte e equipe. Priya coincide sob essa regra, mas continua candidata.

Não remova +tag ou pontos do Gmail por padrão, nem universalize aliases de um provedor. Formato plausível não comprova validade, entrega ou dono. Enviar email de validação também ultrapassa a tarefa de leitura.

Preserve telefone original. Sem código de país, não complete pela sede da empresa. Sufixos iguais não são identificadores globais. Nome, domínio e cargo ajudam a buscar, não confirmam identidade isoladamente.

Três classes em vez de uma probabilidade inventada

Forte não significa aprovado. Empresas diferentes também não provam pessoas diferentes: S04 é confirmação explícita fictícia. Sem equivalente autorizado, mantenha desconhecido. Identidade e vínculo empresarial podem exigir objetos distintos.

Evite “92% de chance” sem calibração. Entregue regra acionada, contraevidência e confirmação necessária.

Um par precisa voltar às linhas originais

candidate-pairs.csv contém pair-id, namespaces, IDs, versão da regra, valores originais e comparados, datas, evidência, objeções, lacunas, classe e papel responsável.

Um identificador reproduzível pode ordenar os dois IDs e incluir a regra: v1|A:102|B:202. É convenção proposta, não trava nativa de idempotência do Buda. Repetir entrada e regra deve gerar o mesmo ID; esse aceite ainda não foi executado.

Não suponha transitividade. Pistas entre A/B e B/C não comprovam A/C. Examine caixa compartilhada, histórico e pessoas distintas antes de agrupar tudo.

conflicting-fields.md mantém valores, fonte e atualização. Os departamentos de Priya podem indicar mudança, datas de exportação ou erro. O responsável escolhe o valor; o mais recente não vence sozinho. O agente não altera owner, stage ou amount.

review-decisions.csv separa sugestão e decisão humana: mesma pessoa, diferentes ou evidência insuficiente, com verificador, base, data e próximo passo. Candidatos sem revisão não contam como duplicatas confirmadas.

Confirmar a pessoa não autoriza a mescla

Registros podem ligar atividades, oportunidades, tickets, assinaturas e permissões. Sem conferir registro principal, migração e desfazer nativo, não prometa reversão simples.

Mantenha exportação e candidatos somente leitura. Não conecte escrita de produção, exclua, mescle ou transfira dono. Após confirmar identidade, o administrador verifica campos e impacto nas relações; só executa com autorização explícita. A fila não substitui o CRM nem comprova integração testada com um fornecedor.

Faça uma passagem somente leitura no Buda

Coloque cópias anonimizadas, dicionário, regras e confirmações necessárias no Drive. Agent Drive e Space Drive têm escopos diferentes; uma Session nova não isola permissões de arquivo.

Leia somente cópias e regras nomeadas. Preserve namespaces, IDs e valores originais; normalize apenas comparação. Produza pares, conflitos e modelo de decisão com fonte, contraevidência e lacunas. Não invente probabilidades calibradas, escreva produção, exclua, mescle, envie ou altere campos de negócio.

Abra casos de homônimos, caixa comum, troca de empresa e múltiplos emails. Confira retorno às linhas e campos desconhecidos. Arquivo existente não prova precisão. Antes da governança ampla de RevOps, deixe claro o que merece investigação e quem decide.

Meça revisão, não quantidade de candidatos

Após verificação humana, precisão dos candidatos pode ser pares confirmados como mesma pessoa divididos por pares com verificação de identidade concluída. Separe evidência insuficiente do denominador verificado. Preserve classe e regra para localizar falsos positivos.

Isso não mede duplicatas perdidas. Recall exige conjunto representativo rotulado por pessoas; sem ele, marque não medido. Oito linhas didáticas não comprovam precisão de negócio nem economia de tempo.

Várias pessoas usam um email. E agora?

Trate como canal de contato, não pessoa única. Preserve contatos e funções, e confira suporte do CRM às relações. Email comum sozinho não autoriza mesclar.

Quem mudou de empresa pode ser o mesmo contato?

Sim, com evidência explícita autorizada. Separe empresa anterior, atividades e novo vínculo. Identidade confirmada não transfere oportunidades antigas.

Quem confirma?

O responsável pela relação verifica pessoa; o administrador verifica ligações e operação. Registre base, papel, data e campos. Sem apoio suficiente, mantenha pendente.

Pesquise e instale um Skill de dados no Marketplace do Buda AI. Leia regras e paradas antes de usar cópias anonimizadas. O primeiro objetivo não é uma lista curta: é um candidato defensável e alguém capaz de dizer “não mesclar”.