Spryker ou CWS Platform: como fica a operação de aprovação de pedidos?
O custo de um fluxo de aprovação aparece nas bordas: unidade sem aprovador, pedido acima de todos os limites e acesso de quem opera.
Nota editorial: comparativo entre Spryker e a CWS Platform escrito para quem responde pela operação, como COO ou diretor de operações. Todo fato sobre Spryker vem da documentação pública dele, com o endereço ao lado.
Na operação de um distribuidor, o pedido que mais custa não é o que dá erro. É o que fica parado esperando alguém. O carrinho está montado, o cliente quer fechar, e a aprovação não anda porque o aprovador certo está em outra filial, porque o valor passou de todos os limites cadastrados, ou porque quem precisa liberar está fora da rede da empresa.
Para o COO, aprovação de pedido não é um recurso de tela. É um fluxo que precisa de dono, de caminho alternativo e de acesso para quem opera. Cada pedido travado vira ligação para o vendedor, retrabalho do atendimento e venda que escorre para outro canal.
Este comparativo olha para Spryker e CWS Platform só por esse ângulo: quem aprova, o que acontece quando a regra não cobre o caso e onde a equipe de operação trabalha. Não é um ranking de funcionalidades. A moldura geral das arquiteturas está no post sobre os três modelos de plataforma de comércio B2B.
O que o Spryker resolve bem
O Spryker traz uma estrutura detalhada para a empresa compradora. O Company Account organiza a empresa em unidades de negócio e usuários, com papéis e permissões configuráveis, e o mecanismo de Business on Behalf permite que um mesmo usuário atue em diferentes unidades com papéis distintos. A hierarquia de unidades é organizada em níveis, como descreve a visão geral de business units.
Sobre essa estrutura funciona o Approval Process. O checkout é restringido quando o total do carrinho atinge o limite da permissão "Buy up to grand total". O comprador com a permissão "Send cart for approval" escolhe um aprovador, o carrinho é bloqueado contra edição e ganha o status "Waiting". O aprovador avalia dentro do limite da sua permissão "Approve up to grand total"; se aprova, o carrinho volta ao comprador para finalizar, e se recusa, o carrinho é desbloqueado e pode ser reenviado.
Para uma empresa compradora que precisa de controle de gasto por papel e por unidade, esse desenho é claro: cada limite tem dono e cada estado do carrinho tem nome.
Onde a arquitetura diverge
A divergência que interessa ao COO está nos casos que o fluxo não cobre. Pelo mecanismo documentado, a relação de aprovação é confinada à mesma unidade de negócio: se a unidade do usuário não tiver aprovadores, o checkout é impedido, mesmo que existam aprovadores em outras unidades ou na unidade-pai direta. Pela instalação do recurso, só o proprietário do carrinho pode enviar a solicitação.
A documentação do próprio fornecedor registra dois pontos que entram no desenho da operação:
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: aprovadores só podem aprovar pedidos de funcionários da sua própria unidade de negócio; quando o total da cotação supera a permissão de todos os aprovadores da empresa, ela não pode ser processada e a saída indicada é editar a cotação ("Approvers can only approve orders of employees within their own business unit.", "Quote D can’t be processed because the quote total is higher than any Approver permissions set for that company. In such case, the only workaround is to edit the quote", https://docs.spryker.com/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/approval-process-feature-overview.html).
- limitação registrada na documentação do fornecedor em 18/09/2026: a aplicação de Back Office deve ficar protegida numa intranet com VPN, Basic Auth, allowlist de IP ou DMZ ("Back Office application must be secured in an Intranet using VPN, Basic Auth, IP allowlist, or DMZ.", https://docs.spryker.com/docs/dg/dev/system-requirements/latest/system-requirements.html).
O primeiro ponto define dois trabalhos fixos para a operação: garantir que toda unidade de negócio do comprador tenha um aprovador, e combinar o que fazer com o pedido grande que passa de todos os limites. Na distribuição, o pedido grande é justamente o que o vendedor mais quer fechar, e editar a cotação para caber no limite é negociação refeita.
O segundo ponto pesa no dia a dia de quem opera. Pelo mecanismo do Order Management System, eventos do pedido podem ser disparados manualmente no Back Office. Se o Back Office vive dentro de um perímetro protegido, o desenho de acesso da equipe de operação, de quem trabalha no escritório a quem trabalha em campo, entra no projeto de implantação.
Na CWS Platform, a política comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace). O desconto do vendedor passa por alçadas com aprovação em níveis, e o limite de crédito do cliente é mantido na plataforma, concedido no CDL Workspace ou por API. O CDL Workspace é um só sistema para todo o ecossistema, e cliente e vendedor usam a mesma interface, no mesmo pedido.
| decisão | Spryker, pelo mecanismo documentado | CWS Platform |
|---|---|---|
| Que aprovação a documentação descreve | Permissões de papel na empresa compradora ("Buy up to grand total", "Approve up to grand total"), com aprovador da mesma unidade de negócio | Desconto do vendedor com alçadas e aprovação em níveis |
| Quem envia o carrinho para aprovação | Só o proprietário do carrinho envia a solicitação de aprovação | Cliente e vendedor no mesmo pedido; o pedido registra quem montou o carrinho e quem escolheu o pagamento |
| Onde a operação trabalha | Back Office protegido numa intranet com VPN, Basic Auth, allowlist de IP ou DMZ | CDL Workspace, um só sistema para todo o ecossistema |
A decisão operacional é saber quantos casos do seu fluxo de aprovação dependem de exceção, e quem resolve cada um.
O que muda na operação, pela lente de COO
O custo de um fluxo de aprovação aparece nas bordas, não no caminho feliz. Três bordas merecem atenção em qualquer avaliação.
A primeira é a cobertura. Clientes B2B mudam de estrutura: abrem filial, trocam comprador, reorganizam centros de custo. Se a aprovação depende de haver aprovador em cada unidade, alguém precisa manter esse cadastro em dia, ou o pedido para no checkout.
A segunda é o teto. Todo fluxo com limite precisa de uma resposta para o pedido que passa do limite mais alto. Quando a resposta é editar o pedido, a operação precisa saber quem edita, quem avisa o cliente e quanto tempo isso leva.
A terceira é o acesso. A equipe que acompanha pedidos, libera exceções e responde ao vendedor precisa entrar no sistema de onde estiver. O modelo de rede define se isso é um login ou um projeto de infraestrutura.
Três perguntas levam esse raciocínio para a mesa: em que casos um pedido pode ficar sem aprovador possível; o que acontece com o pedido acima de todos os limites; e de onde a equipe de operação acessa a administração da plataforma.
Na CWS Platform, um vendedor atende milhares de clientes, e o vendedor monta um carrinho, com os itens e a origem de cada um, e envia o link para o cliente fechar. O pedido aceita pagamento a prazo com entrega fracionada, agendada, em vários endereços e várias origens.
Quando escolher o Spryker
O Spryker atende bem a cenários em que o controle de gasto do comprador é o centro da operação:
Empresa compradora com limites por papel. Escolha essa arquitetura quando os compradores precisam de limites de compra e de aprovação definidos por papel, como no Approval Process.
Hierarquia de unidades estável. Escolha essa arquitetura quando a estrutura das empresas compradoras muda pouco e cada unidade tem aprovador definido, organizada no Company Account.
Operação concentrada numa rede protegida. Escolha essa arquitetura quando a equipe que usa o Back Office já trabalha dentro de uma intranet com VPN, allowlist de IP ou DMZ, e o time de infraestrutura mantém esse perímetro.
Quando a CWS Platform é a escolha certa neste cenário
A CWS Platform é a escolha indicada quando a operação quer a regra comercial em parâmetros e cliente, vendedor e operação trabalhando no mesmo sistema.
Desconto com alçadas. Escolha essa arquitetura quando o desconto do vendedor precisa de aprovação. O desconto do vendedor passa por alçadas com aprovação em níveis. Tabelas, regras e contratos ficam em parâmetros do Commerce Rules Engine (CDL Workspace), no princípio de configuração em vez de código.
Crédito mantido na plataforma. Escolha essa arquitetura quando o crédito do cliente precisa morar no mesmo sistema em que o pedido é fechado. O crédito é mantido na plataforma, concedido no CDL Workspace ou por API.
Cliente e vendedor no mesmo pedido. Escolha essa arquitetura quando o vendedor participa do fechamento. Cliente e vendedor usam a mesma interface, e o pedido registra quem montou o carrinho e quem escolheu o pagamento.
Um só sistema para o ecossistema. Escolha essa arquitetura quando a operação não quer separar ferramentas por ator. O CDL Workspace é um só sistema para todo o ecossistema, e todos os clientes rodam a mesma versão.
Por onde continuar
Para ver a mesma comparação pela lente técnica, o comparativo Spryker ou CWS Platform: por onde passa o preço por cliente na integração com o ERP? trata de como os dados comerciais chegam ao portal.
Se a sua operação tem muitas exceções de aprovação, vale conversar com um especialista da CWS Platform para mapear os casos de borda antes de escolher. As sete perguntas que separam as arquiteturas de comércio B2B ajudam a organizar essa conversa, e a página Quando Vender Mais Não Significa Ganhar Mais trata da dor por trás do desconto sem governança, sem falar de fornecedor nenhum.
Leia também
Marcas citadas neste artigo
Marcas e logotipos pertencem aos seus titulares. A citação não indica parceria nem endosso.
"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.