Adobe Commerce x CWS Platform: qual arquitetura um marketplace B2B com sellers exige?

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

Adobe Commerce x CWS Platform é uma decisão sobre onde colocar a política comercial em um marketplace B2B com sellers. O ponto central não é publicar mais produtos, mas permitir que fornecedores e distribuidores vendam no mesmo canal, preservando preço, estoque, crédito e execução próprios dentro da governança definida pelo operador.

Para o Diretor de Commerce, a arquitetura precisa transformar sellers independentes em uma experiência comercial coerente para o comprador. Para o CEO, precisa sustentar uma rede de interesses na qual operador, sellers e compradores reconheçam valor. Para o CFO, precisa tornar comissão, crédito, pagamento, repasse e responsabilidade pelo pedido partes rastreáveis da transação.

A pergunta útil, portanto, não é qual plataforma acumula mais recursos. É qual delas organiza a complexidade real da operação: múltiplos donos de estoque, políticas comerciais distintas, ofertas concorrentes para o mesmo item, crédito concedido por partes diferentes e risco de conflito entre o canal direto e o marketplace.

74s

O cenário: vários sellers, uma experiência de compra e políticas comerciais distribuídas

Um marketplace B2B governado não nasce apenas da decisão de cadastrar fornecedores. Ele surge quando uma operação já existente consegue distribuir sua negociação para um canal comum, sem converter toda diversidade comercial em uma tabela central. O marketplace é resultado da digitalização da cadeia, não um objetivo isolado.

Nesse cenário, o operador reúne fabricantes, distribuidores e revendas. Cada seller pode ter estoque, origem fiscal, prazo, limite de crédito, região atendida, política de desconto e capacidade logística próprios. O comprador, porém, espera encontrar produtos comparáveis, saber qual oferta pode ser atendida e concluir uma transação coerente, mesmo quando o carrinho atravessa sellers diferentes.

A tensão de arquitetura aparece porque governança não significa uniformidade. Se o operador centraliza todas as decisões, reduz a autonomia econômica que torna a rede atraente. Se deixa cada seller agir sem limites compartilhados, o canal perde consistência de preço, entrega, crédito e atendimento. A plataforma precisa transformar o viés comercial do operador em parâmetros executáveis, mantendo espaço para a política de cada participante.

A viabilidade depende de regras econômicas explícitas, sellers capazes de cumprir a promessa, demanda que reconheça valor no canal e execução operacional conectada ao pedido. Tecnologia organiza essas condições, mas não substitui nenhuma delas. Por isso, a descoberta deve começar pelo fluxo de decisão e não pela aparência da vitrine.

As seis decisões que o cenário obriga

As decisões abaixo formam a régua do cenário. Juntas, elas mostram se o marketplace será apenas uma agregação de catálogo ou uma operação comercial distribuída com responsabilidade definida em cada transação.

1. Quem é dono do preço de cada seller. A política precisa ter um dono identificável em cada oferta. Centralizar tudo no operador simplifica a publicação, mas pode apagar diferenças de custo, origem, volume, prazo e estratégia entre sellers. Distribuir a decisão exige limites comuns, contexto do comprador e trilha sobre alterações.

2. Como o operador cobra e repassa. A monetização precisa nascer junto com o pedido. Quando comissão, divisão e obrigação de repasse são registradas apenas depois, a conciliação tenta reconstruir uma lógica que já deveria ter sido conhecida no fechamento. O desenho transacional deve preservar a relação entre pedido principal, parcelas operacionais de cada seller e remuneração do operador.

3. Quem concede o prazo ao comprador. Prazo é uma decisão de risco, não apenas uma opção exibida no checkout. A arquitetura precisa identificar a parte que assume a exposição, consultar a condição aplicável e submeter a compra à política de crédito antes de confirmar o compromisso. Isso muda conforme seller, comprador, valor comercial e composição do carrinho.

