Tag: Pricing

CPQ vs CRM: Roles, Data, and Boundaries in Manufacturing

In manufacturing, CRM and CPQ solve different problems. A customer relationship management system records accounts, contacts, leads, opportunities, activities and sales pipeline information. A configure, price, quote system defines which product combinations are valid, applies engineering and commercial rules, calculates prices and costs, and produces a quote for the selected configuration.

The boundary is important because a CRM is not normally a product rules engine, and a manufacturing CPQ system is not normally the system of record for customer relationships. CRM manages who the customer is, what opportunity exists and where the deal stands. CPQ manages what can be sold, how it must be configured, what it costs and what should be quoted.

For example, a CRM may contain an opportunity for a food-processing company that needs a pump skid. CPQ can use the required flow rate, pressure, fluid characteristics, materials, motor specification, controls and compliance requirements to validate a pump package, calculate the price and generate a configured bill of materials (BOM). The CRM can then store the opportunity, quote status, customer communications and expected close date while CPQ remains responsible for the product-specific quote.

These systems are complementary rather than interchangeable. The most effective architecture connects them while preserving clear ownership of product, customer, pricing, engineering and production data. This manufacturing CPQ guide provides the broader context for how CPQ supports complex configurable products.

What is CRM in manufacturing?

CRM, or customer relationship management, is software used to manage commercial relationships and sales processes. In manufacturing, CRM commonly stores customer accounts, sites, contacts, sales activities, opportunities, sales stages, territories, forecasts and communications.

A manufacturing CRM may also contain information about installed equipment, dealer relationships, service opportunities, application requirements and historical transactions. However, it does not automatically understand the engineering validity of every product option or calculate the manufacturing consequences of a configuration.

Typical CRM responsibilities

Managing accounts, contacts, prospects, dealers and customer locations.
Recording leads, opportunities, activities, meetings, calls and emails.
Tracking sales stages, probability, expected revenue and forecast dates.
Assigning opportunities to sales representatives, sales engineers or channels.
Managing customer communications and commercial approvals.
Providing context for renewals, service agreements, installed equipment and account history.
Launching or displaying quotes that were created in CPQ.

CRM is therefore primarily relationship- and opportunity-oriented. It may display product and quote information, but those records are often sourced from product, pricing or CPQ systems rather than being mastered entirely in the CRM.

What is CPQ in manufacturing?

CPQ means configure, price, quote. Manufacturing CPQ is software that models configurable products and applies rules to produce technically valid and commercially accurate quotes. Depending on the platform and implementation, it may also calculate engineering values, generate a configurable BOM, automate CAD outputs, create drawings or pass manufacturing data to enterprise systems.

Manufacturing CPQ is broader than generic sales quoting because the selected options can affect engineering, purchasing, production, installation and compliance. A configuration is not simply a collection of selectable features. It may contain dimensions, capacities, materials, ratings, interfaces, tolerances, components, labor assumptions and constraints.

For example, a valve configuration may depend on pressure class, body material, trim material, connection type, temperature range, actuator size and certification. A rule may prevent a particular elastomer from being selected when the process temperature exceeds its rating. Another rule may require a specific actuator or mounting arrangement for a defined torque range.

The product configuration guide explains product models, options, dependencies, constraints and validation in more detail.

Typical manufacturing CPQ responsibilities

Presenting guided selling questions or engineering inputs.
Applying rules that prevent invalid or unsafe combinations.
Performing calculations for sizing, capacity, load, flow, power or dimensions where supported.
Selecting components and applying configurable BOM logic.
Calculating material, labor, overhead, cost, margin, discounts and selling price.
Supporting standard configure-to-order (CTO) products and, in some systems, engineer-to-order (ETO) workflows.
Generating quote documents, configuration summaries and approval packages.
Passing product, pricing and order data to CRM, enterprise resource planning (ERP), product lifecycle management (PLM), computer-aided design (CAD) or manufacturing systems.

Not every CPQ product supports CAD automation, engineering calculations, BOM generation or PLM integration. Buyers must verify these capabilities against the vendor’s documented functionality and the requirements of the product model.

CPQ vs CRM: the core difference

Area	CRM	Manufacturing CPQ
Primary purpose	Manage customers, relationships and opportunities	Configure products, calculate prices and create accurate quotes
Main business question	Who is buying, what is the opportunity and what is the sales status?	What can be sold, how should it be configured and what should it cost?
Core data	Accounts, contacts, activities, opportunities and forecasts	Product models, options, rules, calculations, prices, costs and quote lines
Primary users	Sales, account managers, business development and sales leadership	Sales engineers, application engineers, product managers, estimators and technical sales
Manufacturing relevance	Customer and opportunity context	Technical validity, engineering definition and commercial accuracy
Output	Opportunity record, forecast, activity history and relationship record	Validated configuration, price, quote, and potentially BOM or engineering outputs
Typical downstream systems	ERP, marketing, service, CPQ and analytics	CRM, ERP, PLM, PDM, CAD, MES and order-management systems

There can be overlap. CRM platforms may offer basic product catalogs, price books and quote objects. CPQ platforms may store customer references and opportunity identifiers. Overlap does not remove the need for data ownership decisions.

How CRM and CPQ work together

A common manufacturing workflow begins in CRM and moves into CPQ when the opportunity requires product definition or pricing complexity beyond a simple catalog sale.

Opportunity creation: A salesperson records the customer, application, expected quantity, target date and commercial context in CRM.
Configuration launch: The salesperson or sales engineer opens CPQ from the opportunity, often passing the account, site, currency, channel and opportunity identifier.
Technical discovery: CPQ collects configuration inputs such as dimensions, capacity, material, environmental conditions, motor selection or control requirements.
Validation: Configuration rules identify incompatible options, missing requirements or values outside supported ranges.
Engineering and costing: Where supported, CPQ performs calculations, selects components, generates a configurable BOM and applies cost logic.
Pricing: CPQ applies price lists, customer-specific terms, quantity breaks, discounts, freight assumptions, currency and approval rules.
Quote generation: CPQ creates a quote containing the product description, selected options, commercial terms, exclusions, lead-time assumptions and price.
CRM update: Quote status, total value, version and approval state are returned to CRM for pipeline management.
Order handoff: An accepted quote may be transferred to ERP, PLM, PDM, manufacturing or order-management systems, depending on the architecture.

This workflow keeps CRM focused on the relationship and opportunity while CPQ manages the detailed product and pricing transaction. The exact sequence varies by organization and integration design.

Data boundaries between CPQ and CRM

The most important implementation question is not whether CRM or CPQ can technically store a field. It is which system should own, validate and publish that field.

Data usually owned by CRM

Account name, customer classification and relationship hierarchy.
Contacts, communication preferences and sales team assignments.
Opportunity stage, forecast category, close date and probability.
Sales activities, meetings, tasks and account history.
Territory, channel and relationship ownership.
Commercial context that does not define the product configuration.

Data usually owned by CPQ

Product options, features, attributes and valid values.
Configuration dependencies, exclusions and constraint rules.
Engineering calculations and configuration-specific requirements.
Configured product descriptions and quote-line details.
Pricing logic, discount rules and approval thresholds where CPQ is the pricing authority.
Configurable BOM logic and configuration identifiers where supported.
Quote versions, configuration state and technical assumptions.

Data that may be mastered elsewhere

ERP: Item masters, inventory, standard costs, customer credit, orders and financial transactions.
PLM: Product structures, revisions, engineering change processes and released product definitions.
PDM: CAD files, document metadata and design data management.
CAD: Parametric geometry, assemblies, drawings and model-specific design outputs.
PIM: Product descriptions, marketing attributes and channel content.
MES: Manufacturing execution, work instructions, production status and shop-floor reporting.

These systems are distinct. An ERP item number is not necessarily a CPQ configuration rule. A PLM engineering BOM (EBOM) is not the same as a manufacturing BOM (MBOM), which is structured for production operations. A CAD model is not a CRM product record. The CPQ integration guide covers these system relationships in more detail.

Product configuration is not the same as quoting

Configuration, pricing and quoting are related but separate functions.

Configuration determines whether a product selection is technically valid and defines its attributes, components or requirements.
Pricing calculates what the configured product should cost or sell for.
Quoting presents the commercial offer, terms, assumptions and validity period to the customer.

A CRM product catalog may show a list of products and prices without validating dependencies between options. A basic quoting tool may apply discounts without knowing whether a selected motor can drive a specified pump. Manufacturing CPQ connects these functions when the product model and data are sufficiently mature.

Manufacturing organizations should also distinguish three approaches to configuration. Guided selling asks business-oriented questions and recommends suitable products. Rules-based configuration uses explicit if-then logic, exclusions and required selections. Constraint-based configuration evaluates relationships and limits across multiple variables, such as dimensions, capacity, loads and available components. A platform may support one, two or all three approaches.

Manufacturing example: configurable industrial pump

Consider a company selling centrifugal pump packages. CRM stores the customer, project site, opportunity value, expected delivery date and communication history. A CPQ session collects flow, head, fluid, temperature, material, seal type, motor voltage, enclosure rating, baseplate requirements and control-panel options.

CPQ may then:

reject a pump size that cannot meet the required duty point;
require corrosion-resistant materials for a specified fluid;
select a seal family based on temperature and chemical compatibility;
choose a motor frame and power rating;
calculate a price from components, labor and commercial rules;
produce a configured BOM or manufacturing selection, if supported;
send the technical summary and quote value back to CRM.

If the pump is a standard CTO product, the validated configuration may proceed to order entry with limited engineering review. If the application requires a new skid layout, unusual materials or a modified baseplate, the transaction may become ETO. CPQ can support the intake and handoff, but it does not automatically replace engineering or PLM unless the implementation explicitly provides those capabilities.

CRM, CPQ and BOM ownership

A bill of materials lists the components or assemblies required for a product. CPQ may generate a configurable BOM, but this capability is not universal and should not be assumed.

An EBOM, or engineering bill of materials, represents the product from an engineering design perspective. An MBOM, or manufacturing bill of materials, represents how the product is assembled or produced. A CPQ system may generate a sales or configured BOM that must be transformed or reconciled before production.

CRM is generally not the right place to maintain detailed BOM structures. It can display a product summary or quote lines, but complex component relationships, revisions and production effectivity usually belong in CPQ, PLM or ERP according to the company’s architecture.

The BOM, pricing and quoting guide explains how configured products can connect commercial quoting with downstream product data.

CRM, CPQ and engineering automation

Engineering automation can include calculations, component selection, CAD generation, drawing creation and technical document production. These functions are usually closer to CPQ, CAD, PLM or engineering applications than to CRM.

For example, CPQ might calculate a conveyor length from facility dimensions, select a drive package and pass parameters to a CAD automation service. The service could generate a product-specific layout or drawing. CRM would normally retain the opportunity and may provide a link or summary, but it would not be the authoritative CAD model.

The CAD and engineering automation guide covers the relationship between CPQ inputs, engineering calculations, CAD models and drawings. Organizations should verify whether a selected CPQ platform performs these functions natively, invokes external tools or only stores the resulting references.

Where the boundary becomes difficult

Shared product and price data

Both systems may display product names, item numbers and prices. Without ownership rules, sales teams may see different values in CRM and CPQ. A common approach is to keep customer-specific opportunity context in CRM, while CPQ retrieves product and pricing data from an approved source and returns the calculated result to CRM.

Quote records

CRM may need a quote record for pipeline reporting, while CPQ needs detailed versions, configuration state and rule outputs. The systems should not create competing quote versions. One system should own the detailed quote, with the other storing a synchronized summary and identifier.

Customer-specific pricing

Customer agreements may originate in ERP or CRM, while CPQ applies them to a configuration. The implementation should define whether the price list, contract discount, rebate or credit status comes from ERP, CRM or a dedicated pricing service.

ETO work

In ETO processes, CPQ may capture requirements and create a preliminary commercial estimate, but engineering may need to approve the design before a final quote. CRM should show the opportunity status, while engineering and product systems retain technical approvals, revisions and released data.

Benefits of integrating CPQ and CRM

Faster technical response: Sales teams can launch a configuration from the opportunity instead of manually recreating customer information.
Fewer configuration errors: Rules can prevent invalid combinations before a quote reaches engineering or production.
Better opportunity visibility: CRM can show quote value, status, version and approval state.
Less duplicate entry: Account, contact, currency and opportunity data can be reused in CPQ.
More accurate forecasting: CRM pipeline values can reflect validated quote totals rather than rough estimates.
Improved engineering handoff: Technical inputs, assumptions and configuration identifiers can travel with the opportunity.
Clearer accountability: CRM owns the relationship while CPQ owns configuration and quote logic.

