Marketplace de concessionárias: Adobe Commerce ou CWS Platform para organizar catálogo, rede e atendimento?

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

Adobe Commerce e CWS Platform colocam o peso arquitetural em pontos diferentes quando uma rede de concessionárias cria um portal oficial de peças. A primeira organiza sites, lojas, visões de loja e recursos transacionais dentro de uma hierarquia de commerce, com possibilidade de separar ou compartilhar catálogo, carrinho, entrega e pagamento conforme o nível configurado, como mostra a documentação de múltiplos sites. A segunda parte da operação comercial distribuída: aplicação técnica, disponibilidade por origem, preferência regional, atendimento assistido e divisão operacional do pedido.

Para o Diretor de Commerce, a decisão central não é quantas caixas cada plataforma preenche. É descobrir qual complexidade precisa ser governada. Uma rede pode querer administrar marcas, idiomas, domínios e estruturas corporativas, ou pode precisar fazer com que a peça correta seja encontrada pelo veículo, encaminhada à casa da região e atendida por diferentes origens sem romper a experiência oficial.

O CFO observa margem, custo de atendimento e responsabilidade por cada pedido. O CTO precisa saber onde vivem catálogo, regra regional, estoque, entrega e estado do pedido. O portal de marketplace de concessionárias só se sustenta quando essas decisões deixam de depender de ligação, planilha e memória individual.

O cenário: o portal oficial que transforma a rede em uma operação coordenada

Imagine uma montadora ou grupo de distribuição reunindo concessionárias de linha leve ou pesada em uma vitrine oficial. O proprietário informa o veículo e espera ver apenas peças aplicáveis. A concessionária responsável pela região deve aparecer na frente, enquanto outras casas e a fábrica funcionam como retaguarda quando a origem preferencial não consegue atender.

Esse desenho não é apenas um marketplace com vários vendedores. Ele digitaliza uma operação que já tem territórios, contratos, estoques, conhecimento técnico e responsabilidades de pós-venda. O marketplace é o resultado visível de uma política comercial que precisa continuar válida mesmo quando o consumidor não telefona para o balcão.

A arquitetura também precisa preservar o contexto quando a jornada muda de canal. O consumidor pode começar sozinho, pedir ajuda a um vendedor, envolver um técnico e continuar no mesmo pedido. O agente de apoio ao vendedor deve trabalhar sobre catálogo, preço, disponibilidade e regras vigentes, não produzir uma resposta desconectada da transação.

As seis decisões que o cenário obriga

A escolha começa pelas decisões operacionais abaixo. Elas funcionam como critérios de arquitetura e de aceite do projeto, não como uma lista genérica de recursos.

1. Como o cliente acha a peça que serve no carro dele. A aplicação precisa ser tratada como dado mestre, ligado à identificação do veículo e às referências do produto. Salvar a garagem do consumidor reduz a repetição durante a jornada, mas o critério decisivo é impedir que uma busca por descrição ou código apresente uma peça incompatível.

2. Qual concessionária atende primeiro. A oferta regional deve refletir a responsabilidade comercial da rede, e não apenas ordenar vendedores pelo valor anunciado. Território, disponibilidade, prazo e condição comercial entram na decisão antes de expor a origem que atenderá o consumidor.

3. De onde vem o que a casa da região não tem. A ruptura local não deveria encerrar a venda. A política da rede precisa indicar quais origens podem assumir o item, em que sequência e sob quais condições, mantendo a experiência no portal oficial em vez de devolver ao cliente o trabalho de procurar fora.

4. Quem atende no chat. O atendimento precisa conservar carrinho, produto consultado, condição oferecida e histórico da conversa. Vendedor, técnico e agente de IA podem cumprir funções diferentes, mas todos devem operar sobre o mesmo contexto comercial e deixar o próximo passo registrado.

5. Como um pedido de várias origens se divide. Quando os itens vêm de origens distintas, o consumidor precisa enxergar uma compra coerente, enquanto cada responsável recebe sua parcela operacional. A arquitetura deve relacionar o pedido principal aos pedidos de cada concessionária ou fábrica e acompanhar faturamento, entrega e status por origem.

6. Quem trata o catálogo de aplicação. Abrir rapidamente uma vitrine com dados brutos pode apenas transferir o problema do balcão para o consumidor. A rede deve decidir quais aplicações, atributos, imagens e equivalências precisam estar governados antes da publicação e qual processo continuará enriquecendo o catálogo depois dela.

O que trava hoje, na voz de quem opera

As frases ouvidas no campo mostram onde a operação quebra e qual decisão arquitetural está escondida em cada reclamação.

“Perco tempo procurando a peça certa; a aplicação nunca está completa.” Essa frase revela a decisão sobre a origem da verdade de aplicação. Se código, nomenclatura e compatibilidade não formarem uma estrutura governada, a busca digital apenas acelera a apresentação da peça errada.