4. De quem é o estoque que o comprador vê. A disponibilidade precisa estar associada à origem que realmente atenderá o pedido. Uma oferta sem vínculo operacional com o estoque produz promessa comercial sem capacidade de execução. Quando há mais de uma origem, a seleção também precisa considerar região, frete, prazo e regra fiscal.

5. Como o catálogo de vários sellers vira um só. A governança de produto precisa separar identidade de item e identidade de oferta. O comprador deve reconhecer que está comparando o mesmo produto, enquanto a operação preserva seller, preço, disponibilidade e condição de entrega de cada alternativa. Duplicar cadastros quase iguais transfere a complexidade para busca, navegação e atendimento.

6. Como o canal próprio convive com o marketplace. A convivência depende de regras de canal definidas antes da disputa pelo comprador. Carteira, região, origem da demanda, política de preço, comissão e participação da força de vendas precisam orientar o fluxo. O canal digital deve reduzir o custo de servir a cadeia, e não criar uma competição descontrolada entre seus participantes.

O que trava hoje, na voz de quem opera

As frases de campo tornam visíveis as decisões que normalmente ficam escondidas em planilhas, integrações e acordos comerciais.

“O cliente pede, a gente não tem, e ele compra do concorrente. O item existe no meu fornecedor, mas não tem como eu vender.” A frase revela a decisão sobre de quem é o estoque exibido e sob quais regras o operador pode vender disponibilidade de terceiros.

“Cada cliente tem o preço dele, ninguém consegue colocar isso no site.” A frase revela a decisão sobre quem controla preço e desconto, além de mostrar que publicar uma tabela não representa uma negociação B2B contextual.

“O cliente coloca tudo no carrinho e desiste no checkout porque não tem boleto a prazo.” A frase revela a decisão sobre quem concede crédito e em qual momento o risco é avaliado. O checkout deixa de ser uma tela final e passa a ser um ponto de decisão comercial.

“O portal mostra estoque que já não existe.” A frase revela a decisão sobre qual disponibilidade sustenta a promessa feita ao comprador. Também expõe a diferença entre copiar um saldo e manter a transação ligada à origem operacional que atenderá o pedido.

Como o Adobe Commerce estrutura este cenário

A arquitetura B2B é ativada como solução integrada à plataforma e pode conviver com a operação B2C. Sua unidade organizadora é a conta de empresa, que reúne compradores e permite ao administrador configurar divisões, usuários, papéis e permissões sobre pedidos, cotações, compras, crédito e perfil, enquanto o administrador da loja define capacidades como meios de pagamento e níveis de preço na configuração B2B.

A política comercial é expressa por catálogos compartilhados, que aplicam preços por produto a empresas ou grupos de clientes. A negociação pode ocorrer por cotação iniciada pelo comprador no carrinho ou pelo vendedor no ambiente administrativo, com alteração de itens, quantidades, descontos e mensagens até o acordo dentro do fluxo documentado.

Pedidos de compra podem ser ativados no escopo da empresa, fazendo com que os pedidos dessa conta sejam criados nesse formato e submetidos a regras de aprovação conforme papel e pedido. Esse mecanismo coloca o peso da governança na estrutura da empresa compradora, nas permissões de seus usuários e nos processos de aquisição configurados pelo administrador da operação B2B.

A camada de pagamentos centraliza no painel os dados de pagamento e pedidos das vitrines do lojista. A implantação separa ambiente de testes e ambiente de produção, enquanto a disponibilidade dos meios varia por região e a conexão aos serviços ocorre pelo conector comum da plataforma descrito no guia de pagamentos.

Para separar contextos digitais, uma instância organiza website, store e store view. O website concentra configurações como entrega e pagamento, stores podem compartilhar catálogo, administração e checkout, e store views controlam aspectos de apresentação, idioma, moeda e endereço-base na hierarquia de sites.