Limitations and implementation risks

Integration does not correct weak product data or unclear business ownership. If product options, rules, costs and revisions are inconsistent, connecting CPQ to CRM may simply move errors faster.

Unclear system ownership: The same price, product description or quote status is maintained in multiple systems.
Incomplete product models: Rules cover common combinations but not unusual engineering cases.
Overloaded CRM: Detailed engineering structures are forced into generic product or quote objects.
Weak version control: A quote is revised in CPQ but CRM continues to display an obsolete version.
Integration latency: Customer, inventory, cost or price updates are not available when the configuration is performed.
ETO ambiguity: The organization treats a preliminary estimate as a production-ready definition.
Governance gaps: No product owner is responsible for maintaining rules, option compatibility or release dates.
Excessive customization: The integration becomes dependent on one CRM implementation and difficult to maintain.

CPQ implementation should therefore include data mapping, rule ownership, integration error handling, version management, testing and release governance. The CPQ implementation guide provides a framework for these activities.

How to decide whether you need CPQ or CRM capabilities

Business situation	Likely requirement
Standard products with simple prices and no technical dependencies	CRM product and quote features may be sufficient
Many options but limited technical interaction	Basic CPQ or guided selling may be appropriate
Options have dependencies, exclusions or capacity constraints	A rules-based or constraint-based CPQ model is likely required
Configuration affects BOM, engineering calculations or drawings	Manufacturing CPQ with engineering and downstream integration should be evaluated
Every order is substantially designed for a project	CPQ may support requirements capture and estimating, but engineering and PLM remain central
Customer and opportunity management is the main problem	CRM should be the primary investment

Recommended architecture and governance

A practical architecture normally assigns responsibilities explicitly:

CRM owns accounts, contacts, opportunities, activities and sales-process status.
CPQ owns configuration sessions, technical selections, configuration rules and quote calculations where implemented as the pricing authority.
ERP owns released item masters, orders, financial transactions and often standard costs or inventory.
PLM owns released product structures, engineering revisions and change control where PLM is used.
PDM owns CAD documents and design file management where PDM is used.
CAD and engineering services generate geometry, drawings or calculations where those functions are integrated.
MES manages production execution rather than commercial opportunity data.

Governance should define who can change a rule, who approves pricing changes, how product revisions are released, how obsolete configurations are handled and what happens when an external system is unavailable. Testing should include valid configurations, invalid combinations, boundary values, price changes, revisions, discounts, approvals and integration failures.

CPQ vs CRM in CTO, MTO and ETO workflows

Configure-to-order (CTO) uses a predefined product model and approved options. CPQ can often validate the configuration, calculate the price and create a repeatable order definition.

Make-to-order (MTO) produces a product after an order is received, usually from a defined specification. CPQ may capture the specification and pass it to ERP or production systems.

Assemble-to-order (ATO) combines stocked or predefined modules after an order is placed. CPQ can select compatible modules, while ERP manages availability and fulfillment.

Engineer-to-order (ETO) requires engineering work for the specific customer requirement. CPQ may collect requirements, estimate cost and initiate engineering review, but it should not be described as replacing engineering unless the system and process demonstrably support that outcome.

The manufacturing workflows guide explains these operating models and their sales-to-production handoffs.

Semantic map

The following relationships summarize the entities and boundaries discussed in this guide:

CRM manages customer relationships and opportunities.
CPQ configures technically valid products.
Configuration rules prevent invalid combinations.
CPQ calculates configured product prices.
Configured products may generate configurable BOMs.
ERP manages orders and financial transactions.
PLM manages engineering product definitions and revisions.
PDM manages CAD documents and design files.
CAD automation generates product-specific drawings where integrated.
CRM displays quote status and opportunity value.
ETO requirements initiate engineering review.
CTO configurations use predefined product rules.

Frequently asked questions

1. Is CPQ part of CRM?

CPQ may be embedded in, integrated with or separate from CRM. Conceptually, CPQ is a distinct capability focused on product configuration, pricing and quoting, while CRM manages customer and opportunity relationships.

2. Can CRM replace manufacturing CPQ?

CRM may handle simple products, catalogs and basic quotes. It usually cannot replace a manufacturing CPQ system when rules, engineering calculations, configurable BOMs or complex pricing are required.

3. Does CPQ store customer information?

CPQ can store customer references needed for a quote, but CRM is commonly the system of record for accounts, contacts, activities and opportunities.

4. Does CPQ generate a BOM?

Some manufacturing CPQ platforms generate configurable or sales BOMs, while others only produce quote lines. This capability must be verified for the specific platform and product model.

5. Should product data be mastered in CRM or CPQ?

CRM may store commercial catalog information, but detailed options, dependencies and configuration rules are usually better managed in CPQ or a connected product lifecycle system.

6. Can CPQ calculate manufacturing cost?

Some CPQ systems calculate material, labor, overhead or estimated cost. Others use external ERP or costing services. The source, refresh frequency and approval process for cost data should be defined.

7. What does CRM send to CPQ?

Common inputs include account, contact, opportunity, currency, channel, customer segment, location and commercial terms. The exact fields depend on the integration design.

8. What does CPQ send back to CRM?

CPQ commonly returns quote identifiers, configured product summaries, totals, versions, approval status, validity dates and quote status.

9. Is a CRM quote the same as a CPQ quote?

Not necessarily. CRM may contain a summary quote record for pipeline management, while CPQ contains the detailed configuration, calculations, versions and technical assumptions.

10. Can CPQ automate CAD?

Some platforms integrate with CAD or engineering automation tools, but this is not a universal CPQ capability. Verify supported CAD systems, parameter coverage, drawing outputs and revision handling.

11. Does CPQ replace PLM?

CPQ generally does not replace product lifecycle management. PLM typically manages engineering definitions, revisions and change control, while CPQ uses approved product knowledge to configure and quote.

12. How does CPQ support engineer-to-order sales?

CPQ can capture requirements, estimate cost, identify standard content and initiate engineering review. The final design, approval and release may remain in engineering and PLM systems.

13. Should CRM own pricing?

CRM can display prices and support sales processes, but complex configuration-dependent pricing is often better calculated in CPQ or a dedicated pricing service. Ownership should be explicit.

14. How are discounts handled between CRM and CPQ?

Many architectures let CRM provide customer or opportunity context while CPQ validates discount limits against configured product value, margin and approval rules. The authoritative calculation must be defined.

15. Can CPQ work without CRM?

Yes. CPQ can operate with other front ends or as a standalone application, although CRM is useful for account context, opportunity tracking and sales activity management.

16. Can CRM work without CPQ?

Yes. CRM is sufficient for relationship management and simple quoting. A separate CPQ capability becomes more valuable as product, pricing and engineering complexity increases.

17. What is the difference between a CRM product catalog and a CPQ product model?

A CRM catalog usually supports product display and basic selection. A CPQ product model can include options, dependencies, constraints, calculations, component logic and configuration-specific outputs.

18. What should manufacturers test in a CRM-CPQ integration?

Test account synchronization, currencies, price lists, configuration validity, quote versions, discount approvals, revisions, error handling, duplicate records and accepted-quote handoff to ERP or engineering systems.

Related manufacturing CPQ guides

Manufacturing CPQ guide for the overall role of CPQ in complex-product manufacturing.
Product configuration and rules for options, dependencies, constraints and validation.
BOM, pricing and quoting for configurable BOMs, costing and quote generation.
CPQ integrations for CRM, ERP, PLM, PDM, CAD, PIM and MES connectivity.
Manufacturing workflows for CTO, ETO, MTO, ATO and sales-to-production processes.
Manufacturing CPQ comparisons for evaluating platforms and alternatives.

October 12, 2026

Manufacturing CPQ Process Flow from Customer Need to Quote

A manufacturing CPQ process flow takes a customer need and turns it into a technically valid, manufacturable and commercially accurate quote. CPQ means configure, price, quote. In manufacturing, the process can include product configuration rules, engineering calculations, CAD automation, bill of materials generation, costing, pricing, approvals and integration with enterprise systems.

The flow is usually: capture requirements, select or build a product configuration, validate technical constraints, perform engineering calculations, generate product and manufacturing data, calculate cost and price, prepare the quote, obtain approvals and hand the approved configuration into order execution. The exact sequence varies by product and business model. A standard configure-to-order product may follow an automated path, while an engineer-to-order product may require engineering review before a quote is released.

This is different from generic sales CPQ, which may focus mainly on selecting commercial options, applying discounts and producing a proposal. Manufacturing CPQ must also answer whether the product can be built, which components are required, how it should be engineered and what data production needs. The manufacturing CPQ guide provides broader context on this category.

What is the manufacturing CPQ process flow?

The manufacturing CPQ process flow is the controlled sequence used to convert customer requirements into a validated product definition and quote. It connects commercial activity with product engineering and operations.

Stage	Primary question	Typical output
1. Customer need	What must the product do?	Requirements, application data and target specifications
2. Product configuration	Which valid product choices meet the need?	Configured product and selected options
3. Technical validation	Can the selected combination work safely and correctly?	Validated configuration, warnings or engineering tasks
4. Engineering definition	What product-specific design is required?	Calculations, dimensions, CAD data, drawings or engineering instructions
5. BOM and manufacturing data	Which parts and assemblies are needed?	Configurable BOM, EBOM, MBOM or manufacturing package
6. Cost and price	What will the product cost and what should the customer pay?	Cost breakdown, price, discounts and margins
7. Quote and approval	How should the offer be presented and controlled?	Customer quote, assumptions, lead time and approvals
8. Handoff	How does the approved result enter execution?	Order, ERP transaction, engineering job or production release

Stage 1: Capture the customer need

The process begins before a product option is selected. A salesperson, dealer, application engineer or customer may describe the required duty, environment and operating conditions rather than naming a specific model.

For a pump manufacturer, the requirements might include flow rate, pressure, fluid type, temperature, material compatibility, motor voltage, installation arrangement and regulatory requirements. For industrial machinery, they may include throughput, workpiece dimensions, available floor space, cycle time, safety requirements and automation interfaces.

A manufacturing CPQ application can capture these requirements through guided questions, technical input fields, imported data or a dealer portal. Guided selling presents questions in an order that helps the user reach an appropriate product family. It is not the same as a rules engine: guided selling helps select a suitable solution, while configuration rules determine whether selected features are technically compatible.

Requirements should be represented as structured data wherever possible. Free-text notes can preserve context, but they are difficult to validate and cannot reliably drive calculations, BOM selection or CAD automation.

Important requirement data

Application and operating conditions
Required capacity, performance or duty point
Dimensions, weights and connection standards
Materials, coatings and environmental conditions
Power, voltage, controls and communication requirements
Compliance, certification and documentation needs
Delivery location, quantity and requested date
Customer-specific standards or approved components

Stage 2: Select the product family and configure the product

Once the need is structured, the user selects a product family and configures its features. A product model defines available options, attributes, components, rules and relationships. The model may represent a pump, valve assembly, air-handling unit, conveyor, electrical cabinet, trailer or complete production machine.

Configuration can use several approaches:

Rules-based configuration: explicit rules allow, require or prohibit options. For example, a high-temperature seal may require a specific material and exclude a standard elastomer.
Constraint-based configuration: the system evaluates relationships and limits across many variables. For example, motor power, impeller diameter, frame size and flow may need to remain within engineering limits.
Guided selling: questions narrow the product choice based on customer requirements. The result may then be checked by configuration rules.

A configuration model should distinguish commercial options from technical attributes. A customer may choose a stainless-steel housing as an option, while the resulting wall thickness, fastener material and manufacturing operation are derived values that the customer never selects directly.

The product configuration guide explains product models, dependencies, constraints and configuration validation in more detail.

Stage 3: Validate technical constraints

Validation prevents a quote from being created for a product that cannot be built, will not perform as required or violates a company policy. Validation may happen continuously as the user configures the product or as a formal review before quoting.

Typical rules include:

an option requires another option;
two materials or components are incompatible;
a dimension must remain within a defined range;
a motor must match the voltage and load;
a pressure rating must exceed the application requirement;
a selected component is unavailable for a particular product family;
a certification requires specific construction or documentation;
a customer-specific standard limits approved suppliers or parts.

Validation can produce errors, warnings or review tasks. An error blocks the configuration. A warning may allow the user to proceed while recording an assumption. A review task routes the case to engineering, compliance, purchasing or another specialist.

