What Is a Product Configurator? Types, Examples and Implementation

Human and AI collaborating on digital product configuration

Share This Post

Table of Contents

A product configurator is software that assembles a product from predefined components and attributes without producing an invalid combination. It checks a set of rules in the background and returns a valid specification, often with a type code and a bill of materials. For manufacturers with many variants, it decides whether an inquiry becomes a reliable quote in minutes or only after several rounds of questions to engineering.

What is a product configurator?

The core is the rule logic. A form accepts any input. A configurator, by contrast, knows that a particular motor requires stronger cooling, that two options exclude each other and that a combination may be buildable but not approved. The lexicon of the German Informatics Society mentions, as one option, marking invalid options with an explanation and suggestions for resolving the conflict.

Many names are in use: variant configurator, sales configurator, quote configurator, 3D configurator. They usually mean the same thing, but implementations differ widely. A 3D configurator shows the result, a variant configurator in the ERP generates the manufacturing bill of materials, and a sales configurator guides the selection.

How a product configurator works

Two building blocks produce the result. The product model describes what a product consists of: attributes with units, allowed values, assemblies and options. The rule set defines what fits together. Typical rule types are exclusions (“option A not with B”), requirements (“outdoor use always needs at least IP65”), derivations (power and speed determine the gearbox size) and defaults.

The result is a complete, consistent configuration. Depending on the system, it produces a type code, an item number, a bill of materials for the ERP or a record for the quote. Capable configurators do not need to enforce a fixed order of inputs. Users can start with the dimensions or with the color, and the rule set keeps the configuration valid at every step.

How a product configurator works: from product model through rule set to a valid configuration

What types of product configurators are there?

Three classifications are common.

By modeling approach

This is about how the rule set is represented technically. The German Informatics Society lexicon distinguishes rule-based, model-based and case-based approaches. Case-based systems, which start from similar earlier configurations, are rare in industry. Constraint-based systems are a common form of the model-based approach. In practice, manufacturers mostly encounter these four forms.

ApproachPrincipleSuitable for
Variant tableAll valid combinations are listed in a tableFew attributes, manageable variant space
Decision treeQuestions in a fixed order lead to the variantNeeds assessment, simple product ranges
Rule-basedIf-then rules check every inputMedium complexity, readable rules
Constraint-basedConditions describe what must hold, the engine finds valid solutionsLarge variant spaces, free input order

Variant tables quickly reach their limits. Just seven attributes with five values each add up to 78,125 combinations. Rule-based and constraint-based systems do not have to list these combinations. The difference lies in direction. An if-then rule works from cause to effect and often depends on the order of inputs. A constraint, by contrast, describes a condition that holds in every direction: if someone picks the gearbox first, the system narrows down the matching motors just as it would the other way around.

By use

A sales configurator supports inside and field sales with quotes. A web configurator lets customers or distributors choose for themselves. A 3D configurator adds visualization, and the variant configurator in the ERP, for example in SAP, controls production. Many companies use several of these, ideally with a shared rule set.

Cosmetic, functional or parametric

In cosmetic configuration, color, material or finish change while the function stays the same. Functional configuration changes equipment and performance, such as the drive or control unit of a machine. Parametric means dimensions can be chosen freely within limits, as with windows or cut-to-size parts. From that point on, the configurator has to calculate rather than just select, and the bill of materials is generated dynamically.

When you need a product configurator

Whether a configurator pays off depends heavily on the order type. In pick-to-order, stocked components are simply put together, and a configurator is often not needed at all, as long as no bundle or accessory rules apply. With configure-to-order and assemble-to-order, real configuration tasks arise because components depend on each other. In make-to-order, the manufacturer produces to specific customer requirements, as the Gabler business lexicon puts it. In engineer-to-order, part of every order is newly engineered. There, the configurator can cover the standard share but does not replace custom engineering. A detailed table of these classes and their suitability for quoting processes is in the article on CPQ.

Examples from B2B and B2C

In B2C, configurators are familiar from cars, kitchens or bicycles. Customers put the product together themselves, and the configurator prevents impossible combinations.

In B2B, quoting is what matters most. A switchboard manufacturer combines protective devices, terminals and enclosures that have to fit together electrically and physically. A window manufacturer works parametrically: width, height, opening type and glazing determine hardware and profile. The article on PIM and BIM covers the additional data such manufacturers need to supply to designers. In drive technology, the configurator derives the right combination of motor, gearbox and inverter from load, speed and environment. What all cases have in common is that the knowledge behind them used to sit in the heads of a few experts.

Benefits, and how to measure them

Reliable figures are rare because the effect of a configurator is hard to separate from other measures. A study by the Technical University of Denmark (Hvam et al., 2013) examined four companies. Lead time for quotes and specifications fell by 94 to 99 percent, and effort by 50 to 95 percent. In one case, preparing quotes and bills of materials for electrical switchboards went from three to five days to ten minutes. These effects in the quoting process could be clearly attributed to the configurator. According to the authors, that was not possible for broader effects such as revenue or costs.

