B2B Portal Meets Counter and Field Sales: Adobe Commerce vs. CWS Platform, Side by Side

Architecture comparison: Adobe Commerce and CWS Platform. For marketing and channel revenue leaders at distribution businesses choosing a B2B portal platform that must work alongside branch counter sales and the field sales team. Every statement about Adobe Commerce in this article comes from its public documentation.

A buyer for an auto parts chain logs into the portal on Tuesday, builds a cart with forty items, and stops. On Thursday, they visit the branch counter to ask an application question and buy three items. On Friday, a sales rep calls, rebuilds the cart with a volume discount, and closes the sale.

One sale. Three interactions.

Now comes the question that lands on marketing’s desk: which campaign generated that sale? In most operations, the honest answer is that nobody knows. The portal recorded an abandoned cart. The branch recorded a counter-sale coupon. The sales rep recorded a new order, entered manually, with no connection to Tuesday’s cart.

The buyer experienced one journey. The system stored three.

73s

CAC does not rise because the campaign got worse

The conversation about customer acquisition cost in B2B often turns into a media conversation: the auction got more expensive, the creative wore out, the channel became saturated. Sometimes that is exactly what happened. But in distribution, there is an earlier cause—and it is not a marketing problem.

Today’s B2B buyer is a committee, and much of the decision happens before any contact with sales. That changes marketing’s job: it no longer just generates meetings; it supports research that is already underway. But that research has to end somewhere, and in distribution it ends in three different places.

When those three places do not recognize the same customer, the most expensive thing that can happen to a marketing budget happens: the campaign works and does not get credit. Calculated CAC rises, funding for the channel that actually converted gets cut, and the cut reduces real conversion in the following quarter. It is a cycle fed by a measurement error, not a strategy error.

Diagnosing this as an attribution problem leads to the wrong tool. It is not solved by adding another tracking layer on top of three systems that do not share the transaction. It is solved by making the transaction a single transaction.

Three places where the funnel breaks

It is worth naming all three, because each one breaks for a different reason.

The cart the sales rep cannot see. The buyer adds forty items to the portal cart and gets stuck on payment terms. The sales rep calls for another reason, does not know about the cart, and rebuilds everything from scratch. The order is created in the rep’s system, with no source data. From marketing’s perspective, the portal generated an abandonment and the sale came from the “sales rep channel.”

The price that changes by channel. The same item appears at one price in the portal, another at the branch counter, and a third in the sales rep’s quote. It is not bad faith: each channel reads commercial terms from a different source, and those reads are not simultaneous. The buyer notices, and the next negotiation begins with distrust. Marketing inherits a trust problem that started as an architecture issue.

The sale that never comes back as data. A campaign pushes one product mix. The channel sells another. Without sell-through data from the point of sale, the next campaign is built on the previous assumption, not the result. It is the difference between knowing how much was sold to the channel and how much the channel sold through.

All three have the same cause: the commercial rule lives outside the transaction. Price, approval authority, credit, and availability are queried from a source system rather than calculated when the purchase takes place. Each channel queries at its own time, and the resulting inconsistency is what the customer sees.

What Adobe Commerce solves—and it solves a lot

It is worth being specific, because an imprecise comparison does not help anyone make a decision.

Adobe Commerce has a native B2B module, enabled as an extension on the same platform that serves B2C. Its documentation describes a company account that groups multiple buyers, with divisions, subdivisions, and roles that control orders, quotes, credit, and profiles. Shared catalogs define custom pricing by company or customer group across one or more websites. Authorized buyers initiate quotes from the cart and sellers from the Admin; both sides modify items and quantities, request and apply discounts, and exchange messages until they reach an agreement. When purchase orders are enabled for a company, every order is created as a PO and subject to role-based approval rules.

That is a serious B2B portal, and it solves much of the first break: a quote started by the buyer and continued by the seller is the same object, not two separate ones.

Add an integrated payment service that centralizes payments and invoices from all storefronts in a single dashboard, with sandbox and production environments, region-specific methods, and API-exposed configuration. Add a personalization layer with audiences and segmentation, plus a mature multi-site architecture with website-level configuration scopes.

For businesses that need a robust B2B portal, customer-side purchasing governance, and a large integration ecosystem, this is a legitimate choice.

Where the architecture diverges—and why marketing feels it