Rules should be tested against valid and invalid combinations. A large rule set can become difficult to maintain if rules are duplicated, embedded in code without documentation or owned by no clear business team. Product configuration governance is therefore as important as the rule technology.

Stage 4: Perform engineering calculations and design automation

Some products can be selected from a fixed catalog. Others require calculations that determine product dimensions or components. Manufacturing CPQ may perform these calculations directly, call an engineering service or create a task for an engineer.

For a pump, calculations may determine required head, power, impeller selection and operating range. For a heat exchanger, they may calculate surface area and connection sizes. For a conveyor, they may determine frame length, belt width, drive requirements and support spacing. For a vehicle body, they may calculate clearances, payload effects and mounting requirements.

Design automation can use these results to create a product-specific design. Parametric computer-aided design, or CAD, systems can update dimensions and component selections. The output may include a three-dimensional model, a two-dimensional drawing, a specification sheet or manufacturing instructions. Not every CPQ platform includes CAD automation, so this capability must be verified separately.

Engineering automation is particularly valuable when the same design logic is repeated across many orders. However, it requires governed engineering formulas, compatible CAD templates, reliable input data and a process for handling cases outside the automation envelope. The CAD and engineering automation guide covers these relationships.

Stage 5: Generate the bill of materials and manufacturing data

A validated configuration can drive a bill of materials, or BOM. A BOM is a structured list of the components, materials and quantities required for a product or assembly. In a manufacturing CPQ process, BOM generation may be immediate, conditional or delegated to an ERP, product lifecycle management system or engineering system.

Several BOM concepts should be distinguished:

Configurable BOM: a product structure containing optional, conditional or variable components that are resolved for a particular configuration.
EBOM: an engineering bill of materials, organized around the designed product and engineering relationships.
MBOM: a manufacturing bill of materials, organized around how the product is assembled or produced.

An industrial machine might have one configured product definition, an EBOM describing the designed assembly and an MBOM that adds work instructions, packaging, consumables or production-specific grouping. These structures may be related but are not interchangeable.

CPQ may also derive routings, labor assumptions, purchased components, alternates, tooling requirements and documentation. In other implementations, CPQ creates a configuration identifier and passes the commercial result to an enterprise resource planning system, or ERP, which owns the official item and BOM transaction.

The BOM, pricing and quoting guide explains how configurable BOMs connect to costing and quote generation.

Stage 6: Calculate cost, price and lead time

Costing and pricing are related but different activities. Costing estimates the internal resources required to produce the configured product. Pricing determines what the customer is charged.

Cost inputs may include materials, purchased parts, labor, machine time, subcontracting, freight, tooling, engineering effort, warranty exposure and overhead allocations. Pricing may apply list prices, customer agreements, regional adjustments, quantity breaks, project discounts, channel margins, surcharges and target margin rules.

A manufacturing CPQ process should make clear which values are calculated, which are retrieved from a source system and which can be overridden. For example, material cost may come from ERP, a standard component price may come from a product information management system, and a project discount may require sales management approval.

Lead time can also be configuration-dependent. A standard motor may be available from stock, while a custom coating, nonstandard material or engineered frame may add procurement and production time. A quote that shows price without realistic delivery assumptions is incomplete for many industrial buyers.

Stage 7: Generate the quote and manage approvals

The quoting stage turns the validated commercial result into a customer-facing document. A manufacturing quote commonly contains:

configured product description and option summary;
technical specifications and performance data;
quantities, unit prices and total price;
discounts, surcharges, taxes or freight assumptions;
estimated lead time and delivery terms;
scope boundaries, exclusions and customer responsibilities;
warranty, validity period and payment terms;
drawings, images, datasheets or compliance documents when appropriate.

Approval workflows should be based on business risk, not only price. A quote may need engineering approval for a nonstandard operating point, finance approval for a low margin, legal approval for unusual terms or operations approval for a capacity constraint.

Document generation should use the same configuration and pricing data used to create the quote. Re-keying selected options into a word processor or spreadsheet creates a risk that the document will not match the product being offered.

Stage 8: Handoff from quote to order and production

When the customer accepts the quote, the approved configuration becomes an order candidate or an engineering release. The handoff depends on the manufacturing workflow.

Workflow	Typical CPQ handoff	Example
Configure-to-order (CTO)	Validated configuration, item identifiers and resolved BOM enter order processing	Standard pump package with selectable materials and motor sizes
Engineer-to-order (ETO)	Requirements, calculations and engineering tasks create a project-specific design	Large custom material-handling machine
Make-to-order (MTO)	Demand triggers procurement or production after order acceptance	Configured electrical enclosure built after approval
Assemble-to-order (ATO)	Standard modules are combined after order receipt	Modular conveyor assembled from stocked sections

The handoff may involve customer relationship management, or CRM, for the opportunity and account; ERP for order, inventory, purchasing and financial transactions; product lifecycle management, or PLM, for product definitions and revisions; product data management, or PDM, for CAD files and documents; manufacturing execution systems, or MES, for production execution; and CAD for design outputs. These systems have different responsibilities and should not be treated as interchangeable.

The manufacturing workflow guide explains CTO, ETO, MTO and ATO processes, while the CPQ integration guide covers system boundaries and data exchange.

How the process differs by manufacturing environment

Configure-to-order

CTO works best when the product architecture, options and manufacturing structures are known in advance. Automation can validate selections, resolve a BOM, calculate price and create an order with limited manual engineering.

Engineer-to-order

ETO begins with a customer need but requires project-specific design. CPQ can capture requirements, identify a product platform, calculate preliminary dimensions, estimate engineering effort and create a controlled handoff. It should not be presented as fully automated if engineers must still design and approve the product.

Dealer and distributor sales

Dealer users may need a simplified interface, controlled access to prices and product guidance without seeing internal costs or engineering rules. The manufacturer must still ensure that the resulting configuration can be produced and supported.

Self-service and ecommerce

Self-service configuration can work for bounded products with clear rules, stable pricing and predictable fulfillment. Products requiring application engineering, site surveys or safety review may need a hybrid workflow that routes complex cases to specialists.

Systems and data architecture

A manufacturing CPQ solution commonly sits between customer-facing channels and engineering or enterprise systems. The CPQ application may own the configuration session and quote, while other systems remain authoritative for specific data.

System	Typical responsibility
CRM	Accounts, contacts, opportunities and sales activity
CPQ	Configuration session, rules, calculations, pricing logic and quote
ERP	Items, inventory, purchasing, orders, finance and operational costing
PLM	Product structures, revisions, change processes and lifecycle governance
PDM	CAD files, engineering documents and controlled design data
CAD	Parametric models, drawings and design outputs
PIM	Product attributes, descriptions, media and channel content
MES	Production dispatch, execution, quality and shop-floor records

In practice, ownership must be agreed for each data object. For example, CPQ may calculate a configuration-specific option set, PLM may own released engineering structures, ERP may own sellable item numbers and costs, and CAD may generate the geometric model. Integration should transfer identifiers, revisions, quantities, units and status as well as descriptive text.

Benefits of a controlled manufacturing CPQ flow

Fewer configuration errors: rules prevent incompatible options from reaching the quote.
Faster response: repeatable calculations and document generation reduce manual work.
More consistent pricing: cost and price logic is applied systematically.
Better engineering leverage: engineers spend less time answering repetitive selection questions.
Improved production handoff: approved configurations can carry structured BOM and specification data.
Traceability: the company can record who configured, reviewed and approved the quote.
Improved channel control: dealers can sell complex products within defined technical and commercial boundaries.

Limitations and common failure points

CPQ does not eliminate product complexity. It exposes and formalizes it. Implementation can be difficult when product options are poorly defined, engineering knowledge exists only in documents, prices are maintained in disconnected spreadsheets or BOM ownership is unclear.

Common failure points include:

trying to automate products whose engineering rules have not been documented;
treating every custom request as a simple option;
using one product structure for sales, engineering and manufacturing without mapping their differences;
allowing uncontrolled manual overrides;
ignoring units, revisions, effective dates and regional variations;
building integrations before agreeing on data ownership;
failing to test negative cases and unusual but valid applications;
assuming that a vendor’s generic CPQ capability includes CAD, BOM, ETO or PLM functions.

Some configurations should remain subject to engineering review. A good process makes the boundary visible and routes exceptions deliberately rather than hiding them in manual workarounds.

Implementation considerations

Manufacturers should begin with a defined product family and a measurable workflow problem. Map the current process from customer inquiry through quote and order release. Identify where users re-enter data, where errors occur, which decisions require engineering and which systems own the relevant information.

Before building the model, document:

features, options, attributes and valid ranges;
dependencies, exclusions and required combinations;
engineering formulas and their owners;
component selection and BOM logic;
cost sources, price rules and approval thresholds;
quote templates, assumptions and revision controls;
interfaces to CRM, ERP, PLM, PDM, CAD, PIM and MES;
exception paths for ETO and nonstandard requests.

Use representative examples for testing: a normal configuration, an invalid combination, a boundary value, a discontinued component, a revision change, a low-margin quote and an ETO case. Test not only the user interface but also the outputs: configuration identifier, BOM, CAD file, price, lead time, quote document and downstream transaction.

Ownership should continue after deployment. Product management may own commercial options, engineering may own technical rules, manufacturing may own assembly logic, finance may own pricing policy and IT may own integrations. A release and change-control process is necessary when products, components, suppliers or regulations change.

The CPQ implementation guide covers requirements, migration, testing, governance, adoption and maintenance. Buyers evaluating platforms can also use the manufacturing-focused CPQ comparison and selection resources.

How to measure the process

Useful measures should cover speed, quality and downstream usefulness rather than quote volume alone. Possible measures include quote cycle time, percentage of quotes requiring engineering intervention, configuration error rate, quote-to-order conversion, margin variance, time from order to engineering release, percentage of orders requiring rework and the proportion of BOM data accepted without manual correction.

Metrics need clear definitions. For example, quote cycle time may begin when all required technical inputs are available rather than when an incomplete inquiry first arrives. Otherwise, the measure may encourage premature quotes instead of accurate ones.

Conclusion

A manufacturing CPQ process flow connects customer requirements to a valid product, an engineering definition, manufacturing data, cost, price and a controlled quote. The strongest implementations do not treat CPQ as a document generator. They establish a reliable product model, make configuration rules explicit, separate EBOM and MBOM responsibilities, automate appropriate engineering work and exchange governed data with CRM, ERP, PLM, PDM, CAD and MES systems.

The right level of automation depends on the product. Standard CTO products may support near-real-time configuration and order handoff. ETO products may use CPQ to structure requirements and accelerate preliminary engineering while retaining expert review. In both cases, the objective is the same: provide a commercially accurate offer that the manufacturer can build, deliver and support.

Semantic map

The following relationships summarize the entities and data flows described in this guide:

Customer requirements lead to product configuration.
Product configuration is evaluated by configuration rules.
Configuration rules prevent invalid combinations.
Engineering calculations determine product-specific parameters.
Validated configurations generate configurable BOMs.
EBOMs describe engineered product structures.
MBOMs describe manufacturing assembly structures.
CAD automation generates product-specific design outputs.
Costing estimates resources required to build the product.
Pricing converts cost and commercial policy into a customer price.
CPQ generates quotes from configuration and pricing data.
CRM stores opportunity and customer context.
ERP manages orders, inventory, purchasing and financial transactions.
PLM governs product definitions, revisions and lifecycle changes.
MES supports production execution after order release.
ETO requires engineering review for project-specific designs.

Frequently asked questions

1. What is a CPQ process flow in manufacturing?

It is the sequence that converts customer requirements into a validated configuration, engineering and manufacturing data, cost, price and a formal quote.

2. What does CPQ stand for?

CPQ stands for configure, price, quote. In manufacturing, configure may include technical validation and engineering outputs in addition to selecting commercial options.

3. How does manufacturing CPQ differ from sales CPQ?

Sales CPQ often concentrates on product selection, discounts and proposals. Manufacturing CPQ may also manage constraints, calculations, BOMs, CAD outputs, costing and production handoff.

4. What happens first in the CPQ process?

The process starts by capturing structured customer requirements such as duty, dimensions, materials, environment, performance and compliance needs.

5. What is the role of configuration rules?

Configuration rules define valid and invalid combinations, required options, exclusions, ranges and technical dependencies.

6. Is guided selling the same as product configuration?

No. Guided selling asks questions to recommend a product or configuration path. Product configuration validates the selected features and their technical relationships.

7. Can CPQ generate a bill of materials?

Some manufacturing CPQ systems generate or resolve BOMs, while others pass configuration data to ERP, PLM or another system that owns the BOM. This capability must be verified for each platform.

