Configure, Price, Quote (CPQ) software helps manufacturers convert customer requirements into a valid product definition, an accurate price and a formal quotation. In manufacturing, CPQ may also calculate engineering values, select compatible components, generate a configurable bill of materials, create product-specific drawings or CAD outputs, and transfer order data to enterprise systems.
CPQ is not simply a tool for applying discounts to a sales opportunity. For an industrial pump, packaging machine, electrical enclosure, material-handling system or specialty vehicle, the quoted product may depend on dimensions, materials, performance calculations, certifications, environmental conditions, production methods and compatibility rules. Manufacturing CPQ manages these relationships so that sales, engineering and operations work from the same product logic.
The exact scope varies by platform and implementation. Some products focus mainly on guided selling, pricing and proposal generation. Others include deep configuration rules, engineering calculations, configurable BOM generation, CAD automation and integrations with enterprise resource planning (ERP), product lifecycle management (PLM) or computer-aided design (CAD) systems.
This guide explains the meaning of configure, price and quote in a manufacturing context, how CPQ fits into the technology stack, what data it requires, where it provides value and which limitations manufacturers should consider.
For a broader overview, see the guide to manufacturing CPQ software.
What does Configure, Price, Quote mean?
Configure, Price, Quote describes three connected activities:
- Configure: select a valid product structure and resolve technical requirements, options, dimensions, components and constraints.
- Price: calculate material, labor, overhead, purchased components, services, margins, freight, discounts, taxes or other commercial values according to company policy.
- Quote: present the configured solution, commercial terms, assumptions, delivery information and price in a customer-facing quotation.
In a basic sales CPQ system, these steps may involve selecting predefined products and applying pricing rules. In manufacturing CPQ, the configure step can be an engineering activity. It may determine motor size, shaft diameter, structural capacity, heat-transfer area, electrical rating, enclosure dimensions or the components required to build the product.
The three activities are related but not interchangeable. A product can be technically valid but priced incorrectly. A price can be accurate for a standard product but unsuitable for a custom design. A professional quote can still contain an invalid configuration. Manufacturing CPQ is valuable when it connects the technical, commercial and document processes rather than treating them as separate spreadsheets.
How manufacturing CPQ works
A manufacturing CPQ implementation usually combines a product model, rules, calculations, pricing data, document templates and integrations. The user interface may be used by an application engineer, salesperson, dealer, distributor, customer or internal estimator. The underlying model determines what can be selected and what downstream data is produced.
1. Capture customer and application requirements
The process often begins with requirements rather than a product number. A customer may specify flow rate, pressure, operating temperature, throughput, payload, travel distance, voltage, available space, material compatibility or regulatory requirements.
A guided questionnaire can collect these values and recommend suitable product families. This is called guided selling. Guided selling helps users navigate choices, but it does not necessarily prove that a technically complex product is manufacturable. A deeper configuration model is required when selections affect engineering calculations, component compatibility or production data.
2. Select and validate the product configuration
The CPQ product model defines products, variants, options, features, attributes, dependencies and constraints. Rules can make an option mandatory, exclude an incompatible combination, require an additional component or calculate a value from other inputs.
For example, a pump configuration may include a flow rate, pressure, fluid type, impeller material, seal arrangement, motor, baseplate and control panel. Rules could prevent a material choice that is incompatible with the fluid, require a particular seal for a temperature range, or select a motor based on calculated power.
Rules-based configuration evaluates explicit conditions such as if-then relationships. Constraint-based configuration represents permissible relationships among variables and searches for solutions that satisfy those constraints. A platform may support one approach or a combination of both. Buyers should verify how rules are authored, tested, versioned and maintained.
More information about product models and validation is available in the manufacturing product configuration guide.
3. Perform calculations and engineering checks
Some products can be configured by selecting catalog options. Others require calculations. A CPQ system may calculate required heating capacity, structural load, belt length, pressure drop, motor power, cable size or enclosure dimensions. It may call an external calculation service or exchange data with engineering software rather than performing every calculation internally.
Calculation results can influence the configuration. For example, a conveyor length and payload may determine frame size, drive selection and support spacing. A configured air-handling unit may require a different coil, fan and casing based on airflow and temperature conditions.
Calculation capability should not be assumed from the presence of a product configurator. Manufacturers should ask whether the system supports formulas, units, tolerances, engineering libraries, external calculation services, validation and auditability. The CAD and engineering automation guide covers related design and drawing workflows.
4. Generate product and manufacturing data
Once the configuration is valid, CPQ may generate structured product data. The output can include a configured product identifier, option codes, component quantities, routing choices, technical specifications and manufacturing notes.
A bill of materials (BOM) is a structured list of the components and quantities required for a product. Manufacturing implementations must distinguish between different BOM types:
- Configurable BOM: a rule-driven structure containing alternatives, options or conditional components before a specific order is finalized.
- Engineering BOM (EBOM): a design-oriented structure managed by engineering, often representing how a product is designed.
- Manufacturing BOM (MBOM): a production-oriented structure organized for assembly, fabrication, work instructions and manufacturing processes.
CPQ may create a configurable BOM, a sales or order BOM, an EBOM, an MBOM, or an input for another system. These are not equivalent outputs. The target structure depends on the company’s ERP, PLM, PDM and manufacturing processes.
5. Calculate cost and selling price
The price engine combines the configured product with commercial rules. It may use component prices, supplier costs, labor estimates, machine time, overhead allocations, engineering charges, setup fees, freight, currency rules, customer agreements, volume breaks and margin policies.
Cost and price should be modeled separately. Cost estimates help the manufacturer understand expected profitability. Selling price may include a margin, negotiated discount, risk allowance or market-specific adjustment. A quotation may also include non-product services such as installation, commissioning, training and maintenance.
Pricing rules must account for effective dates and product revisions. A component cost may change without changing the engineering rule, while a product revision may change both the component and the valid options. Governance is needed so users cannot unintentionally quote obsolete prices or discontinued components.
6. Generate and approve the quote
The quote normally includes the configured product description, technical specifications, line items, price, currency, delivery assumptions, validity period, payment terms, exclusions, warranty information and commercial conditions. Document generation may use templates populated from the CPQ data.
Approval workflows can route quotes for review when they exceed a discount threshold, contain non-standard terms, require unusual engineering work or fall below a target margin. Approval is a control mechanism, not a substitute for correct configuration rules.
Manufacturing CPQ architecture
Manufacturing CPQ generally sits between customer-facing sales channels and systems of record. It may be used inside a CRM, as a standalone application or through a web interface used by dealers and distributors. The architecture differs by vendor and implementation, but common data relationships include the following:
| System or capability | Typical responsibility | Relationship with CPQ |
|---|---|---|
| CRM | Customer, opportunity and account management | Provides commercial context and receives quote or opportunity status |
| ERP | Items, inventory, purchasing, orders, costs and financial processes | Receives configured items, prices, BOMs or sales orders where supported |
| PLM | Product definitions, revisions, lifecycle and engineering change control | Provides governed product and revision data or receives approved configurations |
| PDM | Product data and document management, often for CAD files | Stores or supplies controlled engineering files and metadata |
| CAD | Geometric design and engineering documentation | May receive parameters from CPQ or generate product-specific models and drawings |
| PIM | Product information for catalogs and commerce channels | May supply descriptions, media and attributes for customer-facing configuration |
| MES | Manufacturing execution, production tracking and shop-floor data | May receive released product or order information through ERP or other integration |
These systems are not interchangeable. ERP is not a product rules engine, PLM is not automatically a quoting tool, and CAD does not by itself provide commercial pricing. CPQ can coordinate data between them, but the system of record for each data type must be defined.
Manufacturing examples
Industrial pump
A customer provides flow, pressure, fluid, temperature and installation requirements. CPQ selects a pump family, calculates or validates duty requirements, filters materials and seals, selects an impeller and motor, and produces a price. It may generate a configurable BOM and technical datasheet. If the design requires a new casing or non-standard geometry, the configuration may trigger an engineering review rather than an automatic order.
HVAC unit
An air-handling unit may depend on airflow, external static pressure, temperature, humidity, filtration, coil arrangement, fan type, casing material, controls and site dimensions. A valid configuration can determine component selection, estimated performance, dimensions and price. CAD or drawing automation may produce a customer-specific layout, but only if the implementation connects the CPQ model to an appropriate engineering automation process.
Electrical enclosure
An enclosure configuration may include width, height, depth, ingress protection, material, door arrangement, gland plates, thermal management, mounting hardware and electrical accessories. Rules can prevent incompatible dimensions or require cooling equipment when heat dissipation exceeds a limit. The resulting BOM and drawings may need review before release to production.
Specialty vehicle
A vehicle builder may configure chassis, wheelbase, body modules, payload, drive system, seats, safety equipment and accessories. The product model must manage dependencies between physical space, load capacity, electrical systems and regulatory requirements. Dealer-facing configuration may be simpler than the engineering model, with restricted access to advanced options.
Manufacturing CPQ compared with generic sales CPQ
Generic sales CPQ often focuses on selecting products, applying discounts and generating proposals. That is useful for standard goods, but it may not address the technical consequences of configuration.
| Area | Generic sales CPQ emphasis | Manufacturing CPQ emphasis |
|---|---|---|
| Product model | Catalog items, bundles and options | Variants, dimensions, dependencies, constraints and engineering attributes |
| Validation | Commercial eligibility and option compatibility | Technical, dimensional, performance and manufacturability constraints |
| Pricing | List price, discounts and contracts | Configured cost, labor, material, margin, engineering and production impacts |
| Output | Proposal and order details | Proposal plus specifications, BOM, calculations, drawings or engineering work packages where supported |
| Workflow | Sales approval and contract process | Sales, application engineering, design, planning and production handoff |
Not every manufacturing CPQ product supports every capability in the right-hand column. The term describes a use case and scope, not a guarantee of functionality. Evaluation should focus on the product complexity and downstream outputs the manufacturer actually requires.
How CPQ relates to CTO, ETO, MTO and ATO
Manufacturing organizations use several fulfillment models:
- Configure-to-order (CTO): a customer selects from predefined options and the product is assembled or completed after the order.
- Engineer-to-order (ETO): the customer requirement leads to new or substantially modified engineering work before production.
- Make-to-order (MTO): production starts in response to a customer order rather than forecast stock, although the design may be standard.
- Assemble-to-order (ATO): stocked or planned modules are assembled into a customer-selected combination.
CPQ is often easiest to standardize for CTO and ATO products because the valid solution space is known. It can also support ETO by collecting requirements, applying standard rules, estimating engineering effort and creating an engineering handoff. However, CPQ does not eliminate the need for engineering judgment when a solution falls outside the product model.
The manufacturing workflow guide explains how CPQ supports configure-to-order and engineer-to-order processes.
Benefits of CPQ for manufacturers
- Faster quote preparation: sales and application engineers can reuse controlled product logic instead of rebuilding calculations in spreadsheets.
- Fewer configuration errors: rules can block incompatible options before a quote reaches engineering or production.
- More consistent pricing: cost and price logic can be applied consistently across sales teams, regions and dealer channels.
- Reduced engineering rework: standard configurations can arrive with structured requirements, calculations and component selections.
- Better sales-to-engineering handoff: the technical decisions made during quoting can be retained as structured data.
- Improved product governance: revisions, effective dates, approvals and rule ownership can be managed more systematically.
- More complete customer communication: quotes can include relevant specifications, assumptions, images and configuration details.
Limitations and risks
CPQ does not repair poor product data automatically. If options, costs, drawings, part numbers or rules are incomplete, the system can produce incomplete or misleading results more quickly.
Complexity is another risk. A product model that contains every historical exception may become difficult to understand and maintain. Manufacturers should separate standard configurable products from genuinely exceptional ETO work where possible.
Integrations also require careful design. Duplicate item masters, inconsistent units, conflicting revision states and unclear ownership can create errors between CPQ, ERP, PLM, PDM and CAD. A successful quote does not necessarily mean that an order can be manufactured without additional translation.
Finally, calculated outputs may need engineering approval. A CPQ result should not be treated as a certified design unless the organization has validated the formulas, design limits, applicable standards and release process.
Implementation considerations
Start with a defined product scope
Select a product family with measurable business value and a manageable configuration boundary. Document standard options, variables, exceptions, calculations, component relationships, pricing inputs and required outputs.
Assign ownership of rules and data
Product management, engineering, sales operations, finance, manufacturing and IT may each own different parts of the model. Define who approves rules, who maintains costs, who controls revisions and who tests changes.
Model the workflow, not just the screen
Map the path from inquiry to quote, approval, order, engineering release and production. Identify when the configuration becomes authoritative and which system owns the resulting item, BOM, drawing or order.
Test combinations and edge cases
Testing should include valid combinations, invalid combinations, boundary values, discontinued components, unit conversions, currency changes, revision changes, discounts, approval thresholds and integration failures. Regression testing is important whenever product rules change.
Measure operational outcomes
Useful measures may include quote cycle time, first-pass configuration accuracy, engineering hours per quote, quote-to-order conversion, margin variance, approval time, percentage of quotes requiring rework and time from order to production release. The appropriate measures depend on the manufacturer’s baseline and process goals.
For a structured approach, use the CPQ implementation guide and review the CPQ integration architecture guide.
What to evaluate in manufacturing CPQ software
Manufacturers should evaluate capabilities against actual product and workflow requirements rather than generic feature counts. Important questions include:
- Can the system model dimensions, quantities, dependencies, exclusions and conditional components?
- Can non-technical users maintain rules without uncontrolled custom code?
- Does it support calculations, units, tolerances and external engineering services?
- Which BOM types can it create, and how are revisions handled?
- Can it connect to CAD, PLM, PDM, ERP and CRM systems through supported interfaces?
- Does it support CTO, ATO, MTO or ETO workflows, and where are the boundaries?
- Can it manage configurable costs, customer-specific pricing, currencies and approvals?
- Can dealer, distributor, ecommerce or self-service users access a controlled subset of the model?
- How are rules tested, versioned, released and audited?
- What happens when a configuration requires engineering review or falls outside the standard model?
Vendor capabilities must be verified in product documentation, demonstrations using representative products and, where appropriate, a proof of concept. A platform that generates attractive quotes may still be unsuitable if it cannot produce the manufacturing data or integration outputs required by the business. See the manufacturing CPQ comparison and selection resources for additional evaluation criteria.
Semantic map
The following relationships summarize the main entities and processes discussed in this guide:
- CPQ configures configurable products.
- Configuration rules prevent invalid combinations.
- Constraint-based configuration validates technical relationships.
- Guided selling collects customer requirements.
- Engineering calculations determine product parameters.
- A configured product generates structured product data.
- A configured product may generate a BOM.
- An EBOM represents the engineering product structure.
- An MBOM represents the manufacturing product structure.
- Pricing rules calculate selling prices.
- Cost data supports margin analysis.
- CPQ generates customer quotations.
- CAD automation generates product-specific drawings.
- CPQ exchanges item and order data with ERP.
- CPQ exchanges lifecycle data with PLM.
- CPQ supports sales-to-engineering handoff.
- CTO uses predefined configurable options.
- ETO requires engineering work for non-standard requirements.
Frequently asked questions
What is CPQ software for manufacturing?
Manufacturing CPQ software models configurable products, validates technical choices, calculates costs and prices, generates quotes and may produce BOMs, calculations, drawings or integration data for downstream systems.
What does CPQ stand for?
CPQ stands for Configure, Price, Quote: configure a valid solution, calculate its commercial value and produce a formal quotation.
Is manufacturing CPQ the same as sales CPQ?
No. Sales CPQ may focus on catalog selection, discounts and proposals. Manufacturing CPQ may also manage engineering constraints, calculations, BOMs, CAD outputs and production handoffs.
Does every CPQ system generate a BOM?
No. BOM generation varies by product. Some systems produce configurable or order BOMs, while others integrate with ERP or PLM and leave BOM creation to those systems.
Can CPQ replace an ERP system?
No. ERP systems manage broader processes such as inventory, purchasing, finance, production orders and fulfillment. CPQ may exchange configured product and order data with ERP.
Can CPQ replace PLM?
No. Product lifecycle management (PLM) manages product definitions, revisions, changes and lifecycle governance. CPQ may consume approved PLM data or return configuration information.
Can CPQ automate CAD?
Some platforms support CAD or engineering automation, directly or through integrations. Others only generate specifications and quotes. CAD automation must be verified for the required CAD system and product family.
What is the difference between product configuration and pricing?
Product configuration determines what can technically be sold or built. Pricing determines the cost and selling price of that selected solution. The two processes can share data but solve different problems.
What is a configuration rule?
A configuration rule defines a relationship between product choices or values. For example, selecting a high-temperature fluid may require a particular seal and exclude a standard elastomer.
What is constraint-based configuration?
Constraint-based configuration represents limits and relationships among variables, such as capacity, dimensions and compatibility, and validates or searches for solutions that satisfy those constraints.
What is guided selling in CPQ?
Guided selling uses questions, recommendations and simplified choices to help a user identify a suitable product. It may assist configuration but is not automatically a complete engineering validation method.
Can CPQ support engineer-to-order products?
Yes, in some implementations. CPQ can collect requirements, apply standard rules, estimate engineering effort and create a handoff, but it does not remove the need for engineering design and approval.
What is the difference between EBOM and MBOM?
An EBOM is organized around the engineering design. An MBOM is organized around how the product is manufactured and assembled. A CPQ output may be either, neither or an input to another system.
How does CPQ connect with CRM?
Customer relationship management (CRM) systems manage accounts, opportunities and sales activities. CPQ may run within or alongside CRM and attach configurations, prices and quotes to the opportunity.
How does CPQ connect with CAD?
CPQ can pass configuration parameters to CAD automation, receive engineering attributes or link product-specific files. The exact integration depends on the platform, CAD system and data model.
Who maintains CPQ product rules?
Ownership is usually shared. Engineering may own technical rules, product management may own options, finance may own pricing policies and IT may own integrations. Governance must define approval and release responsibilities.
How long does a manufacturing CPQ implementation take?
There is no universal timeframe. Scope depends on product complexity, data quality, integrations, calculations, CAD requirements, workflow changes and the number of channels or product families.
What is the biggest CPQ implementation risk?
A common risk is trying to automate an unclear or poorly governed product model. Manufacturers should establish product boundaries, rule ownership, data quality and downstream requirements before scaling the implementation.
Can customers configure products directly online?
Some CPQ implementations support ecommerce or self-service configuration. The customer-facing model usually needs controlled options, clear explanations and safeguards so that sensitive engineering or pricing logic is not exposed unnecessarily.
How should a manufacturer test CPQ rules?
Testing should cover valid and invalid combinations, boundary conditions, revisions, costs, discounts, units, approvals, integration failures and representative products. Regression testing is needed after rule changes.