Assisted selling: commercetools or CWS Platform?
Rep-assumed sessions, Business Unit hierarchies, and imports in beta, from the seat of whoever owns the commerce experience.
Editorial note: an architecture comparison between commercetools and CWS Platform for the assisted selling scenario, where the sales rep steps into the customer's order to help close it. The person who decides here is the Director of Commerce. Every fact about commercetools comes from its public documentation, with the address next to it.
A distributor's digital channel rarely becomes pure self-service. The customer starts an order on the portal, stops over a question about a substitute part, calls the rep, and the rep finishes what the customer started. On another day the path runs the other way: the rep prepares a replenishment suggestion and the customer only confirms it. Assisted selling is that back and forth, and the Director of Commerce owns the whole experience, not only the part that happens without help.
The question that separates platforms in this scenario is not whether the rep can get into the cart. It is how much modeling work sits behind that: how the rep's book of business is designed, how customer accounts are organized, and how that data reaches the platform when operations go live.
This comparison looks at commercetools and CWS Platform from that angle only. It is not a feature ranking. The overall map of models is in the post on the three B2B commerce platform models.
What commercetools does well
commercetools has a well-described assisted selling flow. Per the Assisted Selling spotlight, sales reps and service teams see open carts in a central Merchant Center interface, filtered by seller or store permissions. An authorized rep takes over the customer's session to adjust products, quantities, prices, discounts, and shipping, and what the rep changes is the same as what the buyer sees.

The flow has two safeguards that matter to whoever owns the experience. The cart can be locked during the session so the buyer does not change what is being negotiated, and at the end the cart is handed back to the buyer to review and submit the order, as the Assisted Selling spotlight describes; the lock also appears on the cart and order management page.
Underneath, the customer's structure is modeled in Business Units, with a company and its divisions, and each user's access to carts, orders, and quotes is granted through Associate Roles with granular permissions, such as viewing orders placed by other users in the same unit.
Where the architecture diverges
The divergence that matters to a Director of Commerce is in the design that supports assisted selling and in how the data reaches the platform. The vendor's own documentation records both points:

- limitation recorded in the vendor's documentation, accessed on October 16, 2026: the limit-increase guide recommends flattening Business Unit hierarchies and reducing per-user role fan-out ("Flatten Business Unit hierarchies and reduce per-user role fan-out.", https://docs.commercetools.com/api/limit-increase-guidance)
- limitation recorded in the vendor's documentation, accessed on October 16, 2026: the resource-specific import endpoints remain in public beta ("the resource-specific import endpoints remain in public beta", https://docs.commercetools.com/api/import-export/overview)
The first record is about the shape of the book of business. A distributor with corporate groups, branches, and buyers in different roles tends to need deep hierarchies and many roles per user. The vendor's guidance, when a project approaches the limits, is to simplify that design. For assisted selling, that means deciding early how the customer's real structure will fit the structure the platform prefers.
The second record is about day one. The Import API, the platform's path for batch ingestion, is asynchronous and eventually consistent, and, as recorded above, the resource-specific endpoints remain in public beta. For anyone planning to have hundreds of reps working in the portal on a set date, that goes into the load schedule and the contingency plan.
On CWS Platform, one sales rep serves thousands of customers, and customer and sales rep use the same interface, on the same order. Commercial policy sits in parameters of the Commerce Rules Engine (CDL Workspace), and price tables, rules, and contracts can come from the ERP or CRM through an API.
| decision | commercetools, per the documented mechanism | CWS Platform |
|---|---|---|
| How the rep enters the order | Takes over the customer's session in Merchant Center, with cart lock and handover back to the buyer | Customer and sales rep use the same interface, on the same order |
| How the book of business is designed | Business Units and Associate Roles; the limits guide recommends flattening hierarchies and reducing roles per user | One sales rep serves thousands of customers |
| How the data reaches the platform | Asynchronous Import API, with resource-specific endpoints in public beta | Tables, rules, and contracts configured on the platform or received from the ERP and CRM through an API |
The commerce decision is whether assisted selling will be a special service mode or the normal way a rep works on the customer's own order.
What changes in assisted selling operations
Going digital does not take the rep out of the path. What changes is that self-service becomes measurable, and the rep covers exactly where the customer gets stuck. Read that way, the rep is the one who brings the customer into digital, and the platform has to treat the rep as a primary user, not an exception.
Three questions help bring this point into any evaluation. First: does the rep work on the customer's own order or in a borrowed session, and what happens when both need to make changes at the same time. Second: does the real account structure, with groups, branches, and buyers, fit the platform's model without simplifications that change how you sell. Third: how do the book of business, prices, and open orders reach the platform on the day operations start, and at what service level.
There is also the question of the record. In assisted selling, knowing who built the order and who decided the payment is what lets you measure self-service and compensate the rep for what the rep actually did.
On CWS Platform, the order records who built the cart and who chose the payment. 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. The cart holds 250 line items by default, and that is configurable, and the same order accepts more than one payment method, with the rules combined in CDL Workspace and maintained through an API.
When to choose commercetools
commercetools fits scenarios where assisted selling is a service mode on top of a composed architecture:
A service center that takes over carts. Choose this architecture when the operation has a service team that needs to see open carts and take over the customer's session, as the Assisted Selling spotlight describes.
Negotiation that requires a locked cart. Choose this architecture when the service team needs to freeze the cart while negotiating and hand it back to the buyer at the end, as the Assisted Selling spotlight describes.
Accounts with a simple structure and granular permissions. Choose this architecture when customers fit a lean hierarchy of Business Units and access control needs fine-grained permissions by role.
When CWS Platform is the right choice in this scenario
CWS Platform is the right choice when assisted selling is the normal way to sell, not a special mode.

Customer and sales rep on the same order. Choose this architecture when the rep and the customer take turns on the same order throughout the day. Customer and sales rep use the same interface, and the order records who built the cart and who chose the payment.
The rep prepares and sends. Choose this architecture when replenishment starts with the rep. The rep builds a cart, with the items and the source of each one, and sends the link for the customer to complete the purchase.
A large book of business per rep. Choose this architecture when each rep covers many accounts. One sales rep serves thousands of customers, and CDL Workspace is a single system for the entire ecosystem.
Commercial terms that follow the account. Choose this architecture when each customer has its own pricing, promotions, and payment terms. Tables, rules, and contracts are configured on the platform, on the principle of configuration over code; the sales rep's discount goes through multi-level approvals, the customer's credit is maintained on the platform, and net terms work with split shipments, scheduled deliveries, multiple ship-to addresses, and multiple ship-from locations.
Where to go from here
If you want the technical view of the same vendor, the comparison commercetools or CWS Platform: what does it cost to keep commercial rules integrated? looks at ERP and CRM integration. If your question is still which architecture fits your operation, the path is the seven questions that separate B2B commerce architectures.
If the decision depends on how your sales force serves customers today, it is worth talking to a CWS Platform specialist to design assisted selling around your reps' real books of business. The pages When Channels Fight Each Other and When the Catalog Becomes Chaos cover the pain behind this scenario in depth, without talking about any vendor.
Brands mentioned in this article
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"
Want to see this in your operation?
Real B2B operations already run on it.