“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.” Aqui aparece a decisão sobre retaguarda de estoque. A rede precisa transformar concessionárias e fábrica em origens comerciais coordenadas, com preferência explícita, em vez de tratar cada ruptura como uma exceção telefônica.

“O cliente liga com a máquina parada na obra, passa o modelo e o número de série, e o balcão ainda precisa descobrir no catálogo qual é a peça e se ela tem em alguma filial.” A decisão revelada é unir identificação técnica e disponibilidade na mesma jornada. Em linha pesada, reduzir a parada do veículo pode pesar mais que uma navegação editorial sofisticada.

O tratamento do catálogo também produz efeito operacional mensurável. Em operação de cliente da CWS, no ciclo 2024 a 2026, o cadastro de um SKU novo passou de 12 minutos para 45 segundos. Em operação de cliente da CWS, no ciclo 2024 a 2026, foram cadastrados 25 mil SKUs em 30 dias.

O que o Adobe Commerce resolve bem neste cenário

A arquitetura organiza uma instância na sequência global, website, store e store view. O website concentra configurações como entrega e pagamento, enquanto stores de um mesmo website podem compartilhar catálogo, administração e checkout, mas selecionar produtos, menus e desenhos diferentes, conforme a documentação da hierarquia de lojas. Isso atende redes que modelam marcas, países, idiomas ou experiências comerciais como destinos digitais administrados dentro da mesma estrutura.

Para compradores empresariais, a conta corporativa agrega usuários, divisões, papéis e permissões. A administração também pode habilitar meios de pagamento, níveis de preço, negociação por cotação, listas de requisição e pedidos de compra sujeitos a regras de aprovação, segundo a documentação do B2B integrado. Esse mecanismo é relevante quando frotistas, oficinas ou grandes contas compram pela rede com responsabilidades formais entre solicitantes e aprovadores.

A camada de merchandising pode ingerir catálogo de plataformas de commerce, PIM ou ERP e organizá-lo em fontes, livros de preço, visões e políticas. As vitrines consultam essa camada por APIs, enquanto carrinho e checkout permanecem no sistema transacional conectado, como descreve a visão geral do conector. O peso fica na separação entre descoberta de produto e registro transacional.

A personalização pode receber eventos de vitrine, histórico de pedidos e dados de perfil, enviando-os à rede de dados para composição de segmentos e jornadas. A documentação de personalização descreve a conexão com dados de ERP, CRM e ponto de venda para adaptar campanhas, comunicações, promoções e conteúdo. No cenário de concessionárias, isso se encaixa quando a prioridade é coordenar conteúdo e relacionamento entre canais a partir de perfis unificados.

Como a CWS Platform monta: catálogo técnico, preferência regional e execução distribuída no mesmo fluxo

A montagem começa pela Marketplace Management Platform (Marketplace Center), que representa concessionárias e fábrica como participantes da operação, mantém a relação entre pedido principal e pedidos filhos e permite que cada origem atualize sua parte. A Product Catalog & MDM (Catalog Engine) governa produtos, SKUs, composições, heranças e importações incrementais. A Distributed Inventory (Inventory Hub) acrescenta disponibilidade por depósito, estoque reservado para oferta futura e prazo por SKU.

Para o Diretor de Commerce, o catálogo de aplicação não é uma etapa cosmética. Marca, modelo, ano, versão, motorização e referências precisam formar relações verificáveis antes de orientar a vitrine. O agente de enriquecimento de catálogo ajuda a transformar dados brutos, imagens e atributos em conteúdo estruturado, enquanto a governança determina o que pode ser publicado e o que precisa de revisão.

Essa estrutura permite tratar cada armazém como um contexto operacional da rede. Região atendida, catálogo exposto, estoque, condição comercial e logística podem participar da política central. A Contextual Pricing (Pricing Engine) calcula a condição aplicável ao contexto, em vez de assumir que preço é um valor isolado e idêntico para qualquer origem.

Quando a casa regional possui o item, ela recebe a preferência definida pela operação. Quando não pode atender, outras origens elegíveis entram na sequência estabelecida. A Shipping & Fulfillment (Logistics Engine) calcula alternativas por origem e suporta carrinho dividido e entrega fracionada, enquanto o portal conserva uma jornada única para o consumidor.

A Assisted Selling Platform (Sales Hub) mantém vendedor e comprador no mesmo carrinho, registra o atendimento e oferece chat dentro da operação comercial. O agente de apoio ao vendedor usa o contexto disponível para apoiar perguntas e próximos passos. Assim, a intervenção humana não exige reconstruir em outro canal a aplicação consultada, os itens escolhidos e a condição em negociação.

