Key points
- You launch with a pilot on a narrow group of customers and widen the rollout against quality criteria, not after a planned number of weeks.
- Four measures are enough to start with: the share of orders placed by customers themselves, order handling time, the number of corrections, and repeat rate, meaning how many customers came back for a second and third order.
- Low adoption almost never means unwillingness. It means friction at a specific step, so you look for where people drop out instead of adding features.
- What you build next should follow signals from real usage and support questions, not a wish list drawn up before launch. Platforms age through data and process faster than through code.
Customers have accounts that are ready, your reps know what changes in their job and how commission is calculated, and the rules were announced before the first invitation went out. What remains is the launch, and this is where the last expensive mistake is easiest to make: treating go-live as a date rather than a sequence. A B2B platform is not "handed over" on a Friday afternoon. It enters the business gradually, customer by customer, and for the first few weeks it is a set of hypotheses waiting to be tested. This chapter is about running that sequence, telling whether it works, and what to do with the platform over the next two years so it does not become another system nobody enjoys opening.
A pilot instead of launching to everyone
A pilot is not a cautious ritual, it is the only window in which a mistake is cheap. You take a narrow group of customers chosen on the criteria from the previous chapter, ideally served by one or two reps, and for a few weeks you run their orders through both the old and the new channel. Every platform order gets checked by hand before it goes further: is the price right, is the unit right, does the document in the ERP look the way it always has. That is tedious and deliberate, because the first twenty orders will tell you more about the platform than every test you ran before launch.
The exit criterion for a pilot is qualitative, not calendar-based. You widen the rollout once two full ordering cycles have passed without a new blocking error and your pilot customers have placed a second and third order without help from a rep. Only then do you add the next group, preferably with a different ordering profile from the first, because that group will expose what a homogeneous sample hid. What such a sequence looks like in practice, broken into stages and decisions, we set out separately in the piece on wholesale digitisation in 90 days.
Four measures from week one
Set your measures before launch, because without a baseline from the period before the platform every number later becomes a matter of interpretation. You do not need elaborate analytics, four indicators and a regular review rhythm will do. The first three describe the process, the fourth tells you whether customers genuinely changed how they work.
| Measure | How to calculate it | What a bad result means |
|---|---|---|
| Share of orders placed by customers themselves | Count and value of platform orders against all orders from customers who have an account | Accounts exist but the process still runs on email: find the step where the path breaks |
| Order handling time | From arrival to confirmation in the ERP, measured separately for email and platform orders | No difference between channels means somebody is still retyping data by hand |
| Number of corrections and errors | Orders amended after submission, always with the reason recorded | A recurring reason points to a data or interface fault, not customer carelessness |
| Repeat rate | Share of customers who placed a second and third order after their first | One order followed by silence is the most common sign of friction, not of absent demand |
Four measures are enough at the start. Collect them from week one and compare against the period before go-live.
An account created is not adoption. Active accounts and login counts look good on a slide and say nothing about whether work has come off your service team. The only measure that shows that is the share of orders customers actually place, counted across the customers who were given access. The rest is activity, not outcome.
Read low adoption as friction, not reluctance
When the share of self-service orders stalls after a month, the first conclusion is usually "customers do not want it" or "the reps are not pushing it". That conclusion is usually wrong and always expensive, because it leads to pressure instead of repair. In practice you can nearly always point to a specific step where people drop out: a password that cannot be reset without a phone call, a search that fails to find a product by the code the customer uses, a cart that gets lost when the delivery address changes, missing availability information that makes people call anyway.
The diagnosis is cheap and non-technical. Call five customers who logged in once and never returned, and ask directly at what point they stopped. Go through recent support tickets and count which questions repeat, because every repeating question is friction nobody has named yet. Check your own side of the process too: if your service desk still accepts email orders from customers who have accounts, adoption will not move however good the platform is. Fixing one real friction usually beats a quarter spent adding features nobody asked for.
What to build second
The second wave of development should follow signals from usage rather than a wish list collected before launch. Four directions come up most often. Approvals, meaning a sign-off path on the customer side when the warehouse orders and purchasing authorises. Credit limits and a visible balance, so a customer knows how much they can order before accounting calls them. Configurators and made-to-order products, if you sell something that cannot be picked off a list. Further markets and languages, with everything that follows: separate price lists, units and documents. Alongside those sits service automation, meaning statuses, delivery notifications and documents delivered without a human in the loop, which is what takes work off the team fastest.
You set the order using two questions: how many customers does this feature affect, and how many hours a week does it take off the team. A feature requested by one large customer can be worth building, but then name it for what it is, a commercial decision about a specific account rather than platform development. The worst pattern is a backlog grown out of individual conversations, where a year later nobody remembers why an item is on it.
How not to feel a year old after twelve months
B2B platforms rarely age through code. They age through data and process: a price list nobody has reviewed in two years, discontinued products still on display, imported photos and descriptions, ERP changes nobody flagged in advance. Minimal maintenance has three parts. An owner inside the company, meaning one person accountable for the platform as a sales tool rather than as "the system". A review rhythm: measures and tickets monthly, backlog and direction quarterly. And a rule that every change in pricing, assortment and integrations has an agreed way of being reflected on the platform, instead of being discovered by a customer.
In our BEAM framework that split is built into the process: the Blueprint stage maps prices, processes and integrations before anything is built, so the scope of the first release follows facts rather than assumptions, while Maintenance & Growth covers what happens after go-live, meaning the measures, the next features and upkeep on a rhythm instead of in bursts. The naming matters less than the mechanism: without a single owner and a steady review cadence, any platform starts to look like a system "we implemented once" within a year or so.
The whole path in one paragraph
You start by asking whether the business is genuinely ready for a platform, because repetitive ordering and the cost of handling it by hand are the precondition, not the result. Then you cut the first release down to what can carry a real order from start to finish. You settle prices and commercial terms, because those, rather than the look of the catalog, decide whether a wholesale buyer trusts what they see. You integrate with the ERP wherever the data has to be single-sourced. You onboard customers and reps, remembering that this is an organizational change rather than an IT project. And you launch as a pilot, measuring the share of orders placed by customers themselves. One last thing no tool will handle: a platform will not replace the commercial relationship, and it will not fix a weak offer. If prices are unclear, availability unpredictable and service unreliable, a portal will show it faster and more plainly than email ever did. The purpose of a platform is narrower and quite specific: it takes repetitive orders off your reps so they can do the part software cannot do for them.
Questions
How long should a B2B platform pilot run?
Usually a few weeks, but the criterion matters more than the calendar. A sensible exit is two full ordering cycles without a new blocking error, plus second and third orders placed by pilot customers on their own. A pilot stretched beyond that point starts to cost you, because the team is running two channels in parallel for the same group of customers.
When should you switch off email and phone ordering?
Not at launch, and not as a technical decision. The conversation about limiting the old channel makes sense only once most of your repetitive customers order on their own because it is faster for them. Even then, keep a route open for exceptions: unusual orders, urgent ones, and customers whose cost of switching genuinely exceeds the benefit. Closing a channel is a commercial decision, and its effects show up in relationships before they show up in statistics.
What if the share of self-service orders is flat after three months?
Start with diagnosis, not with new features. Five calls to customers who logged in and never returned, a review of the questions that keep reaching support, and a check on whether your own team still accepts emails from customers who have accounts will explain most cases. Only if removing the friction changes nothing is it worth returning to the question from chapter one, namely whether this group of customers orders repetitively enough for a platform to give them any advantage at all.
