A customer selects an engine, enclosure and controller. The price looks correct, but the engine does not fit the enclosure. This is not a calculation error. It is a missing product model. That is precisely where a quote calculator ends and a product configurator begins
Two reasoning machines
A quote calculator mainly answers “What is the expected cost for these parameters?”. A product configurator first answers “Which combination is valid at all?”. The former needs pricing formulae. The latter needs constraints, dependencies and an output that downstream systems can use
For services, the boundary can be fluid. A cleaning cost calculator uses floor area and frequency. A configurator for a technical maintenance agreement may check whether the selected response time is available in that region and for that asset type
Constraints instead of an exception list
A weak configurator accumulates rules such as “if A and B, disable C”. After a few dozen options, nobody knows which rule wins. A better model describes properties and constraints: a power level requires a particular voltage, mass cannot exceed the enclosure limit, and certification is available only for specified materials
The rules engine can then reject a combination, suggest a compatible alternative and explain the reason. Explanation matters commercially. “Option unavailable” looks like a website fault. “32 A requires enclosure size M or L” helps the customer decide
The result needs a life beyond the screen
A colourful image at the end is not enough. Manufacturing needs a bill of materials, sales needs proposal lines and the customer needs a configuration code. That code should identify the catalogue and rule version. Six months later, the same configuration may no longer be available; the historical order must remain reproducible
If the configurator sends its output to ERP or CPQ, identifiers must be stable. A user facing name may change, but the technical identity of a variant must not accidentally point to a different product
Example: a control cabinet
- The user selects the application and required environment
- The system narrows enclosure materials and protection rating
- Selected power determines components, cooling and minimum size
- Communication options add modules and licences
- Compatibility rules create a technical variant
- The pricing engine calculates price, lead time and surcharges
- The result generates a code, specification and proposal data
Steps two to five are configuration. Step six is calculation. They can work together, but they are not the same problem
Testing the combination space
Ten options with five values each already produce millions of combinations. Nobody can click through all of them manually. Tests cover every rule, boundary values and pairs of options that commonly conflict. Random valid configurations can also be generated and checked against independent properties such as power, mass and certification
Before a catalogue change, a set of historical configurations runs again. If a previously orderable variant disappears, the team sees it before publication and can decide whether the change is intentional
When a calculator is enough
If every offered combination can be delivered and the main variation is quantity, time or scope, a quote calculator is simpler and clearer. If an invalid combination produces an impossible product, a wrong part or a safety risk, a configurator is required
For highly complex products, the first release does not need the entire catalogue. It is better to configure one product family from start to valid order code than to take every family only as far as an attractive summary. The professional result is not a selection screen. It is a tested, versioned specification