Seven Questions That Separate B2B Commerce Architectures

The scene plays out in almost every selection committee. The comparison spreadsheet has two hundred rows, five vendors in columns, and nearly every cell says "yes." Customer-specific pricing: yes. Discount approval: yes. Multi-warehouse: yes. ERP integration: yes. By the end of the meeting, the decision comes down to license price or rapport with the sales team, because the spreadsheet didn't separate anyone.

The spreadsheet didn't separate anyone because the question was wrong. "Do you support customer-specific pricing?" is a question every platform answers with yes, and five completely different architectures fit inside that yes. One calculates the price the moment the screen is rendered. Another reads a table that was synced overnight. Both check the same box, and the difference between them shows up eighteen months later, in the form of a sales team that went back to closing orders over the phone and text messages.

What separates B2B commerce architectures is one thing, and it usually isn't on the spreadsheet: where the commercial rule lives. Inside the platform, where it's editable and executed on the spot, or outside it, in a system of record that has to be queried, synced, or re-implemented with every change.

The seven questions below exist to expose that before the signature. They aren't a checklist for scoring vendors. They're seven places where a vague answer gets expensive later, and where a good answer is recognizable on the spot.

1. Is your customer's price a stored value or the result of a function?

This is the question that separates the most, and it's the one that gets a yes from everyone.

In B2B commerce, price is almost never a stored value. It's the result of a function whose inputs are the buyer's identity, the fulfilling warehouse, the volume, the payment terms, the payment method, the product's origin, and the tax rule that applies to that combination. A platform that treats price as a field needs a row in the table for every possible combination, and combinations grow multiplicatively, not additively.

What happens when that doesn't fit is predictable and rarely recorded as a decision: the company flattens its pricing policy. It levels the price list because maintaining different prices per branch crossed with prices per customer became impossible to manage. It's a technical workaround disguised as commercial simplification, and it gives away margin upfront on every customer who would pay more, while losing the deal on every customer who needed a price below the flattened list. There is no report that shows the price you failed to charge.

A good answer sounds like this: the price is calculated at display time, from the inputs, with a declared hierarchy of what wins over what (contract over rule, rule over price list).

A red flag sounds like this: "we sync the price table from the ERP every four hours." That's not an answer about pricing, it's an answer about latency.

2. Who edits the commercial rule, and in how many days?

Any ERP can represent a complex pricing rule. Representing it was never the bottleneck. The bottleneck is distributing that rule to hundreds of sales reps and thousands of buyers without training everyone on the ERP, and changing it when the market changes.

If every commercial policy adjustment opens an IT ticket, commercial policy starts moving at the speed of the IT queue. In practice, it stops moving. The sales organization learns that requesting changes isn't worth it, and starts operating by manual exception, which is the same thing as having no policy.

A good answer sounds like this: a business user edits it, within the same week, with no code deployment, and there's a record of who changed what.

The test worth more than the answer: during the demo, ask them to create a new rule in front of you. Not a rule that already exists in the demo environment, one you make up on the spot. It's remarkable how many demos don't survive that request, and it's remarkable how often it simply isn't made.

3. What's the unit of configuration: the company or the warehouse?

Most platforms configure at the company level, and treat branches, distribution centers, and stores as delivery attributes. That works while the operation is homogeneous, and it breaks the first moment two units of the same company have different commercial realities, which in distribution is the rule, not the exception.

A unit serving a different region has a different freight cost, different lead time, different mix, sometimes different tax treatment, and frequently a different discount ceiling. If the unit of configuration is the company, all of that becomes an exception, and exceptions at volume become manual work.

A good answer sounds like this: the unit of configuration is the smallest unit with its own commercial reality, and it carries its own catalog, pricing, region, logistics, payment, credit, and approval authority, within what central configuration allows. Decentralizing configuration without losing governance is the point, and both halves of that sentence matter equally.

4. What happens when two discounts meet?

Every platform has discounts. Few have an answer for when two of them meet.

Margin leakage in B2B rarely comes from one big discount, which would be visible. It comes from the stacking of small discounts, each legitimate on its own, that add up without anyone having approved the sum. Add informal approval, every manager approving their own way, nothing recorded, and net margin drifts away from gross without any report capable of showing where.

It's also worth asking about payment terms. Discounts and terms are the same currency in a real negotiation, and they're convertible into each other. A rep who can only pull the discount lever has one lever, and will use it to the limit. Giving both levers inside guardrails is usually the cheapest way to protect margin.

A good answer sounds like this: there's a preventive block before the order is submitted, not just approval after the fact; there's tiered approval authority; and every exception records the reason, so that an audit is a query and not a project.

