{{ sec.title }}
{{ b.text }}
{{ ln.text }}
| {{ c.label }} |
|---|
| {{ cell.label }} |
{{ post.quote }} CESAR A. MACHADO
Eu explico como localizar duplicidades, escolher o registro principal e preservar histórico sem transformar uma limpeza em perda de dados.
Por Cesar A. Machado · · 2 min
Eu começaria por contato, empresa e negócio separadamente. Cada objeto precisa de tenant, origem, identificadores confiáveis e campos que jamais devem ser sobrescritos. CPF, CNPJ ou e-mail só podem servir como chave se houver base legítima, normalização e regra clara para valores compartilhados.
Na entrada, trim, caixa, telefone e domínio são normalizados por código. Quando existe chave própria estável, uso upsert em vez de criar e limpar depois. A API do HubSpot documenta upsert por propriedade identificadora única: https://developers.hubspot.com/docs/api-reference/latest/crm/using-object-apis.
Correspondência exata em identificador confiável pode bloquear nova criação. Nome parecido, domínio semelhante, telefone incompleto e endereço próximo formam candidatos. A IA ajuda a comparar texto ruidoso e explicar quais sinais aumentaram ou reduziram a confiança.
O Salesforce descreve matching rules como mecanismo de identificação usado por regras e jobs de duplicidade: https://help.salesforce.com/s/articleView?id=matching_rule_map_of_reference.htm&language=en_US. Eu manteria versão, pesos e limiares visíveis, separados por objeto e país.
| Faixa | Ação | Exemplo |
|---|---|---|
| exata | bloquear ou vincular | ID externo |
| alta | revisão humana | domínio e telefone |
| média | fila de análise | nome e cidade |
| baixa | não sugerir | nome isolado |
Mesclar não é apenas apagar uma linha. Eu definiria o registro principal por fonte, completude e recência, mas trataria cada campo com política própria. Nome aprovado pode vencer o mais recente; telefone validado vence valor vazio; consentimento nunca é ampliado por inferência.
Atividades, negócios, tarefas e anexos são reatribuídos explicitamente. Antes da escrita, o sistema mostra uma prévia e grava snapshot dos dois registros, plano de alterações, ator e justificativa. A operação usa chave idempotente para não repetir a mesma fusão.
A fila começa pelos candidatos de maior valor e menor ambiguidade. O revisor aceita, rejeita ou marca registros relacionados, porém distintos. Rejeições alimentam uma lista de pares protegidos para que o sistema não apresente a mesma sugestão toda semana.
Duplicate rules definem o que acontece quando um possível duplicado aparece: https://help.salesforce.com/s/articleView?id=sales.duplicate_rules_map_of_reference.htm&language=en_US. Eu aplicaria a mesma separação: detectar é uma decisão; bloquear, alertar ou mesclar é outra, com permissão própria.
Eu acompanharia duplicatas evitadas na entrada, candidatos confirmados, falsos positivos, tempo de revisão, negócios reunificados e reversões. Uma queda no total de contatos não prova qualidade; pode apenas esconder uma limpeza agressiva.
O piloto ideal usa uma amostra, simula a política e não escreve no CRM. Depois, aplica pequenos lotes com rollback testado. Se você quer estruturar esse processo, envie CRM, objetos, volume e integrações em https://blog.cesarmachado.com/contato. Eu começo pela identidade dos dados, porque é isso que impede economizar horas hoje e perder histórico amanhã.
Dois nomes parecidos podem ser a mesma empresa; dois e-mails diferentes podem ser pessoas distintas. Eu preservo a dúvida até existir evidência suficiente.
Converse comigo sobre o processo que você quer melhorar e os critérios para começar com segurança.
Agendar uma conversaO que eu uso e construo em engenharia de IA.
Portfólio de projetos. Conteúdo a definir.
Quem é Cesar A. Machado.
{{ st.desc }}
{{ sv.desc }}
Sem frequência fixa. Só quando houver algo útil.
Notas de campo, decisões técnicas e guias práticos sobre engenharia de IA, arquitetura, automação e operação.
{{ sobreLead }}
{{ sobreBody }}
{{ item.text }}
Os projetos são apresentados pelo problema e pela engenharia envolvida, preservando informações internas. O objetivo é mostrar como decisões de produto, arquitetura e operação se conectam.
{{ item.text }}
{{ item.linkLabel }} →Um projeto começa com uma pergunta de negócio, avança por uma primeira versão controlada e só cresce quando os dados mostram que a solução cabe na operação.
{{ item.text }}
“{{ item.quote }}”
O ponto de partida é um processo específico, com responsável, volume e impacto identificáveis. A solução precisa caber na capacidade da equipe, produzir evidência e preservar controle sobre decisões importantes.
Envie o fluxo atual, o volume aproximado e o principal gargalo. A primeira conversa serve para entender o problema e avaliar o próximo passo mais proporcional.
Clique em uma ferramenta para abrir. Conteúdo de cada uma a definir.
{{ t.desc }}
Projetos de software e ecossistemas construídos com engenharia de IA. Conteúdo de cada caso a definir.
{{ p.desc }}
{{ detail.desc }}
Toque nas opções que descrevem seu projeto. Só o último passo pede digitação.
Obrigado. Retorno pelo e-mail informado com as próximas perguntas.
{{ post.standfirst }}
{{ b.text }}
{{ ln.text }}
| {{ c.label }} |
|---|
| {{ cell.label }} |
{{ post.quote }} CESAR A. MACHADO
Escreve sobre engenharia de IA e conduz projetos de software e ecossistemas para empresas.
LINKEDIN · /IN/CEZAO{{ post.citation }}
Conteúdo original, revisado pelo autor. Reprodução permitida com atribuição e link.O endereço pode estar incorreto ou o artigo ainda não está publicado.