A B2B ordering portal for your distributors: what actually needs to be in it

If you manufacture in one country and sell through distributors in several others, your order intake probably looks like this: email, WhatsApp, PDF purchase orders, a spreadsheet attachment from the large customer who has done it that way since 2018, and a phone call from the one who never writes anything down.

Someone on your side transcribes all of it into the ERP. That person is the bottleneck, the error source and the single point of failure when they take leave.

A distributor portal is the standard fix. It is also frequently over-scoped into a two-year project that never ships. This guide is about what belongs in the first release and what does not.

What a B2B portal is not

It is not a webshop with a password. The differences are structural, and getting them wrong produces a portal distributors politely ignore.

Aspect	Consumer e-commerce	B2B distributor portal
Buyer intent	Discovery, browsing, persuasion	Knows the code, wants it in the basket
Pricing	One public price	Per-account price list, per-account currency
Order shape	Small basket, one shipment	Many lines, partial shipments, schedules
Payment	Card at checkout	Credit terms, limits, existing balance
Stock	In stock / out of stock	Quantity, location, incoming with dates
Repeat behaviour	Occasional	Weekly, largely the same lines
Success metric	Conversion rate	Seconds per order, error rate

The last row is the one to hold onto. You are not trying to persuade anyone to buy. You are trying to make placing an order faster than writing an email. That is the whole adoption mechanism.

The first release: five things

Ship these, and nothing else, in the first four to six weeks.

1. Authenticated accounts with correct scoping. A distributor sees their own prices, their own orders, their own documents. Nothing else. Multiple users per distributor with different permissions — the person who places orders is often not the person who approves credit.

2. Their price list, in their currency. Assigned per account, pulled from the ERP, with contractual discounts already applied. Never a public price with a discount calculated in the browser.

3. Live stock and lead time. Read from the system of record. Show quantity available now and quantity incoming with dates. Be honest — an optimistic availability figure destroys trust faster than an inconvenient accurate one.

4. Fast order entry, three ways. Reorder from history in one click. Bulk entry by product code with quantity. Paste from a spreadsheet, because your largest customers will do that anyway and it is better inside the portal than in your inbox.

5. Order status without asking anyone. Received, confirmed, in production, shipped, with tracking. This eliminates the second largest category of inbound email after availability questions.

That is a complete, useful product. On our published bands it sits at $3,000–6,000 over 2–4 weeks with a clickable prototype inside the first two weeks; the table is on the pricing page.

The second release: what to add once it is used

Only after the order path is genuinely in daily use.

• Documents per order. Invoices, packing lists, certificates of origin, test certificates, conformity declarations. Distributors chase these constantly, and self-service removes an entire correspondence stream.
• Claims and returns with photo upload and a status trail. Currently the least structured process in most export businesses.
• Credit position. Balance, limit, overdue items. Uncomfortable to expose and remarkably effective at improving payment behaviour.
• Forecasting. Distributors enter expected volumes; you plan production against them. Valuable, and dependent on trust you have not built yet in release one.
• Marketing and technical assets. Images, drawings, manuals, translated datasheets. Low effort, and it removes a steady trickle of requests.
• Compliance document packs. Increasingly relevant given EU requirements on traceability and product data — see EU export compliance for what those now demand.

The traps specific to exporting

Currency. Decide early where conversion happens and never convert twice. Store the order in the transaction currency with the rate and its date. Display in the distributor’s currency. Post to the ERP in yours. Rounding differences that appear at line level compound into invoice disputes.

Language. The interface should be in the distributor’s language; product descriptions are a separate problem. Half-translated portals are worse than English-only ones, because users cannot tell which parts they can rely on. If you cannot translate the product data properly, do not translate the interface halfway either.

Units and pack sizes. A distributor orders in cases; your ERP holds pieces. The conversion belongs in one place, defined per product, and applied consistently. This is a routine and surprisingly frequent source of ten-fold ordering errors.

Incoterms and delivery. Different terms per account, affecting what is quoted and who arranges freight. Get this into the data model early rather than bolting it on.

Tax and invoicing. Destination rules increasingly demand structured electronic invoices — see Gulf e-invoicing for the Saudi and UAE mandates. The portal does not have to solve this, but the data it captures should not make solving it harder later.

Minimum order quantities and container logic. If you ship in full containers, a portal that lets a distributor order 40% of one is generating work, not removing it.

Integration: the part that determines whether it is believed

A portal showing stale data gets used twice.

• Read live from the ERP for stock, prices, credit and order status. Cache for seconds, not hours, and show the timestamp.
• Write orders back, initially into a review queue a human confirms. Move to automatic once the error rate is known and low.
• One identifier per entity, shared between portal and ERP. Do not let the portal invent its own customer or product codes.
• Handle the ERP being unavailable. Queue the order, tell the user it is received, reconcile when the connection returns. Never lose an order because an interface timed out.

