B2B e-commerce: how to manage resellers, price lists, and reorders

A B2B e-commerce site isn't an online store with a discount applied to a group of customers. A reseller doesn't need to be convinced to buy: they already know what they need, they know the codes, they often order the same things, and they want to do it in three minutes without calling. If the portal is slower than the phone call, they go back to the phone call. This guide helps you design the three things that decide whether they'll use it: who gets in and what they see, on what terms they buy, and how short the path to reordering is.

Who gets in, what they see, who decides

In B2B, registration isn't a form that immediately unlocks the catalog. It's an approval request that someone reviews, because the price depends on the customer.

• An unrecognized visitor sees the technical catalog without prices, or doesn't see it at all: it depends on how much it's worth to you for the products to be findable online.
• Whoever registers fills out a short request — company name, VAT number, contact person, area — and waits. The page needs to say that approval requires a review, otherwise it looks like a malfunction.
• Whoever approves is a person: they need to be able to link the request to the customer code that already exists in the business management system, because that's where the price list is attached.

The point to watch closely is the wait. A reseller who registers in the evening and hears nothing for two days has already called the sales rep. Whoever approves needs to receive a notification and treat it as a daily task, not a weekly one.

Inside the customer's company, people aren't interchangeable: the person who fills the cart is often not the one who can commit the spend, and the owner wants to see the order history without having to ask for it. Three roles cover almost every case — whoever fills the cart, whoever confirms, whoever checks documents and history. Adding more before you've seen how the customers actually work is time poorly spent.

Price lists, minimums, and agreed terms

This is the part where projects get complicated, because the real terms almost never live in one place: part in the business management system, part in an email agreement, part in the sales rep's head.

• Decide what the official source of the price is. If it's the business management system, the portal reads it and doesn't recalculate it; if the portal keeps its own table, sooner or later the two numbers will diverge, and the customer will see the wrong one.
• Quantity tiers and minimums need to be shown while ordering, not discovered at confirmation. "Minimum order not reached" appearing at the end is the most common reason for cart abandonment in an order portal.
• Personal terms — agreed discount, payment terms, free-shipping threshold — need to be visible to the customer. Whoever doesn't find what they agreed to on screen calls to verify, and the portal hasn't saved them anything.
• Time-limited promotions and net prices on individual items are the primary source of exceptions: establish how they're recorded and who can enter them, before launching.

Reordering is the feature that decides adoption

Someone buying for work repeats. The difference between a portal that's used and one that's abandoned is almost never in the catalog: it's in how many steps it takes to rebuy the usual things.

• Quick entry by code: a box to type in code and quantity, row after row, without going through product pages. Whoever knows the codes is your best customer.
• Uploading a list: pasting or importing a list of codes and quantities prepared elsewhere, because many resellers prepare their order on a spreadsheet.
• Repeating a previous order from the history, with quantities editable before confirming.
• Personal lists of regular items, with the customer's internal name shown next to your code. It's a small detail that saves time every time.

Keep search forgiving: if searching the same code with or without a hyphen produces different results, the reseller concludes the item isn't available.

An illustrative journey

A components manufacturer opens the portal to its resellers. The journey, from first access to second order, is illustrative but typical.

1. The reseller requests approval from the site and receives a message confirming the request has arrived and announcing it will be reviewed.
2. The sales office links it to the existing customer code and the already agreed price list.
3. On their first login, the reseller finds their own prices, the agreed payment terms, and the history of orders placed so far by phone, imported from the business management system. This is the moment that wins them over: the portal already knows who they are.
4. They prepare the order by code, see the cart approaching the free-shipping threshold, and add two more items.
5. They receive an acknowledgment of receipt, not an order confirmation: quantities and timing still need to be verified. The final confirmation arrives after the availability check.
6. The following month, they reorder in two minutes from the history. From here on, the portal has stopped being a project and has become a tool.

Availability and confirmation: what not to promise

Availability is the point where a B2B portal loses credibility fastest. A visible, wrong number does more damage than a missing one.

• If stock levels aren't reliable in real time, show a qualitative indication — in stock, incoming, made to order — instead of an exact quantity.
• Distinguish physical stock from sellable stock: material already committed to other orders isn't available, even if it's in the warehouse.
• Separate order receipt from order confirmation. In B2B, confirmation involves commitments on quantity, prices, and timing: in many cases it remains a business decision.

Whoever handles the order needs to be able to modify it and communicate the change inside the portal, not with an email that gets lost. The history needs to show what was requested and what was confirmed.

When an order portal isn't worth it

The portal doesn't solve anything if the problem is upstream.

• If there are few customers and they order rarely, the sales rep is faster and more useful: the portal would add a step without removing any.
• If prices can't be reconstructed from any system, the data needs to be put in order first.
• If every order requires advice — measurements, compatibility, customizations — the right path isn't the cart but a structured request.

There's a middle path, often the best one: open the private area first, with documents, history, and availability, without selling. You immediately see how many customers use it, and you find out what they actually ask for, before building the cart.

What this guide doesn't cover

This guide covers designing sales to already-business customers, with their own terms. The upstream choice — whether your case calls for a browsable catalog, a quote request, or a direct purchase — is an earlier decision with its own guide. Syncing stock between the warehouse and the online store, mentioned here only for its effect on trust, is covered elsewhere too.