Depois da confirmação, o Order Management System (OMS / Seller Center) registra o pedido como referência operacional entre plataforma, concessionária e ERP. Os pedidos filhos permanecem ligados ao pedido principal, e cada origem atualiza documentos fiscais, rastreio e status conforme sua responsabilidade. A transição pode ser condicionada por regra, evitando que um item avance sem os dados exigidos para aquela etapa.

O Credit-First B2B Checkout (Checkout & Payments) incorpora crédito ao fluxo B2B e valida estoque, preço, crédito e tributos na mesma transação. Se a condição comercial for rejeitada pelas regras vigentes, o pedido nem chega a ser criado. Isso interessa quando o mesmo portal atende consumidores, oficinas, frotistas e compradores empresariais com formas distintas de pagamento e autorização.

A CWS Platform tem 11 módulos, 6 AI Agents e 1.029 parâmetros configuráveis. No cenário da rede, essa configuração serve para expressar quem pode vender, qual origem tem preferência, que condição pode ser aplicada e como o pedido segue até faturamento e entrega. A arquitetura coloca o peso na continuidade entre descoberta técnica, decisão comercial e execução.

A régua adequada é o custo de transação da cadeia. Encontrar a aplicação, consultar várias origens, chamar alguém para ajudar, dividir a execução e acompanhar cada entrega são atividades que consomem trabalho mesmo quando o pedido é digital. O portal oficial cria valor quando reduz essas passagens sem retirar da rede o controle sobre território, preço, disponibilidade e responsabilidade.

Onde as arquiteturas divergem de verdade

Uma arquitetura expressa a separação comercial principalmente em websites, stores e store views, definindo nesse desenho o que compartilha catálogo, carrinho, entrega e pagamento, segundo a estrutura de múltiplos sites. A outra usa participantes, armazéns, regras regionais e origens de atendimento para organizar a operação distribuída.

Na descoberta, uma arquitetura pode desacoplar merchandising do sistema de registro e publicar visões de catálogo consultadas pela vitrine, mantendo carrinho e checkout em outro sistema conectado, conforme a arquitetura do conector. A outra trata catálogo técnico, disponibilidade e política de origem como partes contínuas da decisão comercial.

No atendimento empresarial, uma arquitetura coloca o peso na estrutura da conta compradora, em seus usuários, papéis, cotações e pedidos de compra, como detalha a solução B2B integrada. A outra concentra o contexto em carrinho compartilhado, regra comercial, estoque por origem e execução do pedido entre participantes da rede.

A documentação da própria Adobe registra dois limites da versão SaaS:

• limitação registrada na documentação do fornecedor em 08/10/2026: o Adobe Commerce as a Cloud Service não suporta lojas Luma ("does not support Luma storefronts", https://experienceleague.adobe.com/en/docs/commerce/cloud-service/overview).
• limitação registrada na documentação do fornecedor em 24/09/2026: o serviço de migração de dados só cobre os dados nativos do Commerce, sem entidades customizadas ou de terceiros ("supports first-party core commerce data only", https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview).

A tabela não determina um vencedor abstrato. Ela mostra onde cada desenho pede que a empresa modele sua complexidade. A escolha deve seguir a unidade real de governança: destino digital e estrutura corporativa, ou rede física, origem de estoque, aplicação técnica e responsabilidade operacional.

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

Há situações em que o requisito central da rede aponta claramente para essa arquitetura. Nesses casos, a adequação vem do modo como ela estrutura o problema, não de uma comparação genérica de inventário.

A rede precisa administrar marcas, países e idiomas como destinos digitais distintos. Escolha essa arquitetura quando websites, lojas e visões de loja forem a unidade principal de organização, com necessidade de compartilhar ou separar catálogo, carrinho, entrega e pagamento por escopo. O mecanismo documentado define uma hierarquia própria para essa administração e para a publicação de cada destino, conforme a documentação de websites e lojas.

Frotistas e grandes contas exigem uma estrutura formal de compradores. Escolha essa arquitetura quando a compra precisar refletir empresas com divisões, usuários, papéis, permissões, cotações e pedidos de compra sujeitos a regras de aprovação. A conta corporativa e seus controles são partes declaradas da solução B2B integrada.

O projeto separa merchandising do sistema transacional. Escolha essa arquitetura quando o requisito for ingerir dados de PIM, ERP ou plataforma de commerce, normalizá-los em fontes e visões de catálogo e oferecê-los por APIs à vitrine, mantendo carrinho e checkout no sistema conectado. Esse desenho está descrito na visão geral da camada de merchandising.

A prioridade é personalizar conteúdo e jornadas com dados de vários canais. Escolha essa arquitetura quando eventos da vitrine, histórico de pedidos, perfil, CRM, ERP e ponto de venda precisarem alimentar segmentos, campanhas e comunicações omnicanal. O fluxo de dados e sua conexão com serviços de perfil e jornada aparecem na documentação de personalizaçã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, a página Quando o Catálogo Vira Caos trata disso em profundidade, sem falar de fornecedor nenhum.