Product configurator
A product configurator is a tool on a website that lets a buyer assemble a valid version of a configurable product by choosing options, while the software enforces which combinations are actually possible and, often, what the result costs.
In practice
The value is in the word valid. Any form can collect options. A configurator knows that a particular motor cannot be specified with a particular enclosure, that choosing a stainless housing forces a different gasket, and that a certain length is only available in one material. Those rules usually live in the heads of one or two people in engineering, and every quote request that ignores them costs a round trip to correct.
That is the honest business case. For manufacturers of configurable products, a large share of inbound quote requests are unbuildable as specified, and the cost is not the sale, it is the days spent going back and forth before a real quote can be produced. A configurator moves that validation to the moment the buyer is choosing, when correcting it is free.
Configurators sit next to CPQ and often get confused with it. A configurator answers what can be built. CPQ answers what it costs and produces the quote document, usually including approvals and discounting rules. Some products do both, and a manufacturer that only needs the first should be careful not to buy a sales-operations platform to get it.
What the configurator hands over matters as much as what it checks. The useful result is something the rest of the business can act on without retyping it: a part number or model code, a spec sheet the buyer can pass around internally, and a quote request that lands in your CRM already complete. Some setups go further and produce a bill of materials for the ERP, either in the configurator or in the ERP itself. Decide where the result has to land before choosing software, because a configuration someone re-keys by hand puts the errors back in.
The build effort is almost never the interface. It is extracting the rules, because they are usually undocumented, partly contradictory and known only in practice. Companies that treat a configurator as a web project are surprised; companies that treat the first phase as writing down the rules are not.
A test you can run: take the last twenty quote requests that came through your website and count how many needed a clarifying conversation before anyone could price them. If it is more than a handful, and the clarifications are about option combinations rather than about quantity or timing, a configurator is solving a problem you already have.
Common questions
What is the difference between a product configurator and CPQ?
A configurator determines what can be built, enforcing the rules about which options work together. CPQ, meaning configure, price, quote, adds the pricing, approval and document side and is aimed at a sales team rather than a buyer. Configurators are often a component inside a CPQ product.
What are the different types of product configurators?
Three are worth telling apart. A visual configurator shows what the choices look like, in 2D or 3D, usually on top of rules, and suits products bought partly on appearance. A rules-based configurator checks which combinations can actually be built and ends in a part number or specification, which is what most industrial products need. A CPQ configurator is the configure step inside quoting software, used by a sales team or put in front of buyers on the site, and adds pricing, discounts and the quote document. Plenty of tools mix them, such as a rules-based configurator with a simple preview.
Do we need a 3D configurator?
Usually not. Visual configuration sells well in furniture and consumer products, but industrial buyers are generally confirming that a combination is valid and correctly specified rather than seeing what it looks like. A clear rules-based configurator that outputs a correct part number is worth more to them than a rendering.
What does a product configurator cost to build?
The variable is the rules, not the software. A product with a dozen options and few dependencies is straightforward; a product where every choice constrains three others is a substantial engineering exercise before any code is written. Scope the rule extraction first and the build estimate becomes real.