Portal B2B com balcão e vendedor: Adobe Commerce e CWS Platform lado a lado

Comparativo de arquitetura: Adobe Commerce e CWS Platform. Para quem responde por marketing e receita de canal numa operação de distribuição, e está escolhendo a plataforma de um portal B2B que precisa conviver com a loja física e com a equipe de vendas. Todo fato sobre a Adobe Commerce neste texto sai da documentação pública dela.

Um comprador de uma rede de autopeças entra no portal na terça, monta um carrinho de quarenta itens e para. Na quinta, passa no balcão para tirar uma dúvida de aplicação e leva três itens. Na sexta, o vendedor liga, refaz o carrinho com um desconto por volume e fecha.

Uma venda. Três atendimentos.

Agora a pergunta que chega à mesa do marketing: qual campanha gerou aquela venda? Na maioria das operações, a resposta honesta é que ninguém sabe. O portal registrou um carrinho abandonado. A loja registrou um cupom de balcão. O vendedor registrou um pedido novo, digitado à mão, sem nenhum vínculo com o carrinho de terça.

O comprador viveu uma jornada. O sistema guardou três.

73s

O CAC não sobe porque a campanha piorou

A conversa sobre custo de aquisição em B2B costuma virar uma conversa sobre mídia: o leilão encareceu, o criativo cansou, o canal saturou. Às vezes é isso mesmo. Mas em distribuição há uma causa anterior, e ela não é de marketing.

O comprador B2B hoje é um comitê, e boa parte da decisão acontece antes de qualquer contato com vendas. Isso muda o trabalho do marketing: ele deixa de gerar reuniões e passa a alimentar uma pesquisa que já está em curso. Só que essa pesquisa termina em algum lugar, e em distribuição ela termina em três lugares diferentes.

Quando os três não se reconhecem como o mesmo cliente, acontece a coisa mais cara que pode acontecer com um orçamento de marketing: a campanha funciona e não recebe o crédito. O CAC calculado sobe, a verba do canal que de fato converteu é cortada, e o corte reduz a conversão real no trimestre seguinte. É um ciclo que se alimenta de um erro de medição, não de um erro de estratégia.

Diagnosticar isso como problema de atribuição leva à ferramenta errada. Não se resolve com mais uma camada de tracking sobre três sistemas que não compartilham a transação. Resolve-se fazendo com que a transação seja uma só.

Três lugares onde o funil se rompe

Vale nomear os três, porque cada um se rompe por um motivo diferente.

O carrinho que o vendedor não vê. O comprador monta quarenta itens no portal e trava numa condição de pagamento. O vendedor liga por outro motivo, não sabe do carrinho, e refaz tudo do zero. O pedido nasce no sistema do vendedor, sem origem. Do ponto de vista do marketing, o portal gerou um abandono e a venda veio do “canal vendedor”.

O preço que muda de canal. O mesmo item aparece com um preço no portal, outro no balcão e um terceiro na proposta do vendedor. Não é má-fé: é que cada canal lê a condição comercial de um lugar diferente, e as leituras não são simultâneas. O comprador percebe, e a próxima negociação começa com desconfiança. O marketing herda um problema de confiança que nasceu numa questão de arquitetura.

A venda que não volta como dado. A campanha empurra um mix. O canal vende outro. Sem o dado de saída da ponta, a próxima campanha é desenhada sobre a hipótese anterior, não sobre o resultado. É a diferença entre saber quanto se vendeu para o canal e quanto o canal vendeu.

Os três têm a mesma causa: a regra comercial mora fora da transação. Preço, alçada, crédito e disponibilidade são consultados de um sistema de origem em vez de calculados no momento em que a compra acontece. Cada canal consulta no seu tempo, e a divergência é o que o cliente enxerga.

O que a Adobe Commerce resolve, e é bastante

Vale ser específico, porque comparação sem precisão não ajuda ninguém a decidir.

A Adobe Commerce tem um módulo B2B nativo, ativado por extensão sobre a mesma plataforma que atende B2C. A documentação dele descreve uma conta de empresa que agrega vários compradores, com divisões, subdivisões e papéis, controlando pedidos, cotações, crédito e perfil. Catálogos compartilhados definem preços customizados por empresa ou grupo de clientes, em um ou mais sites. Compradores autorizados iniciam cotações pelo carrinho e vendedores pelo Admin, os dois lados alteram itens e quantidades, pedem e aplicam desconto e trocam mensagens até o acordo. Ao ativar pedidos de compra para uma empresa, todo pedido passa a ser criado como PO, sujeito a regras de aprovação por papel.

Isso é um portal B2B sério, e resolve boa parte do primeiro rompimento: a cotação iniciada pelo comprador e continuada pelo vendedor é o mesmo objeto, não dois.

Some a isso um serviço de pagamento integrado que centraliza pagamentos e faturas de todas as vitrines num painel só, com ambientes de sandbox e produção, métodos por região e configuração exposta por API. Some ainda uma camada de personalização com público e segmentação, e uma arquitetura multi-site madura, com escopos de configuração por site.

