Telefones no CRM: normalize antes de importar

Uma planilha pode representar o mesmo telefone com espaços, parênteses, código internacional ou ramal misturado ao número. Importar essas variações diretamente dificulta busca, comparação e manutenção. A resposta não é remover todo caractere que não seja dígito: essa limpeza pode esconder contexto necessário para interpretar a entrada. Uma normalização útil preserva a informação recebida e explica como chegou ao valor usado pela integração.

Defina o resultado que você precisa

Comece com um pequeno conjunto de campos: valor original, país de referência, número normalizado, ramal, estado da validação e versão da regra. O original permite revisar decisões e corrigir uma transformação; o normalizado atende ao contrato da aplicação de destino. Armazene telefones como texto, evitando operações numéricas, perda do sinal de mais ou alterações feitas automaticamente pela planilha.

A biblioteca libphonenumber, mantida pelo Google, oferece análise, formatação e validação baseada em metadados de numeração. Isso não demonstra que um número esteja atribuído a determinada pessoa ou seja alcançável. A própria FAQ oficial distingue essa verificação da análise do formato. No seu processo, mantenha “formato aceito” separado de qualquer confirmação operacional de contato.

Monte uma tabela de transformação

A tabela deve ser aprovada por quem conhece a coleta. Uma base inteiramente brasileira pode ter exceções internacionais. Um cadastro corporativo pode conter central de atendimento, extensão e telefone pessoal em colunas diferentes. A regra não deve transformar essas entidades em um único campo só porque o destino oferece uma caixa de texto.

Trate a ambiguidade como um resultado

Proponha estados operacionais como aceito, ausente, ambíguo e rejeitado. Um registro ambíguo continua sendo trabalho pendente; não é uma falha que se resolve apagando o valor. Guarde o motivo de modo legível, por exemplo “país não informado” ou “extensão não separada”. Assim, o responsável pela origem consegue corrigir a causa em vez de editar o arquivo repetidamente sem entender o problema.

Evite adicionar códigos por uma regra silenciosa de localização do operador. Também não aproveite o telefone de outra linha para completar um cadastro incompleto. Quando existe uma hipótese plausível, mantenha-a como sugestão identificada, sujeita a revisão. A importação deve produzir a mesma decisão quando a mesma entrada e o mesmo contexto forem processados novamente.

Não confunda normalização com deduplicação

Dois contatos com o mesmo número podem representar pessoas diferentes que usam uma central. Uma pessoa pode ter vários números. Por isso, a igualdade do valor normalizado pode gerar um candidato à revisão, mas não autoriza, sozinha, a fusão de registros. Antes de unir contatos, confira identificadores adicionais, finalidade do cadastro e vínculos com empresas e negócios.

Registre também qual regra produziu o resultado. Se uma biblioteca ou seus metadados mudarem, processe primeiro uma amostra comparativa. Liste os valores que passaram a receber outra classificação e explique o impacto. Atualizar um componente não precisa significar reescrever automaticamente toda a base em produção.

Valide a carga com uma amostra

1. Selecione casos com formato internacional, nacional, ramal, ausência e ambiguidade.
2. Defina manualmente o resultado esperado de cada caso junto ao responsável pela origem.
3. Execute a transformação sem sobrescrever os valores originais.
4. Compare o relatório e confirme que toda linha tem um destino ou motivo de pendência.
5. Importe um lote controlado e teste leitura, busca e exportação do resultado.

O aceite deve incluir a preservação do original e a capacidade de explicar cada mudança. Complete o trabalho no dicionário de dados, nas regras de deduplicação e no contrato de integração. A qualidade melhora quando a coleta passa a seguir a mesma definição usada na importação.