EN
German
Dutch
A B2B webshop with self-service behind the login is a customer portal. These are not two systems you place side by side, but two jobs of the same environment: winning new customers and managing existing customer relationships.
Wholesalers often ask themselves whether they need a customer portal alongside their B2B webshop. That is the wrong question. It gets framed as a choice so often because at many wholesalers it has in fact become two things. That crept in over the years, without anyone ever choosing it.
Why it often ends up as two environments anyway
Many B2B webshops were designed for the first order. Search, basket, checkout. The questions that come after that order, such as where is my shipment and is this invoice correct, stayed with inside sales. Once that became too much, something was added: a portal from the ERP vendor, a separate dealer platform, a my-account section that does no more than show a few PDFs, or a customer environment that was once built for one large buyer.
The result is a split environment, and it costs more than it solves:
- Two truths about the same data. The shop shows one price, the portal shows another. The customer calls to ask which one is right.
- Two login paths. The buyer does not know where to go for a packing slip, so he sends an email.
- Two administrative burdens. Users, roles and prices are maintained in two places, with the discrepancies that come with it.
- A broken ordering route. The customer sees in the portal what he bought last month, but has to go to the shop to order it again.
One environment that switches after login to customer-specific pricing, order history, open invoices and reordering solves that. To the visitor it is one site. Technically it is one data model with one source: your ERP.
What you do have to decide
If the question is not whether you put a portal next to your webshop, the question becomes which self-service layers you add when. That is a real trade-off, because every layer makes demands on your data.
| Self-service layer | Data the ERP has to expose | What it takes away | Dependency |
|---|---|---|---|
| Order history and order status | orders and order lines, including orders placed outside the shop, with partial deliveries | status questions, requests for a copy of a packing slip | status has to be available at line level, not only per order |
| Customer-specific pricing | pricing agreements, volume tiers, contract conditions, permitted assortment | price checks, credit notes after a wrong price | the conditions in your ERP have to be current and clean |
| Reordering | order history plus current stock and lead time | searching the catalogue, order lists by email | stock must not lag behind, or the customer orders the wrong thing |
| Invoices and open items | invoices, payment status, outstanding amounts | invoice copies, payment questions, manual reminders | financial data has to match what your accounts department sees |
| Users, roles and locations | contacts, debtor numbers, cost centres | orders booked to the wrong entity, unwarranted access | your customer master data has to follow the real organisational structure |
You do not set the order based on which feature demos best, but on two things: which question your inside sales team gets most often, and which data your ERP can reliably expose. Those two rarely line up, and where they fail to line up is your first project.
A portal makes poor data visible to the customer
As long as pricing agreements and stock levels sit only in the ERP, it is mainly your inside sales team that sees the discrepancies. Those get corrected in conversation, usually without the customer noticing. Put the same data behind a login and the buyer sees them directly. An outdated volume tier is then no longer an internal point of attention, but a discussion with your customer.
That is not an argument for postponing self-service. It is an argument for checking, layer by layer, whether the underlying data is right. In practice that means three situations where you are better off starting with cleaning up or exposing data than with building:
The ERP cannot deliver the data. If order lines, open items or pricing agreements are not available through a connection, you build a view that lags behind. That costs trust you will struggle to win back.
The customer and pricing data are not reliable. Outdated conditions, duplicate contacts, debtor numbers that do not match the actual locations, discounts that were once agreed verbally. This is the most underestimated part of any project.
The problem is adoption, not functionality. If only a small share of your orders comes in online while the features are already there, more functionality will not help. Then it is about onboarding buyers and about whether your own account managers encourage the digital route or work around it. Changing behaviour takes considerably longer than the implementation.
On setting up the functional side itself, we wrote earlier and in more detail about how a digital catalogue grows into a customer portal.
One platform or a portal on top?
Because it should be one environment, the platform question shifts as well. It is not about which portal you hang next to your shop, but about whether your platform treats self-service as part of the same data model. Five questions that get you further than a feature comparison:
- How deep does the standard integration with your specific ERP go, and what counts as custom work?
- Which data can the platform expose in real time and which not?
- How are company accounts with multiple users, roles and locations modelled?
- What happens at a release: do you move along or stay behind on an old version?
- Who is responsible if the connection fails, and how do you find out before your customer does?
A platform that was designed as a consumer webshop and had B2B functionality added later runs into limits as soon as customer-specific pricing, quotation workflows, rights per location and approval steps come together. You rarely notice those limits in the demo and almost always in year two.
CloudSuite is set up from the operational logic of wholesalers and brand manufacturers, with B2B e-commerce for wholesalers and self-service in the same platform rather than as a separate layer. How differently that plays out is shown by the customer cases: Secrid handles business ordering through a mobile-only B2B platform alongside a headless B2C webshop on the same backend, Beko Groothandel serves bakers, pastry chefs and chocolatiers as a purchasing organisation, and Versluis, a wholesaler in painting tools, moved away from an outdated webshop. Three very different ordering processes, with the same underlying requirement: the data comes from the ERP and has to be right. Which connections are possible is set out in the overview of ERP integrations.
Where you can start tomorrow
Two inventories, both of which you can carry out without a project or a budget, that give the rest of the process its direction.
Count your inside sales questions for two weeks. Categorise roughly: order status, invoice or payment, price or condition, stock, correction to a running order, other. After that you have your own figures and do not have to lean on industry averages.
Map, per data type from the table above, what your ERP can expose. Available through a connection, how current, and how reliable the content is today.
Where those two lists cross is your first self-service layer. The guide Het B2B-klantportaal contains a scoring framework with five dimensions for comparing platforms and a breakdown of what has to be real time and what can be batch. The PDF opens without a form.
