Configure-to-Order, CPQ
Stefan Jungen
6. August 2026
As soon as an industrial company plans its next step in digital sales, the same question almost always comes up:Customer portaloronline store? Both terms are often used interchangeably in the B2B context, even though they address different challenges.An online store is designed for new business and product discoveryor as an entry point for efficient self-service ordering designed, a customer portal designed tostrengtheningexisting business relationships. Those who fail to clarify this distinction will ultimately end up building either a system that is too simple for complex customer relationships or one that is too elaborate for straightforward ordering processes. This article provides a technical breakdown of both concepts, outlines the features a B2B customer portal actually needs, and clarifies when a combination of both is worthwhile instead of an “either/or” decision.
A webshop is transaction-oriented: search for a product, configure it, order it, pay for it. A customer portal is relationship-oriented. It reflects the entire customer history — contracts, previous orders, spare parts lists, open service requests, and documents such as drawings or certificates. In practice, the two systems increasingly overlap. Modern customer portals for industrial companies often include ordering functions, while advanced webshops provide login areas with personalized content.
The real difference lies in the architecture behind them — in other words, how the content is structured. A webshop is organized around product categories and search functions because the customer first has to find the right product. A customer portal, on the other hand, is structured around the customer relationship itself. The starting point is not the product portfolio, but the customer’s own login with current orders, installed equipment, and individual conditions.
If both structures are mixed without first defining a clear guiding principle, the result is often an interface that feels too complex for new customers and too impersonal for existing ones.
A customer portal becomes worthwhile as soon as the value of the customer relationship goes beyond a single order. In industrial business, this is often the case: spare parts are needed for decades, contract conditions are individual, service requests recur, and technical documentation has to match the current equipment status.
Typical triggers for a portal project include:
A well-developed portal shifts exactly these routine processes from sales to the customer — not by reducing service, but by relieving both sides. Customers gain faster access to information they request regularly anyway, while sales gains more time for consulting on genuinely new or complex requests instead of repeatedly answering questions about delivery status.
An important point is expectation management: a portal does not replace personal sales contact — it filters it. Simple, recurring tasks can be handled without additional interaction, while more complex requests — new variants, technical special cases, contract negotiations — remain the responsibility of the sales team. This is also why portal projects rarely work as pure IT initiatives. They should be planned together with sales from the beginning.
For standardized products with few variants and public list prices, a webshop is usually the right and leaner solution. New customers can place orders without prior interaction, the entry barrier remains low, and operations are comparatively easy to scale.
However, as soon as variant diversity, individual conditions, or technically consultative products come into play, a pure webshop reaches its limits. A practical example illustrates this development clearly: when digitizing KNARR’s sales process, the focus was not just on a new webshop. The project combined e-commerce, product configuration, and 3D visualization into an end-to-end customer journey — supplemented by role and approval concepts, project-based shopping carts, ERP integration, and a fast ordering process for a technically demanding product portfolio.
The rule of thumb is: The more homogeneous the product range and the more anonymous the customer relationship, the more likely a webshop is sufficient. The more configurable the products and the closer the customer relationship, the more likely portal functionality becomes necessary.
Another important indicator is price transparency. If all prices can be communicated publicly, this supports a traditional webshop. If prices are individually negotiated, project-specific, or volume-based, a pure webshop quickly becomes a compromise — either with visible list prices that do not reflect the real pricing logic, or with a complex discount rule set that already starts to resemble portal functionality.
A customer portal is more than just a login area for accessing a product catalog. Experience has shown that the following functional areas provide the greatest value:Not every company needs the full range of features right away. It makes sense to start with the features that address the largest share of recurring inquiries and expand the portal from there.
In practice, the question is rarely “webshop or portal.” The more relevant question is: what architecture should sit behind the system? New customers can enter through an open, product-oriented area. Existing customers can then be directed automatically after login to a personalized portal area with individual prices and order history.
One example of this combination is the VAHLE Customer Hub, which brings webshop functions and portal-based customer service together on a single platform instead of maintaining two separate systems. This not only reduces maintenance effort on the provider side, but also creates a continuous experience for the customer — regardless of whether they are placing their first order or continuing an existing business relationship.
Technically, this means: a shared database of product and pricing information, but with differentiated access rights and views depending on customer status. If you set up the two separately from the start, you’ll have to go through a time-consuming process to merge the systems later on.
The scope of a customer portal or webshop project depends heavily on how configurable the product portfolio is and how deeply pricing, configuration, and CAD data need to be integrated. A good starting point is rarely “everything at once.” It is usually a clearly defined first stage containing the functions with the greatest impact on sales and support.
For companies with complex, configurable products, it is worth looking at solutions that combine e-commerce and configuration from the ground up. 4PACE COMMERCE, for example, combines webshop and portal logic with the ability to digitally represent highly configurable products — a point where many standard shop systems reach their limits.
A sensible project start therefore begins with an honest assessment: Which customer groups exist? Which processes currently consume the most sales time? And which data — prices, variants, CAD models — needs to be available?
This assessment usually makes it possible to prioritize the first stage clearly. For one company, this might mean starting with order history and individual prices before adding a spare parts catalog and CAD access. For another, the priorities may be reversed, depending on where the biggest friction currently occurs in day-to-day sales. An iterative expansion instead of a “big bang” launch with full functionality reduces both project risk and the time until the first measurable benefit.
Customer portals and webshops solve different tasks. A webshop attracts new customers through an open, product-oriented sales process. A portal supports existing customers through personalized prices, order history, and service functions. For industrial companies with highly configurable products and long-term customer relationships, it is rarely useful to consider one completely independently of the other. Companies that combine both models on a shared data basis instead of operating them separately avoid duplicate system maintenance and create a consistent digital experience for both new and existing customers — from the first visit to the tenth repeat order.
A webshop is designed to sell to new or anonymous customers. A customer portal is designed to manage existing business relationships with individual pricing, order history, and service functions. Both can technically be combined on a single platform.
Not necessarily. For standardized products with few individual conditions, a webshop is often sufficient. A portal is particularly useful when existing customers require individual prices, recurring orders, or extensive technical support.
Yes. Modern solutions can run both areas on a shared product and pricing database and differentiate only between access rights and views depending on customer status, instead of operating two separate systems.
The most frequently required functions include: individual prices and conditions, order history with reordering functionality, access to spare parts and technical documents and transparency on quote and order status.
Yes — especially for configurable products, a portal can be particularly valuable. Existing customers can reuse previous configurations, CAD data, and individual pricing logic instead of rebuilding every order from scratch.
HOLGER REIMSBACH
Head of Projects & Operations
This might also interest you
