Key points
- The first release should handle the most common order from your best customer end to end, with no rescue by email in the middle, rather than every edge case from the past five years.
- Six essentials: an account with terms attached, a catalog with prices visible after login, fast reordering, order and document history, fulfilment statuses, units and case packs.
- Configurators, multi step approvals, multi branch structures and a mobile app are usually good features at the wrong time. Handle those cases outside the system and revisit them after launch.
- Pick the first customer group by order repeatability and tidy commercial terms, not by revenue. A handful to a dozen accounts is enough to find out what does not work.
The diagnosis from the previous chapter gives you a list of problems and four written answers. Now you have to cut a scope out of them, meaning decide what gets built first. This is where projects derail most often, and rarely for technical reasons. They derail because the team tries to reproduce everything a sales rep does today, including exceptions that occur twice a year. The result is a scope that cannot be closed and a B2B ordering portal that reaches production a year later than it should, still unfinished.
The scoping rule: the most common order from your best customer
Take a few accounts from your top ten and write out, step by step, what their typical order looks like. Not the most complicated one, the one that repeats every week or two. How many lines, which units, whether the customer uses their own part numbers, how they learn about availability, when they ask about price, what happens after the order is placed, which documents they need at the end. That single scenario is the measure of your first release: it has to work in full, from login to invoice, with no phone call or email rescuing it halfway through.
The acceptance criterion is equally simple and worth writing in one sentence: the customer places their typical order themselves, and that order reaches your company systems without anyone retyping it. Anything not needed for that sentence is a candidate for postponement. The exceptions do not disappear, they stay with the rep exactly as they are today, and that is fine. A first B2B store release is not there to eliminate manual handling, it is there to take the repeatable volume out of it. That distinction decides whether the project ends in a launch or in another round of analysis.
Six essentials of a first release
The six things below form the smallest scope that makes sense together. Each one serves a specific step in the scenario you wrote out, none of them is an optional extra. If one drops out, the customer reaches for the phone halfway through anyway, and the rest loses its point.
A customer account with terms attached
This is the foundation: the customer logs in and is recognised as a specific account, not as an anonymous visitor. The account carries their price list, currency, payment method and terms, delivery addresses and account manager. For the first release the simple variant is enough: several users on the customer side see the same thing and have the same rights. Splitting roles, budgets and visibility between people inside the customer organisation is a real need, but a rare one at launch, and it can double the build.
A catalog with prices visible after login
A wholesale catalog behaves differently from a retail one. Customers do not browse, they look for something specific, so search by item code, EAN and the customer own part number, where those exist, matters more than anything else. Filters should follow technical parameters rather than inspiration. Prices appear after login and always the ones attached to the account, because publicly visible wholesale prices are usually a commercial problem, and prices that contradict what was agreed are a bigger one. Photographs are welcome, complete data and units are more important.
Fast reordering: saved lists, repeat, file upload
This is the heart of the first release and where the real time saving comes from. Three mechanisms cover most cases: a standing purchase list with quantity fields, a repeat of an earlier order with the option to adjust it, and pasting or uploading a file of item codes and quantities, usually straight from the spreadsheet where the customer builds their requirements anyway. For uploads, take care of mapping customer part numbers to your codes and of a readable report of lines the system could not match. That report decides whether the customer tries a second time.
Order and document history
Customers need to find for themselves what they currently ask your office for: orders from recent months, invoices and dispatch documents to download, search by number, date and item code. It is the only one of the six that relieves administration rather than sales, and the effect usually shows up fastest. History is also the fuel for the repeat order mechanism, so plan the two together rather than as separate line items on a backlog.
Fulfilment statuses
"Where is my order" is, after availability, the second most common reason customers get in touch. Show the status in steps that genuinely exist in your process and that you can read from your systems: received, being picked, dispatched with a tracking number, invoiced. Do not invent statuses that have no data behind them, and do not promise precision you cannot sustain. A status refreshed once a day but true is worth more than a live status the customer stops trusting after the first discrepancy.
Units and case packs
The most common source of failure in these rollouts, and something you cannot postpone. The system has to understand that a product sells in packs of twelve, that a carton holds six such packs, that a pallet has its own multiple, and that an order for twenty units rounds up to a full pack. On top of that comes the unit the price is quoted in versus the unit the customer thinks in, which are not always the same. Write these rules down before the build, on paper, for every product group.
Six items looks modest, and that is the point. Together they close a path: the customer logs in, finds their items by their own codes, sees their price and availability, orders in the correct units, checks the status and downloads the invoice. That is the scope we usually close in the first stage of a project, and we described it in more detail under our B2B ordering portal service.
What to deliberately leave for later
Postponing a feature does not mean forgetting it. It means writing it down together with how the case will be handled outside the system, and coming back after launch with real usage data instead of guesses. Four areas get postponed in most projects:
- Configurators and quote on request. Configurable products need documented dependency rules that nobody has usually written down. Until those exist, a rep handles those orders exactly as today.
- Multi step approvals on the customer side. Requester, manager, budget and per user limits is a separate project. At launch one account orders, and internal approval stays a process inside the customer business, outside your system.
- Complex organisational structures. Head office with branches, a shared credit limit split across sites, separate price lists per branch. For the first release one account with several delivery addresses is enough.
- A mobile app. A browser view that works properly on a phone serves the warehouse manager with a list and the rep on the road. A native app is a separate product with its own maintenance and its own release cycle.
To that list you can usually add elaborate promotions, bundles and threshold giveaways, plus self service registration of new accounts with verification and automatic terms. The rejection rule is single and worth applying without exceptions: if a feature serves a case that happens a few times a month, and its absence can be covered by a phone call or an email, it is not a first release feature.
Every exception added to the first release pushes back the day when your first customer places an order unaided. And only from that day do you start learning from real data instead of guessing in meetings. So keep exceptions on a list rather than in the scope, and return to that list after a few weeks of real use. Half the items usually turn out to be unnecessary, and one nobody thought of turns out to be urgent.
How to pick the first group of customers
A first release does not launch for the whole market. It launches for a handful to a dozen accounts, chosen on purpose. A good candidate orders often and repeatably, so you will quickly see whether repeat ordering and file upload actually work. Their commercial terms are tidy, meaning one price list without verbal exceptions added at every order, otherwise you will spend the pilot debugging pricing rather than the platform. They have a named person responsible for ordering rather than a diffuse procedure. And they are close enough to you to say plainly what annoys them instead of quietly going back to email.
Deliberately avoid two extremes. Your largest account, where every mistake is expensive and the conversation about testing is awkward, joins in the second wave once the process is predictable. The account that orders once a quarter should also wait, because you will not gather enough observations from them to improve anything. The rep who looks after the pilot group needs to know their role does not end here, it changes: they are first line support and they will catch the things logs never show.
When the scope is closed
Your scope is ready to be estimated and built when four sentences are true. The most common order is written out in steps, on paper, and it matches what a rep would say if asked without preparation. For every step you know where the data comes from and which system owns it. Every item on the postponed list has a documented way of being handled outside the system, so nobody rediscovers it in a panic a week after launch. The first customer group is named, along with the person who will contact them.
If one of those sentences is not true, the missing piece is nearly always the same: nobody can say exactly where the price for a specific customer at a specific moment comes from. That is the hardest part of the whole undertaking and the one that separates wholesale from retail most sharply. Modelling price lists, discounts and commercial terms is the subject of the next chapter.
Questions
Does the first release need online payments?
In wholesale, usually not. The dominant model is a bank transfer on deferred terms within a credit limit, so the platform mainly has to show the payment terms attached to the account and produce the right documents. Online payment can be useful for new accounts with no history and for orders beyond the limit, but it is a feature you can comfortably add later, once you see how often that case actually occurs.
What about customers who send orders as a spreadsheet with their own part numbers?
That is an argument for file upload, not against it. The customer keeps working in their spreadsheet, and the platform accepts that file, maps their codes onto your item numbers and shows a report of the lines it could not match. If, however, only one account in thirty orders that way, leave them with the rep and revisit it after launch, when you can compare it against real usage of everything else.
How long should building the first release take?
Instead of asking about time, fix the cut off point of the scope, because scope drives the calendar rather than the other way round. The first release described in this chapter is a project measured in weeks, provided your commercial terms are in order and your product data and stock have a single source of truth. Where one of those is missing, that work is what takes the time, not the interface, and it is better planned separately than assumed away.