5. Does the checkout accept how your customer actually pays?

B2B payment is a financial service, not a card form. Net-30, net-60, or net-90 terms, a credit line used as a payment method, trade allowances, splits between different reps on the same order. A platform that treats checkout as the final step of a retail flow turns all the prior effort into waste, because the negotiation dies exactly at the close.

Here the question has a second half that almost nobody asks: is credit checked in real time, or is it information from the last sync? An outdated credit limit is worse than no limit at all, because it authorizes what it should block.

A good answer sounds like this: credit enters the order as a transactional product governed by rules, evaluated at the moment of checkout, and not as a favor negotiated over the phone afterward.

6. Is the inventory on the screen the inventory that exists?

Systems of record operate in batches. The commercial front end operates in real time. When the truth of the former reaches the latter with an hours-long window, the buyer discovers the error at the worst possible moment: after having decided to buy. The effect doesn't show up as a complaint. It shows up as a silent return to the phone, and the digital channel becomes a vanity metric without anyone able to explain why.

The question has a follow-up that separates even more: what does the platform do when inventory hits zero? Ending the sale is the common answer. Routing to another warehouse, including a partner supplier's, without the buyer needing to know, is the answer that turns a stockout into a delayed sale instead of a lost one. An assortment limited by working capital is an architecture choice before it's a financial one.

7. When AI comes in, what does each decision cost?

This is the newest question, and it's the one no selection committee is asking yet. Whoever asks it now will save a lot of money in two years.

Every vendor demos AI today, and the demos work. What doesn't show up in the demo is the cost per decision when it's turned on for the entire operation. Without a deterministic layer that resolves business rules before the model, every trivial decision becomes paid inference. The pilot pencils out with ten users and doesn't with three hundred, and the project becomes an eternal proof of concept.

We measured this in our own operation, and the number is the reason this question exists on the list: across twelve days and 2,151 model calls, the average cost was $0.0193 per call, with a sixty-fold variation between task types. The most expensive task cost seventy times the cheapest. In a hypothetical operation of fifty sales reps with twenty interactions a day, projecting those costs without a deterministic layer underneath, inference alone exceeds the per-user license price in many operations.

A good answer sounds like this: most decisions never reach the model, because pricing, inventory, approval authority, and catalog are resolved by rules; the model is called for what's ambiguous, and cost is measured per task type.

A red flag sounds like this: a per-user AI license number, with no conversation about what generates a call.

How CWS Platform answers these seven

This is the CWS Platform blog, so the honest answer is that the seven questions above describe the architecture CWS chose, and it's only natural that it does well on its own questionnaire. The reader should discount that accordingly.

The summary is short. CWS treats price as a function and not a table, configures at the warehouse level, exposes the commercial rule in 1,029 parameters editable by business users without a code deployment, and puts a deterministic layer between the operation and the language model. That's 11 modules and 6 AI Agents, and the thesis holding them all together is that the product isn't an online store, it's a negotiation platform.

And the most useful part, which is where CWS is not the answer: an operation with fixed pricing, a stable catalog, and little negotiation doesn't need any of this. In that scenario, simpler commerce platforms solve the problem better and for less money, and CWS Platform's complexity becomes cost without a counterpart. The seven questions above are only worth asking for those who answer "it depends" to most of them. Those who answer "it's always the same" are facing a different problem.

What to do with these seven questions

Take them to your next demo and ask number 2 first, because it's the one least tolerant of a rehearsed answer. Ask them to create a new rule in front of you. What happens in the following ten minutes will tell you more about the vendor's architecture than the two hundred rows of the comparison spreadsheet.

Frequently asked questions

Do these questions work for B2C too? Partially. Numbers 6 and 7 apply to any operation. Numbers 1 through 5 deal with negotiation, approval authority, and credit, which are characteristics of commerce between companies. In B2C, where the price is the same for everyone, most of them lose their meaning.

We've already signed with a vendor. Are the questions still useful? They are, and probably more so now. Asked after the contract, they become a diagnosis of where your operation is paying in manual work for what the architecture doesn't solve. That's useful at renewal, and it's useful for deciding what to integrate around the platform.

Why does pricing come first? Because it's the question whose wrong answer is the most expensive and the most silent. Flattening your pricing policy to fit the system generates no incident, no complaint, and shows up in no report. It's the only one of the seven whose cost is invisible by construction.

Is there one right answer to all of them? No. There are expensive answers and cheap answers for your specific case. An operation with one warehouse and one pricing policy doesn't need the sophisticated answer to question 3, and would be paying for complexity it doesn't use. The goal of the seven is to make the cost visible before the contract, not to crown a winner.

A publication by CWS Platform.