Manufacturing CPQ Requirements: Functional and Technical Checklist

Manufacturing CPQ requirements should cover the complete path from product selection to production-ready data. A suitable system must do more than apply discounts and generate a proposal. It should represent configurable products, enforce engineering constraints, calculate prices and costs, produce accurate quotes, and provide usable data to engineering, enterprise resource planning (ERP) and production systems.

This checklist is intended for manufacturers of machinery, equipment, vehicles, pumps, valves, electrical systems and other complex products. It separates functional requirements from technical, integration, governance and implementation requirements. Not every configure, price, quote (CPQ) platform supports every capability. Buyers should verify each requirement against documented product behavior, not assume that a feature exists because it is commonly associated with manufacturing CPQ.

For broader context, see the guide to manufacturing CPQ and the detailed guide to product configuration.

What are manufacturing CPQ requirements?

Manufacturing CPQ requirements are the business, functional and technical capabilities needed for a CPQ system to configure engineered products, calculate commercial results and exchange reliable information with downstream systems.

Manufacturing CPQ normally combines several related disciplines:

Product configuration: selecting valid options, dimensions, materials, accessories and features.
Rules and constraints: preventing incompatible or unsafe combinations and guiding users toward valid designs.
Engineering automation: performing calculations, selecting components and, where supported, creating CAD outputs.
Pricing and costing: calculating list price, discounts, labor, material cost, freight, margin and other commercial values.
Quoting: producing a quote, proposal or order-ready commercial package.
Manufacturing data: generating a configurable bill of materials (BOM), routings, item references or engineering outputs where supported.
Integration: exchanging data with customer relationship management (CRM), ERP, product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD), product information management (PIM) and manufacturing execution system (MES) applications.

Generic sales CPQ may focus mainly on products, prices, discounts, approvals and documents. Manufacturing CPQ adds product structure, technical validity, engineering intent and production consequences.

Start with a manufacturing CPQ scope statement

Before writing a feature checklist, define what the system must control. A requirement for a standard configurable pump is different from a requirement for a fully engineered process skid or a custom agricultural vehicle.

Document the following scope dimensions:

Product families, models and variants in scope.
Configurable attributes such as capacity, dimensions, voltage, pressure, material, finish, motor type and environmental rating.
Sales channels, including direct sales, dealers, distributors, ecommerce and internal application engineering.
Manufacturing strategies, such as configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO), assemble-to-order (ATO) and standard make-to-stock products.
Required outputs, including quote documents, order lines, configurable BOMs, drawings, calculations, specifications and manufacturing instructions.
Systems that own product, customer, price, engineering and production data.
Users, regions, languages, currencies, legal entities and approval responsibilities.

A clear scope prevents a common procurement error: selecting a sales quoting tool for a problem that actually requires product modeling, engineering automation or production integration.

Functional requirements checklist

1. Product model and configuration requirements

The product model is the structured representation of what can be sold and how it can be configured. It may include product families, option groups, attributes, components, variants, documents, prices and manufacturing relationships.

Confirm whether the system can:

Represent multiple product families and model generations.
Separate mandatory, optional, conditional and mutually exclusive options.
Represent numeric values, ranges, units of measure, dimensions and tolerances.
Support materials, coatings, colors, ratings, standards and certifications.
Reuse common components and rules across product families.
Support nested assemblies and configurable subassemblies.
Maintain product revisions and effective dates.
Distinguish a commercial option from an engineering component or manufacturing item.
Store explanatory text, technical specifications, images, drawings and customer-facing descriptions.
Support multiple languages, currencies and regional product availability.
Record why a configuration choice was made and which rules produced it.

For example, a pump model may expose flow rate, head, impeller material, seal type, motor voltage and connection size. The configuration model must ensure that the selected motor can provide the required duty and that the material and seal combination is suitable for the specified fluid.

2. Rules, constraints and validation

Rules determine what the user may select and what the system should calculate or recommend. A serious evaluation should distinguish three related approaches:

Approach	Purpose	Manufacturing example
Rules-based configuration	Applies explicit if-then logic and dependencies.	If a machine uses a high-temperature option, require a compatible seal and insulation package.
Constraint-based configuration	Finds or validates combinations against technical, dimensional or resource constraints.	Select a motor, gearbox and frame that satisfy torque, speed, voltage and envelope limits.
Guided selling	Uses questions and recommendations to simplify selection for a user.	Ask about required throughput and installation conditions, then recommend suitable machine configurations.

Requirements should cover:

Option compatibility and incompatibility rules.
Dependencies between dimensions, performance values and components.
Minimum and maximum values, permitted increments and unit conversions.
Capacity, load, pressure, temperature, power, speed and safety calculations.
Rules that select or suppress BOM items.
Warnings, hard errors and approval-triggering exceptions.
Rule priorities when multiple rules affect the same result.
Traceability from a validation message to the rule or source data.
Testing of positive, negative, boundary and regression cases.

