Skip to content
platform
When Channels Fight Each Other · · 8 min

Assisted selling and agent assist: Spryker or CWS Platform?

When the customer calls in the middle of a cart, the digital channel wins or loses the order on what the sales rep can see.

Architectural comparison of assisted sales between Spryker and CWS Platform showing cart sharing flows

Editorial note: a comparison between Spryker and CWS Platform for the assisted selling scenario, in which a sales rep or customer service agent helps the customer build and close an order in the digital channel. Written for those who own that channel, such as the Director of Commerce. Every fact about Spryker comes from its public documentation, with the address next to it.

B2B customers rarely close a large order on their own. They start the cart on the portal, get stuck on a quantity or delivery question, and call their sales rep. What happens next decides whether the digital channel wins or loses that order: either the rep sees the same cart and picks up where the customer left off, or starts over by phone, spreadsheet, or email.

For a Director of Commerce, assisted selling is the bridge between self-service and the field sales team. If the bridge fails, reps go back to keying orders, the digital channel loses credit for the sale, and the customer learns that calling is faster than using the portal.

This comparison looks at Spryker and CWS Platform from that angle only: how the sales rep joins the interaction, which cart the rep can reach, and what gets recorded on the order. It is not a feature ranking. The broader frame of the architectures is in the post on the three B2B commerce platform models.

Read more on The Cost of Selling Watch on YouTube Subscribe

What Spryker does well

Spryker has its own feature for acting on behalf of a customer. In Agent Assist, a Back Office user becomes an agent when the "THIS USER IS AN AGENT" option is checked. In the storefront, the agent signs in on a dedicated page, searches for the customer by name or email, and confirms to act as that customer, ending the session when the assistance is over.

Layers in which an administration user becomes an agent and acts in the storefront inside the customer's account.

The feature also has an API path. Through the Glue API, the agent gets its own token, searches customers, and receives a customer token with an impersonation scope, as described in the Impersonate customers as an agent assist guide. Per the feature installation guide, the agent's email can be recorded on orders, through configuration.

In quote negotiation, the sales rep can act through the agent account or on behalf of a company user, as described in Request for Quote. For an operation in which service staff need to enter the customer's account with a trail, this set covers the main flow.

Where the architecture diverges

The divergence that matters to a Director of Commerce is what the agent can reach. Per the documented mechanism, whether the agent can view and edit the cart depends on where the cart is stored: saved in the database, the agent can manage it; stored only in the customer's session, the agent cannot.

The agent reaches the cart saved in the database, but not the cart stored only in the customer's session.

The vendor's own documentation records two points that shape how assisted selling is designed:

The first point turns a technical detail into a commercial decision. The cart that triggers the call is the cart in progress. If the project stores the cart only in the customer's session, the agent cannot manage it, and assisted selling starts from scratch. Where the cart lives belongs in the channel specification, not in something the team discovers on the first support call.

The second point is about the calendar. The technical foundation has a date to move to a new version, and the migration has to fit the channel roadmap. For a Director of Commerce, that means reserving a project window in which the priority is keeping what already works, not shipping what the channel is asking for.

On CWS Platform, customer and sales rep use the same interface, on the same order. A sales rep builds a cart, with the items and the source of each one, and sends the link for the customer to complete the purchase, and the order records who built the cart and who chose the payment. All customers run the same version of the platform.

decision Spryker, per the documented mechanism CWS Platform
How the sales rep joins the interaction A Back Office user flagged as an agent, who searches for the customer and acts on the customer's behalf Customer and sales rep use the same interface, on the same order
Which cart the sales rep can reach The one saved in the database; a cart stored only in the customer's session is out of the agent's reach The sales rep builds the cart, with items and source, and sends the link for the customer to complete
What gets recorded The agent's email recorded on orders, when configured The order records who built the cart and who chose the payment
How the technical foundation changes PHP 8.3 supported until July 2027, with migration to be planned before then All customers on the same version

The channel decision is whether the sales rep joins the interaction by acting on the customer's behalf, inside the customer's account, or as a participant in the same order.

What changes in assisted selling operations

Assisted selling works when three things happen without effort from the customer: the rep sees what the customer has already done, both work on the same order, and in the end the company knows who built the cart and who chose the payment.

The sales rep builds the cart, sends the link, the customer closes the order and the record keeps who built it and who chose the payment.

The first defines the experience. If the rep has to ask the customer to rebuild the cart, the interaction starts at a loss. The cart that matters is the cart in progress.

The second defines productivity. When the rep acts by entering the customer's account, every interaction is a session of that customer. When the rep builds the order and sends it to the customer to approve, the rep can prepare several orders and leave the close to the buyer.

The third defines management. Commission, quota, and channel analytics depend on knowing whether the order came from the customer, the rep, or both. Without that record, the debate about the digital channel turns into opinion.

Three questions bring this reasoning into any evaluation: can the rep see the cart the customer started; do rep and customer act on the same order, or does one enter the other's account; and does the order record who built it and who chose the payment.

On CWS Platform, one sales rep serves thousands of customers. The cart holds 250 items by default, configurable, the same order accepts more than one payment method, and the sales rep's discount goes through multi-level approvals.

When to choose Spryker

Spryker fits scenarios where acting on behalf of the customer is the intended design:

Service staff acting in the customer's account. Choose this architecture when the operation wants the agent to enter the customer's account and act for them, as in Agent Assist, with the cart stored in the database.

A custom agent experience over an API. Choose this architecture when the technical team wants to build the agent experience on the Glue API, with an agent token and an impersonation token, as in the Impersonate customers as an agent assist guide.

Quote negotiation led by the sales rep. Choose this architecture when the sales rep edits price, quantity, and shipping in a versioned quote, as in Request for Quote.

When CWS Platform is the right choice in this scenario

CWS Platform is the right choice when assisted selling needs customer and sales rep on the same order, with a record of who built the cart and who chose the payment.

The rep prepares, the customer closes. Choose this architecture when the sales rep wants to build the order and leave the close to the customer. A sales rep builds a cart, with the items and the source of each one, and sends the link for the customer to complete the purchase.

One interface for both sides. Choose this architecture when the sales rep should work on the same order as the customer, without entering the customer's account. Customer and sales rep use the same interface, and one sales rep serves thousands of customers.

Who built the cart and who chose the payment. Choose this architecture when commission and quota depend on knowing who built the cart and who chose the payment. The order records who built the cart and who chose the payment.

Commercial terms in parameters. Choose this architecture when the sales rep negotiates within rules. Commercial policy sits in parameters of the Commerce Rules Engine (CDL Workspace), the customer's credit is maintained on the platform, and payment on terms supports split, scheduled deliveries to multiple addresses and from multiple ship-from locations.

Where to go from here

If the decision also involves how pricing and orders arrive from the ERP, the comparison of customer-specific pricing in the Spryker and CWS Platform ERP integration looks at the same choice through the technical lens.

To design assisted selling for your operation, it is worth talking to a CWS Platform specialist and mapping when the sales rep steps in for each type of order. The page When Channels Fight Each Other covers the pain behind this scenario, without talking about any vendor.

Brands mentioned in this article

  • Spryker

Trademarks and logos belong to their respective owners. Mention does not imply partnership or endorsement.

"responsive, technically engaged, and willing to work through complex commercial rules (negotiated pricing, credit, customer-specific conditions) rather than pushing generic answers"
Maite S. · Setor automotivo · 5.001 a 10.000 funcionários · Software Advice · See reviews

Want to see this in your operation?

Real B2B operations already run on it.

Schedule a demo