Portal B2B com operação de vendas: SAP Commerce Cloud ou CWS Platform?

Nota editorial: comparativo de arquitetura entre SAP Commerce Cloud e a CWS Platform no cenário Portal B2B com operação de vendas. Todo fato sobre SAP Commerce Cloud vem da documentação pública dele, com o endereço ao lado.

A decisão de implantar um canal digital de compras em empresas que já possuem uma equipe comercial consolidada expõe um dilema arquitetural crítico entre modelos como o SAP Commerce Cloud e plataformas nativas de negociação. Se o portal for desenhado apenas como uma vitrine de autoatendimento isolada, a força de vendas enxerga o sistema como um concorrente direto de sua carteira, criando fricção imediata na adoção e gerando disputas internas pelo registro dos pedidos.

Para o Diretor de Commerce, o CFO e o CEO, o sucesso da digitalização depende de transformar o canal em um instrumento de trabalho compartilhado entre comprador e vendedor, e não em um silo transacional. Quando o canal digital consegue absorver regras complexas de precificação, hierarquias de alçada e termos de pagamento sem desintermediar o vendedor de balcão, a operação ganha escala sem deteriorar as margens negociadas.

Avaliar a arquitetura adequada para esse cenário exige compreender onde residem as regras de negócio, como a governança de preços e crédito é executada no fechamento do carrinho e de que maneira a identidade comercial do vendedor permanece atrelada ao ciclo de vida do cliente corporativo.

73s

O cenário: Portal B2B integrado à força de vendas existente

Em uma operação típica de distribuição ou indústria com faturamento distribuído, empresas realizam compras recorrentes enquanto a equipe de vendas atua na prospecção, renegociação de contratos e atendimento direto no balcão. O objetivo corporativo ao introduzir o comércio digital não é substituir essa estrutura humana, mas liberar os profissionais de tarefas puramente burocráticas para que foquem em negociações consultivas.

Contudo, a dinâmica comercial do B2B envolve particularidades contratuais severas. Cada cliente possui condições comerciais específicas, vinculadas ao seu histórico, enquadramento tributário estadual, prazos de pagamento acordados e limites de crédito em conta corrente. Se o portal falha em reproduzir com precisão essas amarras em tempo de execução, o comprador abandona a interface e recorre ao telefone ou e-mail, forçando a equipe interna a redigitar cotações.

Segundo levantamento da McKinsey & Company, 2024, vendedores B2B costumam passar apenas 20% do tempo em contato direto com clientes, diante de benchmarks de um terço a metade, e relata um caso em que a IA generativa liberou 10% do tempo dos vendedores. Quando o portal opera em harmonia com os representantes, o autoatendimento passa a medir onde o cliente encontra barreiras, permitindo intervenções pontuais da equipe para destravar o fechamento.

As seis decisões que o cenário obriga

A estruturação desse modelo exige definições claras em seis decisões arquiteturais que determinam a convivência entre o autoatendimento e a equipe de campo:

1. Quem é dono do pedido quando o cliente compra sozinho. A atribuição de receita precisa ser nativa ao ciclo de vida da conta corporativa. Quando a carteira vincula o cliente ao vendedor responsável e a atribuição de comissão é configurada para o canal digital, o pedido que o cliente faz sozinho no portal deixa de ser uma ameaça à remuneração da equipe.

2. Onde mora o preço negociado. O cálculo de preço deve resolver a hierarquia entre contratos corporativos, regras comerciais e tabelas regionais, com o imposto calculado à parte pelo ERP. Se o comprador visualiza apenas uma lista padrão genérica, a transação emperra e o cliente é empurrado de volta ao contato telefônico manual.

3. Quem aprova o desconto fora da tabela. A concessão de condições especiais requer um motor transacional que execute parâmetros de margem e alçadas por perfil. A aprovação de concessões comerciais precisa ocorrer dentro do fluxo do sistema, registrando motivos padronizados em vez de depender de validações informais por aplicativos de mensagem.

4. Como vendedor e cliente montam o mesmo pedido. O ambiente de negociação precisa suportar a edição concorrente do mesmo pedido entre cliente e vendedor. A experiência falha quando o vendedor é obrigado a recriar manualmente uma lista de compras enviada por e-mail em vez de atuar sobre a mesma sessão que o comprador iniciou.

5. O que o fechamento aceita. O fechamento do pedido precisa validar estoque, preço, crédito e tributos na mesma transação. A concessão de prazos faturados e o consumo de saldo de limite de crédito devem ocorrer no próprio checkout, evitando que ordens aprovadas sejam represadas posteriormente em filas manuais do departamento financeiro.