Ask vendors how rules are authored, versioned, tested and deployed. A rule engine that is powerful but only maintainable by custom programmers may create a long-term governance problem.

3. Engineering calculations and technical validation

Some products require calculations before they can be quoted. Examples include pump duty calculations, heat-transfer sizing, structural load checks, motor selection, pressure-drop calculations and vehicle axle or payload calculations.

Potential requirements include:

Formula and variable management with units and conversions.
Use of customer requirements as calculation inputs.
Component selection based on calculated results.
Lookup tables, engineering curves and manufacturer data.
Rounding, tolerances and significant-figure controls.
Calculation logs and reproducible results.
Integration with external calculation services or engineering applications.
Human review when a result falls outside standard product limits.

Do not assume that a CPQ system includes a general-purpose engineering solver. Some platforms provide formulas and rules; others integrate with specialist applications; some provide neither. Requirements should state whether the CPQ system must calculate, invoke an external service or merely store an approved engineering result.

Related capabilities are covered in the guide to CAD and engineering automation.

4. BOM generation and manufacturing outputs

A bill of materials (BOM) is a structured list of components and quantities required for a product or assembly. A configurable BOM applies selection logic so that the output changes according to the customer configuration.

Specify whether the system must generate:

A sales or quotation BOM for commercial visibility.
An engineering BOM (EBOM), which represents the product from an engineering design perspective.
A manufacturing BOM (MBOM), which represents how the product is assembled or produced.
Service, spare-parts or installation BOMs.
Phantom assemblies, alternates, substitutes, consumables and reference-only items.
Quantities calculated from dimensions, length, area, weight or performance.
Item revisions, effectivity dates, units of measure and plant-specific data.
Routings, operations, labor assumptions or work-center information.

EBOM and MBOM are not interchangeable. An EBOM might describe the designed machine, while an MBOM may reorganize the same product into assembly operations and manufacturing stages. The CPQ system may generate one, both or neither. Define the system of record and the handoff process explicitly.

See the guide to BOM generation, pricing and quoting for related requirements.

5. CAD, drawings and visualization

CAD integration connects configuration choices with computer-aided design data. Depending on the platform and implementation, this may involve selecting existing models, changing parameters, generating a new model, producing a drawing or sending data to a CAD system.

Evaluate whether the requirement is for:

Static product images and option illustrations.
Interactive 2D or 3D visualization.
Parametric model updates based on dimensions or selected options.
Automatic generation of 2D drawings, PDFs or neutral CAD files.
Creation or update of CAD assemblies and parts.
Design validation before release to engineering or production.
Links to PDM or PLM revisions and approved design data.

Visualization improves understanding, but it does not by itself prove that a configuration is manufacturable. CAD automation may also require specialist templates, stable parameter naming, robust model structures and engineering ownership.

6. Costing, pricing and margin control

Pricing and costing are related but different. Costing estimates what the manufacturer spends on material, labor, purchased components, subcontracting, freight or overhead. Pricing determines what the customer is charged.

Requirements may include:

Base prices, option prices, surcharges and formula-based prices.
Material, labor, machining, assembly, tooling, freight and installation costs.
Quantity breaks, customer-specific prices and regional price lists.
Currency conversion, taxes and legal-entity rules.
Discount limits and approval thresholds.
Target margin, contribution margin and minimum-price controls.
Price validity dates and revision management.
Scenario comparison for alternative configurations.
Separation of internal cost data from customer-visible pricing.

A price calculation should be traceable. Users should be able to understand which product choices, cost inputs, commercial rules and approvals produced the final amount.

7. Quote, proposal and approval management

Quote generation turns a validated configuration into a commercial response. Functional requirements may include:

Quote versions, revisions, expiration dates and status history.
Multiple configurations or line items in one quote.
Alternatives, options, exclusions and assumptions.
Technical specifications and customer-specific text.
Drawings, calculations and compliance documents as attachments.
Approval workflows for discount, margin, non-standard terms or technical exceptions.
Electronic acceptance and conversion to an order or opportunity where supported.
Templates for different countries, channels, products and legal entities.

For ETO work, the quote may need to show estimated engineering effort, assumptions, milestones and the boundary between standard product content and project-specific design.

Workflow requirements by manufacturing model

Model	CPQ emphasis	Typical downstream requirement
Configure-to-order (CTO)	Validate known options and generate a repeatable product definition.	Reliable configurable BOM, item references and order data.
Engineer-to-order (ETO)	Capture requirements, identify technical exceptions and initiate engineering work.	Engineering task, approved design, drawings and project-specific BOM.
Make-to-order (MTO)	Configure or specify a product that is produced after order receipt.	Production-relevant specification and planning data.
Assemble-to-order (ATO)	Combine stocked modules or components according to valid choices.	Accurate module demand and assembly instructions.

