Quando os Canais Brigam Entre Si · 17 de outubro de 2026 · 8 min

Venda assistida: Spryker ou CWS Platform?

Quando o cliente liga no meio do carrinho, o canal digital ganha ou perde o pedido pelo que o vendedor consegue enxergar.

Comparativo de venda assistida entre Spryker e CWS Platform com foco em sessão e pedidos compartilhados

Nota editorial: comparativo entre Spryker e a CWS Platform para o cenário de venda assistida, em que o vendedor ou o atendimento ajuda o cliente a montar e fechar o pedido no canal digital. Escrito para quem decide esse canal, como o Diretor de Commerce. Todo fato sobre Spryker vem da documentação pública dele, com o endereço ao lado.

O cliente B2B raramente fecha um pedido grande sozinho. Ele começa o carrinho no portal, trava numa dúvida de quantidade ou de entrega, e liga para o vendedor. A partir daí, o que acontece define se o canal digital ganha ou perde aquele pedido: ou o vendedor enxerga o mesmo carrinho e continua de onde o cliente parou, ou começa de novo por telefone, por planilha, por e-mail.

Para o Diretor de Commerce, venda assistida é a ponte entre o autoatendimento e a força de vendas. Se a ponte falha, o vendedor volta a digitar pedido, o canal digital perde o crédito da venda e o cliente aprende que ligar é mais rápido que usar o portal.

Este comparativo olha para Spryker e CWS Platform só por esse ângulo: como o vendedor entra no atendimento, que carrinho ele alcança e o que fica registrado no pedido. 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.

Leia mais em O Custo da Venda Assista no YouTube Inscreva-se no canal

O que o Spryker resolve bem

O Spryker tem um recurso próprio para atendimento em nome do cliente. No Agent Assist, um usuário do Back Office vira agente quando a opção "THIS USER IS AN AGENT" é marcada. Na loja, o agente autentica numa página própria, busca o cliente por nome ou e-mail e confirma para atuar como ele, encerrando a sessão quando termina o atendimento.

Camadas em que um usuário da administração vira agente e atua na loja dentro da conta do cliente.

O recurso também tem caminho por API. Pela Glue API, o agente obtém um token próprio, consulta clientes e recebe um token de cliente com escopo de personificação, como descreve o guia Impersonate customers as an agent assist. Pela instalação do recurso, o e-mail do agente pode ser gravado nos pedidos, por configuração.

Na negociação por cotação, o representante comercial pode atuar pela conta de agente ou em nome de um usuário da empresa, como descreve o Request for Quote. Para uma operação em que o atendimento precisa entrar na conta do cliente com rastro, esse conjunto cobre o fluxo principal.

Onde a arquitetura diverge

A divergência que interessa ao Diretor de Commerce está no que o agente consegue alcançar. Pelo mecanismo documentado, a visualização e a edição do carrinho pelo agente dependem de onde o carrinho está guardado: salvo no banco de dados, o agente consegue gerenciar; guardado só na sessão do cliente, não.

O agente alcança o carrinho salvo no banco de dados, mas não alcança o carrinho guardado só na sessão do cliente.

A documentação do próprio fornecedor registra dois pontos que entram no desenho da venda assistida:

limitação registrada na documentação do fornecedor, consultada em 16/10/2026: se o carrinho do cliente estiver guardado só na sessão, o agente não consegue gerenciá-lo ("If the cart is stored only in the customer’s session, the agent can’t manage it.", https://docs.spryker.com/docs/pbc/all/user-management/latest/base-shop/agent-assist-feature-overview.html).
limitação registrada na documentação do fornecedor em 07/08/2026: o PHP 8.3 é a versão mínima suportada, mas o suporte termina em julho de 2027 e a migração deve ser planejada antes disso ("PHP 8.3 remains the minimum supported version, but its support will be dropped in July 2027, so plan your migration before that date.", https://docs.spryker.com/docs/dg/dev/supported-versions-of-php.html).

O primeiro ponto transforma um detalhe técnico em decisão comercial. O carrinho que motiva a ligação é o carrinho em andamento. Se o projeto guarda o carrinho só na sessão do cliente, o agente não consegue gerenciá-lo, e a venda assistida começa do zero. Onde o carrinho mora precisa entrar na especificação do canal, não ser descoberto no primeiro atendimento.

O segundo ponto é de calendário. A base técnica tem data para mudar de versão, e a migração precisa caber no plano do canal. Para o Diretor de Commerce, isso significa reservar uma janela de projeto em que a prioridade é manter o que já funciona, e não lançar o que o canal pede.

Na CWS Platform, cliente e vendedor usam a mesma interface, no mesmo pedido. O vendedor monta um carrinho, com os itens e a origem de cada um, e envia o link para o cliente fechar, e o pedido registra quem montou o carrinho e quem escolheu o pagamento. Todos os clientes rodam a mesma versão da plataforma.

decisão	Spryker, pelo mecanismo documentado	CWS Platform
Como o vendedor entra no atendimento	Usuário do Back Office marcado como agente, que busca o cliente e atua em nome dele	Cliente e vendedor usam a mesma interface, no mesmo pedido
Que carrinho o vendedor alcança	O salvo no banco de dados; o guardado só na sessão do cliente fica fora do alcance do agente	O vendedor monta o carrinho, com itens e origem, e envia o link para o cliente fechar
O que fica registrado	E-mail do agente gravado nos pedidos, quando configurado	O pedido registra quem montou o carrinho e quem escolheu o pagamento
Como a base técnica muda	PHP 8.3 com suporte até julho de 2027, migração a planejar antes	Todos os clientes na mesma versão

A decisão de canal é saber se o vendedor entra no atendimento atuando em nome do cliente, dentro da conta dele, ou como participante do mesmo pedido.

O que muda na operação de venda assistida

A venda assistida funciona quando três coisas acontecem sem esforço do cliente: o vendedor vê o que o cliente já fez, os dois trabalham sobre o mesmo pedido e, no fim, a empresa sabe quem montou o carrinho e quem escolheu o pagamento.

O vendedor monta o carrinho, envia o link, o cliente fecha o pedido e o registro guarda quem montou e quem escolheu o pagamento.

A primeira define a experiência. Se o vendedor precisa pedir ao cliente que refaça o carrinho, o atendimento já começou perdendo. O carrinho que importa é o carrinho em andamento.

A segunda define a produtividade. Quando o vendedor atua entrando na conta do cliente, cada atendimento é uma sessão daquele cliente. Quando o vendedor monta o pedido e manda para o cliente aprovar, ele consegue preparar vários pedidos e deixar o fechamento com quem compra.

A terceira define a gestão. Comissão, meta e análise do canal dependem de saber se o pedido nasceu do cliente, do vendedor ou dos dois. Sem esse registro, a discussão sobre o canal digital vira opinião.

Três perguntas levam esse raciocínio para qualquer avaliação: o vendedor enxerga o carrinho que o cliente começou; vendedor e cliente atuam sobre o mesmo pedido ou um entra na conta do outro; e o pedido registra quem montou e quem escolheu o pagamento.

Na CWS Platform, um vendedor atende milhares de clientes. O carrinho tem 250 itens por padrão, configurável, o mesmo pedido aceita mais de um meio de pagamento, e o desconto do vendedor passa por alçadas com aprovação em níveis.

Quando escolher o Spryker

O Spryker atende bem a cenários em que o atendimento em nome do cliente é o desenho desejado:

Atendimento que atua na conta do cliente. Escolha essa arquitetura quando a operação quer que o agente entre na conta do cliente e aja por ele, como no Agent Assist, com o carrinho guardado no banco de dados.

Atendimento por canal próprio via API. Escolha essa arquitetura quando o time técnico quer montar a experiência do agente sobre a Glue API, com token de agente e token de personificação, como no guia Impersonate customers as an agent assist.

Negociação por cotação conduzida pelo representante. Escolha essa arquitetura quando o representante comercial edita preço, quantidade e frete numa cotação versionada, como no Request for Quote.

Quando a CWS Platform é a escolha certa neste cenário

A CWS Platform é a escolha indicada quando a venda assistida precisa colocar cliente e vendedor no mesmo pedido, com registro de quem montou o carrinho e de quem escolheu o pagamento.

O vendedor prepara, o cliente fecha. Escolha essa arquitetura quando o vendedor quer montar o pedido e deixar o fechamento com o cliente. O vendedor monta um carrinho, com os itens e a origem de cada um, e envia o link para o cliente fechar.

Uma interface para os dois lados. Escolha essa arquitetura quando o vendedor deve trabalhar no mesmo pedido que o cliente, sem entrar na conta dele. Cliente e vendedor usam a mesma interface, e um vendedor atende milhares de clientes.

Quem montou e quem escolheu o pagamento. Escolha essa arquitetura quando comissão e meta dependem de saber quem montou o carrinho e quem escolheu o pagamento. O pedido registra quem montou o carrinho e quem escolheu o pagamento.

Condição comercial em parâmetros. Escolha essa arquitetura quando o vendedor negocia dentro de regras. A política comercial fica em parâmetros do Commerce Rules Engine (CDL Workspace), o crédito do cliente é mantido na plataforma, e o pagamento a prazo aceita entrega fracionada, agendada, em vários endereços e várias origens.

Por onde continuar

Se a decisão também envolve como preço e pedido chegam do ERP, o comparativo Spryker ou CWS Platform: por onde passa o preço por cliente na integração com o ERP? olha a mesma escolha pela lente técnica.

Para desenhar a venda assistida da sua operação, vale conversar com um especialista da CWS Platform e mapear em que momento o vendedor entra em cada tipo de pedido. A página Quando os Canais Brigam Entre Si trata da dor por trás deste cenário, sem falar de fornecedor nenhum.