For your own project, your own measurement is what counts. Useful metrics are the time from inquiry to a valid specification, the share of configurations that need no input from engineering, the abandonment rate in self-service and the effort needed to add a new option to the rule set. Record these values before the project starts. Otherwise, there is nothing to compare against later.

What data a product configurator needs

A configurator is only as good as the product model beneath it. Attributes must be structured with units and value lists, not stored as free text. Assemblies and options need unique identifiers, and images and documents need to be assigned to the variant. The article on variant management explains structuring product variants in detail. Prices and availability usually come from the ERP.

That is why this data belongs in the PIM. When attributes, media and texts are maintained there, the configurator uses the same data as the catalog and the online store. Otherwise, two versions of the truth emerge, and with the very first change the configurator shows something different from the data sheet.

Headless: one rule set for many channels

Many manufacturers need the configurator in several places: in the online store, in the distributor portal, in field sales and in the ERP. A configurator with a built-in interface has to be integrated again in every channel and is often maintained twice. With the headless approach, rules and validation sit centrally in a configuration engine, and every interface accesses it through an API. The market usually calls this headless CPQ or a headless configurator. The price of this freedom is that every front end becomes a project of its own.

Headless product configurator: one rule set for web shop, distributor portal and sales

There is also the protection of know-how. Rule sets contain engineering knowledge that a manufacturer does not want to disclose. If the rules are evaluated on the server, the browser only sees the result.

Configurator, CPQ and guided selling

The terms overlap, but they mean different things. The configurator ensures a valid variant. CPQ adds pricing and quoting, meaning what follows commercially from the variant. Guided selling starts even earlier and uses questions about the application to determine which product family fits at all. In many projects all three work together, with the configurator in the middle.

How much does a product configurator cost?

There is hardly a list price, because costs depend on a few drivers. The license or subscription is usually the smallest item. The largest share is often rule capture: experts from engineering and sales have to describe their knowledge in a way that can be modeled and tested. Then there is integration with ERP, PIM, CRM and online store, the front ends in headless projects and, finally, ongoing maintenance, because every new product line changes the rule set.

Common implementation mistakes

The most common mistake starts before the software: attributes are stored as free text in the ERP, and nobody has decided which values are allowed. Duplicate rule maintenance is just as costly: ERP variant configuration and the sales configurator are maintained separately and drift apart. Starting with a public self-service configurator before the rule set has been tested internally is risky too. And anyone who forces every special request into the rule set builds a model that nobody understands anymore. Without versioning, a configuration from five years ago can no longer be traced when a spare part is ordered. Responsibility for the model should therefore be clearly assigned, much like that of a data steward for product data.

What to look for in product configurator software

  • Can business users maintain rules themselves without programming?
  • Can rule sets be versioned and given validity dates?
  • Are there test cases that run automatically after every rule change?
  • Does the system explain conflicts in a way sales and customers understand?
  • Does the configurator use the same data model as PIM and ERP?
  • Can an old configuration be reproduced exactly later on?

VIA/Configuration at Viamedici

With VIA/Configuration, Viamedici offers product configurator software based on rules and declarative models. Invalid combinations are shown immediately, with an explanation and recommended alternatives, and input does not follow a rigid order. Existing rule sets from SAP variant configuration can be used and extended. The front end can be designed freely. VIA/Configuration is available as a standalone product or as an extension of the EPIM/5 platform and the PIM system VIA/PIM360°.

What does HCA mean?

HCA is a Viamedici term, not a general industry term. On the VIA/Configuration product page, the abbreviation stands for High Configuration Application, meaning the configuration application itself, which runs standalone or together with the PIM. More common terms in the market are product configurator, variant configurator or headless configurator.

Conclusion

A product configurator makes variant knowledge usable for sales and customers without every inquiry going through engineering. Whether that works depends less on the interface than on the product model and the rule set. Structuring the attributes first and testing the rule set internally before customers see it gives the configurator the best chance of still being right after the third product line.

Frequently asked questions about product configurators

A product configurator is software that assembles a product from predefined components and attributes and uses a rule set to ensure that only valid combinations are created. The result is a valid specification, often with a type code or bill of materials.

By modeling approach, there are variant tables, decision trees, rule-based and constraint-based configurators. By use, there are sales, web, 3D and ERP variant configurators.

The configurator ensures a valid variant, while CPQ adds pricing and quoting. Many CPQ solutions contain a configurator as a core component.

Costs depend less on the license than on rule capture, integration with ERP, PIM and online store, the front ends and ongoing maintenance of the rule set.

Structured attributes with units and value lists, unique assemblies and options, assigned media, and prices and availability, which usually come from the ERP.

Rules and validation sit centrally in a configuration engine, and the online store, portal or sales tool accesses it through an API. The rule set is maintained only once.

HCA is a Viamedici term. On the VIA/Configuration product page, it stands for High Configuration Application, meaning the configuration application itself.

Mainly in configure-to-order, assemble-to-order and make-to-order, when components depend on each other and quotes currently trigger questions to engineering. For pure pick-to-order without accessory rules, it is often not needed.

Want to see how a configurator works with your product data?
In a demo we show how VIA/Configuration uses rules, variants and prices directly from the PIM.