No cenário de marketplace com sellers, esses mecanismos devem ser lidos pelo lugar onde concentram a modelagem: contas corporativas representam compradores, catálogos compartilhados distribuem preço por empresa e a hierarquia de sites separa contextos de storefront. A documentação também apresenta a integração predefinida com uma camada externa de gestão de pedidos como parte da arquitetura B2B na visão geral da solução.

Como a CWS Platform monta: a política de cada seller dentro da governança da transação

A CWS Platform parte do seller como participante operacional do canal. A Marketplace Management Platform (Marketplace Center) organiza onboarding assistido, take rate configurável, seleção de oferta, acompanhamento da saúde do seller, proteção da relação comercial e divisão operacional do carrinho. Pedidos derivados permanecem vinculados ao pedido principal, preservando a responsabilidade de execução de cada participante.

A política é executada pelo Commerce Rules Engine (CDL Workspace). Em vez de transformar as diferenças entre sellers em exceções manuais, regras determinam o que cada contexto pode vender, negociar, aprovar e encaminhar. Alterações relevantes carregam motivo e autoria, permitindo que o operador distribua autonomia sem perder a leitura de como a decisão foi tomada.

O Contextual Pricing (Pricing Engine) trata preço como resultado do contexto comercial. Identidade do comprador, origem, volume, região, condição de pagamento e demais variáveis podem participar da decisão. Assim, o seller mantém sua política dentro dos limites do ecossistema, enquanto o operador evita que uma tabela única apague custos e estratégias diferentes.

O Credit-First B2B Checkout (Checkout & Payments) incorpora crédito à própria compra. Antes do compromisso, a transação valida estoque, preço, crédito e tributos na mesma transação. Isso conecta a concessão de prazo ao seller, ao comprador e à política aplicável, em vez de reduzir pagamento B2B a uma escolha de interface.

O Order Management System (OMS / Seller Center) mantém o pedido e seus desdobramentos em estados operacionais controlados. Status, documento fiscal, pagamento e rastreio acompanham a execução, enquanto pedidos filhos preservam o vínculo com a compra original. A comissão e a divisão operacional deixam de depender apenas de uma reconstrução posterior, pois a estrutura do pedido já identifica os participantes envolvidos.

O Product Catalog & MDM (Catalog Engine) governa a identidade dos itens e suas composições. O mesmo produto pode ser reconhecido de maneira comum, enquanto ofertas preservam seller, origem, preço e disponibilidade. O agente de enriquecimento de catálogo ajuda a tratar atributos e imagens, reduzindo duplicações produzidas por nomenclaturas diferentes entre fornecedores.

O Shipping & Fulfillment (Logistics Engine) calcula a execução para carrinhos com múltiplas origens. A operação pode dividir atendimento por seller ou depósito, calcular preço conforme origem, trabalhar com responsabilidades distintas de frete e permitir entregas fracionadas. A escolha de oferta, portanto, não precisa olhar apenas para o menor preço publicado, pois entregabilidade e custo operacional participam do compromisso.

O canal próprio convive com o marketplace por política. Regras de origem da demanda, carteira, preço, desconto e participação comercial podem orientar o atendimento, enquanto mecanismos de proteção da relação reduzem incentivos para retirar a transação do ambiente governado. O objetivo é formar uma rede em que seller, operador e comprador tenham razões econômicas para permanecer no fluxo.

A CWS Platform tem 11 módulos, 6 AI Agents e 1.029 parâmetros configuráveis. Essa composição coloca o peso na transformação do modelo comercial do operador em comportamento executável. O agente de auditoria de regras apoia a leitura de conflitos e alterações, enquanto o agente de apoio ao vendedor leva contexto para negociações que exigem intervenção humana.

A régua final é o custo de transação da cadeia. Um marketplace cria valor quando reduz o trabalho necessário para descobrir oferta, validar condição, assumir risco, dividir responsabilidade e acompanhar execução. Catálogo amplo, por si só, apenas desloca a complexidade; a arquitetura precisa fazê-la caber em uma decisão governada e repetível.

