Building a B2B shop
A B2B shop differs from a B2C shop not in design but in pricing, processes and user management. This overview shows the requirements, the selection criteria and the mistakes that delay projects.
How a B2B shop differs from a B2C shop
The difference is not in design and not in the number of products, it is in three areas: pricing, ordering processes, and the people who order. In B2C one person usually buys for themselves, sees a price and completes the purchase within minutes. In B2B one person buys for a company, may see a different price than another department, sometimes needs approval, and frequently reorders the same items.
Anyone equipping a B2C shop with a few B2B features usually fails not on technology but on logic. Customer pricing, approval processes and user management are not add on features, they are the core of the business model. Building should therefore start with analysing those requirements, not with choosing a platform.
The functional requirements
The overview below lists the requirements that appear in almost every B2B project. Which of them matter follows from your customer structure, not from a wish for completeness. Every additional rule permanently increases maintenance effort.
| Requirement | Who needs it | Effort |
|---|---|---|
| Customer specific pricing | Almost all B2B shops | High |
| Tiered pricing by quantity | Manufacturers, wholesale | Medium |
| Purchase on invoice | Almost all B2B shops | Medium |
| Approval workflows | Larger customers, corporates | High |
| Several users per company | From around ten employees | Medium |
| Quick order by item number | Repeat buyers | Low |
| Shopping lists | Recurring needs | Medium |
| Quote function | Considered purchases | Medium |
| ERP integration | From meaningful volume | Very high |
Pricing per customer
Pricing carries the greatest effort because it has to be maintained over time. A pricing model with three layers, say list price, customer discount and tier, is quick to explain when set up and permanently error prone to maintain. Three models have established themselves in practice: fixed customer groups with a defined discount, individual price lists per customer, and tiered prices by quantity.
For platform selection the decisive question is whether pricing can be modelled without programming. As soon as one special rule requires custom code, every later change becomes a development task, and over time that costs more than a higher licence for a system that handles pricing through standard mechanisms.
Ordering processes and approvals
In B2B the person ordering is often not the person who controls the budget. An approval workflow reflects that: an order is captured but only released after approval. That requires defined rules for the threshold, the cost centre and the approver.
What matters is that this process is modelled inside the shop rather than beside it. If approval runs by email or phone, a shadow process appears that cannot be traced and in which orders get lost. Anyone who needs approvals needs them in the system.
User management
A company is not one customer, it is several. Typical is a purchasing manager, two or three buyers, and an accounts team receiving the invoice. These people need different rights: who may order, who may approve, who sees invoices, who may change payment data.
If the shop system offers no user management with roles, the state that emerges is all parties sharing one account. That is convenient at first and a problem later, because nobody can tell who triggered an order and because changing the credentials affects everyone at once.
Payment and invoicing
B2B is dominated by purchase on invoice, often with payment terms of 14 to 30 days. For the merchant that means default risk, which is either covered by credit insurance or consciously carried. Also relevant are direct debit and, in larger companies, purchasing by order number that has to appear on the invoice.
Practically important is that invoices contain what the customer's accounts team expects: order number, cost centre, and a supplier number where applicable. If any of that is missing, the invoice is rejected and payment is delayed by weeks.
Technical requirements
Two technical requirements are decisive, and both are regularly underestimated.
The first is the ERP integration. In B2B there is no inventory without a system, because prices, stock, tiers and orders are maintained there. Without integration something has to be maintained in the shop that already exists in the ERP, which creates two versions of the truth that drift apart. Integration is almost always the largest single line item in the project.
The second is search. In B2B customers rarely buy by category, they buy by item number, technical description or spare part number. A search that only looks at product names is unusable for that audience. Search has to cover numbers, manufacturer numbers and variants, and it has to tolerate typos, because numbers are long.
Own shop, marketplace or customer portal
The channel question is answered differently in B2B than in B2C, because access is often contractually agreed.
| Route | Advantage | Drawback |
|---|---|---|
| Own shop | Full control over pricing, data and processes | Build and operation at your own cost |
| Marketplace | Demand without your own visibility work | No customer pricing, commission, little control |
| Customer portal in the shop | Orders and invoices in one place | Requires user management and roles |
| Customer's procurement system | Direct route into the purchasing department | Technically demanding, customer specific |
For most mid sized suppliers an own shop with a customer portal is the right route, because it allows customer specific pricing and approvals. Marketplaces do not contradict that, they complement it for visibility and new customers. They cannot model customer specific pricing however, which is why they cannot carry the core of a B2B business.
Selection criteria for the shop system
Five questions have proven themselves for platform selection. They are deliberately ordered by how they cause projects to fail.
- Can pricing be modelled without programming? If not, every price change becomes a development task.
- Is there user management with roles and rights? Without it, one shared account for everyone emerges.
- Is a server side ERP integration possible? File imports are a start but not a long term solution.
- Does search work on item numbers? In B2B that is the most used function.
- Can approval workflows be modelled? If customers need them and the system cannot, the process gets outsourced.
Preparing these decisions benefits from a clear project plan, as taught in the E-Commerce Setup seminar. The processes behind orders, approvals and invoices, meaning what actually happens after the click, is the subject of E-Commerce Operations.
Project sequence
A B2B project runs in a different order than a B2C project, because the functional rules have to be settled before the technology.
- Analyse the customer structure. How many customers, what size, what pricing logic, who orders, who approves.
- Write the processes down. Order, approval, delivery, invoice, return. Without that, platform selection is impossible.
- Define the pricing logic, including who may change prices and how often that happens.
- Choose the system using the five questions.
- Build the ERP integration. The longest and most expensive step.
- Migrate the data and map prices.
- Start with a pilot group. Five to ten customers who test the process and find faults before everyone is affected.
- Roll out, accompanied by support in the first weeks.
Typical mistakes
The following mistakes are so common that they appear in every second project.
- Pricing logic not thought through. Result: a system of exceptions that has to be maintained forever and breaks with every change.
- ERP integration underestimated. Result: months of delay and two data sets drifting apart.
- Approval processes outsourced. Result: orders by email that are invisible in the system and regularly lost.
- No quick order function. Result: existing customers keep calling, because entering twenty line items takes too long.
- User management forgotten. Result: one shared account per company and no traceability.
- All customers migrated at once. Result: a fault immediately hits the entire business.
Frequently asked questions
What does a B2B shop cost?
For a B2B shop with customer pricing, user management and ERP integration, the effort realistically sits between 50,000 and 120,000 EUR, with integration alone accounting for 15,000 to 40,000 EUR. For projects with approval workflows and several price lists the upper end is closer to 150,000 EUR. The effort depends on the level of integration, not on the number of products.
Can I run B2C and B2B in one shop?
Technically yes, organisationally only with clear separation. Two audiences with different prices, payment methods and return conditions in one ordering process regularly produce errors, because the requirements contradict each other. A shared data foundation with separate access routes and clearly governed conditions per route has proven itself.
Do I need an ERP system?
Beyond a certain size, yes. As soon as prices, stock and orders are maintained in more than one place, two versions of the truth emerge and drift apart. The threshold is roughly where manual maintenance costs more time than running the integration, so at a few hundred orders per month or with stock managed goods.
How important is search by item number?
For existing customers it is the single most important function, because buyers think in numbers and not in product names. A search that only knows names leads to customers ordering by phone, which is exactly the state the shop was meant to end.
Why is purchase on invoice standard in B2B?
Because the customer's accounts team needs the invoice to process the transaction. Prepayment is organisationally cumbersome for companies, and cards often fall away because corporate cards are rare. As a merchant you carry the default risk, which requires either insurance or a deliberate decision.
Conclusion
A B2B shop succeeds when the functional rules are settled before the technology. Pricing, approvals and user roles are the areas that decide whether the shop gets adopted or whether customers keep calling. The ERP integration is the most expensive single line item and the one most often underestimated. Anyone starting with a clear process picture and a pilot group can correct faults before they affect the whole business.