Articles · Platform & Pricing
A B2B ordering platform, and the decision that sits underneath it
Published
Almost every one of these projects arrives described as a shop with logins on it. That description survives about a week, and what replaces it is the actual product: a catalogue that is different for every customer who signs in.
What a B2B ordering platform actually is
A place your trade customers sign in to and order from, where what they see is a function of who they are. Their catalogue, their prices, their terms, their delivery. A b2b ordering platform and a b2b ecommerce platform get used for the same thing in practice; where the words come apart, the first leans toward repeat replenishment by people who already know what they want, and that is a different design problem from discovery.
The test for whether you need one is not turnover. It is whether two customers should ever see different things. The moment the answer is yes, a single public catalogue has stopped being able to describe the business, and every workaround from that point on is somebody maintaining a spreadsheet.
The catalogue is the product
This is the part that gets underestimated. On a consumer store the catalogue is a fact: here is what we sell. On a b2b portal it is a rule set, and the rules are where the business logic actually lives. Who may buy this. At what price. In what minimum quantity. From which warehouse. With whose approval.
Getting those written down is usually the first proper audit a business has ever done of its own trading terms, and it routinely takes longer than the build. It is also the part that pays for itself, because the answers were previously held by three people and an inbox.
Pricing and permissions are one problem
They get scoped separately and they should not be. A customer seeing a price they should not see and a customer seeing a product they should not see are the same failure with different consequences, and both come from the same place: the platform deciding what to render before it knows who is asking.
A b2b customer portal that shows everything to everybody and applies a discount at the end is not a B2B system. It is a consumer store with a coupon, and it will hold until the first account that is not allowed to buy something.
Where the order goes is not an afterthought
A wholesale ecommerce platform operating in more than one country has a routing problem the checkout cannot see. The right answer is rarely "ship from the warehouse the catalogue knows about". It is the operation that actually serves that customer, which may be a different company, a different stock position and a different lead time.
Build this late and you get a platform that takes orders correctly and fulfils them expensively. It belongs in the catalogue rules, not in the shipping settings.
The part nobody sees
The order backend is most of the work and none of the demo. What happens after submit: how the order reaches the system that holds the stock, what happens when that system says no, how a partial delivery is represented, what a customer sees when something is on back-order.
A b2b ordering system is judged on that, not on the front end. The front end is what people look at in the pitch and the backend is what they live with, which is roughly the inverse of how most of these projects get scoped.
Build or buy, honestly
These two get confused constantly and the distinction is simple once it is said plainly. Procurement software manages your own buying, approvals, budgets, requisitions inside your business. An ordering platform lets your customers buy from you. Both involve catalogues, both get called procurement, and choosing the wrong one is a mistake that takes about a year to become obvious.
If your customers are large enough to mandate their own purchasing system, you will meet punchout: they browse your catalogue from inside their system and return a basket to it for approval. Worth asking your five biggest accounts about before it is worth costing.
And plenty of this is native now. Shopify handles company accounts, per-company catalogues, price lists and payment terms without anyone writing code. What gets built is the part that is specific to you, which is usually routing, an unusual permission rule, or the integration with whatever actually holds your stock.
A worked example: hotel supply
We build and run one of these for Citizen M, who supply the operating stock that keeps citizenM hotels running and, since Marriott's acquisition of citizenM, Marriott hotels too. In the trade the category is OS&E, operating supplies and equipment: the napkins, cutlery, crockery, glassware and bedding a hotel gets through, rather than the furniture it keeps.
It is a good example because the stakes are legible. A hotel that cannot reorder bedding has rooms it cannot turn around, and a hotel that cannot reorder cutlery has a restaurant it cannot open. The catalogue is scoped per hotel, the pricing is set per hotel, and the order fulfils from the local operation serving that building rather than from wherever the catalogue happens to live.
Every general point above is doing real work in that build. It is also sign-in gated, so there is nothing to show you, which is its own illustration of what this category of product is.
Common questions
What is a B2B ordering platform?
A place your trade customers sign in to and order from, where what they see is decided by who they are: their catalogue, their prices, their payment terms, their delivery routing. It is not a shop with a trade discount applied at the checkout, and the difference is not cosmetic: the moment two customers should see different products, a single public catalogue stops being able to describe the business.
How is that different from a B2B ecommerce platform?
In practice the terms get used for the same thing. If there is a distinction worth keeping, "ecommerce platform" leans toward selling and "ordering platform" toward repeat replenishment by people who already know what they want. The second is a different design problem: speed of reorder matters more than discovery, and a search box beats a beautiful category page.
Should I build a platform or buy procurement software?
Buy, if the job is managing your own purchasing, approvals, budgets, requisitions inside your business. Build, if the job is letting your customers order from you. They get confused because both involve catalogues and both get called procurement, and choosing the wrong one is expensive in a way that takes about a year to become obvious.
Can Shopify do this, or does it need custom software?
Shopify handles a lot of it natively now, company accounts, per-company catalogues and price lists, payment terms. Where it needs building is the parts specific to you: routing an order to the right regional warehouse, a permission rule nobody else has, an integration with the system that actually holds your stock. Most of the platforms we build are that shape: native where native works, built where it does not.
What is punchout, and do I need it?
Punchout lets a customer browse your catalogue from inside their own procurement system and return a basket to it for approval. You need it when your customers are large enough to mandate their purchasing system, and you do not when they are not. It is worth asking your five biggest accounts before it is worth costing.
How long does a build like this take?
Longer than a storefront and for a reason that is not development time: the catalogue rules have to be decided before anything can be built, and that is usually the first real audit a business has done of who is allowed to buy what. We have seen that stage take longer than the build. It is also the part that pays for itself.
Two customers who should see different things?
That is the sentence that decides whether you need one of these. Tell us who buys from you and how they differ, and we will tell you what is native, what has to be built, and roughly what that costs.
Stores we build and grow