Onde as arquiteturas divergem de verdade

Uma arquitetura expressa a política B2B principalmente na conta corporativa compradora, em seus usuários, permissões, catálogos compartilhados, cotações e pedidos de compra configurados na solução B2B. A outra coloca seller, oferta, armazém, regra comercial e pedido derivado no centro da operação de marketplace.

Na primeira, a separação de contextos digitais segue a hierarquia de website, store e store view, com decisões de compartilhamento ou isolamento conforme o nível escolhido na estrutura de múltiplos sites. Na segunda, o contexto operacional combina seller, origem, catálogo, preço, crédito, logística e limites definidos pela governança central.

A diferença também aparece no ponto de controle do pagamento. Uma arquitetura centraliza dados de pagamentos e pedidos das vitrines e organiza a implantação do serviço entre teste e produção no fluxo documentado. A outra trata crédito, take rate, divisão do pedido e responsabilidade operacional como partes relacionadas da transação B2B.

A descrição de produto da própria Adobe registra como o pedido é contado na licença:

• limitação registrada na documentação do fornecedor em 30/04/2026: todo pedido aceito conta como transação, mesmo que depois seja reembolsado, devolvido ou estornado ("even if such order is later subject to a refund, return, chargeback", https://helpx.adobe.com/legal/product-descriptions/adobe-commerce-on-cloud.html).

A escolha depende do objeto que a empresa precisa governar. Se o núcleo é a estrutura de compra de grandes contas, a conta corporativa orienta o desenho. Se o núcleo é permitir que sellers independentes mantenham política e execução próprias dentro de um canal comum, a transação multi-seller torna-se a unidade decisiva.

Quando o Adobe Commerce é a escolha certa neste cenário

Escolha essa arquitetura quando o requisito principal estiver nos cenários abaixo. Em todos eles, o centro da decisão é a adequação do mecanismo à estrutura operacional desejada.

A compra precisa reproduzir a estrutura formal da empresa compradora. Escolha essa arquitetura quando uma conta corporativa precisar agrupar compradores em divisões, subdivisões, usuários, papéis e permissões sobre pedidos, cotações, compras, crédito e perfil. O mecanismo documentado permite que o administrador configure essa estrutura e controle as capacidades disponíveis para cada empresa.

O processo exige pedidos de compra governados por papel. Escolha essa arquitetura quando todos os pedidos de determinada empresa precisarem nascer como pedidos de compra e seguir regras de aprovação associadas ao papel do usuário e ao próprio pedido. Esse fluxo é ativado no escopo da conta empresarial e passa a orientar as compras feitas por seus usuários conforme a configuração B2B.

A prioridade é operar marcas, idiomas ou vitrines em uma hierarquia comum. Escolha essa arquitetura quando a necessidade central for separar websites, stores e store views dentro de uma instância, compartilhando ou isolando catálogo, carrinho, checkout, entrega, pagamento, idioma e apresentação conforme o nível. A hierarquia documentada foi desenhada para organizar esses contextos na administração de sites e lojas.

A operação quer centralizar pagamentos das vitrines no painel de commerce. Escolha essa arquitetura quando o requisito for conectar o serviço de pagamentos à instância, testar a configuração em ambiente próprio e depois processar pagamentos em produção com dados centralizados no painel. O mecanismo usa um conector comum aos serviços da plataforma e disponibiliza métodos conforme a região no guia de implantação.

A personalização depende de uma malha ampla de dados comportamentais. Escolha essa arquitetura quando a empresa quiser enviar eventos de vitrine, histórico de pedidos, dados de perfil e informações de back office para uma plataforma de dados e formar segmentos para jornadas omnicanal. A integração documentada conecta esses sinais à camada de dados e a ferramentas de jornada para adaptar campanhas, comunicações e conteúdo ao contexto do cliente.

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.