Salesforce x CWS Platform: qual arquitetura faz o portal B2B vender com a força de vendas?

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

Comparar Salesforce x CWS Platform neste cenário exige olhar além da publicação de uma loja. A decisão real é definir como o pedido digital entra na operação comercial: quem recebe o crédito pela venda, qual preço o comprador enxerga, como uma exceção é aprovada, quem acompanha o carrinho e quais regras precisam ser satisfeitas antes da criação do pedido.

Um portal B2B pode reduzir trabalho manual e, ainda assim, criar conflito com a equipe comercial. Isso acontece quando o cliente ganha um canal de autoatendimento, mas o vendedor perde visibilidade, remuneração ou capacidade de intervir. A arquitetura precisa transformar o portal em instrumento da carteira, não em um canal paralelo que concorre pelo mesmo pedido.

A lente principal é a do Diretor de Commerce, responsável por conectar experiência digital, política comercial e execução. O CFO observa margem, crédito e rastreabilidade. O CEO procura escala sem ruptura com o modelo de vendas. O vendedor de balcão precisa reconhecer no canal digital uma forma de atender melhor sua carteira e participar da negociação.

74s

O cenário: o cliente compra sozinho, mas o vendedor continua dentro da venda

O cenário começa com uma base de clientes recorrentes, cada qual com cadastro, carteira, condição comercial e histórico próprios. Parte desses compradores quer repetir pedidos sem esperar atendimento. Outra parte inicia sozinha, mas precisa de ajuda para escolher itens, negociar uma condição ou concluir o fechamento.

Nesse contexto, o portal não pode tratar toda compra como uma sessão anônima de varejo. A identidade do comprador precisa recuperar o contexto comercial aplicável, enquanto o vendedor precisa visualizar e orientar a mesma negociação. A experiência digital e a venda assistida tornam-se manifestações do mesmo processo.

Essa é a diferença entre publicar uma vitrine e operar uma venda digital B2B. A vitrine organiza navegação e captura um carrinho. A operação comercial distribui preço negociado, critérios de aprovação, crédito, responsabilidade pela carteira e estado do pedido sem obrigar comprador ou vendedor a reconstruir essas informações fora do canal.

O conflito aparece quando o portal recompensa somente o autoatendimento e a organização remunera somente o pedido digitado pelo vendedor. Nesse desenho, incentivar o cliente a usar o canal digital ameaça a participação do vendedor na receita. A resistência deixa de ser um problema de treinamento e passa a ser uma resposta racional ao modelo operacional.

A arquitetura adequada precisa reconhecer que autoatendimento e assistência podem ocorrer na mesma jornada. O cliente pode montar parte do pedido, o vendedor pode revisar a composição, uma regra pode encaminhar uma exceção e o fechamento pode consultar a condição de crédito. O pedido continua sendo um só, mesmo quando a iniciativa muda de mãos ao longo da negociação.

As seis decisões que o cenário obriga

A escolha deve ser conduzida pelas decisões que determinam se o portal funciona como canal comercial compartilhado ou como uma loja isolada da operação de vendas.

1. Quem é dono do pedido quando o cliente compra sozinho. A identidade autenticada deve recuperar a carteira responsável e manter essa relação durante a jornada. A política de remuneração pode então reconhecer a participação comercial mesmo quando o comprador conclui sozinho, retirando do vendedor o incentivo para deslocar o pedido de volta ao atendimento manual.

2. Onde mora o preço negociado. O comprador precisa receber a condição aplicável ao seu contexto, e não uma referência genérica que será renegociada fora do canal. Quando contrato, perfil, depósito e regra fiscal participam do cálculo, o portal passa a distribuir a política já usada pela operação comercial.

3. Quem aprova o desconto fora da tabela. A exceção deve entrar em um fluxo identificável, com limite aplicável, responsável pela decisão, motivo e registro da alteração. Isso transforma uma conversa informal em decisão comercial governada e permite ao CFO distinguir concessão deliberada de vazamento de margem.

4. Como vendedor e cliente montam o mesmo pedido. Comprador e vendedor precisam atuar sobre o mesmo contexto transacional. A assistência deixa de gerar uma nova digitação e passa a orientar, corrigir ou complementar a negociação já iniciada, preservando itens, quantidades e identidade.

5. O que o fechamento aceita. O fechamento deve aplicar prazo, limite de crédito e demais condições antes de criar uma obrigação operacional. Se a transação não estiver apta, o fluxo encaminha a decisão necessária sem produzir um pedido que depois precise ser desmontado pelo financeiro.

6. Quem muda a política comercial e em quanto tempo. A política comercial deve ser administrada como regra de negócio, com autoria, motivo e vigência reconhecíveis. Assim, uma mudança de limite ou aprovação entra no fluxo operacional de maneira controlada, em vez de depender de conhecimento disperso ou alteração improvisada no canal.

O que trava hoje, na voz de quem opera

As frases ouvidas em campo revelam que o impasse não está apenas na interface do portal. Cada uma aponta para uma decisão de desenho comercial.

“Meus vendedores dizem que o portal vai matar a comissão deles.” A frase revela a decisão sobre a propriedade econômica do pedido: se a carteira continua reconhecida quando o cliente compra sozinho, o canal pode ampliar o alcance do vendedor; se esse vínculo desaparece, a organização cria uma disputa interna.

“Cada cliente tem o preço dele, ninguém consegue colocar isso no site.” A frase revela a decisão sobre onde a negociação vira regra distribuível. O desafio não é somente armazenar tabelas, mas calcular a condição pertinente e apresentá-la ao comprador e ao vendedor no momento da compra.

“Aprovar desconto é um caos. Cada um aprova de um jeito.” A frase revela a decisão sobre governança da exceção. Quando limite, justificativa e responsável não estão no fluxo, a velocidade da negociação depende de telefonemas e a auditoria precisa reconstruir o que ocorreu.

“Minha margem bruta está OK, mas a líquida não.” A frase revela a decisão sobre a fronteira da política comercial. Desconto, crédito, condição de pagamento e alterações posteriores precisam ser observados no contexto da transação, pois uma leitura isolada do preço não explica todo o resultado econômico.

“Meu faturamento depende de trezentas pessoas lembrarem de ligar para os clientes certos.” A frase revela a decisão sobre o papel do vendedor. A plataforma deve levar contexto e negociações preparadas à equipe, deixando o trabalho humano concentrado em orientar, aprovar ou tratar a exceção relevante.

O que o Salesforce resolve bem neste cenário

A arquitetura documentada combina uma camada de comércio com registros comerciais. No comércio B2B, a loja nasce de templates, pode ser personalizada no Experience Builder e recebe configuração de pesquisa, carrinho, checkout, pagamento e demais ajustes por recursos Lightning, o que concentra a construção da experiência no ambiente de storefront descrito na documentação.

A preparação da loja inclui contas, produtos, listas de preços e entitlements importados por CSV, com processamento assíncrono e recomendação de Data Loader para cargas maiores. Esse mecanismo atende operações que desejam estruturar catálogo, acesso e condições de compra a partir dos objetos previstos pela camada de comércio e de seus processos de importação.

O acesso da compra B2B é organizado por perfis e permission sets. Compradores podem ser associados a contas e grupos, podem usar autorregistro e também podem navegar como convidados, de modo que identidade e autorização ficam vinculadas à estrutura de acesso configurada para a loja segundo a página de introdução.

O checkout B2B documentado é customizado, com possibilidade de usar provedores terceiros e de adaptar a interface. Isso coloca parte importante da adequação transacional no desenho do checkout e nas integrações escolhidas para a implementação conforme o mecanismo publicado.

Na frente comercial, o núcleo registra leads, contas, contatos e oportunidades, acompanha o avanço das oportunidades e registra o que está sendo vendido e seu valor. A configuração também alcança territórios, equipes de venda, previsões baseadas no pipeline e divisão de receita e crédito, oferecendo uma estrutura corporativa para governar a atividade do vendedor dentro do processo de vendas.

A área de trabalho do vendedor reúne oportunidades, contas, leads, contatos, agenda, metas, tarefas e registros recentes. Há também uma experiência que prioriza métricas e tarefas com IA, enquanto resumos e automação de entrada de dados apoiam o trabalho sobre os registros comerciais apresentados na visão do núcleo de vendas.