Quem precisa de um portal B2B robusto, com governança de compra do lado do cliente e um ecossistema grande de integração, está diante de uma escolha legítima.

Onde a arquitetura diverge, e por que isso chega ao marketing

A divergência não está na lista de recursos. Está em quem calcula a condição comercial no momento da venda.

Na Adobe, o preço da empresa vem de um catálogo compartilhado: uma estrutura que associa preços customizados a um grupo de clientes. É um preço atribuído. Funciona bem quando a política cabe em faixas por empresa, e é o modelo da maioria das operações que vendem o mesmo mix para perfis parecidos.

Em distribuição, a condição raramente cabe numa faixa. O preço é o resultado de uma função com várias entradas ao mesmo tempo: quem compra, de qual armazém sai, que volume, que prazo, que composição de carrinho, que regra fiscal se aplica àquela combinação. A CWS Platform trata isso assim de propósito: o Pricing Engine calcula por produto, depósito, perfil de cliente e regra fiscal, com precedência declarada de contrato sobre regra e de regra sobre tabela. O CDL Workspace aplica alçada, crédito e aprovação como regra executada na hora, não como fluxo à parte.

A consequência prática para o marketing é uma só, e é grande: se a condição é calculada no ato, o portal, o balcão e o vendedor consultam a mesma função e chegam ao mesmo número. Não há sincronização para atrasar, e por isso não há três preços para o cliente comparar.

O segundo ponto é o carrinho. A cotação da Adobe é negociada entre comprador e vendedor por troca de mensagens no objeto da cotação. Na CWS, o Sales Hub opera carrinho compartilhado em tempo real: o vendedor entra no carrinho que o comprador está montando, com as alçadas dele aplicadas enquanto mexe. É a diferença entre negociar de forma assíncrona e atender junto. Para quem tem balcão, essa distinção é a que decide se o atendimento presencial entra no mesmo pedido ou vira outro.

O terceiro é a origem. Quando o vendedor atua dentro do carrinho do comprador em vez de criar um pedido novo, a venda mantém a origem digital. O crédito da campanha não se perde no meio do caminho, e o CAC volta a ser calculável sem uma camada de atribuição por cima.

A documentação da própria Adobe registra um ponto que toca a venda com vendedor:

• limitação registrada na documentação do fornecedor em 15/06/2026: o pagamento a prazo pela conta da empresa não é suportado em pedidos com vários endereços de entrega ("not supported for orders with multiple shipping addresses", https://experienceleague.adobe.com/en/docs/commerce-admin/b2b/enable-basic-features).

Onde a Adobe Commerce é a escolha certa

Este é o blog da CWS Platform, então desconte o viés na leitura. E há cenários em que a resposta honesta não é a nossa.

Se a operação é majoritariamente B2C com uma frente B2B, a Adobe entrega as duas na mesma plataforma, e manter duas plataformas para isso é custo sem contrapartida. Se o ecossistema Adobe já está em casa, com Analytics e gestão de ativos rodando, a integração nativa entre eles vale dinheiro real. E se a política comercial é estável, com preço por faixa de cliente e pouca negociação item a item, a granularidade da CWS vira complexidade que ninguém usa.

A CWS Platform faz sentido no cenário oposto: negociação item a item, preço que muda por armazém e por composição, venda assistida junto do autoatendimento, e a loja física como parte do mesmo pedido.

A pergunta que separa as duas na sua operação

Não é “qual plataforma tem mais recursos B2B”. É esta:

Quando o vendedor atende um cliente que já está com o carrinho aberto no portal, ele entra naquele carrinho ou cria um pedido novo?

Faça a pergunta na próxima demonstração e peça para ver acontecendo, não para ouvir a resposta. O que acontecer nos dez minutos seguintes diz mais sobre o seu CAC do trimestre que vem do que qualquer relatório de atribuição.

Perguntas frequentes

Isso não se resolve com um CDP ou uma ferramenta de atribuição? Elas ajudam a enxergar, e enxergar é melhor que não enxergar. Mas atribuição unifica o registro de eventos que aconteceram em sistemas diferentes; ela não faz o vendedor entrar no carrinho do comprador. O rompimento acontece na transação, e é lá que precisa ser costurado.

Nossa loja física é pequena. Isso muda algo? Muda a ordem de prioridade, não o diagnóstico. Se o balcão responde por pouco volume, o rompimento mais caro provavelmente é o do vendedor que refaz o carrinho, não o do atendimento presencial. Vale medir os três antes de decidir qual atacar.

Já usamos Adobe Commerce. Vale a pena a conversa? Depende do que dói. Se o que dói é governança de compra do lado do cliente, a Adobe cobre e trocar seria retrocesso. Se o que dói é preço que muda por armazém, alçada aplicada no ato e vendedor dentro do carrinho, aí a conversa é sobre onde a condição comercial é calculada, e essa é uma diferença de arquitetura, não de configuração.

Por que o post não traz números de mercado? Porque os que temos à mão não carregam fonte e ano no formato que a nossa régua exige para publicação. Preferimos um argumento sem número a um número sem lastro.

Uma publicação da CWS Platform.