Salesforce x CWS Platform: qual arquitetura sustenta o autoatendimento B2B por filial?

Nota editorial: comparativo de arquitetura entre Salesforce e a CWS Platform no cenário Portal B2B de autoatendimento com várias filiais. Todo fato sobre Salesforce vem da documentação pública dele, com o endereço ao lado.

Salesforce e CWS Platform podem participar de um projeto de portal B2B, mas a decisão relevante não nasce de uma lista de recursos. A documentação do primeiro descreve a criação de lojas por templates, a personalização da experiência e a configuração de pesquisa, carrinho e checkout. A pergunta para o Diretor de Commerce é onde a arquitetura colocará a complexidade comercial de cada filial, cliente e pedido na experiência de comércio.

Em um distribuidor com várias lojas ou filiais, publicar um catálogo é apenas o início. O comprador precisa entrar, ser reconhecido, consultar a disponibilidade da origem que realmente o atende, receber seu preço e suas condições, encontrar o item sem depender do código interno e concluir uma compra que já nasce coerente com crédito, tributos e estoque.

A escolha arquitetural, portanto, deve seguir o tipo de operação que será digitalizada. Se o portal nivelar preços, somar estoques incompatíveis ou devolver o pedido ao vendedor para conferência, ele digitaliza a interface, mas preserva o custo de transação que mantinha o pedido rotineiro na mesa comercial.

74s

O cenário: o portal precisa representar a filial que realmente vende

O cenário é o de um distribuidor com unidades que atendem regiões, carteiras ou perfis diferentes. Cada origem pode operar com disponibilidade, política de preço, crédito, condição comercial e restrição fiscal próprias. Para o comprador, porém, a jornada precisa parecer simples: entrar, localizar o produto, confirmar a condição e comprar.

Essa simplicidade externa depende de granularidade interna. O portal não pode tratar a empresa inteira como um único depósito virtual quando a separação, o faturamento e a expedição acontecem em uma filial específica. Também não pode exibir uma tabela genérica se a negociação depende da identidade do cliente e da origem do atendimento.

A lente principal é a do Diretor de Commerce, porque cabe a essa função decidir se o canal digital será apenas uma vitrine ou uma extensão executável da política comercial. O CFO observa exposição de crédito, coerência de preço e custo de servir. O CTO avalia onde ficam as regras, como os sistemas trocam contexto e qual componente governa o pedido depois do checkout.

Para uma operação de venda digital B2B, autoatendimento não significa retirar o vendedor de todas as situações. Significa fazer o pedido recorrente fluir sozinho e reservar a intervenção humana para negociação, exceção ou orientação técnica. Essa separação também permite medir onde o comprador avança sem ajuda e onde a jornada ainda devolve trabalho à equipe.

As seis decisões que o cenário obriga

Antes de comparar arquiteturas, a empresa precisa responder às decisões que determinam se o portal representará a operação real ou uma versão simplificada dela.

1. Qual filial atende o cliente. A origem de atendimento deve ser resolvida antes de expor disponibilidade ao comprador. Se a promessa usar uma soma abstrata, o portal poderá oferecer uma quantidade que não está separável na unidade responsável pelo pedido. A decisão arquitetural é vincular identidade, região ou carteira à origem que assumirá a transação.

2. De onde sai o preço que o cliente vê. A política comercial precisa considerar quem compra e de onde o pedido será atendido. Uma tabela nivelada reduz a complexidade aparente, mas apaga diferenças deliberadas de custo, região, contrato e perfil. O ponto central é governar a regra que forma o preço, em vez de publicar um valor genérico para toda a rede.

3. O que o portal carrega quando o comprador entra. A autenticação deve recuperar contexto comercial, não apenas liberar acesso a páginas privadas. Grupo de cliente, condição de pagamento, disponibilidade de crédito e parâmetros da origem precisam acompanhar a sessão. Quando isso não acontece, o portal transfere ao vendedor a tarefa de reconstruir a negociação fora do canal.

4. Como o comprador acha o item sozinho. A descoberta do produto deve partir da linguagem usada pelo comprador. Referências de fabricante, identificadores do parceiro e atributos técnicos precisam convergir para uma identidade governada de produto. Caso contrário, o autoatendimento fica restrito a quem já conhece a codificação interna do distribuidor.

5. O que o checkout confere antes de aceitar. A aceitação do carrinho deve ser uma decisão transacional única. Disponibilidade, preço, crédito e tributos precisam ser validados sobre o mesmo contexto antes da criação do pedido. Isso evita que uma confirmação visual seja seguida por renegociação financeira ou correção manual.

