A B2B e-commerce portal differs from a consumer store in its account model rather than its cart. Buyers are organisations with negotiated prices, credit terms, multiple users, approval chains and purchase orders. Marketplace models add a second population of sellers with their own catalogues, payouts and disputes. Both are account problems before they are commerce problems.
Standard platforms handle account-level pricing adequately and struggle with approval hierarchies, contract pricing and ERP-driven availability. Test those three against your real rules before committing.
Key takeaways
- The account is the customer: Multi-user organisations with roles and spending limits, not individual shoppers.
- Reordering beats discovery: B2B buyers mostly repurchase, so history and lists matter more than browsing.
- Approval chains are commerce logic: A cart that cannot wait for authorisation does not fit how businesses buy.
- Marketplaces are two products plus settlement: Which is why they take six to twelve months rather than three.
Model the buying organisation first
Write down how your customers are actually structured before evaluating anything. A B2B account typically involves several users at different permission levels, a spending limit per user, an approver, and sometimes a parent organisation with oversight across subsidiaries.
Add the awkward cases: a reseller ordering on behalf of a client, a delegated administrator who can add colleagues, a site that can order but not see pricing, a finance user who sees invoices but places no orders.
This structure decides whether a standard platform will fit. Feature comparisons rarely decide it, because almost every product does catalogue and checkout well enough.
Build the four capabilities B2B actually needs
Accounts covers users, roles, permissions, spending limits and the organisation hierarchy above them.
Quotes matters wherever prices are negotiated. Buyers request, you respond, they approve, and the agreed price flows into an order without re-keying.
Orders includes purchase order references, approval routing, reordering from history, saved lists and scheduled repeat orders. Reordering is the most-used feature in most B2B portals and frequently the least designed.
Service is invoices, statements, credit position, returns and the ability to see order status without phoning anyone.
Design pricing as a rules problem
B2B pricing is rarely a single number. It is contract prices per customer, volume breaks, product-group discounts, promotional overrides and currency variations, with a defined order of precedence.
Write that precedence down explicitly, including what happens when two rules could apply. This is the area where standard platforms most often stop, and where the workaround — staff manually adjusting orders after they are placed — quietly consumes the savings the portal was meant to deliver.
Decide also who may see price. Some organisations deliberately hide pricing from ordering users, and a platform that assumes price is public cannot express that.
Treat approval as part of the purchase flow
In many organisations a cart becomes a request, not an order. It waits for an approver who may be on leave, may partially approve, or may need a purchase order number first.
Define what the buyer sees while waiting, who is notified and how quickly, whether the submitter can still amend, what happens on rejection, and how stock or pricing is treated during the wait. Unhandled approver absence is a common reason organisations abandon a portal and revert to email.
Understand marketplace mechanics before choosing that model
A marketplace makes sense when supply is genuinely fragmented, when neither side can easily find the other, and when you can solve the empty-marketplace problem for one side before launch.
It adds seller onboarding and verification, per-seller catalogues and pricing, split payments and payouts, commission handling, disputes across two parties, and moderation. Payouts are the most underestimated piece, and handling other people's money directly carries licensing obligations in most jurisdictions — which is why settlement is normally handled through a provider supporting split payments and delayed release.
Expect six to twelve months for a credible first version. A marketplace is two products plus a settlement system, which is why it takes longer than a comparable single-sided store.
Seed one side manually, even unprofitably, before opening the other. Marketplaces that launch to both sides at once usually satisfy neither.
Connect to the systems that hold the truth
B2B commerce depends more heavily on back-end integration than consumer commerce does. Stock availability, contract pricing, credit status and order history typically live in an ERP, and the portal is a window onto them rather than the system of record.
Name the source of truth for each, define what happens when that system is slow or unavailable, and decide whether the portal may accept an order it cannot immediately validate. Answering that last question badly produces either lost orders or promises you cannot keep.
Measure reorder rate, not traffic
The useful measures are share of orders placed through the portal rather than by phone or email, reorder rate, average time from order to approval, and the volume of support contact about status.
Traffic is close to meaningless here, because your buyers are a known and finite population. What matters is how many of them have moved their ordering into the system, and that number tells you whether the portal fits how they actually work.
Related guides
Related reading:
- E-Commerce App Development: A Practical Planning Guide
- Inventory Management System: Features, Workflows, and KPIs
- Payment Integration Planning: Questions to Ask Before Development
If the work prompted by B2B E-Commerce Portal Development: Workflows Beyond the Cart leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Commerce Platform.
Ali Boran Gazel