8. What is the difference between an EBOM and an MBOM?

An EBOM represents the engineered product structure. An MBOM represents how the product is assembled or produced. They may contain different groupings, parts and manufacturing information.

9. Does every CPQ system include CAD automation?

No. CAD automation may be a native capability, an integration or an external engineering service. Buyers should verify supported CAD systems, templates, outputs and revision handling.

10. How does CPQ support engineer-to-order products?

CPQ can capture requirements, select a product platform, perform preliminary calculations, estimate engineering effort and create a controlled engineering handoff. It does not necessarily replace project engineering.

11. How does CPQ calculate manufacturing prices?

It can combine material, labor, purchased-component, freight, engineering and overhead inputs with price lists, margins, discounts, surcharges and approval rules.

12. Which systems commonly integrate with manufacturing CPQ?

Common integrations include CRM, ERP, PLM, PDM, CAD, PIM and MES. The exact scope depends on the product model and the responsibilities assigned to each system.

13. What information should appear in a manufacturing quote?

A quote should normally include the configured product, technical specifications, quantities, price, lead time, assumptions, exclusions, terms and relevant drawings or documentation.

14. Why are manufacturing CPQ implementations difficult?

They require product rules, engineering knowledge, pricing data, BOM logic, system ownership and exception handling to be made explicit and maintained over time.

15. Should every configuration be fully automated?

No. Standard, repeatable configurations are good automation candidates. Novel, safety-critical or highly customized designs may require engineering review.

16. What is the difference between CTO and ETO?

Configure-to-order uses predefined product structures and options. Engineer-to-order requires project-specific engineering before or during order fulfillment.

17. How does CPQ support configure-to-order production?

It validates options, resolves the configuration, calculates price and can pass item, BOM and specification data into order and production systems.

18. What should be tested before launching a CPQ process?

Test valid, invalid, boundary, discontinued, revised, low-margin and ETO scenarios, including the resulting configuration, BOM, price, quote, CAD output and downstream transactions.

19. Who should own manufacturing CPQ rules?

Ownership is usually shared: product management for commercial options, engineering for technical rules, manufacturing for assembly logic, finance for pricing and IT for integrations.

20. What is the main objective of manufacturing CPQ?

The objective is to create an accurate, technically valid and commercially acceptable offer that the manufacturer can reliably build, deliver and support.

October 8, 2026

BOM in CPQ: How Bills of Materials Fit into Configure-Price-Quote

A bill of materials (BOM) in Configure, Price, Quote (CPQ) is the structured list of components, quantities and relationships generated or selected for a specific product configuration. In manufacturing CPQ, the BOM connects what a customer selects with what engineering, purchasing, production and finance need to cost, price, quote and eventually build the product.

The basic flow is:

A salesperson, dealer, engineer or customer configures a product.
Configuration rules validate options, dimensions, materials and dependencies.
The CPQ system resolves the selections into a configurable BOM or product-specific BOM.
Component quantities and attributes support costing and pricing.
The approved configuration and commercial data are assembled into a quote.
Relevant BOM data may be sent to enterprise systems such as an Enterprise Resource Planning (ERP), Product Lifecycle Management (PLM) or Manufacturing Execution System (MES) platform.

Not every CPQ platform generates manufacturing-ready BOMs. Some systems only use product options to calculate prices and produce a proposal. Buyers should therefore verify whether a platform supports BOM generation, which BOM type it produces, how rules are maintained and whether the output is suitable for engineering or production.

This guide explains how BOMs fit into manufacturing CPQ, how they relate to configuration and pricing, how EBOMs and MBOMs differ, and what manufacturers should evaluate during implementation.

What is a BOM in CPQ?

A BOM in CPQ is a structured representation of the parts, assemblies, materials and quantities required for a configured product. The BOM may be generated dynamically from configuration choices or retrieved from predefined product structures. It can support commercial calculations, engineering review, manufacturing planning or several of these purposes at once.

A typical BOM line may contain:

item number or material number;
component description;
quantity and unit of measure;
parent assembly;
effective date or revision;
make-or-buy status;
cost and price references;
optional attributes such as material, finish, size or voltage;
manufacturing or procurement notes;
links to drawings, specifications or CAD files.

In a simple sales CPQ application, the BOM may be only a commercial bundle used to calculate a price. In manufacturing CPQ, the BOM can be the result of a deeper product model containing constraints, engineering calculations, variant logic and relationships between configured features.

For example, configuring an industrial pump may involve selecting flow rate, pressure, fluid type, motor power, seal material, impeller material, connection standard and enclosure rating. Those choices can determine the pump assembly, motor, coupling, baseplate, seal kit, control panel, fasteners and documentation included in the BOM.

The BOM is therefore not merely a list printed on a quote. It is an output of the product configuration model and a potential input to costing, engineering, ERP, PLM, purchasing and production.

How BOM generation fits into the CPQ architecture

Manufacturing CPQ usually contains several related data and logic layers. The exact architecture varies by product and vendor, but the following pattern is common.

Layer	Purpose	Manufacturing example
Product model	Defines products, features, options, components and relationships.	A pump family with available impellers, motors and seal types.
Configuration rules	Controls valid, invalid, required and conditional choices.	A high-temperature seal is required for a specified fluid and temperature range.
Engineering calculations	Derives technical values from customer or application inputs.	Calculating motor size from flow, head and efficiency requirements.
BOM logic	Selects components and calculates quantities or structures.	Adding a reinforced baseplate when motor weight exceeds a threshold.
Cost model	Applies material, labor, overhead, supplier and manufacturing costs.	Calculating cost from selected steel grade, machining time and purchased motor.
Pricing model	Converts cost and commercial rules into customer prices.	Applying customer terms, currency, margin, freight and volume discounts.
Quote document	Communicates scope, price, assumptions, validity and commercial terms.	A proposal showing the configured equipment, options, exclusions and price.
Enterprise integration	Transfers approved data to surrounding systems.	Sending an order-ready structure and item references to ERP and PLM.

These layers should be related but not confused. A configuration rule determines whether a combination is valid. A BOM rule determines which components result from that combination. A cost rule determines what the selected components cost. A pricing rule determines what the customer is charged. A quote document presents the result.

For more background, see the guide to product configuration and configuration rules and the overview of BOM generation, pricing and quote automation.

From customer selections to a configured BOM

1. Capture requirements and configuration inputs

The process begins with inputs such as product family, capacity, dimensions, operating environment, materials, accessories, certifications and delivery requirements. These inputs may be entered by an internal salesperson, sales engineer, dealer, customer or engineering user.

In an industrial enclosure example, the inputs could include width, height, depth, ingress protection rating, mounting method, door arrangement, paint system and electrical components. Some values are discrete options, while others are numerical variables or free-form engineering requirements.

2. Validate the configuration

The CPQ rules engine checks the proposed configuration. Rules may require an option, exclude a combination, recommend an alternative or request engineering review.

There are several related approaches:

Rules-based configuration uses explicit if-then logic, dependencies and compatibility rules.
Constraint-based configuration evaluates relationships and limits across variables, such as dimensions, load, capacity, temperature or power.
Guided selling asks questions and recommends suitable products or options, but may not provide the engineering depth required to validate a complex product.

A guided selling interface can be useful for selecting a suitable product family. It is not automatically a substitute for a constraint solver or engineering rules engine.

3. Resolve components and quantities

After validation, BOM logic determines which components belong in the configured structure. A selected option can add an item, replace another item, change a quantity, alter a component attribute or create a new subassembly.

For example, selecting a dual-pump skid might:

change the top-level equipment quantity from one pump to two;
add a common skid frame;
add two motors and two couplings;
add a shared control cabinet;
add isolation valves and check valves for each pump;
change cable and pipe lengths based on layout dimensions;
require additional instrumentation.

The result may be a multi-level BOM rather than a flat list. A top-level skid contains pump assemblies, each pump assembly contains a motor and hydraulic components, and the control panel contains electrical subassemblies.

4. Apply calculations and attributes

Some BOM values cannot be selected directly. They must be calculated. A configured conveyor may require belt length based on conveyor dimensions. A heat exchanger may require surface area and tube count. A vehicle body may require material quantities based on length, width and payload.

The CPQ system may also assign attributes to BOM lines. A generic motor item might become a specific motor variant with a defined power, voltage, frequency, enclosure and efficiency class. In other cases, CPQ may pass calculated requirements to an ERP or PLM system that selects the final material number.

5. Calculate cost and price

Once the BOM is resolved, the system can use its lines as inputs to costing. Costing may include component purchase prices, manufacturing operations, labor, setup, subcontracting, freight, tooling, scrap, overhead and engineering effort. Pricing then applies commercial policies such as margin, discount, currency, customer segment and approval thresholds.

However, BOM generation and costing are separate capabilities. A CPQ platform may generate a commercial BOM without calculating detailed manufacturing cost. Conversely, a system may calculate price from a product model without producing a production-ready BOM.

6. Produce the quote and route approvals

The quote normally includes a customer-readable description rather than every internal BOM line. It may show major assemblies, options, quantities, technical specifications, exclusions, lead time, price and terms. Internal users may see a more detailed breakdown for margin analysis, review and approval.

Approval workflows can be triggered by low margin, unusual discounts, non-standard materials, extended lead time, engineering risk or an ETO requirement. Engineer-to-order (ETO) products require new or modified engineering work, so the BOM may remain provisional until engineering completes its review.

EBOM, MBOM and configurable BOM

Manufacturers should distinguish among several BOM concepts.

BOM type	Meaning	Typical purpose
EBOM	Engineering Bill of Materials: the product structure from a design or engineering perspective.	Defines designed assemblies, parts, revisions and technical relationships.
MBOM	Manufacturing Bill of Materials: the structure used to plan and build the product.	Includes manufacturing assemblies, operations, work-center relationships, consumables or packaging where applicable.
Configurable BOM	A rules-driven structure containing alternatives, optional items, quantities or conditions.	Represents a product family before one customer configuration is finalized.
Configured or order BOM	The resolved structure for one specific order or quote.	Supports a particular customer requirement, order, build or engineering review.

A CPQ system may own the configurable product model and produce a configured BOM, while PLM owns the authoritative EBOM and ERP or manufacturing systems manage the MBOM. In other architectures, CPQ may read item and structure data from PLM or ERP and return only configuration selections and commercial information.

These responsibilities must be defined explicitly. Treating an EBOM and an MBOM as interchangeable can create problems with assembly sequence, phantom assemblies, work instructions, bulk materials, packaging and shop-floor reporting.

Read more about manufacturing and CPQ terminology, including EBOM, MBOM, CTO and ETO.

Manufacturing examples

Industrial pump configuration

A pump manufacturer may sell several product families with options for capacity, pressure, fluid, temperature, impeller diameter, seal type, motor, coupling, baseplate and controls.

The configuration model can validate that:

the selected impeller supports the required flow and head;
the motor has sufficient power and the correct electrical specification;
the seal material is compatible with the fluid and temperature;
the casing material satisfies corrosion requirements;
the selected flange standard matches the connection requirement;
the baseplate supports the selected motor and pump arrangement.

The resulting BOM could contain a pump casing, impeller, shaft, mechanical seal, bearings, motor, coupling, guard, baseplate, fasteners, documentation and optional instrumentation. A CAD or engineering system may use the same configuration to generate a drawing or dimensional layout, but that capability is not present in every CPQ implementation.

HVAC equipment

An air-handling unit configuration may include airflow, static pressure, casing dimensions, filters, coils, fans, heaters, dampers, controls and access panels. Dimensions can influence the number of modules, panel quantities, coil size, fan selection and shipping sections.

A quote-only CPQ tool may calculate a price from these choices. A deeper manufacturing CPQ system may generate a variant BOM, calculate performance, create a product-specific drawing and pass an order structure to ERP or PLM. The buyer must verify which of these outputs are actually supported.

Specialty vehicle

A specialty vehicle may be configured with chassis, wheelbase, axle rating, body length, storage modules, electrical systems, hydraulic equipment and safety options. A body length change may affect frame members, floor panels, wiring harnesses, lighting, fasteners and weight calculations.

The BOM may need to reflect both optional content and calculated quantities. It may also need revision control because vehicle programs often evolve while orders remain open.

How BOM data supports costing and pricing

The BOM provides a product-specific basis for cost and price, but it does not automatically make the calculation accurate. The quality of the result depends on item master data, supplier costs, operation rates, labor assumptions, waste factors, currency handling and the date on which values are effective.

Costing inputs

