What B2B buyers actually judge a supplier portal on
Consumer e-commerce is a discovery problem. B2B e-commerce is a verification problem. The buyer usually knows what they want before they arrive, and the site's job is to confirm price, availability, and delivery accurately enough that they commit without checking elsewhere.
That inverts the priorities. Search and merchandising matter less than most storefront demos imply. Correctness matters more than almost anything. A wrong price on a B2B order is not a bad customer experience but a commercial dispute and a credit note.
The features that drive adoption are consequently unglamorous. Buyers want their price, real stock, their history, and a delivery date they can plan around. A portal that gets those four right beats a portal with a better interface and stale data every time.
The features that are really data flows
Most of what appears on a B2B feature checklist is the storefront rendering something another system owns.
- Customer-specific pricing: contract prices, volume breaks, and account discounts held in the ERP, applied per logged-in account
- Real-time availability: an available-to-promise figure from the warehouse system, net of allocations, rather than a nightly snapshot
- Order history and reordering: past orders across every channel, including those placed by phone or EDI, presented as one list
- Credit and payment terms: the account's limit and terms from finance, enforced at checkout rather than discovered afterwards
- Quote to order: an approved quote converted into an order without re-entry, with the quoted price honored
The storefront can display all five. It originates none of them. That is why a platform migration rarely fixes a B2B portal buyers do not trust, and why the fix usually sits behind the storefront rather than in it.
Why does customer-specific pricing break so often?
B2B pricing is conditional in ways consumer pricing is not. A single line item's price can depend on the account, the contract, the order quantity, the currency, the delivery location, and whether a promotion is active on that date. The ERP resolves those conditions correctly because it holds all of them.
Problems begin when pricing is copied into the storefront on a schedule. A synchronized price table is a snapshot of a calculation, and it goes stale the moment a contract is renegotiated or a volume break is adjusted. Worse, it silently omits the conditions it could not represent, so an edge case renders at the wrong price with no error anywhere.
The alternative is to resolve price at the moment of display by calling the ERP through the integration layer, so the storefront asks rather than remembers. That keeps a single pricing authority and removes the reconciliation issue entirely.
Customer-specific pricing resolved in real time
The suppliers least likely to attempt this are the ones whose contract terms sit in a decades-old ERP, on the assumption that a system that age cannot answer a webshop while a buyer waits. Leeuwerik Plaat is a Dutch supplier of sheet materials, over a hundred years in business, running a 20,000 square meter warehouse and more than 3,000 products for trade customers. Its buyers order against contract terms, which makes accurate pricing a condition of the webshop being usable at all.
Leeuwerik connected its Kerridge ERP to Adobe Commerce through the Alumio iPaaS, exchanging products, stock, customers, deliveries, orders, and customer-specific pricing in real time. Trade customers can now order around the clock with live pricing visibility, rather than during office hours against a figure someone confirmed by phone.
The starting point is what makes it useful. This was a legacy supplier with an established ERP and no appetite to replace it, closing the gap between its systems and its customers by connecting them rather than rebuilding.
How an integration platform serves a B2B storefront
A B2B storefront has to do two things at once: ask the ERP a question and get an answer while the buyer waits, and push a completed order back the other way. The Alumio iPaaS sits between the storefront and the systems that own those answers, handling both directions. Synchronous calls resolve price and availability at the moment a buyer views a product, so the figure shown is the figure the ERP holds.
Event-driven flows carry the traffic going the other way. An order placed on the webshop appears in the ERP immediately, and its shipping status returns to the buyer's account without anyone rekeying it. Transformers handle the structural mismatch between a commerce order and an ERP sales order. That includes the customer, contract, and tax references the ERP requires and the storefront does not natively hold.
The same layer accepts orders arriving by EDI from larger buyers, which is how order history stays complete across channels rather than showing only what came through the web. Logging records every exchange, so a pricing query has an answer rather than an investigation. This pattern is common across B2B distribution, where the ERP is authoritative and the storefront is one of several channels reading from it.
Choosing B2B e-commerce features by what they depend on
The practical way to evaluate a B2B roadmap is to take each proposed feature and ask which system owns the data behind it and how current that data has to be. Features whose data lives in the storefront are quick. Features that depend on ERP or warehouse data are integration work, regardless of whether the platform lists them as supported.
Sequencing follows from that. Get pricing and availability resolving live before adding quoting, punchout, or approval workflows, because those later features inherit whatever accuracy the first two established. Building them on a stale price table means rebuilding them later.
Suppliers who work this way end up with fewer features and more usage, because the ones they ship are the ones buyers trust enough to stop phoning about.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
