Escolha qual sistema é a referência para cada dado de cliente

Primeiro decida quais registros referem-se à mesma pessoa ou empresa. Depois escolha a fonte que rege cada campo. São perguntas diferentes. Uma possível duplicação pode exigir revisão de identidade, enquanto dois sistemas válidos podem ser referência para campos diferentes. Uma regra vaga como 'CRM vence' pode substituir valor correto.

Reveja possíveis duplicações separadamente antes de usar o mapa. Aqui, suponha que o contacto ou empresa já foi identificado e foque no significado e autoridade de cada campo.

Crie linha por campo que afete passagem ou decisão sobre cliente. Nomeie sistema ou registro de referência, função autorizada a atualizar e motivo. Por exemplo, a equipa financeira pode ser responsável pelo email de faturação no registro aprovado, enquanto serviços mantém preferência de suporte nas notas atuais.

São políticas propostas pela empresa; o CRM não as determina. Se o valor for partilhado entre ferramentas, decida se a outra cópia é apenas leitura, atualizada manualmente ou alterada após confirmação.

Uma regra útil indica evidência a verificar e quem decide. Pode dizer que novo endereço de pedido verificado do cliente é revisto pelo responsável do campo antes da atualização. Evite depender apenas do horário mais recente, pois importação ou assinatura recente pode conter informação antiga ou incidental.

Se não souber qual valor está correto, marque para revisão humana e suspenda a atualização desse campo. Registre valor escolhido, fonte verificada, decisor e data. A regra deve mostrar incerteza em vez de transformar suposição em registro permanente.

A documentação HubSpot descreve deduplicação de contactos por email e empresas por domínio. Também documenta IDs e propriedades únicas personalizadas para associar registros durante importação. São mecanismos específicos da HubSpot. A equipa ainda precisa de política para email de faturação e conflitos entre sistemas.

O guia de importação de múltiplos objetos também descreve associações e identificador único para atualizar registros em caminhos relevantes. Use-o como incentivo para examinar chaves e relações antes de mudar dados. Verifique chaves e comportamento de conflito separadamente em cada plataforma.

No exemplo fictício, o CRM lista alex@northwind.example como contacto principal, enquanto pedido de fatura chega de billing@northwind.example. A equipa não substitui o email principal nem une o remetente ao contacto apenas pelo domínio comum. O responsável pela fatura verifica o pedido, confirma o endereço de documentos de faturação e registra a decisão no mapa.

Email principal e email de faturação podem ser campos válidos com finalidades diferentes. Se não puder confirmar o pedido, o email de faturação continua em revisão e nenhuma atualização automática é presumida.

Reveja regras quando sistema mudar, responsável sair, novo formulário recolher dados ou conflito se repetir. Foque em campos relevantes ao trabalho ativo. Uma pessoa deve conseguir encontrar a regra atual antes de editar ou importar.

O mapa registra decisão para implementação e teste em cada sistema. Se o software não puder aplicá-la, atribua alguém para verificar campos afetados até existir processo mais seguro.

Forneça ao Areinum Assistant a lista de campos e decisões existentes e peça mapa preliminar de fontes, editores e conflitos em aberto. As pessoas responsáveis decidem as regras antes de qualquer sincronização.