6. Quem muda a política comercial e em quanto tempo. A manutenção de parâmetros comerciais deve pertencer à gestão de negócios, com registro rigoroso de alterações. A operação perde agilidade quando a criação de uma campanha regional ou o ajuste em limites de desconto exigem chamados de desenvolvimento e ciclos longos de publicação de código.

O que trava hoje, na voz de quem opera

Nas conversas de campo com lideranças comerciais e operacionais, a resistência ao portal manifesta-se através de inquietações recorrentes:

A frase “Meus vendedores dizem que o portal vai matar a comissão deles” expressa o receio direto da equipe frente à perda de remuneração, revelando uma falha estrutural na decisão 1, em que o canal eletrônico não vincula a autoria e a carteira do vendedor ao cliente que conclui o pedido de forma independente.

O desabafo “Cada cliente tem o preço dele, ninguém consegue colocar isso no site” sintetiza o atrito descrito na decisão 2, demonstrando como a incapacidade de processar tributos, contratos e tabelas contextuais no portal obriga o cliente a abandonar o carrinho para negociar diretamente por telefone.

A queixa “Aprovar desconto é um caos. Cada um aprova de um jeito” evidencia a ruptura tratada na decisão 3, na qual a ausência de fluxos formais de aprovação com parâmetros rígidos de margem gera autorizações descentralizadas e sem rastreabilidade.

O apontamento “Minha margem bruta está OK, mas a líquida não” reflete as consequências combinadas das decisões 3 e 5, ilustrando como o empilhamento descontrolado de benefícios comerciais e a liberação de pedidos sem checagem de limites de crédito drenam o resultado financeiro da operação.

O que o SAP Commerce Cloud resolve bem neste cenário

O SAP Commerce Cloud é estruturado sobre uma plataforma modular de nuvem voltada a grandes ecossistemas corporativos. Para operações que exigem desacoplamento entre apresentação e lógica transacional, o produto disponibiliza o composable storefront construído em Angular, que consome recursos de comércio por meio da camada de APIs REST do Omni Commerce Connect (OCC). A solução organiza recursos avançados em módulos funcionais que cobrem desde busca adaptativa e promoções até gerenciamento de pedidos.

No suporte à atuação assistida, o fornecedor documenta o Assisted Service Module (ASM), que possibilita aos atendentes navegarem e operarem na mesma interface de vitrine utilizada pelos compradores. Esse módulo permite a localização do cliente via identificador de conta ou código do carrinho, além de suportar a emulação do usuário por meio de cabeçalhos técnicos específicos nas chamadas OCC ou via logon único a partir do SAP CRM Interaction Center. Adicionalmente, agentes autenticados contam com recursos para atuar em pedidos de convidados e criar carrinhos dedicados via serviços web de assistência.

Para cenários que envolvem orçamentos e cotações de alta complexidade, a plataforma integra-se ao SAP CPQ por meio do middleware SAP Cloud Integration. O fluxo estabelece o bloqueio temporário do carrinho no portal enquanto uma solicitação de cotação em XML é processada no motor de vendas, mapeando organizações comerciais, canais de distribuição e identificadores externos do ERP. Em estruturas industriais com catálogo customizável e engenharia sob encomenda, a precificação pode delegar regras profundas ao serviço SAP Variant Configuration and Pricing hospedado no SAP BTP.

A sincronização de cadastros e políticas com a camada de gestão empresarial é suportada pelo pacote SAP Commerce Cloud Integration with ERP. Esse mecanismo utiliza adaptadores OData e extensões locais para transferir registros de preços e descontos, mapeando condições formais do ERP para o ambiente de comércio digital, além de prever pontos de extensão programáveis para adequação de fluxos operacionais corporativos.

No autoatendimento B2B, a SAP documenta cotações solicitadas e geridas pelo próprio comprador, conversão de orçamento aprovado em pedido, compra contra contrato vigente, fluxos de aprovação em múltiplas etapas, upload em lote e recompra rápida (fonte). Na cloud ERP edition, preço, disponibilidade de estoque e status do pedido são consultados em tempo real no SAP Cloud ERP. No preço, o Commerce Cloud pode calcular de forma síncrona com o back-end ou trabalhar com tabelas replicadas do ERP por uploads delta (fonte), e estrutura promoções por regras de condição e ação, com integração ao SAP Omnichannel Promotion Pricing (fonte).

Como a CWS Platform monta: governança comercial compartilhada e negociação nativa