purchased component cost;
raw material weight, length, area or volume;
machine and labor rates;
setup and changeover time;
subcontracted operations;
scrap and yield factors;
freight, packaging and customs costs;
engineering or project effort for ETO work;
tooling and one-time charges.

Pricing inputs

target margin or markup;
customer-specific price agreements;
volume breaks;
discount authority;
channel or dealer margins;
currency and exchange-rate policy;
tax, freight and surcharge treatment;
commercial risk and contingency;
approval thresholds.

Some businesses calculate cost and price in CPQ. Others use CPQ to assemble the commercial structure and rely on ERP for authoritative cost or price data. Integration design should define which system owns each value and how revisions, effective dates and failed transactions are handled.

BOMs and CAD, PLM and ERP integration

BOM-related CPQ architecture commonly involves several enterprise systems with different responsibilities.

System	Typical responsibility	Possible CPQ relationship
Customer Relationship Management (CRM)	Accounts, opportunities, contacts and sales activity.	Starts a configuration or stores the quote and opportunity reference.
ERP	Items, inventory, purchasing, costing, orders, production and finance.	Provides item and price data or receives an approved order structure.
PLM	Product definitions, revisions, engineering changes and lifecycle control.	Provides approved product structures or receives configured engineering data.
Product Data Management (PDM)	CAD files, documents and design data management.	Links configured products to models, drawings or controlled documents.
CAD	Computer-Aided Design models and drawings.	Uses configuration inputs to generate geometry or documentation where supported.
Product Information Management (PIM)	Commercial and technical product content.	Supplies descriptions, images, specifications and channel content.
MES	Execution and tracking of manufacturing operations.	Receives production-relevant structures or order data through ERP or direct integration.

These systems are not interchangeable. A CRM opportunity is not a BOM. A PLM EBOM is not necessarily a manufacturing MBOM. A CAD assembly is not automatically an ERP item structure. CPQ must translate or map data between these contexts when the workflow requires it.

Important integration questions include:

Which system is authoritative for item numbers and revisions?
Does CPQ create new items or only select existing items?
Is the BOM transferred as a flat list, hierarchical structure or both?
How are configured dimensions and calculated attributes passed downstream?
How are engineering changes reflected in open quotes?
What happens when an item, price or revision cannot be found?
Can the receiving system distinguish a quote BOM from an order or production BOM?
Are integrations synchronous, asynchronous or manually approved?

See the guide to CPQ integration with ERP, CRM, PLM, PDM, CAD and MES for broader architecture considerations.

CTO, ETO, MTO and ATO BOM workflows

BOM behavior depends on the manufacturing strategy.

Model	Meaning	BOM implication
Configure-to-order (CTO)	A predefined product is assembled after the customer selects allowed options.	CPQ can often resolve a known configurable BOM from approved variants.
Engineer-to-order (ETO)	Engineering designs or significantly modifies the product for the order.	CPQ may create a preliminary BOM and trigger engineering work before final release.
Make-to-order (MTO)	Production starts after an order, using a defined product or specification.	The BOM may be created or released when the order is accepted.
Assemble-to-order (ATO)	Standard subassemblies are stocked and combined for the order.	CPQ selects a combination of existing modules and may generate an assembly structure.

In CTO, the CPQ BOM can be relatively deterministic. In ETO, it may represent requirements rather than a final production structure. A system should make this status visible so that a customer-facing quote is not mistaken for an approved manufacturing release.

These workflows are discussed in more detail in the guide to configure-to-order, engineer-to-order and related manufacturing workflows.

Benefits of BOM-driven CPQ

More accurate configuration and pricing

When price and cost are derived from the actual configured content, the quote is less dependent on manual spreadsheet interpretation. This is especially valuable when options change material, capacity, labor, purchased components or manufacturing effort.

Faster sales-to-engineering handoff

A structured configuration and BOM give engineering a defined starting point. Engineers can focus on exceptions, calculations and new design work instead of re-entering every option from a sales document.

Better visibility of scope

A resolved BOM exposes included components, optional content, exclusions and quantities. This reduces ambiguity during commercial review and helps identify missing accessories or services.

Improved approval control

Approvals can use calculated margin, component cost, non-standard selections, lead time and engineering status rather than relying only on the total quote value.

Reusable product knowledge

Rules and product structures become a governed model that can be reused across direct sales, dealers, ecommerce, internal applications and customer service, subject to the capabilities of the chosen platform.

Limitations and risks

A commercial BOM may not be production-ready

A CPQ-generated BOM may omit routing, operations, work instructions, consumables, packaging, phantom assemblies or shop-floor details. It should not be sent directly to production without confirming its intended use.

Product models become difficult to maintain

Large product families can contain thousands of options and dependencies. Poorly governed rules create contradictions, duplicate logic and unexpected combinations. Ownership, naming standards, version control and automated regression testing are essential.

Data synchronization is complex

Item numbers, costs, prices, revisions and availability change in ERP, PLM and supplier systems. A stale CPQ model can produce an invalid or unprofitable quote even when the configuration logic is correct.

Engineering calculations require validation

Calculations for load, pressure, thermal performance, electrical sizing or structural requirements may require specialist review. A CPQ calculation should not be treated as an engineering approval unless the manufacturer has validated and governed it for that purpose.

Variant explosion can affect performance

When many dimensions, options and conditional components interact, the theoretical number of variants can become very large. The implementation may need modular architectures, constraint solvers, parameterized items or integration with engineering systems rather than storing every possible finished BOM.

Quote and order revisions can diverge

If a customer changes the configuration after approval, the system must show which BOM, cost, price, revision and document version correspond to the change. Otherwise, sales, engineering and production may work from different definitions.

Implementation guidance

Define the purpose of the BOM first

Document whether CPQ needs to produce a commercial BOM, costing BOM, EBOM, MBOM, order BOM or a preliminary ETO structure. One output may not satisfy every downstream process.

Establish data ownership

Assign ownership for products, options, item numbers, revisions, costs, prices, engineering formulas and manufacturing structures. A governance matrix should identify the system of record and the synchronization method for each data object.

Model the product before copying spreadsheets

Existing spreadsheets often mix options, prices, formulas, exceptions and manual judgment. Before migrating them, separate product attributes, configuration rules, BOM logic, cost data and approval policies.

Use stable identifiers

Every component, option, assembly and revision should have a consistent identifier. Descriptions alone are not sufficient for reliable integration because similar descriptions may refer to different materials, revisions or units of measure.

Test combinations, not just individual rules

Testing should include valid configurations, invalid combinations, boundary values, revision changes, quantity calculations, missing data, currency changes, discounts, approvals and downstream integration failures.

Define release states

Useful states may include draft, technically valid, commercially approved, engineering review, order-ready and production-released. The names vary, but the distinction between a quote configuration and a released manufacturing structure should be explicit.

Measure operational outcomes

Relevant measures can include quote cycle time, configuration error rate, engineering rework, margin variance, approval duration, percentage of quotes requiring manual correction, order-entry effort and integration failure rate. The right measures depend on the business process and baseline data.

The broader manufacturing CPQ implementation guide covers requirements, migration, testing, governance, deployment and maintenance.

What to ask CPQ vendors about BOM capability

Does the platform generate a hierarchical BOM, a flat commercial list or both?
Can it represent configurable BOMs with optional, alternative, conditional and calculated components?
Can BOM logic calculate quantities from dimensions, capacity or other variables?
Does it distinguish commercial, engineering and manufacturing structures?
Can it import or synchronize items and revisions from ERP or PLM?
Can it return configured data to CAD or engineering automation tools?
Does it support BOM versioning and effective dates?
Can users compare BOM changes between quote revisions?
How are costs, prices and currencies sourced and refreshed?
Can the system mark a configuration as requiring engineering review?
What APIs and integration events are available?
How are errors handled when an item or downstream transaction is unavailable?
Can dealers or customers see a simplified view while engineering users see detailed data?
What testing and rule-governance tools are included?
Which capabilities are standard, which require configuration and which require custom development?

Vendor evaluation should focus on the manufacturer’s actual product complexity and downstream process rather than on a generic feature checklist. The manufacturing CPQ comparison and selection resources can help structure an evaluation.

Semantic map

The following relationships summarize how BOMs connect configuration, costing, quoting and manufacturing systems:

CPQ configures configurable products.
Configuration rules prevent invalid combinations.
A configured product generates a configured BOM.
A configurable BOM represents product variants.
A configured BOM identifies components and quantities.
BOM components contribute to product cost.
Costing supports price calculation.
Pricing determines the commercial quote value.
A quote communicates configured scope and commercial terms.
Engineering review validates non-standard or ETO requirements.
EBOM represents an engineering product structure.
MBOM represents a manufacturing product structure.
CPQ exchanges item and order data with ERP.
CPQ may exchange product structure data with PLM.
CAD automation generates product-specific drawings when supported.
Approved configuration data can support production planning.

Frequently asked questions

What does BOM mean in CPQ?

BOM means Bill of Materials. In CPQ, it is the component and quantity structure associated with a configured product and may support costing, pricing, quoting, engineering or production.

Does every CPQ system generate a BOM?

No. Some CPQ systems calculate prices and create quotes without generating a BOM. Manufacturers should verify whether BOM generation is supported and whether the output is commercial, engineering or manufacturing-oriented.

How does CPQ create a BOM?

CPQ applies product rules, constraints, option dependencies and calculations to customer inputs, then selects components, assemblies and quantities for the resulting configuration.

What is the difference between a configurable BOM and a configured BOM?

A configurable BOM contains alternatives, options and conditional logic for a product family. A configured BOM is the resolved structure for one particular customer configuration or order.

Is a CPQ BOM the same as an EBOM?

Not necessarily. An EBOM is an engineering product structure. A CPQ BOM may be a commercial or order structure and may require engineering or PLM validation before it becomes an authoritative EBOM.

Is a CPQ BOM the same as an MBOM?

No. An MBOM is organized for manufacturing execution and may include operations, manufacturing assemblies, consumables or packaging that are absent from a commercial CPQ BOM.

Can BOM data be used to calculate price?

Yes, when component costs, quantities and pricing rules are available. The accuracy depends on current item data, supplier costs, labor and overhead assumptions, margins and commercial policies.

Can CPQ calculate manufacturing cost?

Some manufacturing CPQ systems can calculate detailed or estimated cost, while others use costs supplied by ERP or another system. This capability must be verified for the specific platform and implementation.

How does configuration affect the BOM?

Configuration choices can add, remove or replace components, change quantities, alter attributes or trigger calculated dimensions and subassemblies.

What is an example of a BOM rule?

A BOM rule could add a larger motor, reinforced frame and upgraded coupling when a machine is configured for a higher load or capacity range.

Can CPQ generate a CAD model from a BOM?

Some platforms integrate with CAD or engineering automation tools, but BOM generation alone does not create CAD geometry. CAD automation requires suitable parametric models, mappings and validated engineering logic.

How does CPQ support engineer-to-order products?

CPQ can capture requirements, calculate preliminary values, create a preliminary BOM and route the configuration to engineering. The final BOM may not exist until design work and technical approval are complete.

What happens when an item changes in ERP?

The implementation should define synchronization and error handling. CPQ may refresh the item, block the configuration, use an approved replacement or route the quote for review, depending on governance.

Can a BOM appear on the customer quote?

Sometimes. Customer quotes usually show selected equipment, major assemblies and options rather than every internal component. The visible level should match commercial clarity and confidentiality requirements.

How does a BOM affect quote approvals?

The BOM can provide the component cost, non-standard content, engineering effort and lead-time information used to trigger margin, technical or management approvals.

What BOM data should CPQ send to ERP?

The required data may include item numbers, quantities, units, configuration attributes, revisions, customer references and order status. The exact payload depends on whether ERP creates the order, production structure or only a sales document.

Why are BOM revisions important in CPQ?

Revisions show which product definition, component set, cost basis and rules were used for a quote or order. They help prevent discrepancies when products change during a sales cycle.

What is the main risk of using a CPQ BOM for production?

The main risk is assuming that a commercial or configured BOM contains all manufacturing data. Production may also require routings, operations, work instructions, revisions, quality data and manufacturing-specific structures.

How should manufacturers test BOM generation?

Testing should cover normal configurations, invalid combinations, boundary dimensions, option replacements, quantity calculations, revision changes, price changes, approval paths and failed ERP or PLM transactions.

In practice, BOM capability is one of the clearest differences between generic sales CPQ and manufacturing-oriented CPQ. A quoting tool may tell a salesperson what to charge. A manufacturing CPQ architecture can additionally explain what the customer is buying, which components are required, what it costs, whether it can be engineered and how the data should move toward production.

