A Black Friday brasileira de 2026 cai em 27 de novembro — faltam cerca de quatro semanas — e a Salesforce publicou o release de B2C Commerce "Peak-Ready Precision". A manchete é a vitrine agentic: UCP checkout ao vivo (o cliente compra em superfícies do Google — Gemini, Search, AI Mode — com o lojista como merchant of record), Agentic Commerce Search "Shop the Store" (busca em linguagem natural filtrada pelo estoque da loja, em qualquer idioma) e um Shopper Agent que lê o contexto da página em tempo real. É vistoso. Mas quem já passou por um pico de vendas sabe a verdade incômoda: o pico não se ganha na vitrine, se ganha atrás dela. E a parte do release que decide o pico é justamente a de baixo.
O nome do release já entrega a pista. "Peak-Ready" não descreve uma vitrine mais bonita — descreve prontidão para o pico, e prontidão para o pico é, em 90% dos casos, um problema de integração e de capacidade, não de interface. Quem vive o varejo brasileiro sabe que a Black Friday não quebra no banner nem no botão de comprar; quebra no estoque que vendeu duas vezes, na nota que não saiu, no pedido que ficou preso entre a plataforma e o ERP. É por isso que vale ler o release de trás para frente: começar pela parte "chata" (eventos, controles de borda, conexão) e só depois olhar a vitrine.
1. O que o release "Peak-Ready" trouxe
Além da vitrine agentic, o release entregou quatro coisas que importam para a operação. A primeira, e a mais decisiva, é o Event Framework em GA: eventos como sf.cc.order.placed e order/registered passam a ser roteados para webhooks HTTP, sem polling nem batch, notificando sistemas externos no instante em que o pedido cai. A segunda são os controles SCAPI diretos (rate limit, regras de WAF, purga de cache), a defesa de borda contra bot e credential-stuffing no pico. A terceira é que a conexão confiável com a org Salesforce não exige mais licença Data 360 para ligar o Shopper e o Merchandising Agent. A quarta é a própria vitrine agentic (UCP, Shop the Store, Shopper Agent), que amplia as portas de entrada de pedido.
Repare na hierarquia: a vitrine abre novas formas de o cliente iniciar uma compra; o Event Framework decide o que acontece com essa compra depois que ela entra. No pico, é a segunda que separa a venda faturada do pedido perdido.
2. A vitrine agentic amplia as portas de pedido — e cada porta só fatura se integrar atrás
O UCP checkout ao vivo significa que o seu produto pode ser comprado dentro do Google, de um assistente, de uma busca com IA — sem o cliente passar pela sua home. "Shop the Store" transforma uma frase em linguagem natural numa consulta filtrada pelo seu estoque real. O Shopper Agent conversa durante a jornada. Tudo isso tem um efeito operacional único: o pedido deixa de entrar por um só caminho (o seu site) e passa a entrar por vários — Google, chat, busca, app.
Cada porta nova é uma oportunidade de faturamento só se o pedido que entra por ela chegar, em tempo real, ao seu OMS, estoque, WMS e fiscal. Uma venda confirmada na vitrine agentic que não baixa o estoque, não gera a separação no WMS e não emite a nota não é uma venda — é um passivo. A vitrine multiplicou as entradas; a sua integração precisa dar conta de todas elas, ao mesmo tempo, no pior minuto do ano.
Há um detalhe que muitos descobrem tarde: quando o lojista é o merchant of record de um checkout que acontece fora do seu site (no Google, por exemplo), a responsabilidade pelo pedido — estoque, cobrança, nota, entrega, pós-venda — continua inteira sua, mesmo que a interface não seja sua. Não dá para tratar esses pedidos como um canal "de fora" que entra depois; eles precisam cair no mesmo fluxo de fulfillment dos pedidos do site, no mesmo instante, com o mesmo rigor fiscal. É a integração que faz essa unificação acontecer — ou é ela que falha, de forma visível, quando o volume aperta.
3. Event vs batch: por que order.placed em tempo real é a diferença no pico
O modelo antigo de integração entre a plataforma de venda e o back-office costuma ser por batch: de tempos em tempos, um job coleta os pedidos novos e os empurra para o ERP, o OMS, o fiscal. Em dia normal, funciona. No pico, não. O intervalo do batch vira latência: o pedido existe na plataforma, mas o estoque no OMS ainda não sabe, então vende de novo o que já esgotou; a nota demora a sair; o cliente recebe "confirmado" e depois "cancelado". Quanto maior o volume, mais o batch atrasa, e mais caro fica o descompasso.
O Event Framework muda a física do problema. Em vez de a sua integração perguntar "tem pedido novo?" de tempos em tempos, a plataforma avisa no exato instante em que order.placed dispara. O pedido chega ao OMS, ao ERP e ao fiscal em tempo real, por webhook, com a chance de ser processado antes de o próximo entrar. Trocar polling por evento não é refinamento — é o que mantém estoque, separação e nota em dia quando o volume multiplica. Vale lembrar que receber o evento é o começo: o seu lado precisa consumi-lo com idempotência (não duplicar nem perder pedido num retry) e ordem garantida, senão o tempo real vira caos em tempo real.
Na prática, o webhook do order.placed não deve empurrar o pedido direto para dentro do ERP de forma síncrona — esse é o erro que derruba a integração no pico. O padrão robusto é o endpoint que recebe o evento responder rápido (confirmando o recebimento) e enfileirar o pedido numa fila durável, de onde um consumidor o processa com retry controlado, backoff e deduplicação por chave do pedido. Assim, um pico de milhares de order.placed por minuto não sobrecarrega o ERP nem perde evento se um sistema a jusante oscilar: a fila absorve a rajada, e a ordem e a idempotência garantem que cada pedido seja processado uma vez, na sequência certa. É a diferença entre "recebi o evento" e "o pedido virou separação, nota e baixa de estoque corretas".
4. Blindar a borda do pico: SCAPI, rate limit, WAF e anti-bot
O pico não traz só clientes. Traz bot de scraping de preço, tentativa de credential-stuffing e picos de tráfego que derrubam resposta. Os controles SCAPI diretos do release permitem aplicar rate limit, regras de WAF e purga de cache na borda da API de commerce — antes que o tráfego ruim consuma a capacidade que deveria ser do cliente real. É a outra metade da prontidão: de um lado, o pedido legítimo flui por evento até o back-office; do outro, a borda filtra o que não deveria chegar. Prontidão de pico é as duas coisas, desenhadas juntas.
E há uma terceira coisa que amarra as duas: ensaiar antes. Blindar a borda e trocar batch por evento só valem se o conjunto aguenta a carga real — por isso o teste de carga da jornada ponta a ponta, simulando o volume esperado do pico com meses de histórico, é o que revela o gargalo enquanto ainda dá tempo de corrigir. Descobrir no primeiro domingo de novembro que o consumidor de order.placed não escala, ou que a regra de WAF está barrando cliente legítimo, é caro; descobrir num ensaio em outubro é só mais um item do roadmap. A quatro semanas da data, o trabalho não é mais de campanha — é de arquitetura e de teste.
5. Como a CCX prepara o B2C Commerce pro pico
É aqui que a CCX entra. A frente de Integrações & APIs Enterprise conecta o B2C Commerce ao seu mundo não-Salesforce por evento: order.placed → OMS, ERP, estoque, WMS e fiscal em tempo real, com arquitetura event-driven (Kafka, RabbitMQ) e idempotência, no lugar do batch que atrasa no pico — incluindo as integrações SAP ↔ e-commerce e Protheus ↔ e-commerce que sincronizam estoque, preço, pedido e NF em produção.
Sobre isso, a Observabilidade 360° (Datadog, Grafana, OpenTelemetry) rastreia o pedido da vitrine agentic até o fulfillment e expõe o gargalo antes do pico, não depois; e a consultoria Salesforce / Commerce desenha a prontidão: eventos, controles SCAPI (rate limit, WAF, anti-bot) e teste de carga da jornada ponta a ponta. O princípio, a quatro semanas do dia 27/11: o pico não se ganha na vitrine — se ganha na integração por evento atrás dela.
O pico não se ganha na vitrine — se ganha na integração por evento atrás dela. order.placed tem que chegar ao seu OMS, estoque e fiscal em tempo real, não por batch. A CCX prepara o seu B2C Commerce pro pico: integração event-driven + observabilidade ponta a ponta. Falar com especialista Salesforce →
6. Perguntas frequentes
O que é o Event Framework no B2C Commerce? É o recurso (agora em GA) que dispara eventos da plataforma — como sf.cc.order.placed — para webhooks HTTP externos em tempo real, sem polling nem batch, permitindo que sistemas como OMS, ERP e fiscal reajam no instante em que o pedido é feito.
Como integrar order.placed ao ERP e ao OMS? Expondo um endpoint que consome o webhook do evento e propaga o pedido ao ERP, OMS e fiscal por uma camada event-driven com idempotência e ordem garantida — para não duplicar nem perder pedido em retries no pico.
Preciso de licença Data 360 para o Shopper Agent? Segundo o release, a conexão confiável com a org passou a não exigir mais a licença Data 360 para ligar o Shopper e o Merchandising Agent — o que reduce a barreira para ativar a vitrine agentic.
Dá para ficar pronto a quatro semanas da Black Friday? Dá para priorizar o que mais pesa no pico: trocar as integrações de pedido críticas de batch para evento, blindar a borda com os controles SCAPI e instrumentar a jornada com observabilidade — por etapas, começando pelos fluxos de maior volume.