CheckNumber.AI · 7 min read
Como associar resultados de verificação de telefone em lote aos registros do CRM
Crie um mapa local de origem para número, gerencie números compartilhados e reconcilie os resultados exportados com os registros corretos do CRM.
Para associar os resultados de verificação de telefone em lote aos registros do CRM, atribua IDs de registro estáveis antes de preparar o upload e mantenha um mapa local de cada número normalizado para cada registro de origem. Junte os resultados exportados usando o número verificado e esse mapa, em vez da posição da linha. Analise casos não correspondidos e casos de muitos-para-um antes de alterar os campos do CRM.
O problema da correspondência começa antes do upload
Uma exportação de verificação de telefone responde a uma pergunta sobre números enviados; um CRM armazena pessoas, organizações, permissões e histórico. Esses objetos estão relacionados, mas não são a mesma tabela. Um registro de CRM pode ter vários valores de telefone, e um número pode aparecer em vários registros. A normalização ou a desduplicação também podem alterar a contagem e a ordem das linhas enviadas. Se a equipe planeja colar as linhas retornadas sobre a exportação original do CRM por posição de planilha, até mesmo uma verificação limpa pode atualizar o contato errado.
Crie uma chave de registro interna estável antes de transformar qualquer coisa. Se o CRM tiver um ID de registro durável, exporte-o com os campos de telefone. Se a fonte não tiver um, atribua uma chave temporária em uma tabela de preparo local protegida e retenha a exportação original. Inclua a identidade do campo de telefone quando um registro tiver vários números. A tabela de preparo é de propriedade da equipe; isso não é uma afirmação de que o CheckNumber.AI aceita IDs personalizados em todos os produtos ou os retorna em um esquema específico.
Construa um mapeamento de número para registro
Para cada valor de telefone, mantenha o ID do registro de origem, o nome do campo de origem, o texto original, o número normalizado, o contexto do país e o status de preparação. Crie uma tabela de consulta separada, indexada pelo número normalizado, que liste todos os IDs de registro de origem e campos correspondentes. Um número verificado exclusivo pode se relacionar a várias pessoas, como uma central telefônica de uma empresa. Não mescle esses contatos simplesmente porque eles compartilham o número. Por outro lado, uma pessoa com um celular e uma linha comercial precisa de dois resultados possíveis no nível do número.
Prepare a entrada em lote usando a orientação atual do produto. O fluxo de trabalho de lista de telefones do CheckNumber.AI documentado usa CSV ou TXT e um número por linha com código do país, com um país por arquivo. A documentação da API deve ser consultada para o fluxo de trabalho suportado atualmente e os limites aplicáveis ao integrar programaticamente. Este artigo evita deliberadamente assumir um payload de solicitação, nome de campo de resultado ou envelope de resposta que não tenha sido verificado para o verificador selecionado. Mantenha o arquivo de upload, o mapa local, o produto selecionado e a data da verificação associados a um identificador de lote interno.
Normalize a chave de junção de forma consistente
O número enviado para verificação e o número usado para buscar um resultado devem ser representados de forma consistente. Por exemplo, a pontuação de exibição opcional e o sinal de mais inicial opcional não devem criar identidades locais separadas quando o número subjacente com código de país for o mesmo. Use uma rotina de normalização para o upload preparado e para a importação de resultados, e preserve os valores brutos junto com as chaves normalizadas. Teste uma rodada de ida e volta de amostra antes de processar toda a exportação.
Nunca confie na ordem das linhas de resultado. Um serviço pode retornar linhas em uma ordem diferente, e uma equipe pode desduplicar intencionalmente a entrada. Em vez disso, leia o resultado no nível do número, derive sua chave normalizada e junte através do mapeamento local. Se um resultado não puder ser correspondido exatamente à chave pretendida, mantenha-o para revisão. Se várias linhas de resultado forem mapeadas para uma chave, mas divergirem, investigue em vez de escolher a última linha. Se um resultado for mapeado para muitos registros de CRM, distribua o sinal cuidadosamente enquanto preserva cada registro como uma entidade distinta.
Aplique um sinal específico do produto com o significado correto
Diferentes produtos do CheckNumber.AI fornecem sinais diferentes. Uma verificação de validade de telefone, um sinal de atividade e uma verificação de registro em plataforma não devem ser armazenados como se fossem um booleano universal. Registre qual verificador nomeado produziu cada resultado e a data em que foi obtido. Um sinal de registro específico de plataforma pode informar o planejamento de canal no momento da verificação; ele não verifica identidade, propriedade, consentimento, alcance futuro ou entrega de mensagem. Um sinal de atividade pode apoiar a priorização, mas não pode prometer uma resposta.
Decida como o CRM representará um resultado de revisão antes de gravar os valores de volta. Uma equipe pode usar um status interno como revisão necessária ou verificado na data, mas esses são rótulos de CRM sugeridos, não campos de saída do produto. Não sobrescreva um registro de consentimento, preferência de contato verificada ou um campo de telefone confirmado por humano apenas porque uma verificação retornou um resultado incerto. Mantenha o resultado exportado bruto e a interpretação local separados para que revisores posteriores possam ver o que o serviço retornou versus o que a equipe decidiu.
Reconcilie exceções e torne as atualizações reversíveis
Execute contagens em cada estágio: valores de telefone de origem, valores excluídos ou ambíguos, números enviados exclusivos, linhas retornadas, chaves de resultado correspondidas, chaves não correspondidas e registros de CRM propostos para atualização. Essas contagens diferirão por motivos legítimos. O teste importante é que cada diferença possa ser explicada por um mapeamento documentado ou decisão de revisão. Amostre números compartilhados, vários campos de telefone, divisões por país e valores ausentes.
Antes de uma atualização em lote do CRM, produza um arquivo de alteração proposta contendo ID do registro, campo de telefone, status interno anterior, novo status interno, lote de origem e decisão do revisor. Mantenha os dados de origem protegidos e siga a política de retenção da organização. Use um processo de atualização reversível para que um erro de mapeamento possa ser corrigido. As equipes podem revisar o produto Number Checker para obter um sinal adequado no nível do número e, em seguida, implementar a reconciliação do CRM como seu próprio fluxo de trabalho de dados controlado. O valor da verificação depende de fazer essa associação final corretamente, não da rapidez com que as linhas podem ser coladas.
Para cada atualização proposta, peça a um revisor que confirme se o ID de origem ainda existe, se o campo de telefone pretendido não foi alterado desde a exportação e se o lote pertence ao mesmo país e produto. Se o registro do CRM foi alterado nesse meio tempo, pause a atualização e reavalie o mapeamento.
Perguntas frequentes
Como as equipes podem juntar resultados quando as linhas de upload foram desduplicadas?
Mantenha um mapa de cada número normalizado exclusivo para todos os IDs de registro de origem e campos de telefone. Junte o resultado no nível do número à chave e, em seguida, expanda-o para os registros mapeados.
A ordem das linhas de resultado pode ser usada como uma chave de CRM?
Não. Use IDs de origem estáveis e chaves de número normalizadas. A ordem das linhas pode mudar durante a preparação, desduplicação ou exportação.
O que deve acontecer quando vários contatos compartilham um número?
Retenha cada registro de contato. O mesmo sinal no nível do número pode ser associado a vários registros, mas isso não prova que eles representam uma única pessoa.
Como um resultado não correspondido deve ser tratado?
Mantenha-o para revisão, compare os números brutos e normalizados e verifique o mapa do lote. Não atualize um registro de CRM a partir de uma correspondência incerta.