September 23, 2026

Quote Automation for Complex Manufactured Products

Quote automation for complex manufactured products is the use of configurable product models, engineering rules, costing logic, pricing rules and document generation to produce accurate quotations with less manual work. In a manufacturing context, automation must do more than calculate a selling price. It may need to validate dimensions, select compatible components, calculate performance, create a configurable bill of material (BOM), request engineering review and produce a quote that reflects what can actually be designed, purchased and built.

This capability is commonly delivered through configure, price, quote (CPQ) software. Manufacturing CPQ connects the commercial quotation process with product configuration and downstream systems such as enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD) and manufacturing execution systems (MES). The exact scope varies by platform: some CPQ tools focus mainly on guided selling and price calculation, while others support rules-based engineering, BOM generation, CAD automation and engineer-to-order workflows.

For example, a salesperson quoting an industrial pump may select flow rate, pressure, fluid type, temperature, motor, seal material, connection standard and enclosure. The system can reject incompatible combinations, calculate the required pump size, select valid components, apply material and labor costs, add appropriate margins, route exceptions for approval and generate a quotation. Where supported, it can also create a product-specific BOM, CAD model or drawing.

For background, see the guide to manufacturing CPQ, the detailed explanation of product configuration and configuration rules, and the overview of BOM, pricing and quoting.

What quote automation means in manufacturing

Quote automation is the controlled transformation of a customer requirement into a commercial and technical offer. The input may be a salesperson’s selections, an application engineer’s requirements, a dealer’s guided configuration or data submitted through an ecommerce channel. The output usually includes a validated configuration, price, lead-time assumptions, scope and exclusions, and a formal quote document.

Generic sales CPQ often automates product selection, discounts and proposal documents. Manufacturing CPQ adds industrial product logic. Its model may include dimensions, tolerances, materials, ratings, capacity calculations, electrical requirements, component compatibility, manufacturing constraints, supplier availability and engineering review conditions.

Capability	Generic sales CPQ	Manufacturing-oriented CPQ
Product selection	Options and packages	Options, dimensions, variants, components and technical requirements
Validation	Basic dependencies and exclusions	Rules, constraints, calculations, standards and engineering limits
Pricing	List prices, discounts and currencies	Material, labor, purchased parts, overhead, freight, margin and configuration-specific pricing
Output	Quote and proposal	Quote, configuration record, BOM, technical specification and possibly CAD outputs
Downstream connection	Customer relationship management (CRM) and order systems	CRM, ERP, PLM, PDM, CAD, MES, supplier and manufacturing systems

How automated quoting works

A robust quote automation process is a chain of dependent decisions rather than a single price calculation. The typical sequence is configuration, validation, engineering calculation, structure generation, costing, pricing, approval and document production.

1. Capture customer requirements

The process starts with structured requirements. Depending on the product, this could include required output, dimensions, operating environment, material, regulatory standard, power supply, delivery date, quantity and site conditions. A guided interface can ask questions in a logical order and hide options that are not relevant to the selected product family.

Structured requirements are preferable to free-text notes because they can be validated and used by later calculations. Free text may still be necessary for special instructions, but it should not be the only record of an important technical requirement.

2. Select and validate the product configuration

The CPQ product model represents product families, features, options, variants, components and relationships. Rules determine what can be selected together. A rule might state that a stainless-steel wetted path is required for a corrosive fluid, that a particular motor is unavailable above a specified load, or that a high-temperature seal must be selected when fluid temperature exceeds a threshold.

Rules-based configuration typically uses explicit conditions such as “if option A is selected, require option B” or “exclude option C.” Constraint-based configuration goes further by evaluating limits and relationships across variables, such as a maximum shaft load, available installation space or required heat-transfer capacity. Guided selling is different again: it helps a user reach a suitable product by asking business or application questions, but it may not fully validate the underlying engineering design.

More detail on these distinctions is available in the guide to product configuration.

3. Perform engineering calculations

Some products can be quoted from a fixed option matrix. Others require calculations. A pump may need a performance selection based on flow and head. An air-handling unit may require airflow, static pressure, coil capacity and casing dimensions. A vehicle body may require axle loading, payload and frame constraints.

Engineering calculations can be implemented inside CPQ, exposed through a calculation service, or performed by an external engineering application. The important design question is how the calculation result becomes a controlled configuration decision. If a calculation is performed manually in a spreadsheet but the result is not recorded in the product model, the quote may remain difficult to reproduce and audit.

4. Generate a product structure or BOM

A validated configuration can be mapped to a configurable BOM. A BOM is a bill of material: the components, quantities and relationships required for a product or assembly. Manufacturing environments commonly distinguish between an engineering BOM (EBOM), which describes the design structure, and a manufacturing BOM (MBOM), which describes how the product is assembled or produced.

Quote automation may generate a preliminary configurable BOM, an EBOM, an MBOM or a sales-oriented material list. These are not interchangeable outputs. A sales BOM may be sufficient for pricing, while production requires manufacturing operations, routings, substitutes, phantom assemblies, work centres and revision-controlled part numbers.

Some systems generate only a commercial list of selected items. Others can create detailed structures or pass configuration parameters to ERP or PLM for authoritative BOM creation. Buyers should verify the actual output and ownership of each structure rather than assuming that a CPQ-generated BOM is production-ready.

5. Calculate cost

Costing estimates what the manufacturer expects to spend to fulfil the configuration. Cost elements may include raw materials, purchased components, labor, subcontracting, setup, engineering effort, freight, installation and overhead. Cost data may come from ERP, a costing database, supplier records or manually maintained values.

Costing and pricing are related but distinct. Cost answers “what will this configuration cost us?” Pricing answers “what should we charge the customer?” Keeping the two concepts separate supports margin analysis, approval thresholds and controlled discounting.

6. Apply pricing and commercial rules

The pricing engine can combine base prices, option prices, quantity breaks, customer agreements, regional conditions, currencies, surcharges, escalation clauses, freight and discounts. A configured enclosure may add material cost, machining cost and a commercial surcharge. A rush delivery request may trigger a capacity or expedition fee rather than simply changing the product price.

Pricing rules should be versioned and traceable. If a quote is revised after a price-list change, the business should be able to identify which price list, cost basis, exchange rate and approval policy were used.

7. Route exceptions and approvals

Not every quote should be automatically approved. The workflow may route a quote to sales management when the margin falls below a threshold, to engineering when a non-standard dimension is requested, to legal when contractual terms change, or to operations when the delivery date conflicts with capacity.

Approval workflows should show the reason for the exception and the data supporting the decision. A vague “special approval required” status creates delay. A useful workflow identifies whether the issue is technical risk, commercial margin, credit exposure, delivery feasibility or a non-standard customer requirement.

8. Generate the quote document

The final document may include the configured product description, itemized or grouped pricing, quantities, delivery assumptions, validity period, payment terms, exclusions, warranty language and technical attachments. For complex equipment, the document may also include performance data, a preliminary drawing, a specification sheet or a configuration summary.

Document automation should be based on the validated configuration rather than copied text. Otherwise, the price may reflect one option set while the description or drawing reflects another.

Reference architecture for manufacturing quote automation

Quote automation normally sits between customer-facing channels and enterprise engineering and operations systems. A typical architecture contains the following layers:

Experience layer: salesperson, application engineer, dealer, distributor, customer portal or ecommerce interface.
Configuration layer: product models, options, dependencies, constraints, calculations and validation services.
Commercial layer: cost models, price lists, discount rules, currencies, taxes, freight and approval policies.
Engineering output layer: specifications, configurable BOMs, EBOM or MBOM requests, CAD parameters, drawings and technical documents where supported.
Enterprise integration layer: APIs, middleware or file-based exchanges with CRM, ERP, PLM, PDM, CAD, PIM and MES.
Governance layer: version control, permissions, audit history, testing, release management and ownership of product data.

CRM, or customer relationship management, generally stores accounts, opportunities and customer interactions. ERP, or enterprise resource planning, typically manages items, inventory, purchasing, costs, orders and financial information. PLM, or product lifecycle management, controls product definitions, revisions and lifecycle processes. PDM, or product data management, commonly manages CAD files and engineering data. PIM, or product information management, manages product content for commercial channels. MES, or manufacturing execution system, supports production execution. CAD, or computer-aided design, creates engineering models and drawings.

These systems may exchange data, but they are not substitutes for one another. The CPQ integration guide explains how these system boundaries affect architecture and data ownership.

Manufacturing example: quoting a configured industrial pump

Consider a manufacturer selling centrifugal pumps for industrial water, chemical and process applications. A quote may require the following inputs:

flow rate and differential head;
fluid composition, density and temperature;
pump material and wetted-part material;
seal type and elastomer;
connection standard and size;
motor power, voltage, frequency and enclosure;
baseplate, coupling guard and instrumentation;
certification, documentation and delivery requirements.

The configuration model can use the application inputs to identify a suitable pump family and impeller range. Rules can prevent a material from being used with an incompatible fluid, prevent a motor from being selected for an unsuitable voltage, and require a high-temperature seal when the operating temperature exceeds a defined limit.

The system can then select a pump assembly, motor, coupling, baseplate, seal kit and instruments. It can calculate a preliminary cost from material and purchased-part prices, apply labor and overhead assumptions, and produce a selling price using customer and channel rules. If the requested duty point falls outside standard performance limits, the quote can be routed to an application engineer instead of being rejected or silently accepted.

Depending on the implementation, the output may be a quote-level BOM, a technical selection sheet, a CAD assembly, a drawing request or an ERP sales-order configuration. These outputs should be clearly labelled by maturity. A preliminary quote BOM is not automatically an approved manufacturing BOM.

Where quote automation fits different manufacturing workflows

Workflow	Role of quote automation	Typical output
Configure-to-order (CTO)	Selects proven modules and options within a defined product model	Validated configuration, price, standard BOM and order data
Make-to-order (MTO)	Triggers production of a product after the customer order, often with limited configuration	Quote, demand information and item or variant selection
Assemble-to-order (ATO)	Combines stocked or standard subassemblies after selection	Configuration, component demand and assembly structure
Engineer-to-order (ETO)	Captures requirements and identifies engineering work for a non-standard design	Budgetary quote, engineering scope, assumptions and approval tasks

CTO is generally the easiest environment for high automation because the product rules and outputs are repeatable. ETO requires more human review because the design may not exist when the quote starts. Automation can still improve ETO by capturing requirements, estimating engineering effort, creating a preliminary structure and identifying assumptions, but it should not imply that an unverified design is production-ready.

See the guide to configure-to-order, engineer-to-order and related manufacturing workflows for a fuller comparison.

Benefits of quote automation for manufacturers

Shorter response cycles

Automating repeatable configuration, calculations and document production reduces the number of manual handoffs between sales, application engineering and pricing teams. The benefit is greatest where quotes repeatedly use the same product families and rules.

Fewer configuration and pricing errors

Validation can prevent combinations that a salesperson may not know are technically incompatible. Central pricing logic can also reduce inconsistent discounts and forgotten surcharges. Automation does not eliminate errors if the underlying model or price data is wrong; it moves the control point earlier in the process.

Better engineering capacity

Engineers can spend less time reviewing standard configurations and more time on genuine exceptions, new designs and complex applications. This requires a clear boundary between standard, reviewable and non-standard work.

More consistent manufacturing data

A configuration record linked to a BOM or ERP item can reduce re-entry from quote to order. This is valuable when the quoted product contains many options, quantities or technical attributes.

Improved margin visibility

When cost elements are linked to the configuration, commercial teams can see the effect of material substitutions, custom dimensions, expedited delivery and discounting before committing to a price.

Traceable decisions

Versioned rules, prices, approvals and configuration snapshots make it easier to explain why a quote had a particular scope and price. This supports revision management and post-order analysis.

Limitations and risks

Incorrect product models produce repeatable errors

Automation amplifies the logic it is given. An incomplete dependency, outdated part number or incorrect calculation can create many incorrect quotes quickly. Model validation and test cases are essential.

Engineering knowledge is difficult to encode

Experienced engineers often use tacit knowledge, judgement and exceptions. Converting that knowledge into maintainable rules requires workshops, examples, ownership and agreement on what is standard.

Cost data may not be current

A sophisticated pricing engine cannot compensate for stale supplier prices, missing labor standards or inconsistent overhead assumptions. Data freshness and ownership should be part of the design.

BOM maturity may be misunderstood

A CPQ-generated list may support pricing but lack the revisions, operations and manufacturing context needed for production. The handoff to PLM or ERP must define which system creates and controls the released structure.