Requirements should define the handoff from sales to application engineering, order management, production planning and procurement. A quote that looks correct to sales may still be incomplete for manufacturing if it lacks revision, item, dimension, routing or approval information.

Map these flows in the guide to manufacturing CPQ workflows.

Technical and architecture requirements

Data ownership and master data

Identify which system owns each data object. CRM may own account and opportunity data. ERP may own items, inventory, orders and financial data. PLM may own product revisions and lifecycle status. PDM may manage CAD files and document relationships. PIM may manage product descriptions and channel content. MES may manage execution and shop-floor transactions.

For each object, document the source of truth, synchronization direction, update frequency, identifier and error-handling process. Do not treat these systems as interchangeable.

Integration and APIs

Manufacturing CPQ integration requirements commonly include:

CRM opportunity, account and contact synchronization.
ERP item, customer, price, inventory, order and financial integration.
PLM or PDM exchange for revisions, approved structures and documents.
CAD integration for models, parameters, drawings or files.
PIM exchange for product descriptions, images and channel content.
MES or manufacturing-system exchange for production data where appropriate.
Webhooks, application programming interfaces (APIs), batch imports and exports.
Identity, authentication, logging, retries and reconciliation.

Ask whether the API supports the objects and transactions required by the use case. A generic customer or quote API may not support configurable BOMs, engineering revisions or calculation results.

Use the manufacturing CPQ integrations guide when documenting system boundaries and data flows.

Security, deployment and performance

Technical requirements should cover role-based access, single sign-on, data segregation, audit trails, encryption, backup, retention and regional hosting requirements. Manufacturing users may include external dealers, internal sales engineers, application engineers, administrators and production planners, each with different permissions.

Performance requirements should use realistic product models and workloads. Test configuration response time with large rule sets, many concurrent users, complex calculations, document generation and integration calls. A fast demonstration with a small product model does not establish production performance.

Maintainability, versioning and governance

Product rules change when suppliers, standards, materials, costs and manufacturing processes change. The system should support controlled updates, effective dates, approvals, testing and rollback or equivalent recovery procedures.

Define:

Who owns product data, rules, prices, calculations and templates.
How changes are requested, reviewed, tested and released.
How obsolete options and components are handled.
How rules are documented for future administrators.
How configuration defects are reported and traced.
How production, engineering and commercial teams resolve conflicting definitions.

Implementation and evaluation checklist

Document representative products, not only simple examples.
Collect real configuration rules, exception cases, calculations and historical quotes.
Map the current sales-to-engineering-to-production workflow.
Classify requirements as mandatory, important, optional or future scope.
Identify data owners and authoritative sources for each object.
Define the required outputs: quote, specification, EBOM, MBOM, CAD file, drawing, order or engineering task.
Build test scenarios covering valid combinations, invalid combinations, boundary values and exceptions.
Test product revisions, price changes and effective dates.
Verify integrations with representative ERP, CRM, PLM, PDM and CAD data.
Measure rule maintenance effort, quote accuracy, engineering handoff quality and document generation reliability.
Confirm how dealers, distributors and external users are authenticated and supported.
Define governance, release management, support ownership and training before go-live.

During vendor evaluation, ask for a controlled proof of concept using one representative product family. Require the vendor to show how a rule is created, tested, revised and traced; how a configuration becomes a BOM; how a technical exception is handled; and how data moves into downstream systems. A feature checklist alone will not reveal implementation complexity.

The CPQ implementation guide provides a broader framework for requirements, migration, testing, deployment and governance.

Common limitations and risks

Overly broad scope: attempting to replace ERP, PLM, CAD, MES and CRM in one project can obscure the CPQ objective.
Unmaintainable rules: duplicated logic and undocumented exceptions make product models difficult to change.
Weak product data: inconsistent item numbers, units, revisions and descriptions undermine every downstream output.
False automation assumptions: a platform may support a configurable BOM but not a production-ready MBOM or CAD design.
Uncontrolled exceptions: manual overrides may allow technically invalid or commercially unprofitable configurations.
Integration ambiguity: unclear ownership can create conflicting prices, revisions or component definitions.
Insufficient testing: a model can work for common products while failing at dimensional limits or rare combinations.
Low adoption: sales and engineering users may bypass the system if it is slower or less flexible than existing spreadsheets.

These risks are reasons to define boundaries, ownership and test cases early. They are not reasons to assume that one platform will support every engineering and manufacturing process automatically.

Semantic map

