Portal de autoatendimento B2B com várias filiais: Optimizely ou CWS Platform?
Faturamento que mora no ERP, paginação da Admin API e o crédito da conta mantido na plataforma, pela lente de quem responde pela operação.
Nota editorial: comparativo de arquitetura entre Optimizely Configured Commerce e a CWS Platform no cenário de portal B2B de autoatendimento para clientes com várias filiais, escrito para quem decide como COO ou Diretor de Operações. Todo fato sobre Optimizely Configured Commerce vem da documentação pública dele, com o endereço ao lado.
O cliente com várias filiais é o que mais testa um portal de autoatendimento. A matriz negocia, cada filial compra, as entregas saem para endereços diferentes, e o financeiro do cliente quer ver numa tela só o que foi pedido, faturado, entregue e o que está em aberto. Quando o portal não mostra isso de forma confiável, a filial liga para o atendimento, o atendimento abre o ERP, e o custo de servir aquela conta volta a subir.
Para quem responde pela operação, o portal de autoatendimento só funciona quando três coisas andam juntas: o pedido da filial, a situação financeira da conta e o volume de dados que a operação precisa consultar e conciliar todos os dias. Se uma dessas três depende de outro sistema ou de um processo manual, o autoatendimento vira atendimento com uma tela a mais.
Este comparativo olha para Optimizely Configured Commerce e CWS Platform só por esse cenário: onde mora a informação financeira que o cliente consulta e como a operação puxa o volume de dados do portal. A regra comercial do mesmo fornecedor foi tratada em Optimizely Configured Commerce ou CWS Platform: dá para mudar a regra comercial sem abrir chamado?, e os modelos de plataforma em os três modelos de plataforma de comércio B2B.
O que o Optimizely Configured Commerce resolve bem
O Optimizely Configured Commerce entrega ao comprador uma área de conta organizada. No CMS Spire, o histórico de faturas permite configurar quais colunas aparecem: número da fatura, data, condição de pagamento, vencimento, endereço de entrega ou retirada, número do pedido de compra, status, total e saldo em aberto. Pelos detalhes da fatura, o usuário gera um PDF ou dispara o envio por e-mail.
Para clientes com várias unidades, as listas compartilhadas podem ser atribuídas por regra dinâmica sobre campos do cliente de cobrança, com inclusão ou exclusão manual de clientes específicos e datas de início e fim. A Price Matrix organiza o preço do mais específico ao mais geral, critério que vale também para depósito, moeda e unidade de medida.
Para a TI da operação, a Admin API é REST, com paginação OData e endpoint PATCH para todas as entidades. Para uma rede de clientes com filiais que compram de forma recorrente, esse conjunto dá ao comprador uma visão de conta e à operação um caminho de integração documentado.
Onde a arquitetura diverge
A divergência que interessa a quem responde pela operação está em onde a informação financeira nasce e em como o volume sai do portal. A documentação do próprio fornecedor registra dois pontos:
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: o Configured Commerce não gerencia faturamento e só exibe o que o ERP do cliente grava no banco ("Configured Commerce does not manage invoicing and displays only what the customer's ERP system provides to the database.", https://docs.optimizely.com/configured-commerce/docs/order-and-invoice-history-in-spire-cms).
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: a Admin API devolve no máximo 100 resultados por requisição ("Configured Commerce returns a maximum of 100 results in a Admin API request", https://docs.optimizely.com/configured-commerce/api/BhcQ-configured-commerce-admin-api-architecture).
No autoatendimento com várias filiais, o primeiro ponto define a qualidade do que o cliente vê. A tela de faturas é tão atual e tão completa quanto a rotina que leva os dados do ERP para o banco do portal. Se essa rotina atrasa ou falha, a filial vê um saldo que não bate com a cobrança, e a ligação para o atendimento volta. A mesma documentação registra que as faturas ficam disponíveis pela área da conta no site, enquanto o Admin Console dá acesso ao histórico de pedidos.
O segundo ponto é de volume. Com no máximo 100 resultados por requisição, a conciliação de uma rede com muitas filiais e muitos pedidos por dia passa por paginação: a integração precisa seguir as páginas seguintes até o fim, tratar falhas no meio e repetir o processo a cada ciclo. Não é bloqueio, é desenho de integração que precisa de dono, teste e monitoração.
Na CWS Platform, o limite de crédito do cliente é mantido na plataforma, como conta corrente, concedido no CDL Workspace ou por API. O desenho é API-first, com APIs REST e webhooks, e o imposto vem do ERP ou do motor fiscal que o cliente já usa.
| decisão | Optimizely Configured Commerce, pelo mecanismo documentado | CWS Platform |
|---|---|---|
| De onde vem a informação financeira que a filial consulta | Faturamento não gerenciado pela plataforma; exibe o que o ERP grava no banco | Limite de crédito mantido na plataforma, concedido no CDL Workspace ou por API; imposto vem do ERP ou do motor fiscal |
| Como a operação puxa volume do portal | Admin API com no máximo 100 resultados por requisição, com paginação OData | APIs REST e webhooks |
| Como o pedido da filial é entregue | Não coberto pelas fontes desta comparação; pergunta a fazer na avaliação | Venda a prazo com entrega fracionada, agendada, em vários endereços e a partir de várias origens |
A decisão operacional é saber, para cada informação da tela do cliente, qual sistema é dono dela e com que frequência ela chega.
O que muda na operação de autoatendimento com várias filiais
A diferença aparece no volume de contatos que o autoatendimento deveria ter eliminado. Cada vez que a filial não confia no saldo, no vencimento ou no status da entrega que vê no portal, ela liga. Cada vez que a conciliação diária precisa de várias chamadas paginadas para fechar, a equipe de integração ganha um processo para vigiar.
Para o COO, isso vira custo de servir por conta. O portal com várias filiais concentra os casos mais caros: pedido dividido entre unidades, entrega em endereços diferentes, crédito compartilhado entre filiais e cobrança consolidada na matriz. Se cada um desses casos depende de um sistema diferente, o atendimento vira o ponto de integração humano.
Quatro perguntas ajudam a levar esse ponto para qualquer avaliação:
- Com que frequência o dado financeiro do ERP chega ao portal, e o que o cliente vê quando ele atrasa.
- Quantos pedidos e quantas linhas a operação precisa conciliar por dia, e quantas chamadas de API isso representa.
- Onde fica o limite de crédito da conta e quem altera esse limite.
- Como um pedido da matriz é dividido em entregas para as filiais.
Na CWS Platform, o mesmo pedido aceita mais de um meio de pagamento, e o pedido registra quem montou o carrinho e quem escolheu o pagamento. Cliente e vendedor usam a mesma interface, e um vendedor atende milhares de clientes.
Quando escolher o Optimizely Configured Commerce
O Optimizely Configured Commerce atende bem a cenários com estas características:
ERP como fonte única do financeiro, com rotina estável. Escolha essa arquitetura quando o ERP já grava faturas e saldos com frequência e qualidade conhecidas, e o portal só precisa exibir esses dados no histórico de faturas.
Mix por grupo de filiais bem definido. Escolha essa arquitetura quando os grupos de clientes são estáveis e as listas compartilhadas por regra dinâmica cobrem a variação entre unidades.
Equipe de integração para tratar paginação. Escolha essa arquitetura quando a TI já opera integrações por Admin API com paginação e monitoração, e o volume diário cabe nesse desenho.
Quando a CWS Platform é a escolha certa neste cenário
A CWS Platform é a escolha indicada quando o autoatendimento das filiais depende de crédito, pagamento e entrega governados no mesmo lugar do pedido.
Crédito da conta na plataforma. Escolha essa arquitetura quando as filiais compram a prazo contra um limite. O limite de crédito do cliente é mantido na plataforma, como conta corrente, concedido no CDL Workspace ou por API.
Pagamento e autoria registrados no pedido. Escolha essa arquitetura quando matriz e filiais dividem a compra. O mesmo pedido aceita mais de um meio de pagamento, com regras combinadas no CDL Workspace e mantidas por API, e o pedido registra quem montou o carrinho e quem escolheu o pagamento.
Entrega do tamanho da rede. Escolha essa arquitetura quando um pedido atende várias unidades. A venda a prazo funciona com entrega fracionada, agendada, em vários endereços e a partir de várias origens.
Integração por API e eventos. Escolha essa arquitetura quando a operação quer integrar o portal ao ERP e ao CRM sem carregar a política comercial no código. A plataforma é API-first e headless, com APIs REST e webhooks, e tabelas de preço, regras e contratos podem vir do ERP ou do CRM por API.
Por onde continuar
Se a sua pergunta ainda é qual arquitetura serve à sua operação, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B, e a comparação entre modelos está em os três modelos de plataforma de comércio B2B.
Se a decisão depende de mapear onde mora cada informação que a filial consulta, vale conversar com um especialista da CWS Platform para desenhar crédito, pagamento e entrega das suas contas com várias unidades antes de escolher. A página Quando a Integração Trava Tudo trata da dor por trás deste cenário em profundidade, sem falar de fornecedor nenhum.
Leia também
"Estavamos á quase 2 anos tentando implantar uma solução B2B, com a CWS, implantamos em 60 dias."
Quer ver isso na sua operação?
Operações B2B reais já rodam nisso.