Vendas
Desde abril de 2026, o BSUID já aparece nos webhooks da Cloud API — independentemente de os usuários terem adotado @username ou não. Isso significa que a janela de preparação já está aberta. Empresas que não estão capturando esse identificador estão acumulando lacunas de reconhecimento que vão aparecer assim que a adoção dos nomes de usuário crescer.
Se você ainda não está familiarizado com o BSUID e o que ele representa para operações conversacionais, vale começar pelo artigo “Username no WhatsApp: o que muda para quem vende e atende pelo canal”.
Por onde começa a adaptação: auditoria das jornadas que dependem do telefone
O primeiro movimento é mapeamento. Quais partes da sua operação dependem do número de telefone para funcionar?
Essa não é uma pergunta técnica — é uma pergunta de negócio. A resposta determina onde estão os pontos de fragilidade e em que ordem vale intervir.
Situações típicas que dependem do telefone e precisam ser revisadas:
- Reconhecimento do cliente na entrada da conversa (busca por número no CRM)
- Automações que usam o telefone como chave para acionar fluxos
- Campanhas de reengajamento que dependem do número para identificar o contato
- Integrações com sistemas legados que têm o telefone como campo obrigatório
A boa notícia é que essa auditoria não exige um projeto grande. Em muitos casos, é possível identificar os pontos críticos com uma revisão dos principais fluxos de entrada e dos campos usados para busca de cliente no CRM.
O que adaptar no reconhecimento do cliente
Hoje, quando uma mensagem chega pelo WhatsApp, boa parte das operações busca o cliente pelo número de telefone. Com o BSUID disponível, essa lógica precisa ser ampliada — não substituída.
Na prática, a operação precisa ser capaz de:
- Reconhecer o cliente pelo BSUID quando o telefone não estiver disponível
- Quando os dois dados chegarem, garantir que telefone e BSUID apontem para o mesmo registro no CRM
- Preservar contexto da conversa independentemente de como o cliente chegou
O objetivo não é trocar um identificador pelo outro. É garantir que a operação mantenha continuidade mesmo quando o campo de telefone chegar vazio.
O que adaptar no CRM
O BSUID precisa ter um lugar definido no perfil do cliente. Em muitas empresas, o CRM é a fonte central para entender quem é o cliente, em que etapa da jornada ele está e qual foi a última interação. Se o WhatsApp é um canal relevante para atendimento, vendas ou relacionamento, o BSUID precisa aparecer nessa visão.
Ele não deve ser tratado como campo opcional ou puramente técnico. Para conversas no WhatsApp, ele passa a ser um identificador de continuidade — tão relevante quanto o telefone nas situações em que o número não estiver disponível.
Adaptações práticas:
- Criar campo dedicado para BSUID no perfil do contato
- Definir lógica de associação: quando chegar BSUID + telefone, linkar ao registro existente; quando chegar só BSUID, criar registro novo e capturar telefone quando necessário
- Garantir que o histórico de conversa seja acessível a partir do BSUID, não apenas do telefone
A estratégia mais eficiente não é uma migração em bloco. É incremental: conforme clientes interagem, o BSUID vai sendo capturado e associado ao registro existente. A janela de 30 dias da Meta — em que o telefone pode continuar aparecendo para clientes com histórico recente — ajuda nesse mapeamento gradual.
O que adaptar em campanhas e reengajamento
Disparos para bases existentes com telefone conhecido continuam funcionando normalmente. Se a empresa já tem o número e permissão para se comunicar, campanhas e automações seguem como parte da estratégia.
O ponto de atenção está nos novos contatos. Leads que chegarem depois da adoção dos @usernames podem iniciar conversas sem compartilhar o telefone. Nesses casos, a empresa precisa estar preparada para trabalhar com o BSUID como identificador da relação.
A partir de maio de 2026, a Meta passa a permitir o envio de mensagens usando o BSUID como identificador de destino. Em determinados cenários, o BSUID não serve apenas para reconhecer o cliente na entrada — ele também pode ser usado para dar continuidade a interações anteriores.
Para isso funcionar, a operação precisa estar estruturada para armazenar e utilizar esse identificador corretamente desde o primeiro contato.
Quando o telefone ainda é necessário — e como solicitá-lo
Mesmo com o BSUID disponível, o telefone continua necessário em algumas jornadas:
- Autenticação e envio de código de verificação
- Validação de identidade em sistemas legados
- Integrações que usam o número como chave principal
Quando o número não chegar automaticamente e for necessário para a jornada, a Meta disponibilizou o botão nativo REQUEST_CONTACT_INFO. Ele permite que o cliente compartilhe o número de forma voluntária dentro da própria conversa, sem precisar digitar manualmente.
A lógica operacional recomendada: pedir o telefone apenas quando ele for realmente necessário para aquela etapa da jornada, não como coleta padrão no início de toda conversa.
Plano de ação por prioridade
| Momento | Ação | Objetivo |
|---|---|---|
| Agora | Mapear jornadas que dependem do telefone | Identificar pontos de fragilidade antes da mudança ganhar escala |
| Agora | Confirmar se o BSUID já está sendo capturado pela plataforma | Criar base histórica para reconhecimento futuro |
| Próximas semanas | Criar campo de BSUID no CRM e definir lógica de associação | Evitar duplicidade e perda de contexto |
| Próximas semanas | Revisar fluxos de entrada, atendimento e campanhas | Garantir continuidade mesmo sem telefone |
| Antes de junho de 2026 | Definir quando solicitar telefone via botão nativo | Pedir dados pessoais apenas quando necessário |
| Antes de junho de 2026 | Avaliar reserva do @username da empresa | Proteger presença de marca e criar novo ponto de descoberta |
| Após início da adoção | Monitorar conversas sem telefone | Medir impacto real e ajustar jornadas |
| Contínuo | Revisar indicadores de duplicidade e continuidade | Acompanhar maturidade operacional no novo modelo |
Empresas com múltiplas operações ou marcas
Para grupos que trabalham com mais de um portfólio na Meta — marcas diferentes, unidades regionais, frentes comerciais separadas — existe uma camada extra de atenção.
Como o BSUID é escopado por portfólio, o mesmo cliente pode ter identificadores diferentes em cada operação. A Meta prevê o Parent BSUID para unificar essa identidade sob um portfólio-pai, mas isso exige que os portfólios estejam vinculados corretamente.
Esse mapeamento precisa acontecer antes da mudança ganhar escala — não apenas para evitar perda de contexto, mas para que a empresa continue enxergando a jornada do cliente de forma integrada.
Checklist: sua operação está exposta?
Use estas perguntas como diagnóstico inicial:
- Sua operação depende do telefone para identificar qualquer cliente que inicia uma conversa?
- Seus fluxos de automação assumem que o número sempre chega no início do atendimento?
- Seu CRM usa apenas o telefone como chave para localizar histórico do cliente?
- Leads vindos de anúncios Click to WhatsApp são identificados exclusivamente pelo número?
- Sua operação sabe o que fazer quando uma conversa chega sem telefone?
- O BSUID já está sendo armazenado pela sua plataforma ou integração?
- Existe um plano para revisar jornadas que dependem de identificação automática?
Se a maioria das respostas for “não sei” ou “ainda não”: a operação precisa olhar para essa mudança antes que ela se torne perda de contexto na prática.
O prazo crítico é junho de 2026. A preparação que faz diferença começa agora.
Empresas que chegarem em junho já com o BSUID integrado ao CRM, os fluxos revisados e a lógica de identificação ampliada vão absorver a transição sem interrupção. As que esperarem vão descobrir o problema pelo sintoma.
A OmniChat está acompanhando cada etapa dessa mudança para que nossos clientes naveguem essa transição sem perda de contexto e sem interrupção nas conversas.
