Manufacturing CPQ software should do more than produce a sales quote. It should help a manufacturer configure a valid product, apply engineering and commercial rules, calculate cost and price, generate accurate manufacturing data and transfer the result to downstream systems.
This manufacturing CPQ capabilities checklist covers the capabilities buyers should evaluate across product configuration, rules management, engineering automation, bills of materials, pricing, quoting, integrations, workflows, governance and implementation. Not every CPQ platform provides every capability. Some systems focus on guided selling and pricing, while others support deep product models, CAD automation, engineering calculations and production data.
For a general explanation of the category, see the guide to manufacturing CPQ. The most important evaluation principle is to assess the complete flow from customer requirements to an accepted quote and, where appropriate, to an order-ready engineering and manufacturing package.
What is manufacturing CPQ?
Manufacturing CPQ is software for configuring, pricing and quoting complex products whose valid design, cost and production requirements depend on customer selections and technical parameters. CPQ stands for Configure, Price, Quote.
In a manufacturing context, configuration may involve dimensions, materials, performance requirements, environmental conditions, motors, pumps, valves, electrical components, safety options, accessories and manufacturing constraints. The system may also calculate engineering values, generate a configurable bill of materials (BOM), create product-specific drawings or exchange data with enterprise systems.
This is different from generic sales CPQ, which may primarily select products, apply discounts and produce a proposal. Manufacturing CPQ can include those functions, but must also address product validity, engineering effort, production structure and downstream data quality.
Manufacturing CPQ capabilities checklist
Use the following checklist as a starting point for requirements gathering, demonstrations and requests for proposal. Mark each capability as required, desirable, not required or requiring integration with another system.
| Capability area | Questions to evaluate | Typical manufacturing outcome |
|---|---|---|
| Product model | Can the system represent variants, options, dimensions, materials, accessories and custom requirements? | A maintainable model of the product family |
| Rules and constraints | Can it prevent incompatible combinations and validate technical limits? | Fewer invalid configurations and engineering corrections |
| Engineering | Can it perform calculations or invoke engineering services? | Faster application engineering and more consistent sizing |
| BOM | Can it generate a configurable, engineering or manufacturing BOM? | More accurate order and production data |
| CAD | Can it drive parametric CAD, drawings or 3D output? | Product-specific engineering documentation |
| Cost and price | Can it calculate material, labor, overhead, freight, margin and discounts? | More controlled and explainable pricing |
| Quote | Can it create proposals with technical and commercial content? | Faster, more accurate customer documentation |
| Integration | Can it exchange data with ERP, CRM, PLM, PDM, CAD, PIM or MES? | Less rekeying between systems |
| Workflow | Does it support configure-to-order, engineer-to-order and approval processes? | A controlled path from opportunity to order |
| Governance | Can teams test, version, release and audit product logic? | Safer maintenance of product models |
1. Product configuration and product modeling
The product model is the foundation of manufacturing CPQ. It describes what can be sold, which options are available, what values are allowed and how a selected configuration affects engineering, pricing and production.
Evaluate whether the system can represent:
- Product families, models, platforms and variants
- Features, options, components and accessories
- Numeric inputs such as length, flow rate, capacity, voltage or payload
- Ranges, increments, units of measure and tolerances
- Materials, finishes, standards and certifications
- Optional, mandatory, default and mutually exclusive selections
- Customer-specific, regional, channel-specific or plant-specific availability
- Revisions, effective dates and discontinued components
- Reusable subassemblies and modular product structures
A strong product model separates reusable product knowledge from the user interface. For example, a pump family may contain a common base model, selectable impellers, motor variants, seal materials and control options. The model should also capture technical relationships such as required motor capacity for a specified flow and head, rather than relying only on a salesperson’s memory.
Read the detailed guide to product configuration, product models and configuration rules.
2. Rules, constraints and configuration validation
Rules determine whether a configuration is valid and what the system should do when a selection changes. A manufacturing CPQ evaluation should distinguish between rules-based configuration, constraint-based configuration and guided selling.
Rules-based configuration
Rules-based configuration uses explicit logic such as “if option A is selected, require component B” or “motor voltage 480 V is available only with control package C.” These rules are often suitable for product families with well-understood dependencies.
Constraint-based configuration
Constraint-based configuration evaluates technical relationships and limits. Examples include maximum shaft torque, allowable pressure, enclosure size, load capacity, temperature range or dimensional interference. A constraint engine may need to identify valid values within a range rather than simply show or hide a predefined option.
Guided selling
Guided selling asks questions about the customer’s application and recommends or narrows products. It can be useful for distributors and less technical sales users, but it does not automatically provide deep engineering validation. A guided questionnaire should be connected to authoritative product rules where technical correctness matters.
Check for support for dependency rules, exclusions, compatibility, minimum and maximum values, conditional requirements, calculations, warnings, hard errors, substitutions and explanation messages. Ask how rules are tested, versioned and traced to product documentation.
3. Engineering calculations and application logic
Some products require calculations before a valid design or price can be determined. Examples include pump selection, heat exchanger sizing, structural capacity, cable sizing, airflow, pressure drop, motor selection, battery capacity and vehicle payload.
Evaluate whether the CPQ system can:
- Perform calculations using formulas, lookup tables, curves or external services
- Handle units, conversions, rounding and engineering tolerances
- Use customer inputs such as flow, pressure, temperature, load or operating environment
- Return a recommended product, component or range of products
- Store calculation inputs and outputs with the configuration
- Explain assumptions and identify when engineering review is required
- Pass calculated values into pricing, BOM, CAD or documentation outputs
Calculation capability varies widely between platforms. A system may provide simple formulas but require a specialist engineering application for advanced sizing. Buyers should test representative calculations rather than accepting a generic claim that the platform supports engineering logic.
4. BOM generation and production structure
A bill of materials, or BOM, lists the components and quantities required for a product or assembly. Manufacturing CPQ may generate a configurable BOM, an engineering BOM (EBOM) or a manufacturing BOM (MBOM), but these terms are not interchangeable.
- Configurable BOM: a rules-driven structure that resolves into a product-specific component list based on selected options and parameters.
- EBOM: an engineering bill of materials organized around the designed product and its technical structure.
- MBOM: a manufacturing bill of materials organized around how the product is assembled or produced, including manufacturing-specific items and operations where supported.
Ask whether the CPQ system creates the BOM itself, resolves a BOM maintained in an ERP or product lifecycle management (PLM) system, or sends configuration data to another application that generates the BOM.
Important questions include whether the system supports quantities, substitutions, phantom assemblies, alternates, effectivity dates, units of measure, scrap factors, routings, labor operations and plant-specific structures. Also verify how changes are synchronized with ERP and PLM. A visually correct quote is not enough if the resulting order contains an incomplete or obsolete component structure.
Learn more about BOM generation, costing, pricing and quote automation.
5. CAD automation and engineering documents
Computer-aided design (CAD) automation uses configuration data to create or modify product-specific models, drawings or documentation. It is particularly valuable when dimensions, mounting arrangements, connections or component selections change from order to order.
Potential capabilities include:
- Driving parametric CAD dimensions and features
- Selecting components from approved libraries
- Generating 2D drawings, layouts or schematics
- Creating 3D models or lightweight visualization output
- Producing installation, manufacturing or customer approval documents
- Returning geometry, mass, dimensions or other calculated attributes to CPQ
- Submitting generated files to a product data management (PDM) or PLM system
CAD automation is not a standard feature of every CPQ platform. In some architectures, CPQ sends parameters to a CAD automation service, which returns files and metadata. In others, the CPQ system only links to existing drawings. Evaluate file ownership, revision control, regeneration time, failure handling and engineering approval.
See the guide to CAD and engineering automation in CPQ.
6. Costing and pricing logic
Pricing is separate from configuration. A system may validate a product without knowing its cost, and it may calculate a price for an invalid product if the two functions are not connected properly.
Manufacturing pricing requirements may include:
- Component, material and purchased-part costs
- Labor, machine time, setup and outside-processing costs
- Overhead, freight, packaging and installation charges
- Quantity breaks and volume pricing
- Customer, dealer, distributor and regional price lists
- Currency, tax, exchange-rate and effective-date rules
- Markup, margin and contribution calculations
- Minimum order values and surcharge logic
- Approval thresholds for discounts or margin exceptions
- Estimated cost for engineered or nonstandard work
Ask whether pricing uses real-time ERP costs, maintained CPQ tables, PLM data, supplier data or manual inputs. Determine how cost versions are controlled and whether a quote can preserve the price basis used at the time it was issued.
7. Quote and proposal generation
Quote generation should combine commercial terms with technically meaningful configuration information. A manufacturing quote may need to show performance data, dimensions, included accessories, exclusions, assumptions, delivery expectations, installation requirements and approval conditions.
Evaluate support for configurable quote templates, multiple languages and currencies, revisions, alternate configurations, line-item explanations, attachments, terms and conditions, electronic approval and customer acceptance. Check whether the quote stores the underlying configuration rather than only a rendered PDF.
A proposal document should not be treated as the system of record. The accepted configuration, price basis, revision and downstream identifiers should remain available for order processing and engineering handoff.
8. Workflow support: CTO, ETO, MTO and ATO
Manufacturing CPQ should reflect the company’s fulfillment model. The following terms describe different relationships between customer configuration and production.
| Workflow | Meaning | CPQ implication |
|---|---|---|
| Configure-to-order (CTO) | A product is assembled from predefined, validated options. | Strong configuration rules and a reliable resolved BOM are central. |
| Engineer-to-order (ETO) | Engineering work is created or modified for a specific order. | CPQ must capture requirements, trigger review and manage engineering deliverables. |
| Make-to-order (MTO) | Production begins after a customer order rather than from finished-goods stock. | Configuration and demand data must reach planning and production systems. |
| Assemble-to-order (ATO) | Standard components are assembled after the order is received. | Option compatibility and component availability are important. |
Some businesses use more than one model. A machinery manufacturer may use CTO for standard frame sizes, MTO for production scheduling and ETO for unusual process conditions. The CPQ workflow should route exceptions to application engineering instead of pretending every configuration is fully automatic.
Review related manufacturing CPQ workflows.
9. Integration capabilities
CPQ normally operates as part of a wider technology stack. Integration requirements should describe specific data exchanges rather than simply listing system names.
| System | Typical relationship with CPQ |
|---|---|
| Customer relationship management (CRM) | Receives opportunities and accounts; stores quote status, value and sales activity. |
| Enterprise resource planning (ERP) | Provides items, costs, prices, inventory or orders; receives configured order data and BOMs. |
| Product lifecycle management (PLM) | Manages product definitions, revisions, effectivity and engineering release information. |
| Product data management (PDM) | Stores and controls CAD files, drawings and related design data. |
| CAD | Receives parameters or configuration selections and returns models, drawings or attributes. |
| Product information management (PIM) | Provides commercial descriptions, media, specifications and channel content. |
| Manufacturing execution system (MES) | May receive production-relevant configuration, BOM or routing information. |
| Ecommerce and dealer portals | Expose approved configuration and pricing experiences to external users. |
Evaluate APIs, webhooks, batch interfaces, data ownership, error handling, authentication, monitoring and retry behavior. A technically possible integration may still be difficult if product identifiers, revisions, units or lifecycle states are inconsistent.
The CPQ integrations guide explains these relationships in more detail.
10. User experiences and channels
Different users need different levels of product knowledge. Sales representatives may need guided questions and explanations. Application engineers may need detailed parameters and calculation results. Dealers may need restricted product ranges and customer-specific pricing. Customers using self-service configuration need clear validation messages and controlled choices.
Check whether the platform supports role-based access, internal and external portals, dealer-specific catalogs, mobile or responsive interfaces, localization, accessibility, saved configurations, comparison of alternatives and assisted configuration. Channel flexibility should not allow an external user to bypass engineering rules or release uncontrolled products.
11. Governance, testing and maintainability
Product logic becomes a maintained engineering asset. Evaluate how administrators manage changes to rules, components, prices, documents and integrations.
- Version control for product models and rules
- Approval and release workflows
- Effective dates and revision handling
- Role-based permissions
- Audit history and change ownership
- Automated regression testing for common configurations
- Test cases for invalid combinations and boundary values
- Sandbox environments and controlled deployment
- Monitoring for integration failures and calculation errors
- Dependency analysis before retiring or changing a component
Ask who can maintain the model after implementation. If every rule change requires custom development, the operating cost may be high. If too many users can change production rules without review, configuration risk increases.
12. Analytics and operational measurement
Useful analytics should connect commercial activity with product and operational outcomes. Examples include quote cycle time, configuration abandonment, use of engineering review, invalid selections, discount exceptions, win rate by product family, margin by configuration, frequently selected options and recurring manual corrections.
Analytics should distinguish between a quote that was created quickly and a quote that was correct, profitable and accepted without downstream rework. Where possible, compare CPQ data with ERP orders, engineering changes and production issues.
Benefits and limitations
Potential benefits
- Shorter turnaround for standard and moderately complex configurations
- Fewer incompatible product selections
- More consistent application of engineering and pricing rules
- Reduced manual re-entry between sales, engineering and operations
- More accurate BOM and order data
- Better visibility into margins, exceptions and product demand
- More scalable support for dealers and distributed sales teams
Important limitations
- A CPQ project cannot compensate for undocumented or contradictory product knowledge.
- Deep ETO processes may still require engineering review and CAD work.
- Complex rules can become difficult to maintain without ownership and testing.
- Real-time cost and availability depend on the quality and responsiveness of source systems.
- CAD automation requires stable templates, engineering standards and failure handling.
- A generated BOM may not be equivalent to an ERP or PLM-approved production structure.
- Highly customized user interfaces can increase implementation and maintenance effort.
How to use the checklist in a CPQ evaluation
- Map the current workflow. Document how a requirement becomes a quote, order, engineering package and production record.
- Select representative products. Include a standard configurable machine, a dimension-driven product and an ETO example if those are part of the business.
- Capture rules and data sources. Identify product owners, component masters, cost sources, CAD templates, BOM authorities and approval roles.
- Separate required capabilities from integration responsibilities. Decide whether CPQ, ERP, PLM, CAD or another service owns each function.
- Test realistic scenarios. Include valid configurations, invalid combinations, boundary values, revisions, alternatives and exceptional engineering requests.
- Evaluate the operating model. Confirm who maintains models, tests changes, releases prices and handles errors.
- Measure business outcomes. Define KPIs such as quote lead time, engineering touches, correction rate, margin leakage and order-entry quality.
For a broader project plan, use the manufacturing CPQ implementation guide. For software selection, compare documented capabilities using the criteria in the manufacturing CPQ comparisons and selection guidance.
Semantic map
The following relationships summarize how manufacturing CPQ connects product knowledge, engineering, commercial logic and enterprise execution.
- Manufacturing CPQ connects customer requirements with product configuration, pricing and production data.
- Product models define available features, components, dimensions and variants.
- Configuration rules prevent invalid combinations and identify required dependencies.
- Engineering calculations transform application requirements into technical selections.
- A configured product resolves into a product-specific BOM.
- CAD automation generates product-specific models, drawings or documentation.
- Costing logic converts components, labor and overhead into estimated cost.
- Pricing logic converts cost, margin, discounts and commercial terms into a quote price.
- CRM supplies opportunity context while ERP manages order and resource transactions.
- PLM and PDM manage released product and design information.
- CTO uses validated options while ETO introduces engineering review and custom work.
- Governance controls rule revisions, approvals, testing and release.
Frequently asked questions
1. What capabilities should manufacturing CPQ software have?
At minimum, evaluate product modeling, configuration validation, pricing, quoting, version control and integration with the systems that own product and commercial data. Complex manufacturers may also require engineering calculations, BOM generation, CAD automation and ETO workflows.
2. Is manufacturing CPQ the same as sales CPQ?
No. Sales CPQ often focuses on selecting items, pricing, discounts and proposals. Manufacturing CPQ may also validate technical requirements, resolve components, calculate engineering values and create data for engineering or production.
3. Does every CPQ system generate a BOM?
No. Some systems generate or resolve BOMs, while others send configuration data to ERP, PLM or a dedicated product configuration service. Verify the exact BOM type, ownership and downstream process.
4. What is the difference between a configurable BOM and an EBOM?
A configurable BOM contains rules for resolving a product-specific structure. An EBOM is an engineering bill of materials organized around the designed product. A configurable BOM may produce an EBOM, but the two are not automatically identical.
5. Can CPQ replace ERP?
Usually not. CPQ manages configuration and quoting decisions, while enterprise resource planning (ERP) manages transactions such as orders, inventory, purchasing, production planning and financial records. The systems generally need an integration boundary.
6. Can CPQ replace PLM or PDM?
Not necessarily. Product lifecycle management (PLM) and product data management (PDM) typically govern released product definitions, engineering changes and CAD files. CPQ may consume or extend that information for selling and configuration.
7. Does manufacturing CPQ support engineer-to-order products?
Some platforms support ETO requirements capture, engineering review, task routing and document generation. Others are better suited to predefined CTO products. Buyers should test how custom requirements, approvals and engineering changes are handled.
8. What engineering calculations can CPQ perform?
Capabilities range from formulas and lookup tables to specialized sizing services. Examples include pump selection, motor sizing, load calculations, pressure drop and dimensional checks. The required depth must be tested using real engineering cases.
9. Is CAD automation included in CPQ?
Not always. Some platforms include or connect to CAD automation, while others only store links or attachments. Verify supported CAD tools, template requirements, output formats, revision handling and error management.
10. How does CPQ improve BOM accuracy?
It applies configuration rules consistently and resolves selected options into component quantities and structures. Accuracy still depends on maintained product data, correct rules, revision control and successful integration with the authoritative BOM system.
11. Can CPQ calculate manufacturing cost?
Many manufacturing-oriented systems can calculate or import cost elements, but the depth varies. Confirm support for materials, labor, machine time, overhead, outside processing, freight, scrap and plant-specific cost sources.
12. What is the role of guided selling?
Guided selling helps users reach an appropriate product by asking application questions and narrowing choices. It is useful for sales and dealers, but it should be backed by technical rules when an incorrect selection could create an invalid product.
13. Should CPQ own product data?
There is no universal answer. CPQ may own selling-specific options and rules, while PLM, ERP or PIM owns engineering, item or marketing data. The important requirement is explicit ownership, synchronization and revision control.
14. How should manufacturers evaluate CPQ rules engines?
Use realistic tests involving dependencies, exclusions, numeric ranges, calculations, warnings, hard errors, effective dates and revisions. Also evaluate how non-developers create, test, explain and release rules.
15. What integrations are most important for manufacturing CPQ?
Common integrations include CRM for opportunities, ERP for items and orders, PLM or PDM for product and CAD data, and sometimes MES for production execution. The priority depends on where product, cost, BOM and order data are mastered.
16. Can CPQ support dealers and distributors?
Yes, where the platform supports channel-specific catalogs, permissions, pricing, configuration guidance and quote workflows. Manufacturers should ensure dealer-facing choices remain within approved technical and commercial boundaries.
17. How does CPQ handle product revisions?
Better platforms support versioned product models, effective dates, approvals and audit history. Confirm how a previously issued quote retains the rules, prices and components that applied when it was created.
18. What are common manufacturing CPQ implementation risks?
Common risks include incomplete product knowledge, unclear system ownership, excessive custom rules, untested edge cases, unreliable integrations and insufficient governance. A phased implementation with representative products can expose these issues early.
19. What KPIs should be used after implementation?
Useful measures include quote turnaround time, engineering review effort, configuration error rate, order-entry corrections, margin exceptions, quote-to-order conversion and the time required to release product-model changes.
20. Where does AI fit in manufacturing CPQ?
AI may assist with natural-language requirements, recommendations, anomaly detection or configuration analysis. It should not bypass deterministic engineering constraints or release uncontrolled product and production data. See the guide to AI-assisted CPQ.