ETO remains partially manual

Quote automation can organize ETO work, but it cannot reliably remove engineering review where the product, performance or compliance basis is genuinely new.

Integration creates operational dependencies

Real-time calls to ERP, PLM or CAD may fail because of unavailable services, permissions, latency or inconsistent master data. The implementation needs error handling, reconciliation and a defined fallback process.

Rules can become difficult to maintain

Duplicated logic across CPQ, ERP, CAD and spreadsheets creates conflicting outcomes. A governance model should identify where each rule is authoritative and how changes are released.

Data required for automated quoting

A manufacturing quote automation project normally requires more than a product catalogue. The data foundation may include:

product families, variants and option definitions;
part numbers, revisions, units of measure and lifecycle status;
compatibility, exclusion and requirement rules;
engineering formulas, limits, standards and calculation inputs;
configurable BOM relationships and quantities;
material, purchased-part, labor and overhead costs;
price lists, discounts, customer agreements and currencies;
lead-time, availability and sourcing assumptions;
document templates, technical descriptions and revision references;
approval thresholds and exception categories.

Data should be classified by owner. Product engineering may own technical rules, manufacturing engineering may own production structures, finance or commercial operations may own pricing policies, and ERP administration may own item and cost master data. A CPQ project should not hide these ownership decisions inside application configuration.

Implementation approach

Define the first product scope

Start with a product family that has meaningful quote volume, repeatable rules and measurable business pain. Avoid selecting the most complex product as the first model unless the organization has the resources to manage its engineering exceptions.

Document the current quote process

Map every input, spreadsheet, calculation, approval, system lookup and manual handoff. Identify where errors occur and distinguish standard configurations from exceptions. This process map is more useful than a feature checklist when evaluating software.

Build a governed product model

Define features, options, attributes, constraints, calculations and outputs in a structured model. Use real historical quotes and known invalid combinations as test cases. Decide whether rules belong in CPQ, an engineering service, ERP, PLM or another system.

Separate configuration, cost and price

Do not use a single field to represent an option’s cost, price and commercial description. A selected motor may have a cost, a list price, a customer-specific price, a freight effect and a technical description. These values may come from different sources and change under different controls.

Design the system handoff

Specify what happens when a quote is accepted. Does CPQ create an ERP sales order, send a configuration identifier, request a BOM, create a PLM object, upload CAD parameters or simply pass a PDF to a salesperson? Each exchange needs field mapping, error handling and a clear system of record.

Test combinations and revisions

Testing should include valid configurations, invalid combinations, boundary values, missing data, price changes, currency changes, revisions, approval exceptions and integration failures. Test the generated document as well as the internal configuration and price.

Release and govern the model

Product models need version control, change requests, named owners and release dates. A rule change may affect open opportunities, existing quotes and active orders. The organization should decide whether old quotes retain the old model version or are recalculated under the new one.

The manufacturing CPQ implementation guide covers requirements, migration, testing, governance, adoption and maintenance in more detail.

How to evaluate quote automation software

Buyers should evaluate the complete quote-to-order use case rather than counting generic CPQ features. Useful questions include:

Can the system model the product’s dimensions, options, dependencies and engineering constraints?
Can non-developers maintain rules, or does every change require custom code?
What types of calculations are supported, and how are calculation versions controlled?
Does the platform generate a sales BOM, configurable BOM, EBOM or MBOM?
How are part numbers, revisions, substitutes and quantities handled?
Can the system connect to authoritative ERP, PLM, PDM, CAD and CRM data?
Can it create CAD models or drawings, or does it only pass parameters to another system?
How are standard configurations separated from ETO exceptions?
Can it show cost, margin, price and approval reasons independently?
How are quote revisions, expired prices and historical configurations stored?
What APIs, webhooks, integration tools and error-monitoring capabilities are available?
How are dealers, distributors, application engineers and internal sales users supported?
What happens when an integration or external calculation service is unavailable?

Vendor documentation and a proof of concept should be used to verify these answers. A demonstration of a simple option-selection flow does not prove that a platform can handle engineering calculations, production structures or CAD automation.

Key measures after deployment

Useful measures should connect automation to manufacturing outcomes. Examples include quote cycle time, percentage of quotes completed without engineering intervention, configuration error rate, quote-to-order conversion, gross-margin variance, approval turnaround time, percentage of quotes using current price data, re-entry between systems and time required to maintain a product model.

Speed alone is not sufficient. A fast quote that contains an invalid motor, incomplete BOM or unsupported delivery promise can increase downstream cost. Quality, traceability and handoff accuracy should be measured alongside response time.

Related concepts

Quote automation is closely related to CAD and engineering automation when a configuration drives models, drawings or calculations. It also depends on BOM generation, costing and pricing and on integration architecture for reliable movement of data. Manufacturers comparing commercial approaches can use the manufacturing CPQ comparison and selection resources.

Semantic map

The following relationships summarize the main entities and data flows described in this guide:

CPQ configures configurable manufactured products.
Configuration rules prevent invalid product combinations.
Constraint-based configuration evaluates engineering limits.
Guided selling collects customer requirements.
Engineering calculations determine technical selections.
A configured product generates a quote-level BOM.
An EBOM represents an engineering product structure.
An MBOM represents a manufacturing product structure.
Costing calculates the expected cost of a configuration.
Pricing converts cost and commercial rules into a selling price.
Approval workflows review commercial and technical exceptions.
Quote documents describe the validated configuration.
CAD automation generates product-specific drawings when supported.
CPQ exchanges customer and configuration data with CRM.
CPQ exchanges item, cost and order data with ERP.
PLM controls product revisions and lifecycle information.
PDM manages engineering files and CAD data.
ETO quoting identifies work that requires engineering review.
CTO quoting uses pre-engineered product rules and modules.
Product model governance controls changes to quoting logic.

Frequently asked questions

What is quote automation for complex manufactured products?

It is the automated conversion of customer requirements into a validated configuration, cost, selling price, approval workflow and quote document. Depending on the platform, it may also produce BOMs, technical specifications or CAD outputs.

How is manufacturing quote automation different from sales CPQ?

Sales CPQ commonly focuses on product selection, pricing, discounts and proposals. Manufacturing CPQ may additionally handle engineering constraints, calculations, configurable BOMs, CAD parameters, production data and ERP or PLM handoffs.

Does quote automation generate a BOM?

Some platforms generate a quote-level or configurable BOM, while others send configuration data to ERP or PLM for BOM creation. Buyers must verify whether the output is a sales BOM, EBOM, MBOM or production-ready structure.

Can CPQ calculate the cost of a configured product?

Many manufacturing CPQ systems support cost models, but the depth varies. Costing may include materials, purchased parts, labor, overhead, freight and engineering effort. The source and freshness of the cost data are critical.

What is the difference between costing and pricing in CPQ?

Costing estimates the manufacturer’s expense to produce or deliver the configuration. Pricing determines the amount charged to the customer using list prices, margins, discounts, agreements, surcharges and other commercial rules.

Can quote automation handle engineer-to-order products?

It can support ETO by capturing requirements, estimating engineering work, recording assumptions and routing exceptions. It should not represent an unverified custom design as a standard, production-ready configuration.

Can a CPQ system create CAD drawings?

Some platforms support CAD automation or connect to CAD automation services. Others only store selections or pass parameters to another system. This capability must be verified for the required CAD tool, model types, drawings and revision process.

What product data is needed to automate quotes?

Typical data includes product families, options, part numbers, rules, calculations, BOM relationships, costs, prices, lead times, technical descriptions, revisions and approval policies.

Where should configuration rules be maintained?

The answer depends on the architecture. Rules may be maintained in CPQ, PLM, ERP, CAD or an external service. The important requirement is to define one authoritative owner for each rule and prevent conflicting copies.

How does quote automation connect with ERP?

CPQ may retrieve item, cost, inventory or customer data from ERP and send back a quote, configuration identifier, BOM request or sales order. The integration can use APIs, middleware or controlled file exchanges.

Does quote automation replace application engineers?

No. It can automate repeatable selections and identify exceptions, allowing engineers to focus on non-standard applications, new designs, performance review and technical risk.

How are invalid configurations prevented?

Rules and constraints can require compatible options, exclude combinations, enforce numeric limits and trigger calculations. The quality of prevention depends on the completeness and maintenance of the product model.

Can quote automation manage different currencies and customer prices?

Many commercial CPQ systems support currencies, price lists, customer agreements and discount rules. Manufacturers should verify exchange-rate control, effective dates, tax handling and how historical quotes retain their original pricing basis.

What is a configurable BOM?

A configurable BOM is a product structure containing rules or selection conditions that determine which components and quantities apply to a particular configuration. It may require transformation into an approved EBOM or MBOM before production.

How should manufacturers test an automated quoting model?

Use historical quotes, valid and invalid combinations, boundary values, price changes, revisions, approval exceptions, missing data and integration failures. Test the configuration, price, BOM, document and downstream transaction together.

What are the main risks of automated quoting?

Common risks include incorrect rules, stale costs, unclear BOM ownership, duplicated logic, integration failures, unsupported ETO assumptions and documents that do not match the configured product.

How should a manufacturer choose a quote automation platform?

Evaluate product-model depth, rules, calculations, BOM outputs, pricing, CAD and engineering integration, ERP and PLM connectivity, workflow, governance, APIs, implementation effort and support for CTO, MTO, ATO and ETO processes.

What is the first product family to automate?

A suitable first candidate usually has substantial quote volume, repeatable configuration rules, available product data and a clear business problem. It should be complex enough to demonstrate value but bounded enough to govern effectively.

How can a manufacturer measure quote automation success?

Measure quote cycle time, engineering effort, configuration errors, margin variance, approval time, re-entry, use of current data and downstream order accuracy. Speed should be assessed alongside technical and commercial quality.

September 22, 2026

Lead-Time Calculation During Product Configuration

Lead-time calculation during product configuration is the process of estimating when a specific configured product can be completed and delivered. In manufacturing CPQ, the calculation may use the selected options, generated bill of materials (BOM), inventory, supplier lead times, engineering effort, production operations, capacity, approvals and shipping rules.

A manufacturing CPQ system, meaning Configure, Price, Quote software, should not treat lead time as a fixed number attached to a product family. A pump with a standard motor, stocked seal and existing design may have a very different lead time from the same pump with a special alloy, custom impeller, non-standard voltage and customer-specific drawings.

The result can be an estimated lead time, a production date, a promised ship date or a delivery-date range. The quality of that result depends on the product model, BOM data, manufacturing calendars, inventory accuracy and the integration between CPQ and systems such as enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES) and computer-aided design (CAD).

Lead time is therefore part of the configuration, costing and quoting process. It should be calculated from the selected product characteristics and the work required to fulfill them, rather than copied from a generic catalog record.

Why lead time belongs in manufacturing CPQ

Generic sales CPQ often calculates price, discount and quote totals. Manufacturing CPQ must frequently determine whether the selected product can be engineered, sourced and produced within a realistic time frame. This requires more than a sales promise.

During configuration, the system may identify:

which components are required by the configured product;
whether components are in stock, allocated or subject to replenishment;
which operations are required and in what sequence;
whether engineering calculations, CAD changes or approvals are needed;
whether selected options trigger supplier or subcontractor lead times;
whether the product is configure-to-order (CTO), make-to-order (MTO), assemble-to-order (ATO) or engineer-to-order (ETO);
whether available production capacity supports the requested date.

The calculated result can then appear in the quote document alongside price, assumptions, validity period, configuration summary and delivery terms. See the guide to BOMs, pricing and quoting for the relationship between these outputs.

What data is required for lead-time calculation?

A useful lead-time model combines commercial, product, engineering and operational data. A CPQ configurator may hold some of this data directly, while other values are retrieved from connected enterprise systems.

Data category	Examples	Effect on lead time
Product configuration	Dimensions, materials, motor size, voltage, pressure rating, accessories	Determines required components, operations and engineering rules
Configured BOM	Raw materials, purchased parts, subassemblies and optional items	Identifies dependent procurement and production work
Inventory	Available, reserved, safety stock and incoming quantities	Changes whether a part can be issued immediately
Routing	Cutting, machining, welding, painting, assembly, inspection and testing	Defines processing time and operation sequence
Supplier data	Standard and expedited supplier lead times, order calendars	Determines external procurement constraints
Engineering work	Selection calculations, drawing updates, design review and approval	Adds effort before or during production
Calendars and capacity	Shifts, holidays, work centers, queues and maintenance periods	Converts work duration into realistic dates
Logistics	Packaging, carrier service, export documentation and transit	Converts completion date into delivery date