Our approach to connecting existing systems is on the integrations page, and the portal scope in more detail on the dealer portal page.

A rollout that gets adoption

1. Pick three distributors, not thirty. One enthusiast, one sceptic, one large. The sceptic gives you the most useful feedback.
2. Migrate their order history in first. A portal with an empty history has no reorder function, which is the feature that makes it faster than email.
3. Sit with one of them while they place a real order. Watch, do not explain. Every hesitation is a design defect.
4. Time it. If a repeat order takes more than about a minute, fix that before adding anything else.
5. Keep accepting email orders during the pilot. Forcing adoption before the portal is faster produces resentment and a permanent reputation.
6. Then make it the default, once it is genuinely quicker. Announce a date, and give the largest accounts individual help.
7. Measure the right thing. Share of orders arriving through the portal, and inbound emails about availability and status. Those two numbers tell you whether it worked.

Measuring whether it worked

Portals get judged on impressions. Four numbers make the judgement objective, and all four are cheap to collect if you decide to collect them before launch rather than after.

Metric	Why it matters	What good looks like
Share of order lines placed through the portal	The only real adoption measure	Rising each month, by account
Seconds from login to submitted order	Determines whether email wins	Under a minute for a repeat order
Inbound emails asking about stock or order status	The cost the portal was built to remove	Falling sharply within two months
Order entry error rate	The second cost it removes	Near zero on portal orders

Take a baseline for all four before launch. Without one you will be arguing about whether things improved, which is a conversation nobody wins.

One warning about the first metric: measure it per account, not in aggregate. A single large distributor adopting can hide the fact that everyone else ignored it, and the accounts that ignored it are the ones carrying the information you need.

What distributors will ask for that you should refuse, at least at first

Distributors are your customers and their requests deserve respect. Some of them still belong in release four rather than release one.

• “Can we have our own branded version?” Reasonable eventually, and a multiplier on every subsequent change. Not in release one.
• “Can it integrate with our system?” Genuinely valuable for your largest accounts, and it is a separate project per account. Offer a documented file exchange or API rather than a bespoke integration, and see who actually uses it.
• “Can we see other distributors’ pricing to check we are competitive?” No. Ever.
• “Can we place orders against stock that has not arrived yet?” Sometimes correct, and it needs allocation rules first, or you will promise the same incoming pallet to three people.
• “Can we edit an order after submission?” Up to a defined point in your process, and the definition has to be technical, not social. “Until it is picked” is a rule. “If you call us quickly” is not, and it is how order-entry errors return through a different door.

Saying no to these in release one is not obstruction. It is what makes release one exist.

What to resist in release one

Chat widgets, loyalty schemes, configurators, dashboards for the distributor, mobile apps, and anything described as “a platform”. Each is defensible in isolation and each delays the order path, which is the only part that pays for the project.

Further reading: export manufacturers covers the wider scenario, who we build for the segments we work with, the delivery bands are on the pricing page, and a portal can be scoped through the quote form.

For the integration mechanics — how orders are written into SAP Business One or Business Central, and the API rate limits that shape the design — see the integration guide.

Frequently asked questions

Is a B2B portal just an e-commerce site with a login?

No, and treating it as one is the usual mistake. Consumer commerce optimises for discovery and impulse. B2B ordering optimises for speed and accuracy on repeat purchases by people who already know exactly what they want. Reorder from history, bulk entry by product code and a clear stock position matter far more than product photography.

What is the single highest-value feature?

Live, honest stock and lead-time visibility. Most of the email traffic between a manufacturer and its distributors is availability questions. Answering them in the portal removes a large share of inbound messages and simultaneously reduces orders placed against stock that is not there.

How do we handle different prices for different distributors?

Price lists assigned per account, in the account's currency, with contractual discounts applied automatically and never visible across accounts. This must be in the first release. Distributors compare notes, and a pricing leak is a commercial incident, not a bug.

Should the portal connect to our ERP from day one?

Read from it from day one — stock, prices and order status must come from the system of record, not a copy. Writing orders back can start as a reviewed queue and become automatic once you trust it. Building the portal on duplicated data is what makes portals stop being believed.

Do distributors actually use these portals?

They use them when the portal is faster than sending an email, and ignore them when it is not. That is the entire adoption question. If placing a repeat order takes more than about a minute, your team will keep receiving spreadsheets.

What does it cost and how long does it take?

On our published bands, a focused portal covering the order path runs $3,000–6,000 over 2–4 weeks, with a clickable prototype in the first two weeks. Expanding into claims, forecasting, document packs and analytics moves it into the $8,000–15,000 band over 4–8 weeks.

Related guides

• Gulf e-invoicing: what ZATCA and the UAE mandate actually require from your systems
• Automating repetitive back-office tasks: a practical method
• Email triage automation for shared inboxes

Service page: Custom software service