Cadastre-se e fale com o suporte para receber 100 verificações grátis.Cadastre-se grátis
Ilustração do fluxo de trabalho do CarrierLookup para Consulta da operadora original para CRM: Adicionando campos de operadora original e tipo de linha
Uma visão geral do fluxo de trabalho abordado neste artigo do CarrierLookup.

Um guia de design de campos e fluxo de trabalho para equipes de operações de CRM que desejam adicionar a operadora original, a operadora subjacente, o tipo de número e a região de alocação aos registros de contato por meio de consultas síncronas e tarefas de arquivo.

Uma consulta da operadora de telefone para CRM adiciona contexto de alocação a cada contato: a operadora à qual a faixa numérica foi originalmente alocada, a operadora subjacente quando uma marca opera em outra rede, o tipo de número (como celular ou linha fixa) e a região e cidade de alocação. A configuração prática tem três partes: criar campos personalizados com nomes claros, executar consultas síncronas à medida que novos registros chegam e processar o banco de dados existente uma vez com uma tarefa de arquivo. Valores vazios devem ser armazenados como indisponíveis, e cada campo deve ser tratado como contexto para agrupamento e revisão, em vez de prova de que um contato pode ser alcançado.

Projetando os campos do CRM antes de qualquer consulta de operadora

A maioria dos guias sobre este tópico vai direto para a chamada de uma API e deixa o design dos campos ao acaso. Os nomes dos campos decidem como os colegas lerão os dados anos depois, portanto, defina-os primeiro.

Rótulo do campo no CRM Tipo sugerido Notas
Operadora original Texto de linha única Nomes de operadoras variam por país; um menu suspenso fixo enche rapidamente
Operadora subjacente Texto de linha única Frequentemente vazio; preenchido apenas quando uma marca opera em outra rede
Tipo de número Menu suspenso Celular, linha fixa, VoIP, outro, indisponível
Região de alocação Texto de linha única Região vinculada à faixa numérica
Cidade de alocação Texto de linha única Cidade vinculada à faixa numérica
Status da consulta de operadora Menu suspenso Concluído, concluído-vazio, indeterminado, não verificado
Data da consulta de operadora Data Quando a consulta foi executada

Use as palavras "original" e "alocação" nos rótulos para que ninguém interprete a operadora como a rede atual ou a região como o local onde o contato reside. No HubSpot, tipos de campo de propriedade, como texto de linha única, seleção suspensa e seletor de data, cobrem todos esses itens; o Salesforce oferece o equivalente por meio de campos personalizados.

Preparando campos de telefone para a consulta

Uma consulta é tão boa quanto sua entrada. Antes da primeira execução, verifique como os números de telefone são armazenados no CRM:

  1. Escolha um campo de origem. Contatos geralmente possuem Telefone, Celular e um campo de texto livre "outro". Decida qual deles alimenta a consulta ou crie um registro de consulta por campo.
  2. Normalize para E.164. Remova espaços e pontuação, descarte prefixos nacionais e adicione um sinal de mais e o código do país, por exemplo +447700900123. O formato é definido na ITU-T Recommendation E.164.
  3. Armazene o valor normalizado separadamente da entrada original, para que os usuários de vendas ainda vejam o que o contato digitou.
  4. Remova duplicatas no nível do número, para que um número compartilhado por vários contatos seja verificado uma vez e gravado de volta em cada um.
  5. Observe o país de cada número a partir do seu código de país. Consultas síncronas não precisam disso, mas tarefas de arquivo sim.

Registros que não podem ser normalizados devem manter o status "não verificado" com um motivo, em vez de serem enviados e rejeitados.

Novos registros: consultas síncronas dentro do fluxo de trabalho do CRM

Novos contatos chegam um por um a partir de formulários, importações ou integrações, portanto, uma consulta síncrona é a mais adequada. Padrões típicos:

  • Webhook de fluxo de trabalho ou middleware. Quando um registro é criado ou seu campo de telefone é alterado, seu servidor de integração chama POST /api/v1/check para um número e grava o resultado de volta nos campos do CRM.
  • Micro-lotes agendados. A cada poucos minutos, colete novos registros e envie de 1 a 100 números E.164 para POST /api/v1/batch-check. Os resultados retornam na ordem de entrada, portanto, combine-os com os registros por posição ou pelo número que você enviou.
  • Revisão manual. Um usuário de operações pode colar até 500 números na área de lote em tempo real do painel para uma verificação rápida.

Mantenha a X-API-Key em seu servidor de integração; nunca a coloque em um script do lado do cliente do CRM ou em uma extensão de navegador. A API pública documenta um pequeno número de slots compartilhados em trânsito e uma solicitação múltipla por conta de cada vez, portanto, coloque as consultas em fila em vez de disparar uma por registro durante uma importação grande.

Banco de dados existente: uma tarefa de arquivo por país

Para a base existente, exporte os números normalizados e processe-os como tarefas de arquivo em vez de milhares de chamadas síncronas.

  1. Agrupe por código de país. Uma tarefa de arquivo usa um país selecionado, e linhas fora dele são excluídas, portanto, crie uma exportação por país.
  2. Escreva um número por linha em um TXT ou CSV de uma coluna, como dígitos simples com código de país.
  3. Envie cada arquivo no painel ou com POST /api/v1/bulk-tasks, enviando o país antes do arquivo em solicitações multipart.
  4. Consulte GET /api/v1/bulk-tasks/{id} não mais do que uma vez a cada 30 segundos.
  5. Baixe o CSV para cada tarefa bem-sucedida e importe-o para o CRM, combinando o identificador de dígitos simples com seu campo normalizado.

O pré-processamento remove linhas inválidas, duplicatas e números sem código de país, e essas linhas excluídas não são cobradas. Limites por produto sobre o tamanho da lista e do arquivo se aplicam, portanto, verifique a documentação da API antes de decidir como dividir uma exportação grande. Países cujos números são suportados apenas para consultas síncronas, como China continental, Hong Kong e Macau, devem seguir a rota síncrona.

Escrevendo resultados vazios e indeterminados corretamente

Três resultados parecem semelhantes em uma planilha, mas significam coisas diferentes em um CRM:

Resultado O que aconteceu O que escrever
Concluído com valores A consulta retornou dados de alocação Preencha os campos, status "concluído"
Concluído com campos vazios A consulta terminou, mas alguns ou todos os valores estão indisponíveis Deixe os campos vazios ou escreva "indisponível", status "concluído-vazio"
Indeterminado A verificação retornou um código de negócio diferente de zero ou expirou Deixe os campos intocados, status "indeterminado", tente novamente mais tarde

Em uma solicitação múltipla síncrona, uma linha sem um resultado normal pertence ao grupo de indisponíveis, não a uma lista de números ruins. Nunca substitua valores bons anteriores por espaços em branco de uma tentativa indeterminada posterior. Consultas falhas ou indeterminadas não geram cobrança, portanto, uma nova tentativa limitada, por exemplo, algumas tentativas ao longo de um dia, é razoável.

Usando os novos campos em segmentos e relatórios

Com os campos em vigor, as equipes de CRM geralmente criam:

  • Segmentos por tipo de número, para que contatos de linha fixa sigam para sequências baseadas em chamadas e faixas de celular sigam para canais que exigem um número de celular.
  • Grupos de operadoras para comparar relatórios de entrega de provedores de mensagens, tendo em mente que números portados permanecem dentro do grupo da operadora original.
  • Filas de revisão para registros com status concluído-vazio ou indeterminado antes de abordagens de alto valor.
  • Painéis de qualidade de dados mostrando a parcela de registros verificados, concluídos e indisponíveis por país.

Esses campos suportam decisões de agrupamento e revisão. Eles não estabelecem que um contato pode ser alcançado, que o número pertence à pessoa nomeada ou que o contato concordou em ser contatado, portanto, as verificações de consentimento e propriedade permanecem em seus próprios campos e processos.

Perguntas frequentes

Com que frequência as equipes de CRM devem executar novamente as consultas de operadora em registros existentes?

A operadora originalmente alocada descreve a faixa numérica e não muda quando um número é portado, portanto, uma atualização completa frequente agrega pouco valor. Verifique novamente um registro quando seu número de telefone mudar, quando o status armazenado for indeterminado ou quando a data da consulta for antiga o suficiente para que sua equipe queira um contexto novo para uma campanha específica. Um campo de data de consulta facilita a filtragem, e verificar apenas registros alterados ou indeterminados mantém o volume baixo.

O CRM deve substituir a operadora original quando um contato diz que mudou de rede?

Não. O campo de operadora original descreve a operadora à qual a faixa foi alocada pela primeira vez, o que permanece o mesmo após uma portabilidade. Se a rede que um contato usa hoje for importante para sua equipe, registre-a em um campo separado com sua própria fonte e data, como uma observação do contato. Manter os dois valores separados evita que os relatórios misturem o contexto de alocação com informações autorrelatadas.

Como as equipes podem conectar um assistente de IA aos mesmos dados de consulta?

O endpoint oficial MCP permite que um assistente de IA execute consultas síncronas de um ou de 1 a 100 números e leia o saldo, usando a mesma conta e limites da API REST. Ele não oferece uma ferramenta de tarefa de arquivo, portanto, uma atualização de todo o banco de dados ainda deve passar pelo painel ou pela API em lote. Assistentes são úteis para verificações ad-hoc durante a revisão de registros, com resultados gravados por uma pessoa ou uma integração.

Saiba mais

Escolha as informações do produto que se ajustam à próxima etapa do seu fluxo de trabalho.

Fontes