The B2B self-service portal your customers actually want
B2B buyers are not asking for a prettier shop. They are asking to stop phoning your sales rep to find out where their delivery is. What that actually requires, and what to build first.
Photo: free stock photography (Unsplash licence) — see imprint
Your buyers do not want a nicer shop — they want to stop calling your sales rep
Ask a B2B customer what they want from your website and you will get a polite answer about search and images. Ask them instead what they phoned you about last month, and the real list appears: where is order 4412, can I get the delivery note for the pallet that arrived Tuesday, what did we pay for this last time, is the 25-metre roll actually in stock or is that the website being optimistic. Every one of those calls is your customer doing unpaid work because your site could not answer.
This is why so many B2B shop projects land with a thud. The company spends a year on a beautiful storefront, the buyers log in twice, and the phone rings exactly as often as before. The storefront was never the problem. The problem is that the buyer's procurement process — approve, order, receive, check the invoice, reorder — runs through your sales desk, and a shop with a login does not change that. A portal does, or it is not a portal.
Order history in your numbers is not order history
Almost every B2B shop has an order history page, and almost none of it is useful. It lists your order numbers, your product names and the date you shipped. The buyer is looking at a different world: their purchase order number, their internal article number, their cost centre, the project the material was for. When those two lists do not line up, the buyer cannot match a delivery to a PO without opening their ERP, at which point they might as well have phoned you.
Carrying the customer's reference through the whole chain is unglamorous and it is the feature that makes the rest work. Take their PO number at order time, print it on the delivery note and the invoice, show it in the history, and let them search by it. Do the same for their article numbers if they have them. It is a data-modelling job, not a design job, and it is worth more than any redesign you could buy for the same money.
People reorder from deliveries, not from catalogues
In B2C, browsing is the point. In B2B, browsing is a failure state — the buyer already knows what they need, because they bought it in March and it worked. The most valuable button in a B2B portal is not on the product page. It is on a past delivery, and it says 'order these again'. From a delivery note, from an invoice, from a list of everything this site consumed last quarter.
This changes what you build. Search matters less than a good filter over the customer's own past. Recommendations matter less than a saved list the buyer maintains themselves. And a stock figure only helps if it is the truth for this customer at their price and their delivery terms — a generic 'in stock' that turns out to mean 'in stock for someone with a different contract' costs you more credibility than showing nothing at all.
Roles are what turn a login into a portal
A B2B customer is not a person, it is an organisation with an internal rulebook. The person who knows which part is needed is rarely the person allowed to commit the money. Today that rulebook lives outside your shop: the foreman writes a list, the office manager types it into an email, someone signs it, your rep enters the order. Every step is a place your order can die quietly.
Move that rulebook inside and the portal starts doing real work: a requester who can build a basket but not release it, an approver who gets it in one click, a budget per cost centre, an audit trail the customer's finance team can accept. This is also the feature that makes a portal hard to leave — not because you locked anyone in, but because their process now lives in it. That is a far stronger position than a good price.
What to build first, and what to leave for later
Build in the order of the phone calls. Count them for two weeks — a tally sheet at the sales desk is enough — and you will have your roadmap, ranked by the thing that costs you most today. It is almost never search. It is almost always status, documents and reordering, in that order, and those three are cheap compared to the portal features that get pitched in workshops.
- Order status the customer can read without translation into your numbering.
- Delivery notes and invoices as downloads, searchable by the customer's own reference.
- Reorder from any past delivery in one click, with quantities pre-filled.
- Stock and price that are true for this customer's contract, or no number at all.
- Requester and approver roles, once you actually have customers asking for them.
| Feature | The call it removes | Hard part | Build order |
|---|---|---|---|
| Order status | 'Where is 4412?' | Live data out of the ERP, not last night's export | First |
| Documents | 'Can you resend the delivery note?' | Archiving and access rules per user | First |
| Reorder from delivery | 'Same as last time, please' | Discontinued and replaced articles | Second |
| Customer-specific stock | 'Is that really available for us?' | Reservations, contracts, honesty about lead times | Second |
| Roles and budgets | 'We need a quote to get it approved' | Every customer approves differently | When asked for |
- A shop with a login is not a portal — a portal answers the questions that generate your phone calls.
- Order history in your numbering is decoration; carry the customer's reference through every document.
- In B2B the most valuable button sits on a past delivery, not on a product page.
- Two weeks of tallying calls at the sales desk beats any feature workshop as a roadmap.
Frequently asked questions
A shop sells; a portal handles the whole relationship after the sale. Order status, delivery notes, invoices, reordering, roles and approvals all live in a portal, and most of them have nothing to do with a product page. If your customer still has to call for a document or a status, you have a shop with a login, whatever the project was called.
Maybe not. If you have thirty customers, a rep who knows all of them and no growth plan that adds a hundred more, a portal is an expensive way to remove a job you are happy doing. The case turns when your sales team spends its day retyping orders and answering status questions instead of selling. Count the calls before you count the budget.
The portal features are rarely the driver. The cost sits in the integration: getting live order status, documents and customer-specific pricing out of an ERP that was never asked to expose them. A first stage of status plus documents is a contained project of a few months. Roles, budgets and approvals across many customers with different rulebooks are a different order of magnitude.
Only if the number is true for that customer. B2B availability depends on contracts, reservations and lead times, so a shared warehouse figure will be wrong for someone and they will find out at the worst moment. If you cannot compute it per customer yet, show a lead time you can defend instead. A conservative date you keep beats an optimistic number you break.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer