In short
A product configurator is software with which customers or sales staff put together a product themselves from predefined building blocks, variants and options, while a stored set of rules ensures that only technically and commercially permissible combinations are created.
This makes the configurator more than an attractive selection form. It is the machine-readable representation of what a company can actually manufacture and deliver. That is precisely why, in business models with many variants (in mechanical engineering, furniture and window manufacturing, packaging, signage or technical components), it is often the central sales tool and not merely a feature in the online shop.
How a product configurator works
Behind every configuration interface there are three layers that have to be kept apart, because projects almost always fail at the wrong one: the product model, the set of rules and the processing of the result.
The product model: characteristics, values, assemblies
At the start is the question of what a product actually consists of. A characteristic is a property that the customer decides: width, material, motor power, colour, type of connection. Each characteristic has a range of values, either a list of permissible values or an interval with a step size. More complex products cannot manage with a flat list of characteristics; they need assemblies, i.e. nested sub-configurations that bring their own characteristics in turn.
This structure is not a design question but a data question. Anyone who has not cleaned up characteristics, units and permissible values will not get a set of rules to work later. Product data from a PIM is a better starting point here than Excel lists from sales, because it already brings versioning and responsibility for maintenance.
The set of rules: constraints instead of click paths
The real core is the set of rules. It describes which combinations are permitted, which exclude each other, which force a further selection and which dependencies exist between characteristics. Formally, this is a constraint problem: with every user input, the configurator searches for the set of remaining values that are still permissible and hides or locks everything else.
The perspective is important. A badly built configurator leads the user through a fixed click path and checks at the end whether the result fits. A good configurator checks after every input and leaves the order open, because customers do not think in the order in which the design department builds its bill of materials. Anyone who works with rules instead of wizard steps can later use the same logic in inside sales, in the dealer portal and in quote checking. The rules are the asset; the interface is replaceable.
Processing the result: from click to bill of materials
A configuration that only shows a price is a sales brochure. The configurator only becomes productive when its result is processed further: as a variant-specific bill of materials, as a routing, as a quote document with a technical drawing, as an order item in the ERP. The hand-over point to ERP and production planning decides whether the configuration saves effort or merely shifts it elsewhere.
In practice, this means: you need a unique identifier for the configuration, a permanently traceable breakdown into items and a decision on which system holds the truth about price and availability. Without this definition, quotes are created whose price the configurator knows but the order in the ERP does not. Anyone who also thinks about the way back can store and version configurations and call them up again as repeat orders, which in the spare parts business often creates more value than the initial configuration itself.
Types of configurator at a glance
The term covers very different levels of expansion. The differences are more relevant for estimating effort than any feature list.
| Type | What it does | Typical use | Demands on data and rules |
|---|---|---|---|
| Variant selection | Combination of a few characteristics from a fixed variant matrix | Size and colour in a B2C shop | low |
| Rule-based configurator | Dependencies, exclusions, forced selections, validity check | Technical components, furniture, windows | medium to high |
| CPQ (configure, price, quote) | Configuration plus pricing, discount logic, quote document, approval workflow | B2B sales with a quote process | high |
| Engineer-to-order configurator | Generates bill of materials, routing, sometimes CAD geometry | Special machine building, plant engineering | very high |
| Visual 3D configurator | Live display of the configuration, often with a material preview | Furniture, vehicles, kitchens | high, plus asset maintenance |
The levels are cumulative. An engineer-to-order configurator without a robust set of rules produces quotes that production cannot build. A 3D configurator without maintained material data produces images that have nothing to do with the product delivered. The visual part is almost always the cheaper one.
Why configurators take pressure off sales in B2B
At mid-sized companies, the configurator is rarely a marketing project. It is an answer to a bottleneck in sales. In ranges with many variants, product knowledge migrates over the years into the heads of three or four people in inside sales. Every enquiry goes through these people, every quote takes hours, and every holiday extends the response time.
A configurator makes this knowledge explicit. This has four effects that pay off independently of each other:
- Quote turnaround time: standard enquiries can be calculated without queries, because the rules do the checking.
- Error rate: combinations that cannot be built are no longer created at all, instead of being noticed in production.
- Self-service: dealers and existing customers configure themselves, often outside business hours and without a phone call.
- Securing knowledge: the set of rules survives changes of staff, which in businesses facing a generational change is often the real argument.
The price for this is uncomfortable: the product knowledge has to be written down. Most configurator projects do not hinge on the technology but on the fact that nobody wants to decide which of the special cases that have grown up historically really still apply. This clean-up work is the main effort and the real benefit.
Practical examples
In the mass market, configurators have become so self-evident that they are hardly perceived as such any more. The vehicle configurators of the German manufacturers are rule-based systems that check engines, equipment packages, wheels and optional extras against each other, evaluating hundreds of exclusion rules in the process. Nike By You, known as NIKEiD until 2019, shows the simpler variant: few characteristics, a lot of visualisation, no technical dependencies.
In B2B, things look different. With variant configuration, SAP has offered a module of its own since the R/3 days, whose successor in S/4HANA is Advanced Variant Configuration; configuration there is linked directly to the material master, the variant bill of materials and the routing. Specialised CPQ providers such as Tacton or encoway occupy the same field with their own rule tools and sales interfaces. In the shop system itself, the range extends from simple properties and the variant generator in Shopware 6 to dedicated configurator apps that keep the set of rules outside the shop and connect it via an interface.
For the sake of completeness: the German-language specialist literature also defines the term clearly; see the overview of the product configurator on German Wikipedia.
Standard solution or custom development
The question arises particularly sharply with configurators, because the set of rules reflects the business model. As a rule of thumb: the closer the configuration is to production, the more individual the solution becomes. Anyone combining size and colour will find everything in the standard. Anyone who has to generate a bill of materials ready for production from a customer input is working on a process that distinguishes them from the competition, and usually ends up with custom software or with a standard product with a considerable share of their own logic.
A sensible middle way is to separate the set of rules from the interface. The set of rules lives as a separate service with a clear API, and the interface is built appropriately in the shop, in the dealer portal and in inside sales. This saves maintaining the same rules three times and keeps open the option of replacing the front end later without touching the expensively built-up product knowledge. The decision belongs in the same assessment as any other make-or-buy decision, including the follow-up costs over the life cycle.
Typical mistakes
Four patterns repeat themselves so reliably in configurator projects that they can be named in advance.
- Making everything configurable. The reflex to map every variant ever sold inflates the set of rules without generating revenue. An analysis of the last two years of order data usually shows that a manageable proportion of the combinations accounts for most of the orders.
- Price as an afterthought. Pricing with customer tiers, surcharges, project discounts and currencies is often more complicated than the technical configuration in ranges with many variants. Anyone who pushes it to the end builds twice.
- No responsibility for the set of rules. A set of rules without named business ownership becomes outdated within a year. Customers then configure products that no longer exist.
- No transition to the ERP. If a configuration is typed in again in inside sales, sales has become faster and order processing slower.
Distinction from neighbouring terms
CPQ is the sales-side extension: configuration, pricing and quote generation in one process. A PIM manages product information but does not make decisions on permissibility. Variant management in the ERP knows the variants that can be produced but has no sales interface. A configurator connects these worlds but replaces none of them. Anyone who uses it as a substitute for clean variant management only shifts the problem.
Outlook
Two developments are currently changing the field. The first is the shift of configuration into conversations: assistance systems take up a requirement in natural language and translate it into a configuration. This changes the interface, not the set of rules, and makes the quality of the stored rules more important, not less, because a wrong rule is now hidden in a plausibly formulated answer.
The second is machine readability towards the outside. When procurement processes and assistance systems query product data automatically, the configurator becomes an interface that has to describe configurable products in a structured way instead of merely illustrating them. Companies that have already made their product model explicit are prepared for this. The others will then start the same clean-up work, only under time pressure.
Frequently asked questions
What is the difference between a product configurator and CPQ?
A product configurator ensures that a combination is technically permissible. CPQ also includes pricing and quote generation, including approvals. In practice, the configurator is the core and CPQ the sales shell around it.
Does a configurator need a PIM?
Not necessarily, but usually it makes sense. As soon as characteristics, units, texts and images have to be maintained for several channels, a PIM is a better data source than the configurator's own management, which only supplies one system.
How long does introduction take?
That depends almost exclusively on the state of the product data and the clarity of the rules, not on the software. A simple variant selection is a day's work; a rule-based configurator for a range that has grown over time is a project whose main effort lies in workshops with design and sales.
Is a 3D configurator worthwhile?
Where appearance is a purchasing criterion, i.e. for furniture, kitchens, vehicles or signage. For technical components bought according to the data sheet, the effort for geometry and material maintenance rarely pays off. Make the set of rules robust first, then talk about visualisation.
How many rules are normal?
There is no sensible target number. What matters is their origin: rules that come from design and production are robust; rules that arose from individual cases in sales should be put to the test before implementation. A set of rules that nobody can explain any more is a maintenance risk, regardless of whether it contains fifty or five hundred rules.