A CWS Platform aborda o canal de venda digital B2B a partir do princípio de que o portal não é apenas uma vitrine eletrônica isolada, mas uma plataforma unificada de negociação e atendimento. A coordenação da força de vendas é sustentada pelo Assisted Selling Platform (Sales Hub), no qual o vendedor de balcão ou representante externo acessa um ambiente de trabalho integrado ao efetuar login. Ele identifica o cliente por nome, CPF ou CNPJ, compra em nome dele e pode manter vários atendimentos abertos. No atendimento valem as condições do cliente (endereços, limite de crédito, preços de contrato e regras de preço), sem que o comprador precise estar logado.

Essa convivência se apoia no carrinho compartilhado. Vendedor e comprador trabalham sobre o mesmo pedido: o que um altera aparece para o outro ao recarregar a página, e o chat permite negociar e ajustar o carrinho na conversa. O pedido rotineiro sai da mesa do vendedor, que fica com o relacionamento e a negociação complexa.

A determinação dos valores transacionados ocorre no Contextual Pricing (Pricing Engine), que resolve o preço na ordem de precedência: contrato comercial sobrepõe-se à regra de preço, que por sua vez tem precedência sobre a tabela geral. A elegibilidade de cada regra pode considerar tipo e tag de cliente, CNAE, inscrição estadual, contribuinte de ICMS, NCM, quantidade mínima e o par UF do depósito e UF de destino; entre regras não cumulativas vale só a de maior prioridade, e regra ou contrato podem bloquear desconto adicional do vendedor. O imposto do item é calculado pela API de tributos do ERP do cliente.

Para manter a integridade financeira sem transferir gargalos à retaguarda, o Commerce Rules Engine (CDL Workspace) orquestra alçadas de aprovação multinível diretamente no fechamento. Se o desconto inserido pelo vendedor ultrapassar o limite autorizado para seu perfil, a transação exige a inserção de um motivo padronizado e encaminha a ordem automaticamente para o aprovador responsável da cadeia hierárquica. O fechamento passa pelo Credit-First B2B Checkout (Checkout & Payments), que trata o limite de crédito como conta corrente do cliente, com saldo e extrato: com saldo suficiente, o pedido é aprovado automaticamente; sem saldo, conforme a regra da loja, fica pendente de aprovação. Daí o pedido segue para o OMS / Seller Center e para o ERP, que emite a nota fiscal.

A régua arquitetural que separa essas concepções é a capacidade de diminuir o custo de transação da cadeia comercial. Quando a plataforma executa as regras contratuais e os limites de crédito, e vendedor e cliente trabalham no mesmo carrinho, o processo de venda ganha velocidade e reduz retrabalho manual.

Onde nascem as dores deste cenário, e como a arquitetura as resolve:

Onde as arquiteturas divergem de verdade

A principal divergência entre as arquiteturas reside em como o canal digital posiciona a atuação da equipe de vendas em relação ao autoatendimento do cliente.

O SAP Commerce Cloud cobre o autoatendimento B2B com profundidade e, para cotação complexa, combina o Commerce Cloud com o SAP CPQ por meio do SAP Cloud Integration. A CWS parte do outro lado: vendedor e comprador trabalham no mesmo carrinho, sob as mesmas regras de preço, alçada e crédito, executadas na própria plataforma.

A própria documentação da SAP registra dois limites na integração de pedidos com o S/4HANA:

• limitação registrada na documentação do fornecedor em 09/09/2026: o módulo SAP S/4HANA Order Management só é suportado no Composable Storefront e não cobre cenários com Product Variant Configuration do S/4HANA ("supported only on the SAP Commerce Cloud, composable storefront", https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/47ad58c1a27447949aad8addbee46fca/63eab6b625fe43b3a3e637b14eb0e6be.html?locale=en-US&state=PRODUCTION&version=2211).
• limitação registrada na documentação do fornecedor em 09/09/2026: no pedido síncrono com o S/4HANA não há suporte a vários centros de custo B2B ("Multiple B2B cost centers aren't supported.", https://help.sap.com/docs/SAP_COMMERCE_INTEGRATIONS/47ad58c1a27447949aad8addbee46fca/dd3c227d5863456c9e6d242c06adbf52.html?locale=en-US&state=PRODUCTION&version=2211).

Na prática, a escolha depende de onde está o centro do projeto: autoatendimento com paridade ao ERP SAP, ou autoatendimento e venda assistida no mesmo carrinho, sob as mesmas regras.

Quando o SAP Commerce Cloud é a escolha certa neste cenário

O SAP Commerce Cloud é a escolha mais sólida nestes contextos:

Empresa que já roda SAP Cloud ERP e quer o portal dentro do ecossistema. Escolha essa arquitetura quando o ERP já é o SAP Cloud ERP e a prioridade é paridade imediata com ele. A SAP Commerce Cloud, cloud ERP edition consulta preço, estoque e status do pedido em tempo real no ERP, traz compra a prazo, preço por cliente e cotação para pedido, e a SAP anuncia implantação padrão de cerca de 12 semanas (fonte). Pré-requisitos declarados: contratação prévia de SAP Finance Base, Finance Premium ou Finance Base and Supply Chain Base, e venda em blocos de 10.000 pedidos/ano, com contratos de 1 a 3 anos.

Cotação de produto configurável, com engenharia sob encomenda. Escolha essa arquitetura quando o produto é configurado sob encomenda, com regras de variante que pedem um configurador dedicado. O SAP CPQ trata cotações de mais de 10.000 linhas, com regras de elegibilidade e guardrails de desconto (fonte), e se conecta ao SAP Variant Configuration and Pricing no SAP BTP (fonte); integrado ao Commerce Cloud, a cotação aceita volta ao portal e vira pedido (fonte).

Front-end próprio, em código, como requisito. Escolha essa arquitetura quando a empresa quer construir e manter o próprio front-end, com time de engenharia dedicado. O composable storefront é uma aplicação Angular desacoplada, publicada como bibliotecas open-source, que conversa com o back-end pelas APIs REST do Omni Commerce Connect (fonte).

Autoatendimento como canal principal, em conta que já roda SAP Cloud ERP. Escolha essa arquitetura quando o objetivo é o comprador resolver sozinho cotação, compra contra contrato, aprovação em etapas, upload em lote e recompra, com os dados do ERP SAP, e a venda assistida não é o centro do projeto (fonte). Se a necessidade for só consulta de pedidos e faturas, o SAP B2B Self-Service Portal atende sem catálogo, carrinho ou checkout, por desenho contratual.

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

A CWS Platform é a escolha adequada quando o objetivo estratégico é dar autonomia à equipe comercial e operacionalizar regras de vendas em curto prazo sem complexidade de código.

Equipe de vendas operando em cooperação com o comprador. Escolha essa arquitetura quando a força comercial precisa atuar de maneira colaborativa no fechamento de pedidos sem disputar canais com o cliente. O vendedor monta e salva o carrinho e envia o link; o cliente edita, fecha sozinho ou devolve para o vendedor finalizar, e o vendedor fica identificado no pedido. A carteira pode vincular cada cliente a um único vendedor, e a atribuição de comissão é configurável.

Distribuição com várias lojas e filiais. Escolha essa arquitetura quando a operação tem várias filiais com preço, pagamento e crédito próprios. Contratos podem ser limitados por filial e UF, regras de preço criadas na matriz são replicadas nas lojas escolhidas, cada loja escolhe seu gateway de pagamento e o limite de crédito pode valer por loja ou para a matriz inteira.

Autonomia comercial para governança de alçadas e crédito. Escolha essa arquitetura quando a diretoria comercial precisa ajustar alçadas de desconto, margem mínima e condições de pagamento por configuração, sem chamado de desenvolvimento. Depois que a CWS habilita o recurso para a loja, o próprio time comercial liga e ajusta os parâmetros no CDL.

Integração ao ERP por API, com vitrine sem código. Escolha essa arquitetura quando a prioridade é integrar o ERP por APIs REST (clientes, contratos, regras de preço, limite de crédito) e webhooks de evento, sem manter um front-end próprio: a vitrine é montada sem código, em template único dinâmico.

Escolher a CWS para o portal não significa trocar o ERP. Se a empresa roda SAP, o ERP segue como sistema de registro: a CWS recebe dele cliente, contrato e limite de crédito por API, pode calcular o imposto por item chamando a API de tributos do ERP antes de fechar o pedido e devolve o pedido para faturamento, porque a nota fiscal continua sendo emitida pelo ERP. As planilhas de contrato e regra aceitam os códigos externos do ERP para cliente, depósito e SKU.

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 Vender Mais Não Significa Ganhar Mais e Quando os Canais Brigam Entre Si tratam disso em profundidade, sem falar de fornecedor nenhum.

Leia também

• O que é venda B2B e como ela funciona na prática
• Módulo de vendas do ERP ou plataforma B2B dedicada?