A product configurator determines how a product can be configured. A CPQ configurator uses product configuration as one part of a broader Configure, Price, Quote process. In manufacturing, that broader process may include engineering rules, calculations, costing, pricing, quote generation, bills of material (BOMs), CAD outputs and handoffs to enterprise systems.
The terms overlap because many modern manufacturing CPQ platforms contain a product configuration engine. However, they are not automatically interchangeable. A standalone product configurator may validate options and display a configured machine without calculating a commercial price or creating a production-ready BOM. A CPQ configurator normally connects the valid configuration to commercial and, depending on the implementation, engineering and operational outputs.
The practical distinction is therefore one of scope:
- Product configurator: focuses primarily on selecting and validating the product.
- CPQ configurator: configures the product and supports pricing, quoting and related downstream processes.
For a manufacturer selling pumps, industrial machinery, HVAC systems, electrical equipment or specialty vehicles, the right choice depends on whether the business needs only configuration guidance or needs to turn a validated configuration into an accurate, manufacturable commercial transaction.
What is a product configurator?
A product configurator is software that helps a user select valid features, options, dimensions, materials and components for a product. It applies product rules to prevent incompatible combinations and may calculate technical values or display the result visually.
For example, a pump product configurator might ask for:
- flow rate and discharge pressure;
- pump type and impeller diameter;
- motor voltage and power rating;
- casing material, such as cast iron or stainless steel;
- seal and bearing options;
- connection size and mounting arrangement.
The configurator can use dependencies and constraints to determine whether a chosen combination is valid. A stainless-steel casing may require a particular seal. A selected flow rate may require a larger impeller or motor. A voltage option may be unavailable for a specific motor size. If the user selects an incompatible combination, the system can block it, remove the option or explain what must change.
A product configurator can be deployed in several places, including a sales application, dealer portal, business-to-business ecommerce site, engineering application or internal product-selection tool. It may be a standalone application or a component within a larger CPQ, product lifecycle management (PLM), customer relationship management (CRM) or ecommerce architecture.
What is a CPQ configurator?
A CPQ configurator is the configuration component of CPQ software. CPQ stands for Configure, Price, Quote. It combines product configuration with commercial logic so that a valid product selection can become an accurate price and customer quote.
In a manufacturing environment, a CPQ configurator may perform the following sequence:
- Collect customer and application requirements.
- Guide the user through valid product options.
- Apply configuration rules and engineering constraints.
- Calculate dimensions, capacity, performance or other technical values.
- Determine the configured product structure.
- Calculate material, component, labor, freight or other costs where supported.
- Apply list prices, discounts, surcharges, regional pricing and margin rules.
- Generate a quotation with technical specifications and commercial terms.
- Create a configurable or product-specific BOM and send relevant data to ERP, PLM, CRM, CAD or manufacturing systems where integrations exist.
Not every CPQ product performs every step. Some systems focus on guided selling, pricing and proposals. Others extend into engineering automation, CAD generation and production data. Buyers should verify the actual scope of a platform rather than assuming that the word CPQ means it creates manufacturing-ready outputs.
CPQ configurator vs product configurator: key differences
| Dimension | Product configurator | CPQ configurator |
|---|---|---|
| Primary purpose | Select and validate a product configuration | Configure a product, calculate its commercial result and generate a quote |
| Main users | Customers, dealers, salespeople, engineers or product selectors | Sales, sales engineering, application engineering, commercial operations and sometimes customers or dealers |
| Core rules | Options, dependencies, exclusions and technical constraints | Configuration rules plus pricing, discount, approval and quoting rules |
| Output | Validated configuration, product summary or visual representation | Price, quote, technical specification and potentially BOM, CAD or order data |
| Pricing | Optional; may show no price or a simple price | Central capability, including prices, discounts, surcharges and margins |
| Engineering data | May use technical rules and calculations | May connect configuration to calculations, CAD automation and engineering workflows |
| Manufacturing integration | Usually optional and dependent on the product | Often designed to exchange data with ERP, PLM, CRM, CAD or manufacturing systems, although depth varies |
| Commercial approvals | Usually outside the main scope | May include discount, margin, exception and approval workflows |
The boundary is not absolute. A sophisticated product configurator can include pricing, while a CPQ platform may provide only limited engineering or manufacturing functionality. The useful question is not what label a vendor uses, but which inputs, rules and outputs the implementation supports.
Where the two concepts overlap
Both systems normally contain a product model. A product model describes the features, options, components, parameters and relationships that define a product family.
Both may support:
- feature and option selection;
- mandatory and optional components;
- dependencies and exclusions;
- compatibility rules;
- dimension and capacity limits;
- configuration validation;
- guided questions for nontechnical users;
- technical specifications or a configuration summary;
- visualization of the selected product.
The difference is what happens after a valid configuration is found. A product configurator may stop at the validated selection. A CPQ configurator generally passes that result into pricing and quoting services and may continue into order, engineering or production processes.
How configuration rules differ from pricing rules
Configuration rules answer: Can this product be built or sold in this combination? Pricing rules answer: What should this valid combination cost or sell for?
Configuration rules
Configuration rules describe product logic. Examples include:
- A 15 kW motor requires a larger frame than a 7.5 kW motor.
- A high-temperature seal is required when the operating temperature exceeds a defined threshold.
- A particular valve body material is unavailable with a selected pressure class.
- A truck body length requires a compatible chassis wheelbase.
- An electrical enclosure must meet a specified ingress-protection rating for an outdoor application.
These rules protect technical validity, safety, manufacturability and serviceability. They may be implemented as simple if-then rules, compatibility matrices, calculations or constraint-solving logic.
Pricing rules
Pricing rules convert the valid configuration into a commercial result. Examples include:
- adding the price of a stainless-steel casing;
- applying a regional price list;
- calculating a surcharge for a special coating;
- applying a dealer discount within an approved range;
- requiring approval when a quote falls below a target margin;
- calculating freight based on weight, dimensions or destination.
A product configurator can contain the first group without containing the second. A CPQ configurator is expected to connect both groups, although the sophistication of the pricing engine varies by product and implementation.
Manufacturing example: configuring an industrial pump
Consider a manufacturer selling centrifugal pumps for water treatment and industrial process applications.
A basic product configurator might guide a user through pump family, flow range, pressure, impeller size, motor, material and connection options. It would reject an invalid combination, such as a motor that cannot deliver the required duty point or a pressure class that is incompatible with the selected casing.
A CPQ configurator would use the same product logic but add commercial and operational outputs:
- The user enters the required flow, pressure, fluid temperature and material requirements.
- An engineering calculation identifies a suitable pump family and motor range.
- The rules engine filters incompatible impellers, seals, materials and accessories.
- The system selects or derives components for the configured assembly.
- The pricing engine calculates the equipment price, options, services and freight assumptions.
- The quote includes a technical description, performance information, exclusions, delivery assumptions and commercial terms.
- A configurable BOM or engineering BOM (EBOM) may be generated for review.
- After order acceptance, the configuration may be transferred to an enterprise resource planning (ERP) system or product lifecycle management (PLM) system for order processing and engineering control.
If the pump requires a new casing design, a nonstandard seal arrangement or a customer-specific mounting interface, the transaction may become engineer-to-order (ETO). In that case, the CPQ configurator can capture requirements and create a controlled engineering request, but it may not be able to complete the design automatically.
How a CPQ configurator fits into the manufacturing architecture
A CPQ configurator is usually an application layer between product and commercial data and the systems that manage customers, products and operations.
Product and engineering data
Product data may originate in PLM or product data management (PDM) systems, engineering databases, ERP item masters, CAD models or maintained CPQ product models. PLM manages product information and lifecycle processes; PDM generally focuses more narrowly on engineering files, revisions and relationships.
The CPQ model must represent sellable options and rules at a level that sales and engineering can maintain. It may not be a direct copy of the engineering structure. A customer-facing option such as “corrosion-resistant package” may map to several engineering components, documents and operations.
CRM and sales channels
Customer relationship management (CRM) systems manage accounts, opportunities and customer interactions. A CPQ configurator may be launched from CRM or embedded in a sales process. The configuration should be associated with the opportunity, customer, salesperson, dealer or project.
ERP and production systems
Enterprise resource planning (ERP) systems manage transactions such as orders, inventory, purchasing, manufacturing and financial records. A CPQ configurator may send a quote or order with item identifiers, quantities, prices, configuration attributes and BOM data to ERP.
A manufacturing BOM, or MBOM, represents how a product is assembled or produced. It may differ from an EBOM, which represents the engineering design structure. A CPQ implementation must define whether it creates an EBOM, an MBOM, a configurable BOM, or only a commercial list of selected components.
CAD and automation
Computer-aided design (CAD) automation can use configuration parameters to generate a product-specific model, drawing or document. This is more advanced than displaying a product image. It requires stable parametric models, controlled templates, mapping between configuration attributes and CAD parameters, and a process for handling exceptions.
Some CPQ configurators have CAD automation capabilities; others integrate with separate engineering automation tools; many do not generate CAD at all. This distinction is important when evaluating a platform for machinery or ETO products.
Types of product configuration inside CPQ
Rules-based configuration
Rules-based configuration uses explicit logic such as if-then statements, option dependencies, exclusions and formulas. It works well when product logic is known and can be maintained as business rules.
Constraint-based configuration
Constraint-based configuration represents permitted relationships and lets a solver find or validate combinations that satisfy multiple constraints. This can be useful for products with many interacting dimensions, capacities, materials and performance requirements.
Guided selling
Guided selling asks questions in business or application language and recommends suitable product options. It is useful when a dealer or salesperson understands the customer problem but not every technical attribute. Guided selling should not be confused with a complete engineering configurator: recommendations still need to be checked against authoritative product rules.
A manufacturing CPQ implementation may use all three approaches. Guided questions capture requirements, a rules engine validates the selection and calculations determine technical values. The resulting configuration then drives price and downstream outputs.
When a product configurator may be enough
A standalone product configurator may be appropriate when the main requirement is product selection rather than transaction automation. Examples include:
- helping customers select a standard motor or pump variant;
- showing compatible accessories for an existing product;
- providing a dealer-facing technical selection tool;
- displaying a visual configuration for a modular vehicle;
- validating options before a salesperson enters an order elsewhere;
- supporting engineering or service teams with product selection.
It may also be suitable when pricing is fixed and managed in another system, or when the company wants to separate configuration logic from commercial quoting.
When a CPQ configurator is more appropriate
A CPQ configurator is usually more suitable when configuration and commercial decisions are tightly connected. Typical indicators include:
- salespeople currently calculate prices manually in spreadsheets;
- different teams use different product and discount rules;
- quotes contain invalid options or omit required components;
- engineering reviews a large number of routine configurations;
- configured options affect cost, margin, delivery or freight;
- the company needs formal quote approvals;
- dealers need controlled pricing and configuration access;
- the quote must include technical specifications and a consistent BOM;
- the configuration must be transferred to CRM, ERP, PLM, CAD or manufacturing systems.
The business case is strongest when errors or delays occur at the boundary between sales, engineering and production. A CPQ configurator can encode repeatable product logic so that routine configurations do not require the same manual intervention as genuinely novel designs.
Important limitations and risks
Neither term guarantees a particular technical capability. A system called a CPQ configurator may provide only basic option selection and pricing. A product configurator may support complex engineering constraints but have no quote workflow.
Manufacturers should examine the following limitations:
- Product model complexity: large rule sets can become difficult to understand, test and change.
- Data ownership: product, price, cost and engineering data may be maintained in different systems with conflicting revisions.
- Rule maintenance: rules must change when components, suppliers, standards, designs and manufacturing methods change.
- Exception handling: unusual customer requirements may require ETO processes rather than forced configuration.
- BOM semantics: a commercial configuration does not automatically equal an engineering or manufacturing BOM.
- Integration boundaries: sending data to ERP or PLM requires agreed identifiers, revisions, units, statuses and error handling.
- CAD automation effort: automated drawings and models need controlled templates and engineering governance.
- Pricing governance: discounts, cost updates, currencies and regional price lists require ownership and release control.
- User experience: a technically correct configurator can still fail if questions are unclear or require engineering knowledge that salespeople do not have.
Implementation considerations for manufacturers
Define the required output first
Start by documenting what the configuration must produce. Possible outputs include a validated product selection, technical specification, price, quote, EBOM, MBOM, CAD model, drawing, work request, sales order or production package. Do not treat these outputs as equivalent.
Choose the right product scope
Begin with a product family where rules are reasonably stable and quoting effort is measurable. A focused pump, valve, enclosure or machine module may be a better starting point than the entire portfolio.
Separate configuration, pricing and engineering logic
These forms of logic interact but have different owners. Product management may own commercial options, engineering may own technical constraints, finance may govern margin rules and manufacturing may own assembly structures. The implementation should make these responsibilities visible rather than placing all logic in unstructured code.
Establish source-system responsibilities
Decide which system is authoritative for each data type:
- product revisions and engineering documents in PLM or PDM;
- items, inventory and order transactions in ERP;
- customer and opportunity data in CRM;
- pricing and discount policies in CPQ or an approved commercial system;
- CAD templates and parameters in the engineering environment.
In some businesses, CPQ becomes the operational source for the sellable product model while PLM remains the source for engineering-controlled data. That arrangement can work, but the synchronization and approval process must be explicit.
Test combinations and revisions
Testing should include valid and invalid combinations, boundary dimensions, obsolete components, regional pricing, discounts, units of measure, revision changes and integration failures. Manufacturers should also test whether an old quote remains reproducible after product or price rules change.
Plan for CTO, MTO and ETO
Configure-to-order (CTO) uses predefined options and standard modules. Make-to-order (MTO) produces an item after the order but may use a relatively stable design. Assemble-to-order (ATO) combines stocked modules after the order. Engineer-to-order (ETO) requires new or substantially modified engineering work.
A CPQ configurator is often most predictable for CTO and some MTO or ATO scenarios. It can support ETO by capturing requirements, estimating commercial impact and initiating engineering work, but it should not pretend that every ETO design can be reduced to a fixed option list.
Questions to ask when evaluating a CPQ configurator
- Can it represent dimensions, formulas, capacities and engineering constraints?
- Can non-developers maintain product rules safely?
- How are configuration rules tested and versioned?
- Can the system distinguish a sellable option from its underlying components?
- Does it calculate cost, price, margin, freight and lead-time effects?
- What exactly does “BOM generation” mean in the product documentation?
- Can it produce an EBOM, MBOM, configurable BOM or only a quote line list?
- Does it integrate with the company’s ERP, CRM, PLM, PDM and CAD systems?
- Can it create a controlled engineering request for exceptions?
- How are product, price and engineering revisions handled?
- Can dealers or distributors access a restricted product model and price list?
- Are APIs available for ecommerce, portals or custom applications?
- Can the implementation support multiple plants, regions, currencies and units?
- How are approvals and overrides recorded?
- What skills are required to maintain the model after go-live?
Conclusion
A product configurator is primarily concerned with selecting and validating a product. A CPQ configurator includes that capability but extends it into price calculation and quote creation. In manufacturing, the distinction becomes more significant because a configured product may also need technical calculations, a BOM, CAD outputs, engineering review and integration with ERP or PLM.
There is no universal boundary between the two categories. Some product configurators include commercial features, and some CPQ systems provide only limited manufacturing automation. The correct evaluation method is to map the required product rules, pricing logic, engineering outputs and system handoffs, then verify which capabilities are native, integrated or absent.
For a broader explanation of manufacturing CPQ architecture and use cases, see the manufacturing CPQ guide. Related topics include product configuration and rules engines, CAD and engineering automation, BOM generation, pricing and quoting and CPQ integrations.
Frequently asked questions
Is a CPQ configurator the same as a product configurator?
No. A CPQ configurator includes product configuration but also connects the result to pricing and quoting. A product configurator may stop after validating the selected product.
Can a product configurator calculate prices?
Some can. Pricing is an optional capability in a product configurator, while it is a central part of the CPQ model. Buyers should verify whether pricing supports discounts, surcharges, currencies, costs and margin rules.
Does every CPQ configurator generate a BOM?
No. BOM generation varies considerably. Some systems create a configurable BOM or quote component list, while others can produce an engineering or manufacturing BOM through an integration.
What is the main benefit of a CPQ configurator for manufacturers?
It connects a valid product configuration with an accurate commercial result and, where supported, structured engineering or production data. This reduces manual translation between sales, engineering and operations.
Can a product configurator support complex machinery?
Yes, if it supports the required rules, calculations and data structures. A simple option selector may be insufficient for machinery with interacting dimensions, performance requirements and component constraints.
What is guided selling?
Guided selling asks business-oriented questions and recommends suitable products or options. It can make a technical product configurator easier for salespeople and customers, but recommendations still need authoritative validation rules.
What is the difference between configuration rules and pricing rules?
Configuration rules determine whether a combination is technically or commercially valid. Pricing rules determine what that valid combination costs or should be sold for.
Can a CPQ configurator replace engineering?
Usually not. It can automate repeatable engineering decisions and route exceptions, but novel designs, safety reviews and nonstandard requirements may still require engineers.
Is CAD automation included in every CPQ configurator?
No. CAD automation is an advanced capability that may be native, delivered through a separate tool or unavailable. It requires parametric CAD models, templates, mappings and engineering governance.
Can a CPQ configurator support engineer-to-order products?
It can support parts of an ETO process, such as requirements capture, preliminary pricing and engineering-work requests. It may not automatically design every custom product.
What systems does a CPQ configurator connect to?
Depending on the implementation, it may connect to CRM, ERP, PLM, PDM, CAD, product information management (PIM), manufacturing execution systems (MES) and ecommerce channels. The specific integration depth must be verified.
Should product rules be stored in ERP or CPQ?
There is no universal answer. ERP is normally authoritative for transactions and inventory, while CPQ often manages the sellable configuration model. Responsibilities and synchronization should be defined during architecture design.
What is an EBOM?
An EBOM, or engineering bill of material, describes the product from an engineering design perspective. It may differ from an MBOM, which describes how the product is assembled or manufactured.
What is a configurable BOM?
A configurable BOM is a structure containing possible components and selection logic. A particular configuration resolves that structure into the components required for the selected product.
When is a standalone product configurator preferable?
It may be preferable when the main need is technical selection, compatibility validation or visualization, and pricing and order processing remain in another system.
When should a manufacturer choose CPQ instead?
CPQ is more appropriate when configuration directly affects price, margin, quote approvals, technical documents, BOMs, order data or the handoff from sales to engineering and production.
Semantic map
| Entity | Relationship | Related entity |
|---|---|---|
| CPQ configurator | configures and prices | configurable product |
| Product configurator | validates | product options and combinations |
| Configuration rules | prevent | invalid product combinations |
| Pricing rules | calculate | price, discount and margin |
| Configured product | can generate | configuration summary or BOM |
| EBOM | represents | engineering product structure |
| MBOM | represents | manufacturing assembly structure |
| CPQ | exchanges commercial data with | ERP and CRM |
| CPQ | may consume engineering data from | PLM, PDM and CAD |
| CAD automation | generates | configuration-specific models and drawings |
| CTO | uses | predefined product options and modules |
| ETO | requires | engineering work for nonstandard requirements |
| Guided selling | translates customer requirements into | product recommendations |