B2B Portal Implementation Step by Step — 12 Days to Build, Four Weeks to Migrate
A B2B portal is one of the few software projects in a wholesale business where the build is the easy half. Twelve working days from kickoff to a portal taking real orders is a schedule you can hold to, because the work is well understood: a catalogue, accounts, a pricing engine, an ERP connection.
Then the portal goes live and eighty-five customers carry on phoning.
That's the part that decides whether the project was worth doing, and it's the part almost nobody schedules. So this is the whole implementation, both halves — the twelve days of build and the four weeks of migration that follow, in the order they actually happen.
Four decisions to make before day one
The workshop on day one goes badly when these are still open. Settle them in the week before, when nobody is billing you by the day.
Who grants ERP access, and on what environment. This is the item that slips projects, and it's almost never technical. Whether you run enova365, Optima or Subiekt changes the connector, not the timeline; what changes the timeline is a hosting setup where nothing outside the office can reach the ERP, or a vendor relationship where credentials need three signatures. Ask the question now.
Where prices come from. In most wholesale businesses, the answer is "the ERP, mostly, except for the twelve customers with arrangements that live in the sales director's head." Those twelve are the project. Either the arrangements get encoded into the ERP before the portal reads them, or the portal shows the wrong price to your best customers on day one.
How much of the catalogue goes in. Not all of it, usually. The portal needs the SKUs that customers actually reorder, with clean descriptions and a photo — not the long tail nobody has bought since 2023. Trimming the catalogue is a day of work for someone in your team, and it can happen in parallel with the build.
What "working" means numerically. Agree the number before anyone writes code. Not "faster ordering" — a share of orders arriving through the portal by a stated week, measured on your data. Without it, the go-live conversation becomes a matter of opinion.
Days 1–2: the workshop, and why shortening it costs you later
Two days with the owner and the sales manager, going through how orders actually get taken today — including the exceptions everyone has stopped noticing. The customer who orders in cartons while the ERP thinks in bottles. The standing 3% that one client gets on Fridays. The two customers who are technically one company.
Alongside it: ERP access gets configured and product data gets exported for the first time. That first export is diagnostic in itself. If the descriptions are inconsistent or half the SKUs lack units, you've found a data cleanup task that is far cheaper to discover on day two than on day eleven.
Days 3–7: the build
Catalogue, customer accounts, admin panel, and the piece that carries the most business risk — the pricing engine.
Per-customer pricing is where a wholesale portal differs from a webshop. Every customer sees their own negotiated prices, synchronised from the ERP: customer A sees beer X at 3.20 zł a unit, customer B at 3.05, customer C at 3.35, exactly as their contract says. No "sorry, I quoted you wrong." If your discount structure has tiers, promotions and per-category exceptions stacked on each other, this is the part of the build to spend the extra day on.
Any regulated category adds work here too — an alcohol wholesaler needs age verification and excise-compliant product data before it can take a single order, and that isn't a feature you bolt on afterwards.
Days 8–10: ERP integration
Three days: connecting the API, mapping the data, and testing the order flow end to end — placed in the portal, imported into the ERP, confirmed back to the customer.
The mapping is the fiddly part and it's worth naming what it involves: SKUs to portal products, customer accounts to ERP contractors, units of measure, VAT rates, payment terms, credit limits. Every one of these has an edge case in a business that has been trading for fifteen years.
Two settings that matter more than they look. Stock sync interval — the rollout I keep referring to started at 30 minutes and had three customers order out-of-stock items in the first week; dropping to 10 minutes ended it. Order status write-back — the customer needs to see that the order landed, or they will phone to check, which defeats the entire point.
Build the ERP coupling as one isolated module. When your vendor ships a version bump, you want to revalidate one component rather than the whole portal.
Days 11–12: test with real orders
Not test data. Take three or four genuine orders from the past week, place them through the portal, and check they arrive in the ERP identically to how they were entered by hand — same prices, same discounts, same units, same document.
This is also when the sales team sees the admin panel for the first time and asks for the two changes that always come up: seeing an order before it hits the ERP, and being able to place an order on behalf of a customer over the phone. Both are small if they're built now.
Then the part nobody plans: four weeks of migration
Nobody made eighty-five customers switch overnight. It went in waves, and the sequencing was the whole trick.
Week 1 — the 20 who were ready. The ones already ordering by email and planning purchases in a spreadsheet. 18 of 20 placed an order within 48 hours and not one called for help. That's what starting with the right group buys you: a first week where the portal looks like it works, which is what the sales team needs to believe before they sell it to anyone else.
Week 2 — the next 30, with a phone call each. Here the approach changed. A salesperson called every customer, walked them through the portal in five minutes and placed the first order together with them. Those five minutes per customer were worth it: customers left alone with a login and a password frequently gave up after one attempt and went back to email. Self-service is what the portal becomes; it is not how people get onto it.
Weeks 3–4 — the remaining 35. Same phone-call approach, less urgency, more repetition. By the end of the month the portal was carrying 70% of all orders.
What breaks in the first month
Three things, all cheap to fix if you're watching for them.
Stock sync too infrequent, as above — set it tighter than feels necessary and relax it later.
Mobile treated as secondary. A meaningful share of reorders get placed from a phone, often by someone standing in their own warehouse. If the portal is usable but awkward on a phone, adoption stalls in exactly the group you most want to convert.
The 15% who never move. Older owners who prefer the phone, and that's the end of it. Keep one person on phone duty, accept that 100% adoption was never the target, and note that this residue is precisely the volume an email intake agent picks up later — as one step in a longer sequence rather than an argument with your customers.
What the schedule looks like written down
Twelve working days of build. Four weeks of migration in three waves. One number, agreed in advance, checked at week six.
Two things follow from writing it that way. The first is that the budget conversation gets easier, because what a portal costs is far less interesting than what it costs per week of delay — three full-time people retyping orders is a payroll line that runs whether the portal exists or not. The second is that the migration gets an owner. A portal without someone responsible for making eighty-five phone calls is a portal that goes live and stays empty, which is the most expensive outcome available: you paid for the build and collected none of the return.
I build B2B portals and order-intake agents for Polish wholesalers — catalogue and per-customer pricing wired into enova365, Optima, Subiekt or whatever you run, plus the email intake that handles the customers who never migrate. If you want a realistic schedule for your catalogue and customer base, get in touch — the scoping conversation is free and takes half an hour.
Let’s talk about your project
Free 30-minute consultation. We’ll figure out if and how I can help.