The difference is not in the feature list. It is in who calculates the commercial terms at the moment of sale.

In Adobe, company pricing comes from a shared catalog: a structure that associates custom prices with a customer group. It is an assigned price. It works well when policy fits into company-level price tiers, which is the model for most operations selling the same mix to similar customer profiles.

In distribution, commercial terms rarely fit into a tier. Price is the output of a function with multiple inputs at once: who is buying, which warehouse will fulfill the order, what volume is involved, what payment term applies, what cart composition is being purchased, and what tax rule applies to that combination. CWS Platform handles this intentionally: the Pricing Engine calculates by product, warehouse, customer profile, and tax rule, with declared precedence of contract over rule and rule over price table. CDL Workspace applies approval authority, credit, and approvals as rules executed in the moment—not as a separate workflow.

The practical consequence for marketing is straightforward, and significant: if commercial terms are calculated at the moment of purchase, the portal, branch counter, and sales rep all query the same function and arrive at the same number. There is no synchronization delay, and therefore no three prices for the customer to compare.

The second point is the cart. Adobe’s quote is negotiated between buyer and seller through messages in the quote object. In CWS, Sales Hub runs a real-time shared cart: the sales rep enters the cart the buyer is building, with the buyer’s approval authority applied while the rep works in it. That is the difference between negotiating asynchronously and serving the customer together. For businesses with branch counters, that distinction determines whether an in-person interaction joins the same order or becomes another one.

The third point is source. When the sales rep works inside the buyer’s cart instead of creating a new order, the sale keeps its digital source. Campaign credit is not lost along the way, and CAC becomes measurable again without an attribution layer on top.

Adobe's own documentation records a point that touches selling with a sales rep:

• limitation recorded in the vendor's documentation on June 15, 2026: Payment on Account is not supported for orders with multiple shipping addresses ("not supported for orders with multiple shipping addresses", https://experienceleague.adobe.com/en/docs/commerce-admin/b2b/enable-basic-features).

When Adobe Commerce is the right choice

This is the CWS Platform blog, so account for that bias as you read. There are scenarios where the honest answer is not ours.

If the operation is primarily B2C with a B2B front, Adobe supports both on the same platform, and maintaining two platforms for that creates cost without a corresponding benefit. If customer-side purchasing governance is the central requirement—with deep corporate hierarchies, divisions, subdivisions, and formal purchase orders with multiple approval levels—Adobe documents this in detail, while CWS treats part of it as product validation rather than a proven feature. If the Adobe ecosystem is already in place, with Analytics and asset management running, their native integration has real value. And if commercial policy is stable, with pricing by customer tier and little item-by-item negotiation, CWS’s granularity becomes complexity that nobody uses.

CWS Platform makes sense in the opposite scenario: item-by-item negotiation, pricing that changes by warehouse and cart composition, assisted selling alongside self-service, and the branch counter as part of the same order.

The question that separates the two in your operation

It is not “which platform has more B2B features.” It is this:

When a sales rep serves a customer who already has a cart open in the portal, does the rep enter that cart or create a new order?

Ask the question in your next demo, and ask to see it happen rather than hear the answer. What happens in the next ten minutes says more about your CAC next quarter than any attribution report.

Frequently asked questions

Can’t this be solved with a CDP or an attribution tool? They help you see, and seeing is better than not seeing. But attribution unifies the record of events that happened in different systems; it does not put the sales rep inside the buyer’s cart. The break occurs in the transaction, and that is where it needs to be stitched together.

Our physical branch presence is small. Does that change anything? It changes the order of priorities, not the diagnosis. If the counter accounts for a small share of volume, the most expensive break is likely the sales rep rebuilding the cart, not the in-person interaction. Measure all three before deciding which one to address.

We already use Adobe Commerce. Is this conversation still worthwhile? It depends on what hurts. If the issue is customer-side purchasing governance, Adobe covers it and switching would be a step backward. If the issue is pricing that changes by warehouse, approval authority applied at the point of sale, and sales reps working inside the cart, then the conversation is about where commercial terms are calculated. That is an architecture difference, not a configuration difference.

Why does this post not include market numbers? Because the figures we have on hand do not include sources and publication years in the format our publishing standard requires. We prefer an argument without a number to a number without support.

A CWS Platform publication.