How the calculation works

1. Validate the configuration

The system first evaluates product rules and constraints. For example, a valve configuration may require a particular body material for a corrosive fluid, prohibit a pressure rating with a selected actuator, and require a positioner when a control signal is specified.

Invalid combinations should be blocked before lead time is calculated. Otherwise the system may produce a date for a product that cannot be engineered or manufactured. Rules may also assign lead-time effects. A standard motor may add no additional delay, while a custom motor may add six supplier weeks.

Rules-based configuration applies explicit if-then logic. Constraint-based configuration evaluates permitted and prohibited combinations across multiple parameters. Guided selling asks questions and recommends suitable options, but it does not by itself guarantee a manufacturable configuration. These distinctions are explained further in the product configuration guide.

2. Generate or resolve the configured BOM

The configured BOM identifies the materials, components and subassemblies needed for the selected product. A configurable BOM may contain conditional items, quantities, alternates and phantom assemblies. The CPQ result may be an engineering bill of materials (EBOM), a manufacturing bill of materials (MBOM), or data that is transformed into one of these structures by an ERP or PLM system.

An EBOM describes the product from an engineering perspective. An MBOM describes how it will be manufactured, including plant-specific operations and production structure. They are related but not interchangeable. For lead-time calculation, the system needs to know which structure contains the relevant purchasing and manufacturing dependencies.

For example, selecting a stainless-steel pump casing can change the BOM from a stocked cast iron casing to a made-to-order casting. That one option can affect material procurement, machining, inspection and the final assembly sequence.

3. Check inventory and procurement

The system evaluates whether required items are available. It should distinguish unrestricted stock from reserved stock, quality-hold stock, safety stock and expected receipts. A simplistic check that only looks for a part number can produce an unreliable date.

For unavailable items, the calculation may use supplier lead time, purchase-order status, minimum order quantities, receiving time and inspection time. Long-lead components can become the critical path. The critical path is the sequence of dependent activities that determines the earliest possible completion date.

Inventory and supplier data commonly come from an ERP system or supplier-management process. CPQ should show whether the value is real-time, periodically synchronized or maintained manually. A quote should not present a precise date if the underlying availability is stale.

4. Add engineering and design effort

Standard configurations may use an approved design and require no additional engineering. Other configurations may need sizing calculations, CAD model updates, drawings, design review, customer approval or a new part number.

Engineering effort can be modeled as fixed activities, conditional activities or calculated work. For example, a conveyor configured within an approved dimensional range may use an existing parametric design. A conveyor outside that range may trigger ETO work, including structural analysis and a new fabrication drawing.

CAD automation can generate product-specific drawings or models, but not every CPQ platform provides CAD automation. Where it is used, the calculation should account for generation, review and release time. See CAD and engineering automation in CPQ.

5. Calculate manufacturing operations

Manufacturing duration may include setup time, run time, queue time, movement, subcontracting, inspection, testing and rework allowances. These values can be assigned to routing operations, work centers or product families.

Processing time and elapsed time are different. A machine may require four hours of work but be scheduled three days later because the work center has a queue. A lead-time engine should therefore distinguish:

touch time: the time employees or equipment actively work on the product;
queue time: waiting before an operation begins;
transfer time: movement between operations or facilities;
calendar time: elapsed time after shifts, weekends and holidays are applied.

If CPQ cannot access finite-capacity scheduling, it may calculate a standard or quoted lead time rather than a capacity-constrained promise. That limitation should be visible to users.

6. Apply dependencies and calendars

Activities can run sequentially or in parallel. Purchased components may be ordered while engineering completes, but final assembly cannot begin until all required parts are available. A proper calculation represents these dependencies rather than adding every duration together.

Calendars may differ by plant, work center, supplier and customer location. The model should account for working days, shutdowns, time zones, regional holidays and planned maintenance. A five-day supplier lead time may mean five supplier working days, not five calendar days.

7. Add inspection, approval and logistics time

Quality inspection, factory acceptance testing, customer approval, packaging and documentation can affect the final date. These activities are particularly important for electrical equipment, medical equipment, pressure equipment and engineered machinery.

The delivery date should be distinguished from the manufacturing completion date. Transit, export controls, customs, installation and site commissioning may be outside the CPQ calculation or may be added as separate logistics stages.

Example: configuring an industrial pump

Consider a centrifugal pump configured for a chemical-processing application. The user selects flow, head, fluid, temperature, casing material, seal type, motor, baseplate and control panel.

The configuration rules validate that the selected seal and casing are suitable for the fluid. Engineering calculations select the impeller diameter and motor rating. The configured BOM includes the casing, impeller, shaft, seal, motor, coupling, baseplate, fasteners and control components.

Activity	Illustrative dependency
Engineering selection	Required before the final BOM and drawing release
Special alloy casing	Supplier casting and inspection create a long-lead dependency
Custom motor	Purchased in parallel with casing procurement
Machining	Starts after casting receipt and inspection
Assembly	Starts after machined parts and motor availability
Performance test	Follows assembly and precedes shipment

The final estimate is driven by the longest dependent path, not by the sum of every item. If the casing takes eight weeks and the motor takes six weeks, the motor does not necessarily add six weeks to the casing if procurement occurs in parallel. However, a late engineering approval or failed inspection can move the promised date.

The quote should state assumptions such as supplier availability, approval timing, delivery location and whether the date is estimated or committed.

Lead time across CTO, MTO, ATO and ETO

Workflow	Lead-time characteristic
Configure-to-order (CTO)	Uses predefined options and approved product structures; lead time is often driven by inventory, assembly and scheduling
Make-to-order (MTO)	Production begins after the order; material procurement and manufacturing are important dependencies
Assemble-to-order (ATO)	Subassemblies are stocked and final configuration or assembly occurs after order entry
Engineer-to-order (ETO)	Customer requirements trigger new engineering, design approval and often new manufacturing data

These models should not be collapsed into one generic lead-time rule. An ETO product may need a quotation-stage engineering estimate, followed by a revised date after design release. More detail is available in the manufacturing workflow guide.

Integration architecture

A practical architecture assigns ownership to the appropriate system:

CPQ: captures requirements, validates configuration, calculates commercial values and presents the quote;
CRM: stores account, opportunity and customer interaction data;
ERP: manages items, inventory, purchasing, routings, orders and often standard lead times;
PLM: manages product structures, revisions, engineering change and release status;
PDM: manages engineering files and CAD document relationships;
CAD: creates or updates geometry, drawings and models when automation is available;
MES: records and sometimes schedules shop-floor execution;
PIM: manages product information for channels and catalogs, but usually does not replace ERP or PLM scheduling data.

Data flows may include configuration selections from CPQ to ERP and PLM, availability from ERP to CPQ, engineering outputs from CAD or PDM, and order status from ERP or MES back to the customer-facing process. Integration patterns and API design should be addressed during architecture planning; see CPQ integrations.

Lead-time limitations and risks

Stale data: inventory and supplier dates may change after the quote is created.
Insufficient capacity data: a standard duration is not the same as a scheduled completion date.
Unmodeled engineering work: custom calculations, reviews and drawing changes are often omitted.
Ambiguous BOM ownership: an EBOM may not contain the manufacturing operations required for scheduling.
Hidden dependencies: tooling, certifications, subcontracting and customer approvals can become critical-path activities.
False precision: a date down to the day may be misleading when supplier or capacity uncertainty is high.
Overly rigid rules: lead-time logic becomes difficult to maintain if every exception is hard-coded in the configurator.

Where uncertainty is material, the quote can provide a range, a target date with assumptions, or separate dates for engineering release, production completion and delivery. Any promise should be governed by the company’s commercial and production policies.

Implementation recommendations

Define the business meaning of lead time. Decide whether the output means engineering completion, ship date, customer delivery date or a committed promise.
Map the critical path. Identify procurement, engineering, production, inspection and logistics activities that can delay fulfillment.
Start with high-value product families. Model the configurations where lead-time accuracy has the greatest commercial or operational impact.
Assign data ownership. Document whether CPQ, ERP, PLM, PDM, MES or a supplier process owns each value.
Separate rules from transactional data. Product constraints belong in the product model; current inventory and purchase-order status should normally come from operational systems.
Test realistic scenarios. Include standard, long-lead, unavailable, substituted, engineered and invalid configurations.
Version the model. A quoted lead time should be traceable to the product rules, BOM revision, supplier assumptions and calendars used at calculation time.
Monitor estimate versus actual. Compare quoted, planned and completed dates to identify unreliable routing, supplier or engineering assumptions.

Implementation should be treated as a product-data and process-governance project, not only as a user-interface project. The CPQ implementation guide covers requirements, testing, governance and maintenance in more detail.

How lead time connects to costing, pricing, BOMs and quote documents

Lead time is not the same as price, but the two often share data. Expedited procurement, overtime, premium freight or additional engineering can change cost and therefore price. Conversely, a low-cost option may have a longer supplier lead time.

The configured BOM supports material costing and procurement analysis. Routing data supports labor and machine costing. Engineering tasks can be priced as an engineering charge or absorbed into product cost. Approval rules may prevent a salesperson from promising an accelerated date without margin review or operational approval.

A complete quote may therefore contain the configuration summary, BOM or line-item description, price, validity period, estimated lead time, delivery assumptions, exclusions, approval status and next steps. The quote should make clear which values are calculated and which are manually entered.

Semantic map

The following relationships summarize how lead-time calculation fits into manufacturing CPQ:

Configuration selections determine product requirements.
Product requirements determine the configured BOM.
The configured BOM determines procurement and production dependencies.
Inventory and supplier data determine material availability.
Routing and capacity data determine manufacturing duration.
Engineering rules determine design and approval work.
The critical path determines the earliest feasible completion date.
ERP, PLM, CAD and MES integrations provide operational and engineering data.
Lead-time results support pricing, approvals and quote documents.
Actual completion data improves future lead-time estimates.

FAQ

What is lead-time calculation in CPQ?

It is the calculation of how long a configured product will take to engineer, source, manufacture, test and deliver.

Why is a fixed product lead time often inaccurate?

Options such as materials, motors, dimensions, custom controls and engineering requirements can change the BOM, suppliers, operations and critical path.

Does every CPQ system calculate manufacturing lead time?

No. Some CPQ systems calculate only price and quote content. Buyers should verify support for BOMs, routings, inventory, capacity and enterprise integrations.

What is the difference between quoted and committed lead time?

A quoted lead time is an estimate based on stated assumptions. A committed lead time is an approved promise supported by operational planning and commercial policy.

Can CPQ calculate lead time without ERP integration?

It can use static product rules and standard durations, but accuracy is limited without current inventory, purchasing and order data.

How does a BOM affect lead time?

The BOM identifies the components and materials that must be available, purchased, fabricated, assembled or inspected.

Is an EBOM the same as an MBOM?

No. An EBOM describes the engineering product, while an MBOM describes the manufacturing structure and may include plant-specific operations.

How do configuration rules affect delivery dates?

Rules validate options and can add conditional procurement, engineering, inspection or production activities to the calculation.

What is the critical path in a configured product?

It is the dependent sequence of activities that determines the earliest possible completion date.

Can lead time and price be calculated together?

Yes. The same configuration can drive BOM costing, expedited charges, engineering fees, production assumptions and the quoted delivery estimate.

How is ETO lead time different from CTO lead time?

ETO includes customer-specific engineering and design release, while CTO normally uses predefined and approved product options.

Should lead time be shown as a date or a range?

A date is appropriate when data and capacity are reliable. A range or date with assumptions is safer when supplier, engineering or scheduling uncertainty is significant.

How are supplier lead times used?

Supplier lead times are applied to unavailable purchased parts, usually with order, receiving, inspection and calendar rules.

Does CAD automation reduce lead time?

It can reduce manual design and drawing effort when the configuration is within the supported parametric model, but review and release activities may still be required.

How should customer approvals be included?

Approval activities should be modeled as dependencies when production or procurement cannot proceed until the customer accepts drawings, specifications or test plans.

What happens when inventory data is stale?

The calculated date may be unreliable. The system should show the data timestamp or use a cautious estimate and require confirmation before commitment.

Can CPQ calculate finite production capacity?

Only when it has suitable scheduling or capacity data, directly or through integration. Otherwise it normally uses standard durations rather than a fully scheduled promise.

Which teams own lead-time rules?

Ownership is usually shared by product management, engineering, supply chain, manufacturing planning, sales operations and IT, with clear governance for changes.

September 21, 2026