Durante a década inteira em que o WhatsApp virou o canal nº1 de receita no Brasil, o número de telefone foi a coluna que segurava tudo. Ele era a chave que ligava a conversa ao contato no CRM, o carrinho abandonado ao pedido, o pós-venda ao histórico. Sua operação inteira de atribuição — quem falou com quem, qual conversa virou deal, quanta receita saiu de qual conversa — foi construída em cima de uma string de 13 dígitos.
Essa coluna está sendo aposentada. Com o BSUID (Business-Scoped User ID) em rollout até junho/2026 e o username (o handle público que permite o cliente falar com você sem expor o número) chegando como feature de 2026, a Meta está reescrevendo o que é a identidade do cliente dentro do canal. E a pergunta que ninguém no seu time comercial está fazendo — mas que RevOps precisa fazer agora — é simples: quando o telefone deixa de ser a chave, quem passa a ser o dono da identidade do cliente?
O ponto: identidade fragmentada é atribuição quebrada
Aqui está o que muda na prática. Até hoje, o mesmo número de telefone era reconhecido por você, pelo seu concorrente e por qualquer outra empresa que o cliente contatasse. O telefone era um identificador universal — funcionava como um CPF informal do relacionamento digital.
O BSUID não é universal. Ele é, como o próprio nome diz, business-scoped: cada empresa passa a receber um identificador próprio para o mesmo cliente. O João que fala com a sua loja tem um ID. O mesmo João, falando com a loja do lado, tem outro. E o telefone real dele deixa de circular como chave primária em vários desses fluxos.
Na prática: a Meta parou de te entregar um identificador que atravessa empresas e passou a te entregar um identificador que só faz sentido dentro da sua operação. A identidade do cliente deixou de ser um dado do cliente e virou um dado da relação entre você e ele.
Se você quer entender a mecânica contratual e de cadastro dessa transição, já cobrimos isso em detalhe no artigo sobre o que o BSUID muda no contrato com BSP, no cadastro e no time. Aqui a questão é outra e mais estratégica: quem controla a chave, controla a atribuição.
O problema de gestão: três donos disputando a mesma identidade
Quando o telefone era a chave, a pergunta "quem é dono do dado do cliente" tinha resposta fácil: era de quem tivesse o número. Agora a resposta se fragmenta entre três candidatos, e cada um puxa a identidade pra si:
- A Meta — que agora gera e controla o BSUID e o username, e decide o que te entrega sobre o cliente
- Seu BSP — que recebe esse identificador da Meta e decide como te repassa, como armazena e o que acontece com ele se você trocar de fornecedor
- Seu CRM — que precisa de uma chave estável pra amarrar conversa, contato e deal, e que historicamente usava o telefone pra isso
O risco não é abstrato. Se o BSUID vive dentro do seu BSP e não é replicado de forma limpa pro seu CRM, você acabou de criar um cliente que existe em dois sistemas com duas identidades diferentes e nenhuma ponte confiável entre elas. É o pesadelo clássico do dado duplicado, agora turbinado pela mudança de chave.
Por que isso importa pra RevOps: sem chave estável, não há atribuição
Atribuição de receita é, no fundo, um problema de identidade. Pra provar que uma conversa virou deal, você precisa amarrar o mesmo cliente através de vários sistemas e vários momentos no tempo. Se a chave que costura tudo isso muda de dono — ou pior, se ela existe em versões diferentes em cada sistema — sua capacidade de dizer "essa receita veio do WhatsApp" degrada silenciosamente.
Isso ataca três métricas de receita direto:
- Atribuição de receita ao canal: se a conversa e o deal não compartilham chave, o WhatsApp vira invisível no relatório de origem — exatamente o problema que já detalhamos em como provar que a receita veio do WhatsApp. Sem chave estável, todo modelo de atribuição desmorona na base.
- Sales velocity: quando o vendedor não consegue puxar o histórico completo do cliente porque a conversa está numa identidade e o deal em outra, ele reabre contexto do zero. Cada retrabalho de identificação é tempo morto no ciclo.
- Conversão e roteamento: se o cliente que já foi atendido volta com uma identidade que seu sistema não reconhece como a mesma pessoa, ele cai como lead novo, é roteado errado e perde o vendedor que já tinha o relacionamento. Já falamos de como isso destrói continuidade em fila única ou por squad — a mudança de chave agrava esse ponto.
Em resumo: o BSUID não é só um detalhe de cadastro. É uma mudança na infraestrutura de identidade sobre a qual sua máquina de atribuição foi construída. Ignorar isso é aceitar que, em algum momento de 2026, seus relatórios de receita por canal comecem a mentir — sem ninguém perceber o momento exato.
O que muda na prática pro seu time e pro cliente
Pro cliente
Com o username, o cliente pode iniciar conversa com sua empresa sem nunca te dar o número — algo bom pra privacidade dele, ruim pra sua base de contatos. Você pode ter uma conversa ativa, qualificada e até fechada com alguém de quem você não tem telefone. Sua noção de "lead capturado" precisa parar de depender do número.
Pro seu time comercial
O vendedor não vai mais conseguir procurar um cliente por número de telefone com a mesma confiança de antes. Se o processo de qualificação do seu time assume que "todo cliente tem telefone identificável", esse pressuposto quebra. O time precisa aprender a trabalhar com uma identidade que é interna à sua operação, não mais um dado que o cliente carrega no bolso.
Pro seu fornecedor
É aqui que mora a maior armadilha. O BSP se torna um intermediário ainda mais crítico da identidade do cliente. Se o BSUID vive na plataforma dele e não é entregue a você de forma portável, você acabou de aumentar dramaticamente seu custo de troca de fornecedor — porque trocar de BSP passa a significar perder a costura de identidade que liga anos de conversa ao seu CRM.
Como o gestor deve agir
Isso não se resolve no painel. Resolve-se com decisão, contrato e processo. A sequência abaixo é de gestão, não de tela:
- Reúna RevOps, líder de Vendas e o dono do CRM antes de falar com fornecedor. Defina internamente: qual sistema é a fonte da verdade da identidade do cliente? Se você não decidir isso, o BSP decide por você — e a resposta dele nunca vai ser "seu CRM".
- Pergunte ao seu BSP, por escrito, como o BSUID é entregue ao seu CRM. A resposta "a gente cuida disso internamente" é insuficiente. Você precisa saber se a chave chega ao seu CRM de forma que ligue conversa a contato de forma confiável.
- Exija portabilidade da identidade no contrato. Se você trocar de BSP em 2027, o mapeamento entre BSUID e seus contatos vai junto? Coloque isso como cláusula, não como promessa verbal. Sem isso, você virou refém.
- Estabeleça uma regra de deduplicação como processo de negócio. Quando o mesmo cliente aparece com nova identidade, quem decide que é a mesma pessoa e como? Isso é decisão de RevOps, não improviso do atendente.
- Redesenhe o que "lead identificado" significa. Pare de amarrar seu conceito de contato válido ao número de telefone. Um cliente via username, sem telefone, ainda é um contato completo pra fins de pipeline.
- Monitore a taxa de conversas órfãs. Defina, antes da transição, um indicador simples: quantas conversas não conseguiram ser ligadas a um contato existente no CRM? Se esse número subir durante o rollout, sua costura de identidade está vazando.
Riscos e armadilhas
O erro mais comum vai ser tratar isso como problema de tecnologia e delegar 100% ao time técnico ou ao BSP. É problema de governança de dado de receita, e RevOps é dono. O time técnico executa a costura; RevOps decide quem é dono da chave, o que o contrato exige e como a atribuição sobrevive.
A segunda armadilha é o silêncio. Diferente de um bug, atribuição quebrada não gera erro — gera relatório que continua bonito enquanto vai ficando errado. Sua taxa de conversão por canal pode despencar não porque o canal piorou, mas porque a receita dele parou de ser rastreável. É o mesmo padrão de métrica que enfeita slide e não sobrevive a uma pergunta do CFO.
A terceira é assumir que o BSP vai proteger seus interesses de portabilidade por bondade. Uma identidade de cliente que só existe dentro da plataforma dele é lock-in comercial. O incentivo dele não é o mesmo que o seu. Leia o contrato com esse olhar.
Resultado esperado e próximos passos
Quando você trata a identidade do cliente como um ativo de RevOps — com dono definido, chave portável e processo de deduplicação — a transição do BSUID vira um não-evento pra sua receita. As conversas continuam ligando a deals, a atribuição continua provando o valor do canal, e você mantém liberdade de trocar de fornecedor sem perder anos de histórico.
Quando você não trata, o custo aparece devagar: relatórios de canal que perdem precisão, vendedores que reabrem contexto do zero, clientes recorrentes tratados como novos, e um lock-in de BSP que você só descobre quando tenta sair. A diferença entre os dois cenários não está na tecnologia da Meta — está em quem, dentro da sua empresa, decidiu ser o dono da chave antes de junho de 2026.
Próximo passo concreto: agende uma conversa de 30 minutos com seu BSP esta semana e faça uma única pergunta — "como o BSUID do meu cliente chega ao meu CRM, e o que acontece com ele se eu trocar de fornecedor?". A qualidade da resposta te diz tudo sobre quem é o dono da identidade dos seus clientes hoje.