01 / Perimeter
Cluster: portals and the B2B channel
A B2B ordering portal, connected to your real data
A reseller who orders by email or WhatsApp creates work downstream: somebody interprets the request, checks availability, retypes the lot into the ERP. With a portal connected to the ERP the customer places the order themselves, on their own price list and against real stock, and it arrives already clean.
What the portal reads from the ERP
- Customer records
- Price lists per customer
- Discount rules
- Stock levels
- Order history
- Credit limits
- Payment status
- Products and variants
The portal is not a parallel archive: it reads from the systems where the data is decided. If the price list changes in the ERP, it changes in the portal — with nobody updating a file.
- Who it is for
- Manufacturers and distributors selling to resellers, agents or branches on differentiated price lists and terms.
- What I deliver
- The ordering portal and its connection to the ERP: price lists per customer, real stock, validation and the order coming back in.
- Indicative time
- An estimate, not a contractual commitment: six to twelve weeks, depending on the catalogue and the commercial rules to be reproduced.
- What it isn't
- It is not a consumer shop and I don't handle online payment: the portal reproduces the credit terms you already have with your customers.
02 / Diagnosis
The hidden cost of the order by email
Every order that arrives in free text has to be translated by somebody
The reseller writes «send me 12 of the big one». Somebody in the office works out what that means, checks, picks the code, verifies availability, applies the right discount and retypes it into the ERP. That somebody is the bottleneck of your channel.
The sales office works as a switchboard, not as a sales office
The calls asking whether an item is in stock, at what price and when it arrives take up the hours that should go into selling. They are legitimate questions the customer could answer for themselves, if they had access to the data.
The wrong price list is lost margin, not a clerical error
When customer-specific terms live in a file updated by hand, sooner or later somebody applies another customer's discount. You don't find it in the order: you find it in the margin at the end of the quarter.
Selling what you don't have costs more than not selling
Confirming an item that is out of stock means an apologetic phone call, a partial delivery and a customer who calls a competitor next time. A stock figure that is a day old is exactly how that happens.
Reordering should be the easy case, and instead it is as manual as the rest
Most of a reseller's orders look like their previous order. Without a history they can consult, every reorder is rebuilt from scratch by both sides.
Before and after, on the same channel
These are not results measured on clients: they are the process changes a portal connected to the ERP produces, described for what they are.
| Process | Before | After |
|---|---|---|
| Order from a reseller | Arrives by email or message, somebody interprets it and rewrites it in the ERP. | The customer enters it in the portal on their own price list, and it arrives already validated. |
| Checking availability | A call to the office, which looks in the ERP and calls back. | The stock figure is in the portal, read from the ERP at the moment of the request. |
| Prices and discounts | A file per customer, updated when somebody remembers. | The customer's price list is the one in the ERP, with no copy in between. |
| Reordering | The customer remembers what they took, the office rebuilds the lines. | A history they can consult and one-click reordering, without going through your office. |
| A customer on hold | The order comes in, and finance stops it afterwards. | Credit rules are applied while the order is being placed, not downstream. |
| Order status | The customer phones to find out whether it has shipped. | The status is in the portal, updated by the ERP. |
03 / Solution
An ordering channel on the real data
A portal that shows your data, not a copy of your data
Your customers should not have to phone to find out whether an item is in stock.
The difference between a useful portal and an online catalogue comes down to one thing: where it takes its data from. A portal exposing a catalogue loaded by hand is one more archive to maintain, and it drifts away from the ERP within weeks. A portal that reads price lists, stock, terms and history from the ERP at the moment the customer looks is instead a window onto the real data, and it adds work for nobody. The order that comes out of it does not need interpreting, because it was born inside the right constraints.
Flusso dei dati
The functions that usually earn their place
- Customer-specific price lists taken from the ERP, not from a file updated by hand
- Live stock availability, so nobody sells what isn't there
- Orders that enter the ERP already validated, with no re-keying
- Order history and one-click reordering for the reseller, without going through your office
- Credit limits and payment status applied at the moment the order is placed
- Product pages with technical documentation and safety data sheets the customer can download
- Access for agents placing orders on behalf of the customers assigned to them
- Order status and delivery documents visible to the reseller, updated by the ERP
04 / Specifications
What drives the complexity
The specifications of the portal
The complexity of a B2B portal is not in the design: it is in how many different commercial rules you have to reproduce, and in how clean the catalogue in your ERP is.
Access and visibility
- Who signs in
- Resellers, agents, branches. Each account sees its own price list and its own history, not anyone else's.
- Roles
- Several users for the same customer company, with the option to separate whoever builds the order from whoever confirms it.
- Agents
- An agent works for the customers assigned to them, with each one's price list and a separate history.
- Visible catalogue
- Can be limited by category, brand or territory, if your distribution agreements require it.
Data and prices
- Where they come from
- Read from the ERP at the moment of the request, not from a copy exported the night before.
- Price lists
- A reference list, customer and category discounts, promotions with a start and end date.
- Stock
- An exact quantity or a band of availability, depending on how much you want to expose.
- Catalogue
- Products, variants, units of measure, pack multiples, images and technical documentation.
The order
- Validation
- Codes that exist, minimum quantities and multiples, products no longer in the catalogue, credit limit exceeded.
- Into the ERP
- The order arrives already validated on codes, quantities and that customer's terms, ready for logistics.
- Payment
- The terms you already have with the customer stay as they are. The portal does not take payment: it shows the credit limit and the payment status.
- Reordering
- From history or from recurring lists, with a check that the products are still in the catalogue.
Running it
- Use on mobile
- The interface works on a phone: many orders are born on a shop floor or in a warehouse, not at a desk.
- If the ERP doesn't answer
- The portal stays readable and the order is queued: the customer is told the real state of things, not a false success.
- Code and infrastructure
- Source, documentation and credentials handed over and held in your name.
- Adoption
- We start with a few pilot resellers. The old channel stays open until the portal has proved itself.
Included in a B2B portal project
- Analysis of the real commercial rules, including the exceptions nobody has ever written down
- An architecture document with the data model and the integration towards the ERP
- Development of the portal, the integration and the validation, with code review done by me
- Handling of communication errors with the ERP and a queue for orders
- Launch with pilot resellers, with the previous channel still open
- Technical documentation, handover of code and credentials, and an agreed post-release support period
Not included, and I say so up front
- Selling to consumers and taking payment online: that is not the perimeter
- Producing photography and product copy: the portal shows what you have
- Cleaning up the catalogue in the ERP beyond what the portal needs, unless agreed separately
- Hosting and infrastructure, which stay in your name
- Extended training of the sales network beyond the launch material and the handover
- Any promise of more orders: it cannot be guaranteed and I don't make it
The layers an order passes through
05 / Route
From the catalogue to the first real orders
How you get to a portal in use
A B2B portal almost always fails for one reason: the resellers don't use it. That is why we start from a few pilot customers and from the most frequent use case, not from the complete catalogue.
- 01
Commercial analysis
I reconstruct the real rules: who buys on what terms, which exceptions exist and who decides them. It is the part that is usually written down nowhere.
- Cosa ricevi
- A document of the commercial rules and the edge cases to handle.
- Durata
- 1–2 weeks (estimate)
- 02
Architecture and integration
I define what the portal reads from the ERP, at what frequency, and how the order comes back. This is where we find out what the ERP really exposes.
- Cosa ricevi
- An architecture document, the data model and an integration plan.
- Durata
- 2–3 weeks (estimate)
- 03
Development in milestones
First the complete ordering path on a subset of the catalogue, then the secondary functions. At every delivery there is something a reseller can try.
- Cosa ricevi
- Milestones you can try in a test environment, one function at a time.
- Durata
- Varies by project
- 04
Pilot and release
We open it to a few chosen resellers, watch where they get stuck and fix it. The old channel stays live until the portal's numbers make it redundant.
- Cosa ricevi
- The portal in production, launch material, documentation and credentials handed over.
- Durata
- 2–4 weeks (estimate)
The item that moves these dates most is not the portal: it is the state of the catalogue in your ERP. Product codes used in two ways, units of measure implied rather than stated, items that were withdrawn but never marked as such — none of it matters while a person is interpreting the order, and all of it becomes visible the moment a customer looks at it directly. The minimum clean-up needed to launch is sized during the analysis, and it is the part worth starting before the development does.
06 / Frequently asked
The same ones I get on the phone
Questions about B2B ordering portals
Here are the answers to what nearly everyone asks in the first half hour. If yours is missing, write to me.
01What is the difference between a B2B portal and an online shop?
The audience and the rules. A B2B portal does not sell to consumers: it exposes to identified customers their own price list, their own terms and their own history, and it reproduces constraints that do not exist in consumer retail — minimum quantities, pack multiples, credit limits, a catalogue that differs by territory. I don't handle online payment: the payment terms stay the ones you have already agreed with your customers, and the portal shows them.
02Will my resellers actually use it?
Only if it suits them, not you. The two things that work are reordering from history, because it saves them time, and visible stock, because it saves them the phone call. That is why we start with a few pilot resellers and watch where they genuinely get stuck, with the previous channel still open. Anyone who switches off email and phone on launch day ends up with fewer orders and no data to explain why.
03Does the portal work if our ERP is on site?
Yes, and it is the most common case. Only the minimum necessary is exposed outwards, in a controlled way: the portal has no free access to the ERP, it asks only for the data it needs through a defined channel. The concrete options depend on what your ERP makes available and on the network you have, and they are settled during the analysis, before quoting.
04What happens if the ERP doesn't answer?
The portal stays readable with the last information available, declared as such, and the order is queued and sent when the ERP starts answering again. The principle is not to lie to the customer: better to say «order received, awaiting confirmation» than to confirm something that never reached its destination. Every attempt stays in the log.
05What does it cost, and how long does it take?
I have no price list: the cost depends on how many commercial rules have to be reproduced, on how clean the catalogue in your ERP is and on what the ERP exposes. As an estimate and not a commitment, six to twelve weeks from the analysis to the portal being in the hands of the first resellers. After the analysis you get a fixed figure for the project, not an open hourly rate.
06Our catalogue in the ERP is a mess. Is that a problem?
It is the most frequent problem, and it has to be faced first: a portal shows the customer exactly the disorder that is in the data. During the analysis we settle the minimum that must be fixed to launch — usually codes, units of measure and products no longer valid — and what can wait. A full clean-up of the history is a piece of work in its own right, and I say so before the project starts rather than after.
07Can agents order on behalf of customers?
Yes, and it is one of the most used functions. The agent signs in with their own account, picks from the customers assigned to them and works with that customer's price list and terms. The history stays separate per customer, so the reseller sees their own orders regardless of who entered them.
08Our resellers are in several countries. Does the portal handle currencies and languages?
Yes, and both are decided in the same place as everything else: in the ERP. Currency, price list and payment terms belong to the customer record, so a French reseller and a British one signing in to the same portal see their own currency because that is what their record says, not because the portal keeps a conversion table of its own. The interface language is a separate matter and is a choice: one language for everyone is cheaper and often enough for a technical catalogue, several languages means somebody on your side maintaining the product descriptions in each of them, which is usually the real cost. Tax treatment stays where it is calculated today, in the ERP: the portal shows it, it does not decide it.
07 / Related
Where to go next
Pages connected to this one
A portal is custom software built for your resellers, and it always sits on top of an integration. If your problem is further upstream, start here.
08 / Contact
Half an hour, no automated quotation
Tell me how your resellers order today
We spend half an hour: you tell me how the orders arrive today, how many people handle them and which commercial rules genuinely exist. I tell you whether a portal makes sense in your case, what is needed from your ERP and with what order of magnitude of spend. If it doesn't make sense, I say so straight away.
Or write to me: I answer, usually within one working day.
All the contact detailsHow the call works
- Length
- Thirty minutes, video call or phone, in English.
- Who is there
- Me. No salesperson, no handover afterwards.
- What I need
- To know how many resellers you have, how they order today and which ERP you run.
- What you get
- An honest view on feasibility, on the rules to reproduce and on the order of magnitude.