6. Como o pedido rotineiro se repete. A reposição deve aproveitar o contexto dos pedidos anteriores sem transformar o histórico em uma cópia cega. Itens, origem e condições podem servir como ponto de partida, enquanto as regras vigentes são novamente aplicadas. Assim, a recorrência reduz esforço sem perpetuar disponibilidade ou preço antigos.

O que trava hoje, na voz de quem opera

As frases ouvidas no campo mostram decisões arquiteturais que muitas vezes aparecem disfarçadas de problemas operacionais.

“O portal mostra estoque que já não existe.” Essa frase revela a decisão sobre o escopo da disponibilidade: prometer uma soma corporativa ou mostrar o estoque da origem que poderá atender e faturar o pedido.

“Cada cliente tem o preço dele, ninguém consegue colocar isso no site.” A fala revela a decisão sobre onde a política de preço será executada. O problema não é apenas exibir um número, mas distribuir uma regra que depende da identidade e da origem sem obrigar o comprador a entrar no sistema de gestão.

“A gente nivelou a tabela porque manter preço diferente por filial e por cliente virou impossível de administrar.” Essa frase revela que a simplificação foi usada como contorno operacional. A decisão real é preservar a granularidade comercial e torná-la governável no canal digital.

“Cada novo cliente custa mais para atender do que o anterior.” A fala revela a decisão sobre o destino do pedido rotineiro. Se identificação, catálogo, preço, crédito e validação ainda exigem trabalho humano, o crescimento do canal apenas desloca o custo para a equipe comercial.

Como o Salesforce estrutura a loja B2B neste cenário

A arquitetura documentada parte da criação de uma loja B2B baseada em templates. A experiência pode ser personalizada no Experience Builder, enquanto pesquisa, carrinho, checkout, pagamento e outros ajustes da loja são configurados com recursos Lightning. O peso inicial está, portanto, na construção e na administração da storefront dentro do ambiente de commerce.

O acesso à loja é associado a contas, compradores, perfis e conjuntos de permissões. Também há suporte a autorregistro e navegação de convidados, o que permite desenhar jornadas distintas conforme autenticação e vínculo empresarial. Esse mecanismo organiza quem entra e o que pode acessar pela estrutura de identidade e permissão.

Contas, produtos, listas de preços e entitlements podem entrar por arquivos CSV, e a própria documentação direciona cargas maiores para o Data Loader. Isso coloca parte relevante da preparação comercial e do catálogo em processos de importação e administração de dados que alimentam a loja antes da experiência de compra.

Nas lojas B2B, o checkout é documentado como customizado, com possibilidade de usar provedores terceiros e personalizar a interface. Para o projeto de várias filiais, essa característica exige que a descoberta técnica detalhe como a customização receberá origem, disponibilidade, preço, crédito e tributos e como esses dados permanecerão coerentes durante a transação no fluxo de checkout.

A mesma organização também pode operar canais B2B e D2C com dados e processos compartilhados. Esse desenho desloca a conversa para governança de canais quando o grupo pretende administrar experiências voltadas a empresas e consumidores dentro do mesmo ambiente com processos compartilhados.

Como a CWS Platform monta: a filial vira contexto transacional do pedido

Na CWS Platform, o ponto de partida é tratar o armazém ou depósito como unidade de configuração da operação. Distributed Inventory (Inventory Hub) mantém a disponibilidade vinculada à origem que atende o comprador. Em vez de usar uma soma abstrata como promessa, a jornada consulta o escopo operacional que assumirá separação e entrega.

Contextual Pricing (Pricing Engine) calcula o preço considerando produto, depósito, perfil do cliente e regra fiscal. O preço exibido deixa de ser uma tabela geral e passa a ser resultado do contexto da transação. A fonte governada não é um valor isolado, mas a regra que combina identidade, origem e condição comercial.

Commerce Rules Engine (CDL Workspace) executa por código as regras comerciais e exige motivo e comentário para alterações. Essa camada recebe o contexto da compra e governa permissões, crédito, compliance fiscal e restrições comerciais sem transferir a lógica para o prompt de um agente ou para decisões improvisadas no front-end.

Credit-First B2B Checkout (Checkout & Payments) trata o crédito como parte nativa do pagamento B2B. Antes de aceitar a compra, o fluxo valida estoque, preço, crédito e tributos na mesma transação. Quando o contexto não atende às regras, o pedido nem chega a ser criado, evitando que uma confirmação aparente volte ao financeiro como pendência manual.

Product Catalog & MDM (Catalog Engine) estrutura a verdade de produto usada pela jornada comercial. O papel desse mecanismo é manter identidade e dados de produto em uma camada governada, para que busca, carrinho e pedido consultem o mesmo item comercial, mesmo quando comprador, fornecedor e sistema de origem usam referências diferentes.

