B2B commerce basics
If your mental model of an online shop comes from buying shoes, almost every assumption in it is wrong here. This is the article to read properly, because every design decision in the platform follows from what is on this page.
The scenario
A buyer at a machine builder needs 40 metres of hydraulic hose and the fittings
for it. She has a framework agreement with you, negotiated last spring, so her
prices are not your list prices. She orders against cost centre 4711, and
anything over 2,500 EUR goes to her department head for approval. She does not
browse — she has a parts list from her maintenance system and knows exactly which
article numbers she wants. Her employer's procurement system, SAP Ariba, is where
she is supposed to start. If any of that is awkward, she picks up the phone and
calls your Innendienst, who has been doing this for eleven years and is faster
than any website.
Nothing in that paragraph exists in B2C. All of it is normal in B2B.
The short version
| B2C | B2B | |
|---|---|---|
| Who buys | A person, for themselves | An employee, for their employer |
| The price | One price, visible to everyone | Negotiated, per customer, often confidential |
| Assortment | The same for everyone | Customer-specific; some articles are not for everyone |
| Catalog size | Hundreds to thousands | Tens of thousands to millions |
| Decision | Emotional, fast | Specification-driven, sometimes weeks |
| Payment | Card, up front | On account, 30 days net, 2% Skonto |
| Approval | None | Cost centres, limits, a second signature |
| Where it starts | Your shop | Their procurement system, or the phone |
Prices are negotiated, not published
This is the single biggest structural difference. In B2C the price is a property of the product. In B2B it is a property of the relationship.
A single article can carry, at the same time: a list price, a segment price for all wholesalers, a contract price for one account agreed in a framework agreement, and a scale price that drops at 10, 50 and 250 pieces. Which of these a buyer sees depends on who is logged in, what they have agreed with you, and how many they put in the basket. Two buyers looking at the same page see different numbers, and that is correct behaviour, not a bug.
Some of your customers regard their conditions as confidential. Showing a list price to someone who has negotiated a better one is embarrassing; showing one customer's conditions to another is a genuine commercial problem.
The customer is a company, not a person
The account is Max Müller GmbH. Inside it sit several people: a purchasing assistant who builds baskets, a technician who searches for parts, a department head who approves, and an accounts payable clerk who never logs in but receives the invoice. Each needs different rights.
That structure is not decoration. It decides who may see prices at all, who may order, who must be approved, which delivery addresses are available, and which cost centre a line is booked to. When a company reorganises, you change the organisation record, not fourteen individual logins. See Organizations and Contacts and roles.
Buying is a governed process
Two mechanisms do most of the work.
Cost centres. Every order line is booked somewhere internally. If your shop cannot capture a cost centre, your customer's controller has to reconstruct it from the invoice, and your shop quietly becomes the awkward channel.
Approval workflows. Orders above a value, or from certain people, or for certain article groups, go to someone else before they become orders. Until then they are pending, not lost. A shop without approvals forces the buyer to leave the shop, get approval by email, and come back — which is when the phone starts looking attractive again. See How procurement governance works and Approval models.
The catalog is long-tail and technical
A technical wholesaler runs 50,000 to several million articles. Most of them sell rarely. All of them must be findable.
Buyers do not browse a category tree to find a seal — they filter by thread size, material, pressure rating and norm, or they search by an article number, a manufacturer number, or the number printed on the machine. That only works if those facts are structured data rather than sentences in a description. This is why the catalog work is the hard part of a B2B project, and why it comes first. See How PIM works and How B2B buyers actually search.
Some products have no article number until they are specified
A hose assembly, a control cabinet, a drive with the right shaft and coating: these are not picked from a list, they are configured. The buyer chooses length, material, connection and options; rules enforce which combinations are valid; and only at the end does a price and an orderable line exist. Handled on paper that is a week of drawings and emails. Handled properly it is four minutes in a browser.
The catch is that a configurator is a catalog project before it is a storefront feature. Every option, every surcharge, and every rule that says "this coating not with that seal" has to be modelled by someone who knows the product. See Configurable products.
Some products have to be identified, not chosen
A service technician standing at a stopped machine does not know your article number. He knows the machine type, sometimes its serial number, the position number in an exploded drawing, and the number stamped on the broken part — which is often a manufacturer number you have never listed.
Spare-parts business is therefore an identification problem before it is a selling problem. It is won with bills of material that break a machine into orderable positions, drawings a buyer can click, and supersession chains that route a discontinued number to its replacement. Get it right and you take work off your Innendienst that no competitor can undercut. See How buyers identify a spare part.
Your customers' systems want your catalog classified
Large buyers do not read your catalog, they load it. Inside their procurement system every article must sit in a class that system understands: eCl@ss in German industry, ETIM in electrical and technical wholesale, UNSPSC for international and public buyers. Each class brings its own list of features you are expected to fill.
This is not cosmetic. A catalog without the classification a customer asked for is rejected at import, and their buyers never see an article of yours at all. The same goes for the exchange format — BMEcat, Datanorm, or the Excel layout one customer invented in 2009 and still insists on. See Classification standards.
Buyers repeat themselves
Consumers rarely order the same thing twice. B2B buyers do almost nothing else. A workshop orders the same consumables every month; a service technician needs the same wear parts for the same machine.
The features that follow are unglamorous and they are what buyers actually judge you on: order lists they can save and reorder, quick order by pasting or uploading article numbers without opening a single product page, and recurring orders for genuinely predictable consumption. A buyer who can reorder last month's basket in twenty seconds stops phoning.
Repeat business can run itself
Once you accept that buyers repeat themselves, the next step follows: stop making them place the order at all. A standing order ships a fixed cart on a fixed interval. A subscription bills a service or a consumables plan on a cycle. A reorder suggestion watches consumption and tells the buyer it is time, before the workshop runs out.
Your customer gets no stock-outs and no purchasing admin. You get revenue you can forecast and orders nobody has to type. It also raises the switching cost considerably, which is the polite way of saying it is the strongest retention mechanism in B2B. See Recurring revenue in B2B.
Not every enquiry is an order
Configurable products, project business, unusual quantities — these start as a quote, not a purchase. The buyer sends a request, someone in sales prices it, you go back and forth over a version or two, and the buyer accepts — at which point it becomes an order without anyone retyping it.
When a quote is worth repeating, it hardens into a framework agreement: an agreed price for an agreed volume over an agreed period, usually a year. The buyer then does not place orders, they call off against the committed volume, and part of your job is showing them how much of it is left. A large share of Mittelstand revenue sits here — the shop is the delivery mechanism for a deal a person closed. See The quote lifecycle.
Money moves later
Payment on account is the norm: 30 days net, 14 days with 2% Skonto. Cards are rare and often actively unwanted. That means two things your shop must respect: payment terms are a property of the customer, and credit limits are real. An order that would take an account over its limit is a business decision, not a technical error, and your ERP is usually the system that knows the answer. See Payment terms.
The order often does not start in your shop
Large customers do not want to visit 40 supplier websites. Their buyers work in one procurement system — SAP Ariba, Coupa, Onventis — and expect to reach your catalog from inside it. Punchout (OCI or cXML) makes that possible: the buyer clicks your supplier entry, lands in your shop already authenticated with their own prices and assortment, fills a basket, and the basket is handed back into their system for approval. For some suppliers this is the majority of their digital revenue. See Punchout explained.
And the uncomfortable one: for most Mittelstand companies, the majority of orders still arrive by phone, fax and email. The shop is not competing with a competitor's shop. It is competing with a phone call to someone the buyer likes. See Move existing customers online.
What this means for your project
Your shop will be judged on whether the right price appears, whether the right person may order, whether the article can be found by its number, and whether reordering is faster than the phone. It will not be judged on the hero image.
Next
- B2B commerce glossary — the vocabulary, in plain language.
- Your first week — where to start, in a sensible order.