commercetools ou CWS Platform: como fica a aprovação de pedidos para quem vende?
Aprovação do comprador em até cinco estágios, Intake ligado por chamado e a alçada de desconto do vendedor, pela ótica de quem vende.
Nota editorial: comparativo de arquitetura entre commercetools e a CWS Platform, escrito para quem responde como VP de Vendas. Todo fato sobre commercetools vem da documentação pública dele, com o endereço ao lado.
Quem lidera vendas num distribuidor conhece o pedido que não fecha por falta de assinatura. O cliente quer comprar, o vendedor negociou, a mercadoria está em estoque, e o pedido fica parado em alguma caixa de aprovação. Às vezes do lado do cliente, porque o comprador precisa da assinatura do gerente. Às vezes do lado de casa, porque o desconto passou do que o vendedor pode dar sozinho.
As duas filas parecem a mesma coisa no relatório de pipeline, mas são decisões diferentes. Uma é governança do comprador. A outra é governança da sua margem. E há uma terceira fila, menos visível: o pedido que chega por e-mail, em planilha ou PDF, e espera alguém do comercial digitar.
Este comparativo olha para commercetools e CWS Platform só por esse ângulo: quem aprova o quê, quantas etapas um pedido pode atravessar e como o pedido que chega fora do portal entra no sistema. Não é um ranking de funcionalidades. O mapa geral dos modelos está no post sobre os três modelos de plataforma de comércio B2B.
O que o commercetools resolve bem
O commercetools trata a aprovação do comprador como regra declarada. As Approval Rules combinam critérios do pedido, como moeda, país e valor total, com os papéis de quem pede e de quem aprova. Quando um pedido casa com uma regra ativa, a plataforma gera o Approval Flow sozinha, e o fluxo acompanha quem ainda precisa aprovar em cada nível.

No portal de exemplo, o guia de aprovações do front-end mostra os níveis de aprovadores combinados com operadores E e OU entre papéis. As regras podem ser herdadas pelas unidades de baixo da hierarquia de Business Units, o que poupa o cliente de repetir a configuração em cada filial.
Para a negociação, a visão geral de Quotes descreve o caminho do pedido de cotação até a proposta vinculante, com o vendedor ajustando itens, quantidades, validade e desconto direto no Staged Quote. E para o pedido que chega em texto livre, o Intake converte mensagem e arquivos, como PDF, planilha ou e-mail, em carrinho, pedido de cotação ou lista de compras.
Onde a arquitetura diverge
A divergência que interessa a quem vende está em dois pontos: quantas etapas a aprovação aceita e quanto esforço custa ligar o recurso que traz o pedido de fora para dentro. A documentação do próprio fornecedor registra os dois:

- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: com até cinco níveis por Approval Rule, um pedido pode passar por no máximo cinco estágios sequenciais de aprovação ("With up to five levels per Approval Rule, an Order can pass through a maximum of five sequential approval stages.", https://docs.commercetools.com/api/associates-overview)
- limitação registrada na documentação do fornecedor, consultada em 16/10/2026: para habilitar o Intake em um projeto é preciso abrir um chamado de suporte com a chave do projeto ("To enable Intake for a Project, submit a support request that includes the Project key.", https://docs.commercetools.com/offering/intake)
O primeiro registro diz respeito à estrutura de aprovação do cliente. Pela documentação de Approval Flows, o pedido só é aprovado quando todos os aprovadores exigidos em todas as regras aplicáveis aprovam, e uma só rejeição rejeita o fluxo inteiro. Para o comercial, isso desenha o tempo de ciclo: cada nível a mais é mais um ponto possível de espera, e uma recusa em qualquer nível encerra o fluxo inteiro.
O segundo registro diz respeito ao ritmo de adoção. O recurso que transforma o e-mail do cliente em carrinho é um Add-On, e ligá-lo passa por um chamado de suporte. Não é uma barreira técnica grande, mas é um passo que não está nas mãos do time comercial.
Há também uma pergunta que a documentação de Approval Rules não responde, porque não é o assunto dela: as regras descritas são do lado do comprador, entre os associados da conta. A governança do desconto do seu vendedor é outra camada, e vale perguntar a qualquer fornecedor onde ela mora.
Na CWS Platform, o desconto do vendedor passa por alçadas com aprovação em níveis, e a política comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace). O vendedor monta um carrinho, com os itens e a origem de cada um, e envia o link para o cliente fechar.
| decisão | commercetools, pelo mecanismo documentado | CWS Platform |
|---|---|---|
| Que aprovação está documentada | Aprovação do comprador por Approval Rules, com até cinco níveis por regra e no máximo cinco estágios por pedido | Alçadas de desconto do vendedor, com aprovação em níveis |
| Como o pedido que chega fora do portal entra | Intake, um Add-On habilitado por chamado de suporte, converte texto e arquivos em carrinho ou cotação | O vendedor monta o carrinho com os itens e a origem de cada um e envia o link para o cliente fechar |
A decisão comercial é escolher onde a sua governança de margem vai morar, e quem precisa ser acionado para mudar a forma como o pedido chega.
O que muda na operação, pela lente de VP de Vendas
O incentivo comercial sem banda de preço e sem alçada clara vira negociação caso a caso, em que o vendedor que dá mais desconto e o que protege margem ficam parecidos no relatório. A aprovação existe para separar os dois. O problema é quando ela atrasa o pedido mais do que protege a margem.

Três perguntas ajudam a levar esse ponto para qualquer avaliação. Primeira: a aprovação que a plataforma documenta é a do comprador, a do vendedor ou as duas, e onde cada uma é configurada. Segunda: quantas etapas um pedido pode atravessar, e o que acontece com ele quando alguém recusa no meio do caminho. Terceira: quem do seu time consegue ligar ou mudar o recurso que traz o pedido de fora para dentro, e quanto tempo isso leva.
Para quem vende, desconto e prazo são a mesma moeda. Um vendedor que só pode mexer em uma alavanca vai usá-la até o limite. Por isso a pergunta sobre alçada não é só sobre desconto: é sobre que margem de negociação o vendedor tem antes de pedir ajuda.
Na CWS Platform, um vendedor atende milhares de clientes, e cliente e vendedor usam a mesma interface, no mesmo pedido. O pedido registra quem montou o carrinho e quem escolheu o pagamento, o que separa o trabalho do vendedor da decisão do comprador. O carrinho comporta 250 itens por padrão, configurável, e o mesmo pedido aceita mais de um meio de pagamento.
Quando escolher o commercetools
O commercetools atende bem a cenários em que a governança do comprador é o centro da venda:
Clientes com cadeia de aprovação interna formal. Escolha essa arquitetura quando a sua carteira é de empresas que exigem aprovação por valor, país ou moeda antes de comprar, e as Approval Rules com até cinco níveis por regra cobrem essa cadeia.
Contas com muitas filiais que herdam regras. Escolha essa arquitetura quando o cliente tem divisões que devem seguir as regras da matriz, como a herança entre Business Units permite.
Pedido por e-mail e arquivo como canal principal. Escolha essa arquitetura quando boa parte dos pedidos chega em texto livre ou anexo, e a empresa aceita contratar e habilitar o Intake para convertê-los em carrinho.
Quando a CWS Platform é a escolha certa neste cenário
A CWS Platform é a escolha indicada quando a governança que mais pesa é a da margem do seu próprio time comercial.
Alçada de desconto do vendedor. Escolha essa arquitetura quando o desconto precisa de limite e de aprovação por nível de responsabilidade. O desconto do vendedor passa por alçadas com aprovação em níveis, e tabelas, regras e contratos são configurados na plataforma, no princípio de configuração em vez de código.
Vendedor que monta e o cliente que fecha. Escolha essa arquitetura quando o vendedor prepara o pedido e o cliente decide. O vendedor monta um carrinho, com os itens e a origem de cada um, e envia o link para o cliente fechar; o pedido registra quem montou o carrinho e quem escolheu o pagamento.
Carteira grande com a mesma equipe. Escolha essa arquitetura quando cada vendedor precisa cobrir mais contas. Um vendedor atende milhares de clientes, e o CDL Workspace é um só sistema para todo o ecossistema.
Venda a prazo com a operação do distribuidor. Escolha essa arquitetura quando o pedido a prazo precisa sair com entrega fracionada, agendada, em vários endereços e a partir de várias origens, e o crédito do cliente é mantido na plataforma.
Por onde continuar
Se você quer a visão técnica do mesmo fornecedor, o comparativo commercetools ou CWS Platform: quanto custa manter a regra comercial integrada? olha para a integração com ERP e CRM. Se a sua pergunta ainda é qual arquitetura serve à sua operação, o caminho é as sete perguntas que separam as arquiteturas de comércio B2B.
Se a decisão depende de onde a sua aprovação de desconto trava hoje, vale conversar com um especialista da CWS Platform para mapear as alçadas do seu time e o caminho do pedido até o fechamento. As páginas Quando os Canais Brigam Entre Si e Quando Vender Mais Não Significa Ganhar Mais tratam da dor por trás deste cenário em profundidade, 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.