Para organizações que combinam modelos de canal, a mesma organização pode operar comércio B2B e D2C com dados e processos compartilhados. Esse desenho é relevante quando a decisão principal envolve administrar storefronts voltadas a públicos diferentes dentro de uma estrutura comum de dados e processos.

Como a CWS Platform monta: uma negociação compartilhada, governada antes de virar pedido

A CWS Platform coloca o peso no encontro entre autoatendimento e venda assistida. A Assisted Selling Platform (Sales Hub) mantém comprador e vendedor no mesmo carrinho, associa o cliente à carteira e oferece o contexto de atendimento. O vendedor pode acompanhar uma negociação iniciada no portal sem abrir uma versão paralela, enquanto o cliente preserva o que já selecionou.

Esse desenho muda a função do canal. O portal deixa de capturar um pedido para depois entregá-lo à equipe e passa a ser o próprio ambiente de negociação. A carteirização mantém a responsabilidade comercial visível, e a política de remuneração pode reconhecer o vendedor responsável mesmo quando a conclusão ocorre por autoatendimento.

O preço é calculado dinamicamente, considerando produto, depósito, perfil de cliente e regra fiscal. A precedência entre contrato, regra e tabela permite apresentar a condição pertinente ao contexto, em vez de publicar uma referência genérica e transferir a negociação real para uma ligação.

Distribuir essa lógica é parte central da arquitetura. A regra de preço pode existir no sistema de gestão, mas comprador e vendedor precisam consumi-la sem operar diretamente esse sistema. O portal torna a política comercial acessível no ponto de decisão e reduz a necessidade de interpretar manualmente planilhas, mensagens ou instruções locais.

A governança da exceção passa pelo Commerce Rules Engine (CDL Workspace). Limites comerciais e fluxos de aprovação são aplicados durante a negociação, com motivo e registro de quem alterou a decisão. Quando uma condição ultrapassa o que pode ser concedido diretamente, a transação segue para aprovação; quando viola um limite impeditivo, o pedido nem chega a ser criado.

O fechamento ocorre no Credit-First B2B Checkout (Checkout & Payments). Crédito entra como condição nativa da transação, e o mecanismo valida estoque, preço, crédito e tributos na mesma transação. Prazo e limite deixam de ser uma conferência posterior do financeiro e passam a participar da aptidão do pedido antes da confirmação.

Após o fechamento, o Order Management System (OMS / Seller Center) governa o pedido por estados e exige os elementos operacionais associados a cada transição. Nota fiscal e rastreio entram no fluxo correspondente, enquanto a integração com o sistema de gestão preserva uma verdade compartilhada sobre o andamento do pedido.

O agente de apoio ao vendedor pode organizar o contexto da carteira e preparar uma ação comercial, mas a decisão transacional continua submetida aos serviços determinísticos. A IA pode orientar a jornada, sugerir uma composição ou chamar atenção para uma oportunidade. Preço, regra, crédito e estado do pedido continuam sendo executados pelos mecanismos responsáveis.

Esse limite importa para o Diretor de Commerce porque impede que uma experiência conversacional crie uma política paralela. Também importa para o CFO, que encontra a regra e sua exceção no fluxo. Para o vendedor de balcão, a consequência é prática: atender pelo portal significa trabalhar sobre o mesmo pedido do cliente, não disputar quem vai digitá-lo.

O modelo também reposiciona o vendedor como aprovador e orientador. Em negociações rotineiras, o comprador avança sozinho. Quando surge uma escolha técnica, uma condição excepcional ou uma oportunidade de composição, a equipe entra no ponto adequado e atua sobre uma negociação já preparada.

A régua correta é o custo de transação comercial. Cada redigitação, consulta de preço, pedido de autorização, conferência de crédito e reconstrução de contexto acrescenta trabalho sem necessariamente acrescentar valor ao comprador. Uma arquitetura orientada à negociação reduz essas passagens ao colocar cliente, vendedor e regra sobre a mesma transação, preservando a intervenção humana onde ela realmente decide.

Onde as arquiteturas divergem de verdade

A divergência começa no centro de gravidade. Uma arquitetura documenta a loja a partir de templates, Experience Builder e recursos Lightning, enquanto os registros de vendas organizam contas, oportunidades, territórios e pipeline em uma camada comercial própria. A outra parte do carrinho compartilhado e leva carteira, preço, aprovação e crédito para dentro da negociação.