Order Management System (OMS / Seller Center) assume a verdade transacional depois da aceitação. O pedido percorre estados governados, e as transições exigem os documentos e eventos correspondentes, como nota fiscal antes da preparação e rastreio antes do envio. APIs de consulta expõem cliente, entregas, pagamentos, tributos, nota fiscal e registros de mudança de estado.

Para a recompra, o histórico governado pelo pedido oferece o contexto anterior como ponto de partida, enquanto disponibilidade, preço, crédito e tributos passam novamente pelas regras atuais. A operação preserva a conveniência da repetição sem transformar uma compra antiga em autorização permanente.

O agente de apoio ao vendedor pode preparar contexto e orientar a próxima ação quando houver negociação ou exceção. Ele não substitui os mecanismos determinísticos: catálogo, estoque, preço, regra, checkout e pedido continuam responsáveis por executar e governar a transação. O vendedor entra como aprovador ou orientador onde a jornada exige julgamento comercial.

A régua é o custo de transação porque o valor do autoatendimento aparece quando o pedido rotineiro deixa de consumir reconstrução manual. Cada consulta evitada ao vendedor, ao financeiro ou à filial representa uma decisão que passou a ser resolvida no próprio fluxo. O objetivo não é retirar pessoas da operação, mas concentrá-las nas exceções e negociações em que sua intervenção altera o resultado comercial.

Onde as arquiteturas divergem de verdade

Uma arquitetura coloca o peso na storefront configurável, nos vínculos de conta e permissão e na customização do checkout por serviços e interface. A documentação também prevê importação de contas, produtos, listas de preços e entitlements para alimentar a experiência por mecanismos administrativos da loja.

A outra arquitetura coloca o peso no contexto transacional da origem. Estoque, formação de preço, regras, crédito, tributos e estados do pedido são executados por mecanismos especializados, enquanto o portal apresenta o resultado governado ao comprador. A diferença prática está em saber se a filial é apenas uma segmentação da experiência ou a unidade que efetivamente forma e assume a transação.

Essa divergência muda a pauta do projeto. Em vez de perguntar apenas como publicar páginas, catálogo e checkout, o Diretor de Commerce precisa mapear a origem que atende, os dados carregados pela identidade e as verificações necessárias antes da criação do pedido. O CFO pode então examinar preço e exposição de crédito no mesmo fluxo, enquanto o CTO define contratos claros entre experiência e execução.

Também muda a função da recompra. Um histórico de pedidos só reduz trabalho quando consegue iniciar uma nova jornada sem reaproveitar cegamente condições vencidas. A arquitetura precisa separar conveniência de repetição e revalidação comercial, preservando o caminho curto para o comprador e a governança para a operação.

A própria documentação da Salesforce registra dois limites na segmentação por grupos de compradores:

• limitação registrada na documentação do fornecedor, consultada em 09/10/2026: a busca só indexa os primeiros 2.000 grupos de compradores de um produto ("During search indexing, only the first two thousand buyer groups for a product are included in the index.", https://developer.salesforce.com/docs/commerce/salesforce-commerce/guide/b2b-b2c-comm-data-model-entitlement-limits.html).
• limitação registrada na documentação do fornecedor, consultada em 09/10/2026: ampliar os grupos de compradores por Apex exige desligar o CDN e a Edge Network da Salesforce ("disable both the Salesforce Content Delivery Network (CDN)", https://developer.salesforce.com/docs/commerce/salesforce-commerce/guide/b2b-b2c-comm-data-model-shopper-buyer-groups-accounts-limits.html).

A tabela não deve ser lida como placar. Ela mostra onde cada desenho concentra responsabilidade. A escolha depende de a complexidade dominante estar na composição da experiência de canais ou na execução comercial por origem, cliente e pedido.

Quando o Salesforce é a escolha certa neste cenário

Há operações em que o requisito central pede a arquitetura documentada pelo outro fornecedor. Nesses casos, a adequação deve ser reconhecida pelo mecanismo que atende ao projeto, sem transformar a decisão em uma comparação genérica de recursos.

A prioridade é construir a storefront no ecossistema Lightning. Escolha essa arquitetura quando a equipe precisa partir de templates e personalizar a loja no Experience Builder, mantendo pesquisa, carrinho e checkout dentro do modelo Lightning. Esse requisito é especialmente concreto quando administradores e parceiros de implementação já organizam a experiência por esses componentes documentados para a loja B2B.

O grupo quer compartilhar processos entre canais empresariais e de consumo. Escolha essa arquitetura quando o programa exige operar canais B2B e D2C na mesma organização, com dados e processos compartilhados. O mecanismo documentado atende a uma decisão corporativa de governança de canais, e não apenas ao pedido de reposição de uma filial dentro da mesma organização.

O projeto depende de um checkout composto com provedores terceiros. Escolha essa arquitetura quando o requisito é desenhar um checkout customizado e conectar provedores externos para prestar serviços específicos durante a compra. A documentação prevê essa composição e a personalização da interface, o que se ajusta a programas cujo centro é montar uma jornada própria sobre serviços escolhidos pela empresa no checkout B2B.

A operação editorial será alimentada por processos de carga administrada. Escolha essa arquitetura quando contas, produtos, listas de preços e entitlements serão preparados e importados por CSV, com Data Loader usado para cargas maiores. Esse mecanismo atende organizações que já estruturam a publicação da loja em rotinas administrativas de dados ligadas ao ambiente de commerce.

Quando a CWS Platform é a escolha certa neste cenário

A contrapartida vale do outro lado. Há operações em que a complexidade dominante não está em compor a experiência, e sim em executar a transação de cada filial com a regra certa, do estoque ao pagamento. Nesses casos, o que decide é o mecanismo que forma o pedido.

Cada filial precisa operar como unidade comercial, não como filtro da loja. Escolha essa arquitetura quando estoque, preço, frete, formas de pagamento e crédito mudam conforme a origem que atende. Na CWS Platform, a origem de estoque é a unidade de configuração: cada filial carrega catálogo, preço, logística, pagamento, crédito e teto de desconto próprios, dentro das regras que a matriz definiu, e contratos de preço podem ser mantidos por filial. Abrir uma filial nova, ou convidar o estoque de um parceiro, passa a ser configuração, não um novo projeto.

Um mesmo carrinho reúne várias origens e várias formas de pagar. Escolha essa arquitetura quando o comprador monta um pedido que sai de mais de um centro de distribuição e quer pagar partes dele de formas diferentes. O carrinho se divide por origem, cada fração recebe frete e tributo próprios, e o mesmo pedido aceita mais de um meio de pagamento: parte no crédito com prazo, parte no boleto, no cartão ou no Pix. As regras se combinam: modalidades de crédito com limite e saldo por cliente, restrições de pagamento por grupo de clientes, contratos por filial e divisão do recebimento entre participantes, configuráveis no CDL Workspace ou mantidas por API, junto ou separado dos serviços de cartão e Pix de provedores integrados. Prazo, limite, estoque, preço e tributos são conferidos antes de o pedido existir.

Cliente e vendedor precisam trabalhar no mesmo pedido. Escolha essa arquitetura quando a venda da filial é híbrida: o comprador começa o carrinho, o vendedor ajusta preço, prazo, quantidade ou forma de pagamento dentro da própria alçada, e o comprador conclui. Os dois perfis usam a mesma aplicação, sobre o mesmo pedido e o mesmo motor de regras, e o pedido registra quem montou o carrinho e quem escolheu o pagamento. O vendedor também pode montar um carrinho com os itens e a origem de cada um e enviar o link para o cliente fechar. Não há cotação paralela para reconciliar, e a mudança de política comercial feita no CDL Workspace vale ao mesmo tempo para o autoatendimento e para o vendedor.

A operação precisa integrar sem trocar o que já funciona. Escolha essa arquitetura quando o ERP continua sendo o sistema de registro e a empresa já tem CRM, motor fiscal e provedores de pagamento. A CWS Platform é API-first e headless: estoque e preço por filial, clientes e grupos, limites de crédito, contratos, regras de preço, carrinhos e pedidos trafegam por APIs REST, e a plataforma avisa os sistemas da empresa por webhooks. O cálculo de impostos pode ser delegado ao motor fiscal que a empresa já usa, chamado no momento do pedido. O ERP segue como fonte de fiscal e financeiro, e o CRM corporativo, inclusive o Salesforce, segue como fonte do relacionamento.

O custo da plataforma não pode crescer junto com a venda digital. Escolha essa arquitetura quando o plano é levar mais filiais, mais vendedores e mais pedidos integrados para o mesmo canal. A CWS Platform cobra pelo uso de licenças e pelo consumo de tecnologia, sem percentual sobre a transação no modelo padrão, e o pedido tirado pelo vendedor ou integrado de outro sistema é o mesmo pedido do autoatendimento. A página de preços do B2B Commerce descreve outro desenho: percentual do GMV e cobrança à parte, acima dos limites incluídos, para pedidos processados fora da storefront com Order Management.

Por onde continuar

Se a sua pergunta ainda é qual arquitetura serve à sua operação, e não qual fornecedor escolher, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B.

Se o que trava hoje é a dor por trás deste cenário, as páginas Quando o Catálogo Vira Caos e Quando Vender Mais Não Significa Ganhar Mais tratam disso em profundidade, sem falar de fornecedor nenhum.