The following relationships summarize the entities discussed in this guide:

Manufacturing CPQ connects product configuration, engineering validation, pricing, quoting and production data.
Product models contain options, attributes, components and configuration rules.
Configuration rules prevent invalid combinations and trigger calculated results.
Engineering calculations validate requirements and support component selection.
A configured product can generate a configurable BOM when the platform supports BOM logic.
EBOM represents an engineering product structure, while MBOM represents a manufacturing structure.
CAD automation can generate product-specific models or drawings when supported and properly integrated.
Costing estimates internal manufacturing expense, while pricing determines the customer charge.
CRM supplies customer and opportunity context, while ERP supplies commercial and operational records.
PLM and PDM manage product lifecycle and design data that may be referenced by CPQ.
CTO uses validated standard configurations, while ETO introduces project-specific engineering work.
Governance controls changes to product rules, prices, revisions and integration mappings.

Frequently asked questions

What is the most important manufacturing CPQ requirement?

The most important requirement is a maintainable product model that can represent real options, dependencies, constraints and outputs. Without it, pricing and quote documents may appear correct while the configured product remains technically invalid.

How is manufacturing CPQ different from sales CPQ?

Sales CPQ generally emphasizes product selection, pricing, discounts and proposals. Manufacturing CPQ may additionally validate engineering constraints, calculate technical values, generate BOMs or CAD outputs and exchange data with ERP, PLM or production systems.

Does every manufacturing CPQ system generate a BOM?

No. Some systems generate configurable BOMs, some pass selections to an ERP or PLM system, and some only produce commercial quote data. BOM generation and its required EBOM or MBOM structure must be verified separately.

What is a configurable BOM?

A configurable BOM is a product structure whose components, quantities or assemblies change according to configuration choices. For example, a machine BOM may change when the user selects a different motor, frame size or material.

Should CPQ own the product master?

Not necessarily. Ownership depends on the architecture. ERP, PLM, PDM or another system may remain the authority for items, revisions or engineering structures, while CPQ uses synchronized data to configure and quote products.

What rules should be included in a CPQ requirements document?

Include compatibility, dependency, dimensional, performance, safety, pricing, BOM-selection and approval rules. Also specify how rules are versioned, tested, explained to users and linked to source data.

What is the difference between a hard error and a warning?

A hard error blocks a configuration because it is invalid or prohibited. A warning allows the user to continue but records a condition that may require review, such as a non-standard dimension or an unusual commercial margin.

When are engineering calculations required in CPQ?

They are required when product selection depends on technical inputs such as flow, pressure, load, temperature, speed, voltage, capacity or dimensions. The calculation may run inside CPQ or through an integrated engineering service.

Does 3D visualization prove that a product is manufacturable?

No. Visualization helps users understand a configuration, but manufacturability also depends on rules, tolerances, materials, component availability, production methods and engineering review.

What is the difference between EBOM and MBOM?

An EBOM describes the product from an engineering design perspective. An MBOM organizes components and operations according to how the product is manufactured or assembled. A CPQ implementation may produce one, both or neither.

Which systems commonly integrate with manufacturing CPQ?

Common integration targets include CRM, ERP, PLM, PDM, CAD, PIM and MES. The exact scope depends on which system owns customers, products, revisions, prices, designs, inventory and production data.

What should a CPQ proof of concept include?

Use a representative product family with real rules, calculations, pricing, exceptions and downstream outputs. Test valid and invalid configurations, revision changes, quote generation, BOM results and at least the most important integrations.

How should manufacturers evaluate CPQ rule maintenance?

Ask business and engineering users to create, change, test and release representative rules. Measure whether they can understand dependencies, identify affected products and deploy changes without unsafe manual workarounds.

What are the CPQ requirements for configure-to-order?

CTO generally requires repeatable configuration validation, controlled option combinations, accurate pricing and an order-ready product definition. Configurable BOM and ERP integration are often important, but the required output depends on the manufacturing process.

What are the CPQ requirements for engineer-to-order?

ETO requires structured capture of customer requirements, technical exception handling, engineering task initiation, document management and a controlled transition from preliminary configuration to approved design and production data.

Can CPQ replace CAD or PLM?

Usually it should not be assumed to do so. CPQ may integrate with CAD or PLM and automate selected tasks, but CAD design authority, lifecycle control and engineering revision management may remain in specialist systems.

How should pricing and costing requirements be separated?

Document internal cost inputs separately from customer-facing prices. Costs may include material, labor and purchased components, while pricing may include list prices, discounts, surcharges, margins, taxes and commercial terms.

What governance is needed after CPQ implementation?

Manufacturers need named owners for product models, rules, prices, calculations, templates and integrations. They also need change control, testing, release procedures, auditability and a process for handling product and supplier changes.