Clientes duplicados: o que comparar antes de mesclar

Para revisar clientes duplicados, compare primeiro a identidade e a função de cada ficha; depois decida se é necessário mesclar. Um registro em vendas e outro em faturamento podem estar corretos. O que falta talvez seja uma correspondência confiável entre ambos.

O problema surge quando a administração encontra dois históricos semelhantes e alguém propõe ficar com “o mais completo”. Uma ficha pode conter o contato atual; a outra, as referências usadas por uma integração. Escolher pela quantidade de campos preenchidos não resolve esse conflito. Este guia oferece uma matriz e um registro de decisões para revisar o caso antes de modificá-lo.

Uma ficha por ferramenta pode ser o correto

Distinga a mesma entidade representada em dois sistemas de dois registros redundantes dentro de um. O primeiro caso pode precisar de um mapa de correspondências; o segundo, de uma investigação sobre a origem do duplicado. Nenhum autoriza apagar uma linha pelo seu nome.

Defina também o que cada registro representa: organização, pessoa de contato, unidade ou conta comercial. Uma pessoa que trabalha em uma empresa não é um duplicado dessa empresa. Duas unidades também não devem ser unidas se sua operação precisar tratá-las separadamente.

Esta revisão se encaixa na preparação de uma migração, mas também serve sem mudar de ferramenta. Seu resultado pode ser conservar duas fichas e explicar sua relação.

Preserve a origem antes de normalizar

Trabalhe com uma cópia somente para leitura. Para cada linha, guarde sistema, espaço de trabalho, tipo de registro, identificador original e data de extração. CRM / W1 / account / A17 identifica algo distinto de BILL / W1 / account / A17: repetir o número não demonstra que seja o mesmo cliente.

Mantenha os valores originais e crie colunas auxiliares para comparar espaços, maiúsculas ou variantes conhecidas do nome. Não elimine sufixos, departamentos ou referências que possam distinguir entidades. Um campo vazio significa “sem dado”, não “coincide com outro vazio”.

Anote de onde procede cada sinal. Um código comum tem mais valor se você souber quem o atribuiu e tiver verificado sua correspondência. Um código copiado em uma importação errônea pode propagar o mesmo erro para as duas fichas. A data da última edição também não converte automaticamente um valor em correto.

Uma matriz com três resultados e quatro casos

O exemplo seguinte é inteiramente fictício. Todos os registros pertencem ao espaço W1; os códigos ORG e EV são referências de exercício, não identificadores fiscais nem dados de clientes. Para o exercício, supomos que as evidências descritas estejam disponíveis apenas para mostrar o raciocínio.

Não atribua porcentagens de confiança inventadas. “Provável” abre uma revisão: não é uma mesclagem aprovada. “Ambíguo” conserva o bloqueio e explica o que falta. Mesmo quando você confirmar a identidade, ainda resta decidir se é necessário modificar algo.

A ausência de pedidos em uma ficha também não prova que ela está sobrando: pode ser um registro recente ou representar outra função. Classifique com evidência, não com o número de campos vazios.

O mapa de aliases não executa uma mesclagem

Suponhamos que o responsável resolva o primeiro caso: A17 e B62 representam ORG-07, mas ambas as ferramentas precisam de sua ficha. A decisão é conservá-las e registrar sua correspondência. Em uma planilha independente, ENTITY-F07 pode ser sua referência de trabalho:

system,workspace,record_type,source_id,entity_key,review_id
CRM,W1,account,A17,ENTITY-F07,R-01
BILL,W1,account,B62,ENTITY-F07,R-01

Estas colunas são um modelo próprio, não um formato de importação de Frihet nem uma ordem para um conector. entity_key agrupa identidades verificadas; source_id conserva a referência original. Um alias não modifica as ferramentas por existir em uma planilha.

Não agrupe pessoas, empresas e unidades sob a mesma chave. E não combine por transitividade sem revisar: se A se parece com B e B se parece com C, você ainda não demonstrou que A e C são a mesma coisa.

Registre uma decisão que outra pessoa possa revisar

Copie esta ficha para cada par. Conserve a proposta anterior quando a decisão mudar, com uma nova versão que a substitua.

Revisão: R-01 / versão 1
Referências completas: CRM/W1/account/A17; BILL/W1/account/B62
Evidência: EV-01; correspondência ORG-07 comprovada pelo responsável
Conflito: contato responsável distinto; valor vigente confirmado em EV-05
Decisão: conservar ambas as fichas e registrar correspondência ENTITY-F07
Responsável pela revisão: ROLE-OPS
Ação nas ferramentas: nenhuma
Pendente: revisar como o conector usa essa correspondência
Substitui: nenhuma revisão anterior

Os códigos são fictícios. Em uso real, referencie evidência acessível a quem deve revisá-la e evite copiar dados pessoais desnecessários na planilha. Se mais tarde uma modificação for autorizada, registre separadamente o executor, o momento, as referências anteriores e o resultado observado. “Aprovado”, “executado” e “verificado” são estados distintos.

Este histórico é revisável, não uma garantia de reversão. Retificar uma decisão escrita não reconstrói automaticamente os dados já modificados.

O que verificar no fornecedor antes de mesclar

O comportamento depende do produto e do tipo de registro. HubSpot documenta que uma mesclagem não pode ser desfeita e que os identificadores, propriedades e associações seguem regras específicas. Não presuma que o ID que você marcou como principal sempre sobreviverá intacto.

Shopify também adverte que a operação não é reversível e exclui certos perfis, como os que têm ou tiveram contratos de assinatura. Esses exemplos não descrevem o comportamento de Frihet nem do seu outro fornecedor.

Antes de qualquer ação irreversível, deixe estas perguntas respondidas:

• Essa combinação de tipos é suportada e você tem as permissões adequadas?
• Que valores são preservados, quais são descartados e qual ID o resultado terá?
• O que acontece com histórico, relacionamentos e referências externas?
• O que a sincronização fará: reconhecer a mudança, recriar uma ficha ou falhar?
• Que recuperação realmente existe e o que sua cópia não cobre?

Leia o escopo das integrações (em inglês) e verifique o contrato do conector utilizado. Uma função de leitura não demonstra que ele sabe propagar mesclagens.

Encerre o caso verificando também sua origem

Se uma mesclagem for autorizada, primeiro defina como limitar seus efeitos sobre os sistemas conectados. Teste com dados sintéticos em um ambiente de teste compatível; se não existir, mantenha o bloqueio até resolver as incógnitas com o fornecedor. Uma exportação isolada não demonstra que você pode restaurar tudo.

Após uma modificação autorizada, compare campos e referências com o previsto e revise a próxima sincronização antes de ampliar o lote. Se o resultado for incerto, investigue antes de repetir a ação.

Na gestão de clientes de Frihet, a exportação da lista como CSV está disponível. Pode servir como entrada para uma revisão; não significa que este modelo possa ser importado nem que clientes sejam mesclados automaticamente.

Encerre anotando por que o duplicado apareceu: cadastro manual, importação ou regra do conector, se houver evidência. Se ainda não souber, deixe um responsável e uma verificação pendente. Duas fichas conservadas com uma relação clara são um resultado válido; uma lista mais curta sem histórico explicável não é.

Fontes consultadas em 14 de setembro de 2026. Verifique a documentação vigente do seu fornecedor antes de fazer alterações.