Existe uma cena que se repete há anos em toda distribuidora, indústria e atacado do Brasil: o comprador da outra ponta não abre o portal B2B. Ele manda mensagem. "Preciso de 40 caixas do parafuso 16-oz, igual ao pedido de março." Do lado de cá, alguém do time comercial abre o ERP, procura a tabela de preço daquele cliente, confere estoque, digita o pedido e responde. O canal é o WhatsApp; o processo é manual.
O que mudou em julho de 2026 é que a Salesforce colocou um agente exatamente nesse lugar. Com o Buyer Agent do Agentforce Commerce em disponibilidade geral, o comprador conversa por WhatsApp ou SMS e recebe de volta a imagem do produto para confirmar o SKU, o preço do contrato daquele cliente e o pedido fechado — sem login de portal. Acompanham dois recursos que mudam o formato da negociação: Multi-Cart (várias compras em paralelo, porque comprador B2B não tem um carrinho, tem cinco) e Round-Trip Quoting (carrinho vira cotação, cotação volta para carrinho).
O anúncio é sobre agente. O problema real é outro, e ninguém coloca no slide: cada uma dessas três entregas é uma integração síncrona com o sistema de registro. Este artigo é sobre o que precisa existir atrás do agente — e o que quebra, em ordem, quando não existe.
1. O que muda de fato com o Buyer Agent
Vale separar o que é novo do que é embalagem. Chatbot de vendas B2B existe há uma década e quase sempre foi decepcionante, porque parava exatamente onde a conversa ficava interessante: "vou verificar com o time e retorno". O Buyer Agent muda três coisas concretas.
O canal virou o de sempre. Não é um widget no site que o comprador precisa lembrar de abrir. É o WhatsApp e o SMS — os mesmos aplicativos onde ele já pedia, informalmente, há anos. A adoção não precisa ser conquistada; ela já aconteceu por conta própria.
A confirmação virou visual. Pedido B2B erra em SKU, não em intenção. "O parafuso 16-oz" pode ser seis códigos diferentes no catálogo, com rosca, acabamento e embalagem distintos. O agente devolve a imagem do produto para o comprador confirmar antes de fechar. É uma correção de UX simples com efeito grande em devolução e retrabalho.
O preço deixou de ser genérico. Esse é o ponto pesado. Em B2B, não existe "o preço": existe o preço daquele cliente, naquela tabela, naquela vigência, com aquele desconto por volume e aquele acordo comercial específico. Um agente que responde preço de tabela pública em ambiente B2B não é útil — é perigoso.
Some-se o novo POS do Agentforce Commerce (iOS já disponível, Android e Windows a partir de agosto de 2026), que traz o balcão físico para o mesmo grafo de pedido do digital. O recado da plataforma é coerente: só existe operação "unificada" quando existe um sistema de registro. E é aí que a conversa deixa de ser sobre agente e passa a ser sobre arquitetura.
2. Por que o portal B2B já estava morto no Brasil
Antes de discutir integração, é honesto reconhecer por que essa mudança encontrou terreno tão fértil aqui. O portal B2B foi desenhado para um comportamento que o comprador brasileiro nunca teve.
Ele pressupõe que o comprador vai lembrar a senha, navegar num catálogo com milhares de SKUs, encontrar o item certo por código e conferir sozinho a condição comercial. Na prática, o comprador de uma distribuidora faz o mesmo pedido recorrente há três anos, conhece o vendedor pelo nome e resolve tudo em quatro mensagens. Para ele, o portal é fricção pura: mais passos para chegar ao mesmo lugar.
O resultado é conhecido por quem opera: portais B2B caros, com baixa adoção, enquanto o volume real de pedidos escoa por WhatsApp e telefone — sem trilha, sem padronização, dependente de quem estava de plantão. A empresa tem um canal digital que ninguém usa e um canal informal que sustenta o faturamento.
O que o agente conversacional faz é aceitar a realidade em vez de brigar com ela: se o pedido já acontece na mensagem, coloque o sistema na mensagem. É a decisão certa. Mas ela transfere para a camada de integração todo o trabalho que antes era feito por uma pessoa consultando o ERP na mão.
3. As 4 integrações que o pedido conversacional exige
Um agente que fecha pedido B2B precisa responder, em tempo de conversa, a quatro perguntas que não moram nele. Cada uma é uma integração com contrato, latência e política de falha própria.
Integração 1 — Preço de contrato. A pergunta "quanto custa para este cliente" é respondida pelo ERP, não pelo CRM e muito menos pelo chat. Envolve tabela por cliente, vigência, escalonamento por volume, condição de pagamento e, no Brasil, tributação que varia por UF e por regime. Isso exige um serviço de precificação exposto com contrato claro, latência compatível com conversa (na casa de centenas de milissegundos, não segundos) e política explícita de fallback: se o serviço de preço não responde, o agente não chuta — ele informa que vai confirmar. Preço errado em B2B não é bug de UX; é nota fiscal errada e crédito comercial queimado.
Integração 2 — Estoque em tempo real. Em conversa, o tempo passa. Entre a cotação e a confirmação podem se passar horas, e nesse intervalo o estoque muda — inclusive por causa de outros pedidos do mesmo agente. Aqui não basta ler saldo: é preciso decidir se a arquitetura vai trabalhar com reserva temporária (o item fica bloqueado enquanto a cotação está aberta) ou com confirmação no fechamento (e o risco de frustrar no final). As duas são defensáveis; o que não é defensável é não ter escolhido. E Multi-Cart amplifica o problema: cinco carrinhos paralelos do mesmo comprador competindo pelo mesmo saldo é exatamente o cenário onde estoque fantasma aparece.
Integração 3 — Catálogo com mídia coerente por SKU. A confirmação visual só funciona se cada SKU tiver imagem correta, atual e inequívoca. Parece detalhe de e-commerce, mas em B2B industrial é onde o catálogo costuma ser mais pobre: código, descrição técnica e nenhuma foto — ou uma foto genérica da família de produtos, que é pior que nenhuma, porque confirma o item errado com confiança. Habilitar confirmação por imagem sem arrumar a mídia do catálogo transforma um recurso de precisão em uma máquina de devolução.
Integração 4 — Trilha do pedido. Conversa é assíncrona e não confiável: mensagem duplica, webhook chega duas vezes, o comprador manda "confirma" de novo porque não viu a resposta. Sem idempotência, isso vira pedido duplicado. Sem reconciliação, ninguém sabe se o pedido que o agente disse que criou existe mesmo no ERP. Sem trilha auditável, quando o cliente reclamar do preço combinado em uma terça-feira, não há o que mostrar. Essa quarta integração é a menos glamourosa e a que decide se o canal aguenta operação de verdade.
4. O que quebra sem elas (na ordem em que costuma quebrar)
Vale antecipar o roteiro de falha, porque ele é bastante previsível.
Primeiro quebra o preço. O agente sobe lendo preço de tabela padrão "só para começar". Um cliente com contrato negociado recebe um valor acima do acordado, aceita, e o pedido entra. A correção não é técnica — é comercial, feita por telefone, com desgaste. Multiplique por alguns clientes e o canal ganha fama de não confiável, o que é fatal: o comprador volta a mandar mensagem para a pessoa.
Depois quebra o estoque. Cotações abertas em paralelo, sem reserva e sem verificação no fechamento, geram pedidos de itens que já não existem. O impacto não fica no digital: bate no separador, no faturamento e na promessa de prazo. O cliente não distingue "o agente errou" de "a empresa errou".
Depois quebra o registro. Uma reentrega de webhook cria o mesmo pedido duas vezes. Sem chave de idempotência ligando conversa e pedido, você descobre pela expedição — que separou o dobro. Ou o inverso: o agente confirmou ao comprador e a gravação no ERP falhou silenciosamente; o pedido "existe" no WhatsApp e não existe em lugar nenhum.
Por último quebra a confiança. Que é o único item da lista sem rollback. É por isso que a frase que a E-Commerce Brasil publicou esta semana descreve tão bem o risco: se a empresa não tem dado e processo estruturado, ela não acelera eficiência — ela acelera o caos. Um agente é um multiplicador de throughput. Ligado sobre integração frágil, ele multiplica erro na mesma velocidade com que multiplicaria pedido.
5. Como a CCX faz: canal enterprise + integração event-driven ao sistema de registro
No Brasil há um agravante e uma vantagem. A vantagem: o canal já existe e não precisa ser conquistado — o comprador já está no WhatsApp. O agravante: falta a camada enterprise por trás dele, e é ela que separa piloto de operação.
É nessa camada que a CCX trabalha. O CCX Message é a plataforma de WhatsApp Business enterprise que sustenta o canal: templates HSM aprovados, WhatsApp Flows para coletar dados estruturados dentro da própria conversa, inbox multi-operador para o handoff humano quando o agente não deve decidir sozinho, webhooks assinados por HMAC, idempotência nativa de 24h, retry exponencial em 7 níveis e reconciliação de entrega a cada 5 minutos — com throughput acima de 50 mil mensagens/s por worker, latência de ingest abaixo de 200ms no p99 e compliance LGPD e SOC 2 Type II. Não é um número de vaidade: idempotência e reconciliação são exatamente a Integração 4 descrita acima, entregues como recurso de plataforma em vez de gambiarra por projeto.
Do outro lado da conversa está o sistema de registro, e é aí que entra a prática de Integrações & APIs Enterprise: REST, GraphQL e gRPC para as chamadas síncronas de preço e disponibilidade, e arquitetura event-driven com Kafka e RabbitMQ — com outbox pattern — para propagar pedido, estoque e status sem perder mensagem no caminho. Inclui as integrações que esse cenário exige na prática: SAP ↔ e-commerce, Protheus ↔ e-commerce (estoque, preço, pedido, NF), CRMs e gateways. Quando a plataforma é a Salesforce, soma-se a expertise em Commerce Cloud e Data Cloud para que o agente leia um contexto de cliente que seja o mesmo do resto da operação.
O começo, na prática, não é ligar o agente. É um discovery curto que responde a quatro perguntas: qual sistema é dono do preço de contrato e com que latência ele responde; qual é a política de reserva de estoque durante uma cotação aberta; qual a cobertura real de mídia por SKU no catálogo; e como o pedido criado na conversa é reconciliado com o ERP. Com essas quatro respostas, o agente é a parte fácil.
Se o seu comprador B2B já pede por WhatsApp, a CCX conecta o canal ao seu ERP: preço de contrato correto, estoque em tempo real e pedido rastreável — com fila, idempotência e reconciliação de entrega. Conhecer CCX Message →
6. FAQ
O Buyer Agent substitui o portal B2B?
Na prática, ele substitui o uso do portal para o pedido recorrente, que é a maior parte do volume em distribuição e atacado. O portal continua fazendo sentido para consulta ampla de catálogo, histórico e autosserviço administrativo. O erro é tratar o agente como camada de UX sobre o mesmo backend frágil: sem preço de contrato e estoque em tempo real, ele reproduz na conversa os problemas que o portal já tinha.
Preciso da Salesforce para fazer compra B2B por WhatsApp?
Não. A capacidade não é exclusiva de uma plataforma — o que ela exige é o canal com camada enterprise e as quatro integrações com o sistema de registro. Empresas com SAP, Protheus, VTEX, Shopify ou stack própria conseguem o mesmo resultado; o que muda é onde mora cada resposta. A escolha da plataforma deve vir depois do mapa de integrações, não antes.
Como garantir que o preço de contrato não saia errado?
Com uma fonte única de verdade para precificação, exposta como serviço com contrato de API versionado, latência monitorada e política explícita de fallback. A regra que evita a maior parte dos incidentes é simples: na indisponibilidade do serviço de preço, o agente nunca estima — ele informa que vai confirmar e escala para o humano.
O que é Round-Trip Quoting e por que ele complica a integração?
É o ciclo carrinho → cotação → carrinho: o comprador monta, pede cotação, o comercial ajusta, e a cotação volta a ser carrinho fechável. Complica porque introduz um estado de longa duração numa conversa. Enquanto a cotação está aberta, preço e estoque continuam mudando — o que obriga a decidir sobre validade da cotação, reserva de saldo e revalidação no fechamento.
Como evitar pedido duplicado quando o comprador confirma duas vezes?
Com idempotência de ponta a ponta: uma chave derivada da conversa e da intenção de pedido, respeitada tanto na camada de mensageria quanto na API que grava no ERP, mais reconciliação periódica comparando o que foi confirmado na conversa com o que existe no sistema de registro. É a diferença entre um canal que aguenta escala e um que gera trabalho de conferência manual.