Também muda o lugar em que o preço ganha significado. Listas de preços e entitlements entram na preparação da loja e podem ser importados junto com contas e produtos pelo fluxo documentado de comércio. Na CWS Platform, o cálculo contextual ocorre quando produto, depósito, perfil e regra fiscal encontram a identidade do comprador.

A assistência comercial segue caminhos distintos. O núcleo de vendas acompanha oportunidades, atividades, previsões e divisão de receita ou crédito na estrutura do processo comercial. Na CWS Platform, a assistência se materializa dentro do carrinho compartilhado, no qual cliente e vendedor modificam a mesma negociação.

O checkout também expressa uma escolha arquitetural. O comércio B2B utiliza checkout customizado, com serviços de terceiros e interface adaptável conforme a documentação da loja. Na CWS Platform, crédito e validações comerciais são tratados como parte nativa da aptidão transacional.

Por fim, a pergunta não é qual ambiente reúne mais recursos, mas qual complexidade precisa ser absorvida. Quando o requisito dominante é estruturar storefront, acesso e objetos corporativos, templates, perfis e permission sets recebem o peso no mecanismo publicado. Quando o requisito dominante é impedir que o portal rompa a negociação B2B, o peso recai sobre carteira, carrinho comum, preço contextual, regra, crédito e pedido governado.

A própria documentação da Salesforce registra dois limites que a operação com força de vendas encontra:

• limitação registrada na documentação do fornecedor, consultada em 09/10/2026: o seletor de contas perde desempenho acima de 200 contas e falha com 2 mil ("At 2 thousand Buy For accounts the Account Switcher fails.", https://developer.salesforce.com/docs/commerce/salesforce-commerce/guide/b2b-b2c-comm-data-model-shopper-buyer-groups-accounts-limits.html).
• limitação registrada na documentação do fornecedor, consultada em 09/10/2026: cada consulta de preço avalia no máximo 25 tabelas de preço, e a loja aceita 5 tabelas atribuídas ("Price books above the 25 limit are not included in the price evaluation.", https://developer.salesforce.com/docs/commerce/salesforce-commerce/guide/b2b-b2c-comm-data-model-price-book-limits.html).

A decisão deve seguir a operação que precisa ser governada. Um portal B2B com força de vendas exige coerência entre incentivo, identidade, preço, aprovação, crédito e pedido. Quando esses elementos permanecem separados, o cliente encontra uma loja, mas a empresa continua negociando por fora dela.

Quando o Salesforce é a escolha certa neste cenário

Há cenários em que o requisito central está na estrutura corporativa, na construção do storefront ou na convivência entre modelos de canal. Neles, a adequação deve ser avaliada pelo mecanismo documentado, não por uma lista genérica de recursos.

O projeto começa pela governança corporativa de vendas. Escolha essa arquitetura quando a prioridade for organizar leads, contas, contatos e oportunidades, com territórios, equipes, previsões de pipeline e divisão de receita ou crédito. O mecanismo documentado concentra esses elementos no núcleo do processo comercial e oferece ao vendedor uma área de trabalho baseada nesses registros e atividades.

A implantação exige um storefront montado no ecossistema Lightning. Escolha essa arquitetura quando o requisito for criar a loja por templates, personalizar páginas no Experience Builder e configurar pesquisa, carrinho, checkout e pagamento com recursos Lightning. Ela também atende projetos que desejam importar contas, produtos, listas de preços e entitlements pelos processos previstos para a loja B2B.

A organização precisa compartilhar processos entre comércio B2B e D2C. Escolha essa arquitetura quando a mesma organização precisar operar canais B2B e D2C sobre dados e processos compartilhados. Esse mecanismo é adequado quando a composição de canais e storefronts dentro do mesmo ambiente corporativo é um critério central da iniciativa de comércio.

O acesso da loja precisa seguir uma estrutura declarativa de permissões. Escolha essa arquitetura quando compradores precisarem ser associados a contas e grupos, com acesso governado por perfis e permission sets. O desenho também contempla autorregistro e navegação como convidado, oferecendo caminhos distintos de entrada conforme a política definida para a loja na documentação.

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