CPQ Guide

Tag: quote automation

  • 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

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

  • How Pricing Engines Work in Manufacturing CPQ

    A pricing engine in manufacturing CPQ is the software component that calculates the commercial price of a valid configured product. It uses the selected options, dimensions, materials, quantities, manufacturing data, cost records, customer terms, currencies, discounts and margin policies to produce a price that can be quoted and approved.

    In a simple sales CPQ system, pricing may mean adding products, quantities and discounts to a price list. Manufacturing CPQ usually requires more. A configured pump, industrial enclosure, conveyor, machine or specialty vehicle may have dimensions, performance requirements, materials, motors, controls and safety options that change the bill of materials (BOM), manufacturing effort and final price. The pricing engine must therefore work with the product configuration and, in some implementations, with engineering calculations, cost estimates and generated manufacturing data.

    The pricing engine is not the same as the product configuration engine. The configuration engine determines whether a product combination is valid. The pricing engine determines what that valid combination costs and what the customer should be charged. They normally operate as connected services in a broader configure, price, quote (CPQ) workflow.

    For a broader explanation of BOM generation, pricing and quote automation, see the related CPQ Guide resource.

    What a manufacturing CPQ pricing engine does

    A manufacturing pricing engine transforms product and commercial data into a price calculation. A typical calculation may include:

    • base product or assembly price;
    • configured options and accessories;
    • quantity-based pricing;
    • dimensions, capacity or performance calculations;
    • materials and purchased components;
    • labor, machine time and subcontracting;
    • setup, tooling, engineering and testing charges;
    • freight, packaging and installation;
    • customer, channel or project-specific discounts;
    • currency conversion, taxes and payment terms;
    • target margin and approval thresholds.

    The engine may calculate a selling price directly from a price list, or it may first calculate an estimated or standard cost and then apply a markup or margin rule. More advanced manufacturing implementations calculate prices from a generated or derived BOM, routing assumptions, engineering formulas or external costing services.

    Where pricing fits in the manufacturing CPQ workflow

    Pricing is one stage in a chain of dependent decisions. A typical workflow is:

    1. Product selection: A salesperson, dealer, engineer or customer selects a product family.
    2. Configuration: The user selects features such as capacity, dimensions, motor type, material and controls.
    3. Validation: Rules and constraints identify incompatible or incomplete selections.
    4. Engineering calculation: The system may calculate performance, sizing, power, loads or other technical values.
    5. BOM derivation: The configured product is mapped to components, assemblies and quantities.
    6. Cost calculation: Material, labor, purchased parts, overhead and special work are estimated or retrieved.
    7. Price calculation: Price lists, markups, discounts, surcharges, freight and commercial policies are applied.
    8. Approval: Exceptions such as low margin, unusual terms or non-standard engineering are routed for review.
    9. Quote generation: The system produces a customer-facing quote and, where supported, internal BOM, CAD or order data.

    Not every CPQ platform performs every step. Some systems calculate price and produce a proposal while relying on an enterprise resource planning (ERP) system for costs and a product lifecycle management (PLM) or product data management (PDM) system for engineering data. Buyers should verify which system owns each calculation and how results are exchanged.

    Core data used by a pricing engine

    Product and option data

    The engine needs a product model that identifies base products, options, accessories, variants and dependencies. For example, a pump model may have selectable flow range, head, impeller material, seal type, motor rating, voltage and control package. Each selection can add a price, replace a standard component or trigger a calculation.

    Product configuration is governed by rules. A stainless-steel wetted path may be required for a chemical application. A particular motor may be unavailable at a selected voltage. A larger impeller may require a larger housing. These rules belong primarily to the configuration model, but their outcomes provide inputs to pricing.

    See the guide to product configuration, options and configuration rules for a deeper treatment of product models and constraints.

    Price lists and price components

    A price list may contain prices for finished products, options, spare parts, services or standard assemblies. The data can be organized by currency, market, customer class, sales channel, effective date or legal entity.

    Price components may be additive, substitutive or conditional:

    • An additive component adds a charge for an accessory.
    • A substitutive component replaces the standard price when a premium material is selected.
    • A conditional component applies only when a feature, market, quantity or delivery condition is present.

    For example, a standard carbon-steel enclosure might have a base price, while stainless steel replaces the material cost and adds fabrication labor. A washdown finish may add a separate coating charge. The engine must avoid charging twice when one option replaces another.

    Cost data

    Cost-based pricing requires reliable cost data. Common sources include ERP item costs, supplier prices, standard costs, manufacturing routings, labor rates, machine rates, subcontractor estimates and engineering-service rates.

    Cost can be stored at different levels of accuracy. A standard cost may be adequate for an early budgetary quote. A detailed estimate may be necessary for an engineered-to-order (ETO) machine involving custom design, purchased components and fabrication. The system should identify whether a result is an estimate, a standard cost or an approved project cost.

    Customer and commercial data

    Customer records may determine contract prices, discount groups, currencies, territories, payment terms, freight rules and tax treatment. A customer relationship management (CRM) system may provide the account and opportunity context, while the CPQ system applies the pricing logic.

    Customer-specific pricing should be governed carefully. A broad discount stored against an account can unintentionally override a product-specific floor price or create a margin problem. Effective dates and versioning are important when contracts, supplier costs or exchange rates change.

    Common pricing methods in manufacturing CPQ

    Method How it works Typical use Main limitation
    Price list Retrieves a fixed price for a product, option or assembly. Standard products and repeatable options. Limited flexibility for engineered variation.
    Option-based pricing Adds or replaces prices based on selected features. Configured equipment with known option premiums. Can become difficult to maintain with many interactions.
    Formula pricing Uses dimensions, capacity, quantity or technical values in a formula. Cut-to-size products, tanks, conveyors and fabricated assemblies. Requires controlled formulas, units and validation.
    Cost-plus pricing Calculates cost and adds a markup or target margin. Custom machinery and ETO work. Depends on accurate and timely cost data.
    Matrix pricing Uses several factors such as product, region, quantity and customer class. Dealer and industrial distribution channels. Large matrices can be hard to govern.
    Project or negotiated pricing Starts with calculated values and permits controlled commercial adjustments. Large capital equipment and strategic projects. Requires approvals, auditability and version control.

    How rules and formulas affect price

    Pricing rules express commercial consequences of configuration decisions. A rule might state that a high-temperature seal adds a defined charge, that a larger frame requires a larger motor, or that a custom paint system adds material and labor costs.

    Rules can be simple or conditional. A simple rule adds a price for a selected option. A conditional rule may evaluate several values:

    if material = stainless steel and pressure_class = high:

    The actual calculation might then select a different component cost, apply a fabrication multiplier and require engineering approval. In production systems, such logic should be represented in a maintainable rule model rather than hidden in ad hoc spreadsheets or code whenever possible.

    Formula pricing is common when dimensions or performance influence cost. A fabricated duct, tank or conveyor may use length, width, gauge, material density and labor factors. A pump package may use motor power, enclosure class, controls and accessories. Unit consistency is essential: millimeters and inches, kilograms and pounds, or kilowatts and horsepower must not be mixed without explicit conversion.

    Costing, margin and selling price

    Manufacturing CPQ should distinguish at least three concepts:

    • Cost: What the manufacturer expects to spend on materials, labor, overhead, purchased items or external services.
    • Price: What the manufacturer charges before or after discounts and commercial adjustments.
    • Margin: The difference between selling price and relevant cost, expressed as an amount or percentage.

    A markup and a margin are not interchangeable. If cost is 1,000 and the business applies a 20 percent markup, the price is 1,200. If the business requires a 20 percent gross margin, the price is 1,250 because the cost represents 80 percent of the selling price. The pricing engine must use the organization’s defined convention consistently.

    A practical pricing calculation may be:

    1. derive configured components;
    2. retrieve or estimate material and purchased-part costs;
    3. add labor, machine, engineering and subcontracting costs;
    4. apply overhead or cost factors where appropriate;
    5. apply target margin or markup;
    6. add logistics, installation or service charges;
    7. apply approved discounts and customer terms;
    8. check minimum price and margin thresholds.

    Some businesses price from a published list and use cost only for margin analysis. Others use cost-plus rules for every engineered quotation. Both approaches can be valid if the ownership, timing and accuracy of the data are understood.

    Relationship between pricing and BOM generation

    A bill of materials (BOM) lists the components and quantities required for a product or assembly. A configurable BOM represents the component structure selected or derived for a particular configuration. Pricing may use this structure, but a quote BOM and a manufacturing BOM are not necessarily identical.

    An engineering BOM (EBOM) describes the product from an engineering perspective. A manufacturing BOM (MBOM) organizes the product for production, including manufacturing assemblies, operations or plant-specific structures. A CPQ system may generate a sales BOM, an EBOM-like structure, an MBOM, or only a commercial summary. The implementation must define which output is required.

    For example, selecting a conveyor length may add frame sections, guards, belts, supports and drive components. The pricing engine may price each component and labor operation, while the ERP later creates the production order. In another architecture, CPQ may send only a configured item and option codes to ERP, where the BOM is resolved using ERP rules.

    Read more about configurable BOMs, EBOMs, MBOMs and quote generation.

    Pricing in configure-to-order and engineer-to-order

    Configure-to-order (CTO) products are assembled from predefined options and standard components. Pricing can often be calculated from maintained price components and a configurable BOM. Examples include standard pumps, switchgear packages and material-handling modules.

    Engineer-to-order (ETO) products require new or substantially modified engineering for a specific order. Pricing may need engineering hours, design risk, prototype work, custom tooling, non-standard materials and project contingencies. A CPQ system may calculate an initial estimate and then send the opportunity for engineering review rather than presenting the result as a fixed production price.

    Make-to-order (MTO) means production begins in response to an order, while assemble-to-order (ATO) uses stocked components assembled after the order. CTO, MTO and ATO can overlap operationally, but they describe different aspects of product and fulfillment behavior. The pricing design should reflect the actual workflow instead of assuming that every configurable product is CTO.

    The relationship between commercial configuration and engineering handoff is described in the guide to manufacturing workflows such as CTO and ETO.

    Approvals and pricing governance

    Manufacturing quotes often require approvals when the result falls outside normal policy. Approval conditions may include:

    • margin below a product-family threshold;
    • discount above the salesperson’s authority;
    • price below a minimum floor;
    • non-standard payment or delivery terms;
    • custom engineering or tooling;
    • unusual material, supplier or warranty requirements;
    • an ETO configuration with unresolved cost uncertainty.

    Approval workflows should preserve the configuration, calculation inputs, price version, approver, decision and timestamp. If a salesperson changes a motor, dimension or discount after approval, the system should recalculate and determine whether approval is required again.

    Integration architecture

    Pricing engines rarely operate in isolation. Typical system responsibilities are:

    System Possible responsibility
    CRM Account, opportunity, contact and sales-process context.
    ERP Items, inventory, standard costs, purchasing, orders, financial data and sometimes BOM resolution.
    PLM Product definitions, revisions, engineering change control and lifecycle status.
    PDM Engineering files, CAD documents, metadata and revision control.
    CAD Parametric models, drawings and design outputs where automation is supported.
    PIM Commercial product information, descriptions, attributes and channel content.
    MES Manufacturing execution, production status and shop-floor data.
    CPQ Configuration interaction, pricing logic, quote composition and commercial workflow.

    Integration can be synchronous, such as requesting a current cost during configuration, or asynchronous, such as publishing an approved quote and BOM to ERP. APIs, integration middleware and scheduled data synchronization may all be used. The important question is not whether a system has an integration label, but which system is authoritative for each data element and what happens when systems disagree.

    See CPQ integration with ERP, CRM, PLM, PDM, CAD and other systems for architecture and ownership considerations.

    Pricing and CAD or engineering automation

    Some manufacturing CPQ implementations use engineering calculations or computer-aided design (CAD) automation. A user might enter tank dimensions, airflow, load capacity or vehicle wheelbase. The system can use those values to select components, calculate technical requirements and estimate price.

    CAD automation may generate a product-specific model or drawing after configuration. That output can provide dimensions, material quantities or manufacturing information used by pricing, but the relationship is implementation-specific. A CPQ platform may support CAD integration, call an external engineering service or have no CAD capability at all.

    Pricing should not depend on an unverified drawing result. Where engineering automation is used, the implementation should define calculation tolerances, failure handling, revision control and the point at which an engineer must review the output. More information is available in CAD and engineering automation for CPQ.

    Benefits of a manufacturing pricing engine

    • Faster quotation: Sales and application engineers can calculate repeatable configurations without rebuilding spreadsheets.
    • Better price consistency: Rules reduce variation between salespeople, plants and dealers.
    • Improved margin control: Cost and price can be evaluated before a quote is released.
    • Traceable assumptions: The quote can retain the selected options, price version and approval history.
    • Fewer configuration errors: Invalid options are blocked before they produce a misleading price.
    • Stronger handoff: The same configuration can support the quote, BOM, engineering review and order entry.
    • Better channel support: Dealers can receive controlled prices without maintaining private spreadsheets.

    Limitations and common failure modes

    A pricing engine cannot compensate for poor product data. Common problems include outdated costs, duplicate price rules, unclear ownership, missing option dependencies and formulas that are understandable only to their original author.

    Pricing can also become unreliable when the system treats every product as a fixed catalog item even though dimensions, material grades or engineering effort vary significantly. Conversely, excessive customization can create an unmaintainable model with thousands of exceptions.

    Other risks include:

    • using standard cost as if it were a real-time project estimate;
    • mixing markup and margin definitions;
    • applying discounts before or after surcharges without documenting the sequence;
    • failing to version price lists and rules;
    • allowing manual overrides without reason codes or approval;
    • sending a commercial BOM to ERP when ERP requires a different manufacturing structure;
    • not recalculating after a configuration change;
    • ignoring currency, tax, freight and delivery-date effects;
    • embedding critical pricing logic in spreadsheets outside governance.

    Implementation considerations

    Define calculation ownership

    Document whether CPQ, ERP, PLM, a costing application or an external service owns each value. For example, PLM may own the released option structure, ERP may own standard cost, and CPQ may own customer discount rules.

    Model the product before the price

    Start with valid product configurations and their dependencies. Pricing rules built on an unstable product model will need constant correction. Separate technical validity rules from commercial rules so that engineers can maintain constraints without changing sales policy unnecessarily.

    Establish a pricing hierarchy

    Define the order in which base prices, option adjustments, formulas, surcharges, discounts, taxes and freight are applied. Record whether a rule replaces, adds to or discounts another value.

    Test representative scenarios

    Test standard, maximum, minimum, boundary and invalid configurations. Include different currencies, quantities, customer classes, plants, effective dates, discounts and approval conditions. Compare calculated results with independently reviewed examples.

    Govern changes and releases

    Assign owners for product rules, price lists, cost data, formulas and approval policies. Use version control, effective dates, test environments and release procedures. A price change should be traceable to its source and should not silently alter previously issued quotes unless that behavior is intentional.

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

    How to evaluate a manufacturing CPQ pricing engine

    When comparing CPQ software, ask vendors and implementation teams:

    • Can the engine price option-based, formula-based and cost-plus products?
    • Can it use dimensions, quantities, engineering calculations and derived components?
    • How are price rules versioned, tested and assigned to owners?
    • Can it distinguish standard, estimated and project-specific costs?
    • How are currencies, taxes, freight, installation and payment terms handled?
    • Can it calculate margin and enforce price floors?
    • Can discounts and overrides require approvals?
    • Does it generate a configurable BOM, and what type of BOM?
    • Which system is authoritative for item and cost data?
    • How are ERP, CRM, PLM, PDM, CAD and external costing services integrated?
    • Can a revised configuration trigger a complete recalculation?
    • Are formulas, rules and price components visible to administrators?
    • Can the system support CTO, MTO, ATO and ETO scenarios?
    • How are failed calculations, missing costs and engineering exceptions presented?

    Do not evaluate pricing by feature count alone. A platform with a simple price-list engine may be suitable for standard configurable products, while an ETO manufacturer may require governed formulas, cost rollups, engineering review and integration with ERP or PLM.

    Semantic map

    The following relationships summarize how pricing connects configuration, engineering, BOMs, enterprise systems and quoting in manufacturing CPQ.

    • CPQ configures complex manufactured products.
    • Configuration rules prevent invalid combinations.
    • Valid configurations provide inputs to pricing.
    • Pricing engines calculate commercial values.
    • Cost data supports margin analysis.
    • Configured products generate configurable BOMs.
    • Engineering calculations influence component selection and price.
    • CAD automation can generate product-specific drawings.
    • ERP provides or receives item, cost and order data.
    • PLM governs product definitions and revisions.
    • Approvals control discounts and margin exceptions.
    • Quote documents communicate configured products and prices.

    Frequently asked questions

    1. What is a pricing engine in manufacturing CPQ?

    It is the calculation component that determines the cost or selling price of a valid configured product using options, quantities, formulas, costs, discounts, margins and commercial terms.

    2. Is a CPQ pricing engine the same as a product configuration engine?

    No. The configuration engine validates the technical product combination. The pricing engine calculates its cost and price. They exchange data but have different responsibilities.

    3. Can a pricing engine calculate the price of an engineered machine?

    Yes, if it has the required product rules, cost data, engineering formulas and approval workflow. For complex ETO work, the result may be an estimate that requires engineering review rather than a final production price.

    4. How does a CPQ system price configurable options?

    It can add an option charge, replace a standard component price, use a formula, or retrieve a price based on product, customer, quantity, region or effective date.

    5. What is the difference between cost and price in CPQ?

    Cost represents expected expenditure to manufacture or deliver the product. Price is the amount charged to the customer. The pricing engine may use cost to calculate a target margin or markup.

    6. Can manufacturing CPQ calculate margin?

    Many systems can calculate margin when cost and price are available, but the exact capability and cost detail vary. The implementation must define which costs are included.

    7. Does pricing depend on the BOM?

    It can. A CPQ system may price the components and quantities in a configurable BOM, or it may use a high-level price model while ERP resolves the manufacturing BOM later.

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

    An engineering BOM describes the product from an engineering perspective. A manufacturing BOM organizes it for production. Pricing may use either, a sales BOM, or a separate commercial structure depending on the architecture.

    9. How does ERP interact with a CPQ pricing engine?

    ERP may provide item data, standard costs, currencies or customer terms. CPQ may send the configured product, price, BOM or order information back to ERP. The exact ownership must be defined.

    10. Can a CPQ pricing engine use real-time supplier costs?

    It can if the architecture integrates a current supplier or ERP source. Without such an integration, the engine may rely on maintained standard, average or manually updated costs.

    11. How are discounts controlled in manufacturing CPQ?

    Discount rules can be based on customer, channel, quantity, product family or contract. Approval thresholds can require review when discounts reduce price or margin below policy.

    12. What happens when a salesperson changes a configured option?

    A well-designed system revalidates the configuration and recalculates dependent components, costs, prices, margins and approvals. Previously approved results may need approval again.

    13. Can pricing engines support multiple currencies?

    Many can, but currency conversion, rounding, price-list ownership, tax treatment and exchange-rate timing must be explicitly configured and tested.

    14. How does formula pricing work for manufactured products?

    Formula pricing uses values such as length, area, weight, capacity, power or quantity to calculate a component, labor amount or surcharge. Units and boundary conditions must be controlled.

    15. Does every manufacturing CPQ platform include costing?

    No. Some platforms provide price-list and discount logic but rely on ERP, estimating software or custom services for detailed costing. Buyers should verify documented capabilities.

    16. Can CPQ price ETO products?

    It can support initial estimates, engineering charges and controlled exceptions, but ETO pricing often requires human review because design effort, supplier costs and production requirements may be uncertain.

    17. How does CAD automation affect pricing?

    CAD or engineering automation can calculate dimensions, materials or derived components that influence price. However, not every CPQ platform supports CAD automation, and generated outputs may require engineering validation.

    18. How should pricing rules be maintained?

    Assign owners, use versioning and effective dates, separate technical rules from commercial rules, test representative configurations and document the calculation sequence.

    19. What should manufacturers test before deploying a pricing engine?

    Test standard and boundary configurations, invalid combinations, quantity breaks, discounts, currencies, taxes, freight, revisions, cost changes, approval thresholds and integrations with downstream systems.

    20. What is the main risk of spreadsheet-based manufacturing pricing?

    Spreadsheets can contain hidden formulas, inconsistent versions, manual overrides and outdated costs. They may be useful during analysis, but governed CPQ logic provides stronger repeatability and traceability for recurring configurations.

  • Dynamic Pricing for Configurable Industrial Products

    Dynamic pricing for configurable industrial products is the automated calculation of a product price as configuration, cost, market, customer and commercial conditions change. In a manufacturing Configure, Price, Quote (CPQ) system, the price is not simply selected from a static product catalogue. It is derived from the configured product, its components, engineering requirements, production route, commercial terms and applicable pricing rules.

    For example, a pump manufacturer may need to price a unit based on flow rate, pressure, motor power, metallurgy, seal type, hazardous-area certification, control panel options, delivery location, customer agreement and current material costs. A valid configuration should produce not only a sales price, but also an explainable cost calculation, a manufacturing-relevant bill of materials (BOM), appropriate engineering outputs and a quote that can pass through the required approvals.

    This makes manufacturing dynamic pricing different from generic sales CPQ. Generic CPQ may apply discounts to predefined products. Manufacturing CPQ may calculate a product-specific price from rules, dimensions, materials, purchased components, labor, overhead, logistics and engineering effort.

    For background, see the manufacturing guide to BOMs, pricing and quoting and the broader guide to manufacturing CPQ.

    What is dynamic pricing in manufacturing CPQ?

    Dynamic pricing is a pricing method in which the system recalculates the price of a configured industrial product from current inputs rather than relying on one fixed price for every variation.

    The inputs may include:

    • selected options, features and dimensions;
    • configuration rules and engineering constraints;
    • the resulting configurable BOM, engineering BOM (EBOM) or manufacturing BOM (MBOM);
    • material, component, labor and subcontracting costs;
    • quantity, production location, currency and delivery terms;
    • customer, channel, territory and contractual price lists;
    • target margin, minimum margin and discount limits;
    • freight, duties, installation, commissioning and service requirements;
    • lead time, capacity or expedited production requirements;
    • approval policies for unusual risk or low-margin transactions.

    A dynamic price may therefore be calculated as a cost-plus price, a price-list adjustment, a formula-based price, a target-margin price, a market or customer-specific price, or a combination of these methods. The calculation should be deterministic and auditable: the same configuration and pricing context should produce the same result unless a controlled data change has occurred.

    How configuration drives the price

    Dynamic pricing begins with a product model. The product model represents the configurable structure of a machine, assembly or system and defines the available options, attributes, dependencies and constraints. A rules engine validates choices and may calculate derived values such as motor size, shaft diameter, panel rating, cable length or required cooling capacity.

    Configuration and pricing are related but different functions. Configuration answers, What can be built? Pricing answers, What should this configured product cost and what price should be offered? A configuration can be valid but commercially unpriced, and a price rule should not be used to hide an invalid engineering combination.

    Consider a configurable industrial air-handling unit. The buyer selects airflow, external static pressure, casing material, filter class, fan type, motor efficiency, controls and weather protection. The configuration engine may determine the fan size and motor rating. The pricing engine can then use those results to select component costs, apply labor factors, add the controls package and calculate a selling price.

    Rules that influence price

    Rule type Manufacturing example Pricing effect
    Selection rule A stainless-steel wetted path requires compatible seals. Adds the price of the seal and material upgrade.
    Dependency rule A variable-frequency drive requires a compatible control enclosure. Adds required hardware and assembly labor.
    Calculation rule A larger tank diameter requires more shell material. Calculates material quantity and cost.
    Exclusion rule A selected motor cannot be paired with the chosen voltage. Prevents an invalid configuration rather than changing price.
    Commercial rule Approved distributors receive a channel discount. Applies a customer or channel-specific adjustment.
    Approval rule Margin below the approved threshold requires review. Routes the quote for approval and may restrict discounting.

    Rules should be separated where practical. Engineering rules protect product validity, cost rules calculate economic inputs, pricing rules determine the offer, and approval rules control commercial risk. Combining all of them in scattered formulas makes the model difficult to test and maintain.

    Dynamic pricing and the configurable BOM

    A bill of materials is a structured list of components, quantities and relationships required for a product or assembly. An industrial CPQ system may generate a configurable BOM during configuration, but the exact capability depends on the platform and its integration architecture.

    An EBOM describes the product from an engineering perspective. An MBOM describes how the product is manufactured, including production structures, operations or shop-floor requirements. A configurable BOM is a rules-driven structure that resolves into a product-specific BOM after the customer selects options and values. These structures may be related but are not interchangeable.

    The BOM can provide pricing inputs such as:

    • part numbers and configured quantities;
    • material grades, dimensions and weights;
    • purchased component prices;
    • manufacturing or assembly labor;
    • outside processing and subcontracting;
    • packaging, testing and inspection requirements;
    • replacement or supersession logic;
    • cost roll-up by assembly, product family or operation.

    For a configured conveyor, for example, a change in belt width may alter the belt length, frame material, drive motor, guarding, supports and shipping dimensions. A robust pricing flow should recalculate the affected cost components rather than apply an arbitrary surcharge to the original price.

    In some businesses, CPQ maintains a commercial or sales BOM while the ERP or product lifecycle management (PLM) system owns the authoritative production structure. The integration must define which system owns each field and when the configured result is transferred. A price calculated from an obsolete or incomplete BOM can be commercially attractive but operationally unreliable.

    Pricing architecture for configurable products

    A practical dynamic pricing architecture usually contains several layers.

    1. Product and configuration model

    This layer defines products, options, attributes, dimensions, compatibility, dependencies and configuration states. It may include guided selling for helping a user choose a suitable product, rules-based configuration using explicit if-then logic, or constraint-based configuration that evaluates relationships among multiple variables. These approaches can coexist, but they solve different problems.

    2. Cost model

    The cost model identifies the economic inputs required to produce or deliver the configured product. It may retrieve standard costs from an Enterprise Resource Planning (ERP) system, use supplier prices, calculate material quantities, estimate labor, add overhead or call an engineering calculation service.

    Cost data requires effective dates, currencies, units of measure and ownership. A cost for a motor in euros per unit cannot be safely combined with a copper price in dollars per kilogram without controlled conversion and unit logic.

    3. Pricing engine

    The pricing engine converts cost and commercial context into a list price, net price or price breakdown. Common methods include:

    • Cost-plus pricing: adds a markup or margin to calculated cost.
    • Formula pricing: uses dimensions, quantities, indices or engineering variables in a defined formula.
    • Price-list pricing: starts with published or customer-specific prices and applies configuration adjustments.
    • Target-margin pricing: calculates a selling price intended to achieve a defined margin.
    • Matrix pricing: uses combinations such as product family, size, region and customer segment.
    • Contract pricing: applies negotiated terms, minimum quantities or agreed escalation clauses.

    4. Commercial policy and approvals

    Pricing policy determines who can change a price, discount or margin and under what conditions. Approval thresholds may depend on margin, total contract value, non-standard terms, engineering risk, delivery commitment or deviation from a price list.

    5. Quote document and downstream transaction

    The final calculation should produce a quote with clear line items, options, quantities, terms, validity dates, taxes where applicable, delivery assumptions and exclusions. After acceptance, the configured data may be sent to ERP, PLM, manufacturing execution system (MES), customer relationship management (CRM) or other systems. The handoff should preserve the configuration identity and calculation version.

    Example: dynamic pricing for a configurable pump skid

    Suppose a manufacturer sells pump skids for chemical processing. The customer selects flow, pressure, pump arrangement, motor type, wetted materials, seal package, base frame, instrumentation, enclosure rating and documentation level.

    The configuration rules validate that the selected pump can meet the duty point and that the motor is compatible with the electrical supply. An engineering calculation determines the required motor power and approximate pipe sizes. The configured BOM then includes pumps, motors, valves, pipework, fittings, instruments, frame steel, control hardware and documentation.

    The cost calculation may include:

    • current pump and motor purchase costs;
    • stainless-steel weight derived from frame and pipe dimensions;
    • fabrication and welding hours;
    • electrical assembly labor;
    • testing and inspection;
    • third-party certification;
    • packaging and freight.

    The price calculation can apply a target margin, a customer contract adjustment and a quantity discount. If the resulting margin is below policy because of a volatile material price or an unusually expensive certification requirement, the quote is routed for approval. The quote document can show the selected configuration and commercial price without exposing confidential internal cost data.

    If the customer changes the material from painted carbon steel to 316 stainless steel, the system should re-evaluate compatibility, BOM quantities, cost, labor, lead-time assumptions and margin. Applying only a fixed material surcharge would be simpler but may be inaccurate for a product whose dimensions and fabrication process also change.

    Dynamic pricing across CTO, ETO, MTO and ATO workflows

    Manufacturers use different fulfillment models, and pricing logic must match the workflow.

    Workflow Meaning Pricing implication
    Configure-to-order (CTO) A product is selected from predefined options and assembled or produced after order. Pricing can often use structured option prices, standard costs and a controlled configurable BOM.
    Engineer-to-order (ETO) Engineering work is created or substantially changed for the order. Pricing must estimate engineering hours, design risk, validation, tooling and non-recurring effort.
    Make-to-order (MTO) Production starts after an order rather than from finished-goods stock. Pricing may use order-specific material, labor and capacity assumptions.
    Assemble-to-order (ATO) Standard modules are combined after the order. Pricing often combines module prices with assembly, testing and logistics rules.

    ETO is particularly challenging because the final design may not yet exist. A CPQ system may need estimating rules, engineering rate tables, minimum charges, risk allowances and approval steps. It should distinguish a calculated production price from a preliminary estimate whose uncertainty is higher.

    Integration with ERP, PLM, CAD and CRM

    Dynamic pricing depends on reliable enterprise data, but no single system should automatically be assumed to own every data object.

    System Typical relationship with CPQ pricing
    ERP May provide item masters, standard costs, inventory context, currencies, customers, orders and financial data.
    PLM May own product structures, revisions, approved options, engineering changes and lifecycle status.
    Product data management (PDM) May manage CAD files, engineering documents and design metadata.
    Computer-aided design (CAD) May provide geometry, dimensions, mass properties, drawings or design-specific outputs when integrated.
    CRM May provide account, opportunity, sales channel and customer context.
    Product Information Management (PIM) May provide commercial descriptions, media and catalogue attributes.
    MES May provide manufacturing execution information, actual production feedback or shop-floor status.

    Integration design should address data ownership, synchronization frequency, effective dates, error handling, revision control, units of measure and traceability. More integrations do not automatically produce better pricing. An unstable cost feed or ambiguous part revision can reduce confidence in every quote.

    See the guide to CPQ integrations for a broader discussion of ERP, CRM, PLM, PDM, CAD, PIM and MES relationships.

    Benefits of dynamic pricing

    • More accurate configuration-specific prices: the price reflects selected materials, components and requirements.
    • Faster quoting: sales and application engineers can calculate standard configurations without rebuilding spreadsheets.
    • Better margin control: the system can expose margin, cost drivers and approval exceptions before submission.
    • Consistent commercial policy: regional, customer and channel rules are applied consistently.
    • Improved engineering handoff: the quote retains the configuration and assumptions used to calculate price.
    • Traceable changes: users can identify which rule, cost, revision or price list produced a result.
    • Better product data: repeated configuration and pricing activity can reveal common options, unprofitable variants and obsolete rules.

    Limitations and risks

    Dynamic pricing is not a substitute for accurate product and cost data. Typical risks include:

    • Incomplete cost data: missing labor, freight, tooling or engineering effort creates false margins.
    • Overly complex formulas: undocumented exceptions become difficult to test and explain.
    • Stale prices: supplier, material or currency changes may not reach CPQ at the required frequency.
    • Conflicting ownership: different systems may contain different versions of a component, BOM or revision.
    • ETO uncertainty: early estimates may appear more precise than the available engineering information supports.
    • Margin distortion: allocating overhead or shared costs inconsistently can make product comparisons misleading.
    • Commercial resistance: sales teams may bypass the system if pricing rules do not reflect legitimate market or customer exceptions.
    • Performance problems: large product models and repeated engineering calculations may slow configuration.
    • Governance burden: every new option, supplier change or pricing policy may require controlled model maintenance.

    Pricing transparency also requires care. A customer-facing configurator may show option prices and totals, while internal cost, margin and approval information should remain role-restricted.

    Implementation approach

    1. Define the pricing scope

    Start with a product family and a measurable use case, such as standard pump packages, modular conveyors or electrical enclosures. Define whether the first release will calculate list price, net price, cost, margin, engineering estimates or all of these.

    2. Map the current calculation

    Document spreadsheets, ERP lookups, engineering formulas, manual surcharges, discount practices and approval decisions. The objective is to expose actual pricing logic, including exceptions that are not written in formal procedures.

    3. Establish data ownership

    Assign owners for product options, configuration rules, item numbers, BOMs, costs, price lists, discount policies, currencies and quote templates. Record effective dates and revision rules.

    4. Separate engineering and commercial rules

    Test whether each rule validates a configuration, calculates a cost, sets a price or controls approval. Separate responsibilities make troubleshooting and change management easier.

    5. Build representative test cases

    Test standard, maximum, minimum, boundary and invalid configurations. Include different currencies, quantities, customer types, plants, delivery terms, revisions and material prices. Reconcile results against approved manual calculations.

    6. Connect downstream systems carefully

    Begin with the minimum reliable integration. Confirm whether CPQ sends a sales configuration, EBOM, MBOM, order line, engineering request or merely a quote reference. Validate error handling when an item, cost or revision is missing.

    7. Govern releases and monitor results

    Use version control, approval workflows, regression testing and a change log for pricing rules. Monitor quote cycle time, pricing exceptions, approval frequency, margin variance, manual overrides, order rework and configuration errors.

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

    What to evaluate in a CPQ configurator

    When evaluating a CPQ configurator for dynamic industrial pricing, ask vendors to demonstrate a real product model rather than a generic discount scenario. The demonstration should include dimensions, incompatible options, calculated components, a configurable BOM, cost roll-up, customer pricing, approval thresholds and quote revision history.

    • Can the platform represent the product’s actual dependencies and constraints?
    • Can users distinguish invalid configurations from valid but non-standard ones?
    • Can the system calculate quantities and derived attributes?
    • Can costs be versioned by date, plant, currency and supplier?
    • Can pricing rules be maintained by authorized business users?
    • Can the system show price and margin explanations?
    • Can it create or consume a configurable BOM?
    • Can it estimate engineering effort for ETO work?
    • Can it preserve configuration identity through ERP, PLM, CAD or CRM integration?
    • Can approvals be triggered by margin, discount, value, risk or non-standard requirements?
    • Can the organization test model changes before publishing them?

    Do not assume that a product marketed as a CPQ configurator includes BOM generation, CAD automation, engineering calculations, 3D visualization or PLM integration. Verify each capability, its data requirements and its production limitations.

    Related concepts

    Dynamic pricing is closely connected to product configuration and configuration rules, CAD and engineering automation, and configure-to-order and engineer-to-order workflows. These subjects should be designed together because a commercial price that cannot be traced to a valid product definition will not reliably support order entry or production.

    Semantic map

    The article’s main relationships are:

    • Product configuration determines the selected industrial product.
    • Configuration rules prevent incompatible options and calculate derived attributes.
    • A configured product resolves into a configurable BOM or downstream product structure.
    • BOM quantities and component data provide inputs to cost calculation.
    • Cost models support margin and price calculation.
    • Pricing policies determine list price, net price, discounts and approvals.
    • Approvals control exceptions and commercial risk.
    • Quote documents communicate the configuration, price and assumptions.
    • ERP, PLM, CAD, CRM and MES exchange different types of product and commercial data.
    • CTO, ETO, MTO and ATO workflows require different levels of pricing certainty and engineering effort.

    Frequently asked questions

    What is dynamic pricing for configurable industrial products?

    It is the automated calculation of a price from a specific product configuration, cost data, commercial rules and customer or order context instead of one fixed price for every variant.

    How is dynamic pricing different from discounting?

    Dynamic pricing determines a configuration-specific price from product and commercial inputs. Discounting is an adjustment applied to a price, often based on customer, quantity, channel or negotiation.

    Does dynamic pricing require a CPQ system?

    Not always. It can be implemented with custom software or integrated ERP tools, but CPQ is designed to connect product configuration, pricing, quoting and often BOM or engineering processes.

    Can a CPQ system calculate manufacturing cost?

    Some systems can calculate or roll up cost, while others retrieve cost from ERP or another service. The capability, cost detail and integration method must be verified for each platform.

    Can dynamic pricing use a bill of materials?

    Yes. A configured BOM can provide component quantities, materials and assemblies for cost and price calculation, although not every CPQ platform generates or owns a production BOM.

    What is the difference between a configurable BOM and an EBOM?

    A configurable BOM resolves from selectable rules and options. An EBOM represents an engineering product structure. A CPQ system may use one, both or an integration with PLM depending on the workflow.

    Should CPQ own the MBOM?

    Usually this depends on enterprise architecture. CPQ may generate commercial configuration data, while ERP, PLM or manufacturing systems own the authoritative MBOM. Ownership and synchronization must be explicitly defined.

    How does material cost affect dynamic pricing?

    Material cost can be retrieved by item, grade, quantity, weight, length or other calculated attributes. Effective dates, units, currency and supplier or plant context are needed for reliable results.

    Can dynamic pricing support engineer-to-order products?

    Yes, if the model can estimate engineering, tooling, testing, risk and non-recurring effort. ETO prices should communicate assumptions and uncertainty rather than imply that an unfinished design is fully known.

    How does configuration affect margin?

    Options can change material, purchased components, labor, engineering effort, freight and risk. A margin calculation should therefore use the resolved configuration and relevant cost assumptions.

    What is target-margin pricing?

    Target-margin pricing calculates a selling price intended to achieve a defined margin based on the estimated cost of the configured product.

    Can dynamic pricing support customer-specific contracts?

    Yes, if the pricing model supports customer or contract price lists, validity dates, currencies, quantities, exclusions and approval rules.

    How are pricing exceptions approved?

    Approval rules can route quotes based on margin, discount, total value, non-standard configuration, delivery commitment, engineering risk or contract terms.

    How often should industrial pricing data be updated?

    The frequency depends on the volatility and business impact of the data. Supplier components, metals, currencies and freight may require more frequent updates than stable labor standards or published option prices.

    Can a customer see the cost calculation?

    Usually the customer sees the configured items, prices and commercial assumptions rather than internal cost or margin. Role-based access should separate customer-facing and internal calculations.

    Does dynamic pricing require CAD automation?

    No. CAD automation is optional and separate from pricing, although CAD-derived dimensions, mass or design outputs can provide useful cost and engineering inputs for some products.

    What should be tested before launching dynamic pricing?

    Test valid and invalid configurations, boundary values, revisions, costs, currencies, quantities, customer terms, discounts, approvals, BOM results, integrations and quote documents.

    What is the main implementation risk?

    The main risk is automating incomplete or contradictory product and cost data. A sophisticated pricing engine cannot compensate for unclear product ownership, unreliable costs or undocumented exceptions.

  • CPQ Quote Templates for Technical Products

    CPQ quote templates for technical products are controlled document layouts that assemble configuration, pricing, costing, product details, delivery information, terms and technical outputs into a customer quotation. In manufacturing, the template is not simply a branded PDF. It is the presentation layer of a larger process connecting product configuration, rules, engineering calculations, bill of materials (BOM) data, approvals and enterprise systems.

    A manufacturing Configure, Price, Quote (CPQ) system may use a quote template to convert a valid configuration of an industrial pump, machine, electrical panel, vehicle or engineered assembly into a consistent commercial document. Depending on the platform and implementation, the same transaction may also generate a configurable BOM, an engineering review request, a computer-aided design (CAD) output, an internal costing view or an order-ready data package.

    The important distinction is that a quote template does not configure the product or calculate the price by itself. The product model, rules engine, pricing logic and integrations produce the data. The template formats approved data for a customer, dealer, sales engineer, production planner or internal approver.

    What is a CPQ quote template?

    A CPQ quote template is a reusable document definition that controls how a configured product quotation is structured, populated, calculated and delivered. It typically contains fixed content, dynamic fields, conditional sections, line-item tables, totals, technical specifications, commercial terms and approval information.

    For a technical manufacturer, a template can draw from several sources:

    • Customer and opportunity data from a customer relationship management (CRM) system.
    • Selected options, dimensions, materials and accessories from the product configuration.
    • Validated prices, discounts, surcharges, taxes and currencies from the CPQ pricing model.
    • Cost and margin data for internal review.
    • Configured BOM or item references for technical schedules.
    • Lead times, shipping information and plant data from enterprise resource planning (ERP) or other systems.
    • Engineering notes, performance calculations, drawings or models where the implementation supports engineering automation.
    • Approval history, revision number, expiration date and commercial terms.

    The result may be a web-based quote, PDF, word-processing document, email attachment, customer portal view or structured document generated through an application programming interface (API). The format should reflect the audience. A customer may need a concise commercial proposal, while an internal engineering team may need a detailed configuration summary and a manufacturing BOM.

    Why technical product quotes need more than a standard sales template

    Generic sales CPQ often focuses on selecting products, applying discounts and producing a proposal. That can be adequate for relatively standardized goods. Technical manufacturing quotes normally require additional evidence that the selected product can be built, supplied and supported at the stated price and performance.

    For example, a pump quotation may need to show flow rate, head, motor power, voltage, materials of construction, seal type, connection size, certification requirements and expected delivery. Those values should come from a validated configuration rather than being manually retyped into a document.

    An industrial machine quote may need to distinguish standard equipment from options, identify customer-specific interfaces, state assumptions about utilities and site conditions, show installation exclusions and reference a preliminary layout. An electrical enclosure quote may need to include enclosure dimensions, ingress protection, component ratings and a list of selected devices.

    These requirements create a chain of dependencies:

    1. The customer or sales engineer selects requirements and product options.
    2. The configuration model evaluates dependencies, constraints and calculations.
    3. The system validates that the result is technically permissible.
    4. Pricing and costing logic determine the commercial values.
    5. A BOM, technical summary or engineering output may be produced.
    6. Approval rules evaluate margin, risk, discounting or non-standard content.
    7. The quote template presents the approved information in a controlled format.

    This is why a quote document should be treated as an output of the manufacturing CPQ architecture, not as an isolated design exercise.

    Core sections of a manufacturing CPQ quote template

    1. Customer, project and quote identification

    The first section normally identifies the customer, site, project, contact, salesperson, quote number, revision, issue date and validity period. For industrial sales, it may also include the customer purchase reference, application, installed location and required delivery date.

    Revision control is especially important when technical requirements change. A revised quote should make it possible to determine which configuration, prices, terms and engineering assumptions were used at each point in the negotiation.

    2. Executive commercial summary

    The summary should state what is being offered without requiring the reader to interpret an internal product code. It may include the equipment name, quantity, main performance values, total price, currency, delivery estimate and major exclusions.

    A good summary is concise but traceable. A line such as “custom process pump package” is less useful than “three-stage stainless-steel centrifugal pump package, 45 m³/h at 60 m head, 30 kW motor, 400 V, including baseplate and coupling guard.” The exact values should be generated from the configuration data.

    3. Configured product and option details

    This section shows the selected features, options, dimensions and materials. It can be presented as a specification table, grouped by assembly or divided into standard equipment, selected options and customer-specific requirements.

    Not every internal rule needs to appear in the customer document. The template should distinguish customer-relevant specifications from internal implementation details. For example, a customer may need to see that a pump uses a cartridge mechanical seal, but not the internal rule identifier that made the seal compatible with a particular shaft arrangement.

    4. Pricing, costing and commercial adjustments

    The pricing section can include quantity, list price, option prices, engineering charges, tooling, freight, discounts, taxes and total price. Internal versions may also show estimated cost, contribution margin and approval thresholds, while external versions normally exclude confidential cost data.

    Manufacturers should define whether prices are calculated from a price list, cost-plus logic, configuration-specific formulas, contract pricing or a combination. The quote template should display the result of that logic, not recreate it with independent spreadsheet formulas.

    5. Delivery, scope and terms

    Technical quotes commonly require delivery assumptions, manufacturing lead time, shipping basis, installation responsibilities, commissioning scope, warranty, payment terms and quote expiration. These values may depend on plant, product family, territory, customer status or selected options.

    Conditional text is useful here. A quote for a standard configure-to-order machine may use one delivery statement, while an engineer-to-order project may require language stating that final delivery depends on engineering approval and drawing sign-off.

    6. Technical documents and engineering outputs

    Where supported, the quote can include or reference a preliminary drawing, rendered image, performance curve, datasheet, calculation summary or product-specific CAD output. A link to an attachment is often safer than embedding every technical file directly in the proposal.

    CAD automation and engineering automation are separate capabilities from document generation. A CPQ platform may generate a quote but not create drawings or models. Buyers should verify whether these outputs come from the CPQ system, a CAD integration, a product lifecycle management (PLM) or product data management (PDM) system, or a separate engineering application. See the guide to CAD and engineering automation in CPQ for the relationship between these capabilities.

    7. Assumptions, exclusions and customer responsibilities

    Technical projects often fail commercially when assumptions are hidden. Templates should provide a controlled place for items such as available electrical supply, foundation requirements, ambient conditions, site access, customer-supplied utilities, certifications and installation boundaries.

    Some assumptions may be generated from configuration answers. Others may be entered by an engineer or selected from approved clauses. Free-text fields should be governed because uncontrolled wording can create contractual or technical risk.

    How CPQ data flows into a quote template

    A typical data flow begins with a product model. The model defines products, features, options, attributes, dependencies and constraints. A rules engine evaluates whether combinations are valid. Some systems use straightforward rules such as “if 480 V is selected, exclude the 230 V motor.” More advanced models may calculate shaft size, heat load, capacity, frame dimensions or required components.

    After validation, the pricing engine applies prices and commercial logic. It may use formulas for dimensions, quantities, material grades, regional price lists, currency conversion, volume breaks, discounts or engineering charges. Costing may use estimated labor, material, outside processing and overhead values, although costing depth varies significantly between platforms.

    The system can then produce one or more representations of the configured product:

    Representation Purpose Typical quote use
    Configuration summary Explains selected features and parameters Customer specification and sales review
    Configurable BOM Represents components selected by product rules Technical schedule, costing or order preparation
    Engineering BOM (EBOM) Describes the product from an engineering design perspective Engineering review or design reference
    Manufacturing BOM (MBOM) Describes components and assemblies used to manufacture the product Production planning or ERP handoff
    CAD output Represents geometry or drawings for a specific configuration Preliminary approval, installation or technical attachment
    Commercial values Shows prices, costs, discounts and totals Customer quotation and internal approval

    These representations are related but not interchangeable. A quote template may show a simplified component list without being the authoritative EBOM or MBOM. The system architecture should identify which application owns each record.

    Quote templates and BOM generation

    A bill of materials is a structured list of components, quantities and relationships needed to define a product or assembly. In CPQ, a configurable BOM can be generated from the selected options and rules. For example, choosing a stainless-steel pump casing, a specific motor, a baseplate and a seal arrangement may add different items to the resulting structure.

    The quote document can use BOM data in several ways:

    • Show a customer-facing equipment schedule with major assemblies and selected components.
    • Include an internal detailed component list for engineering review.
    • Display component descriptions and quantities used to explain price differences.
    • Pass item identifiers and quantities to an ERP system for order creation.
    • Provide a reference for purchasing or production after quote acceptance.

    However, a quote BOM should not automatically be treated as a production-ready MBOM. Manufacturing may require routing information, work centers, phantom assemblies, substitute rules, revision control and plant-specific data that are not maintained in CPQ. The BOM, pricing and quoting guide explains these distinctions in more detail.

    Pricing and costing fields in technical quote templates

    Pricing is the amount offered to the customer. Costing estimates the resources consumed to produce or deliver the product. A manufacturing CPQ implementation may use both, but they serve different purposes.

    Common pricing fields include:

    • Base product price.
    • Option and accessory prices.
    • Quantity and volume adjustments.
    • Customer, dealer or project discounts.
    • Engineering, tooling and setup charges.
    • Freight, packaging and installation charges.
    • Taxes, duties and surcharges.
    • Currency, payment terms and price validity.

    Common internal costing fields include material cost, purchased component cost, labor estimate, subcontracting, engineering effort and manufacturing overhead. These values may come from ERP, an enterprise costing system or CPQ calculations. The source and refresh frequency should be documented because stale cost data can produce misleading margin results.

    Quote templates should also define rounding rules. Unit prices, extended line amounts, tax calculations and total values must use consistent currency precision. The template should not introduce a second calculation method that can disagree with the pricing engine.

    Approval workflows and controlled document generation

    Technical quotes often need approvals for low margin, unusual payment terms, large discounts, non-standard materials, export restrictions, safety requirements or engineering risk. A CPQ workflow can route the quote to sales management, finance, engineering or operations before allowing external release.

    Approval status should be visible internally and should be tied to a specific quote revision. If a salesperson changes the motor, material or delivery commitment after approval, the system should determine whether the quote must be reapproved.

    Document generation should normally happen from approved data. Useful controls include:

    1. Locking or versioning the configuration used for the quote.
    2. Recording the price list and exchange rate used.
    3. Identifying the template version.
    4. Preventing external release when mandatory fields are missing.
    5. Storing the generated document with the opportunity or quote record.
    6. Maintaining a clear relationship between quote revision and downstream order.

    Template types for different manufacturing workflows

    Workflow Template emphasis Typical limitations
    Configure-to-order (CTO) Validated options, standard specifications, price and delivery May not describe project-specific engineering assumptions
    Make-to-order (MTO) Selected product parameters, manufacturing scope and delivery May require additional production planning data
    Assemble-to-order (ATO) Configured modules, available components and delivery promise Availability and allocation may belong to ERP
    Engineer-to-order (ETO) Scope, assumptions, engineering services, milestones and exclusions Final design and price may remain provisional
    Dealer or distributor sales Customer-facing price, channel discount, branding and simplified specifications Dealer document may hide internal cost and engineering data

    CTO means configure-to-order: the product is assembled or manufactured from predefined options. ETO means engineer-to-order: significant design work is required for the customer. MTO means make-to-order, while ATO means assemble-to-order. A single company may need different templates for each workflow.

    For a deeper view of these process differences, see the guide to manufacturing CPQ workflows.

    Integration requirements

    Quote templates are only as reliable as the data supplied to them. Integration architecture should identify the system of record for every important field.

    System Potential contribution to the quote process
    CRM Account, contact, opportunity, salesperson and sales activity
    ERP Items, price lists, inventory or availability, customers, currencies and order creation
    PLM Product definitions, approved revisions, engineering metadata and lifecycle status
    PDM CAD files, drawings, documents and revision-controlled product data
    CAD Parametric geometry, drawings, models and configuration-specific technical outputs
    Product information management (PIM) Descriptions, images, specifications and channel content
    Manufacturing execution system (MES) Production status or manufacturing execution information where integrated

    CRM, ERP, PLM, PDM, PIM and MES are not interchangeable. A CPQ system may connect to several of them, but the integration depth varies. Some implementations exchange only customer and item data. Others synchronize product models, revisions, BOMs, pricing, drawings and order status. The CPQ integration guide provides a framework for evaluating these data flows.

    Designing customer-facing and internal templates

    One template rarely serves every audience well. A practical architecture commonly separates documents into at least three views:

    • Customer quote: commercial price, product summary, major specifications, delivery, terms, assumptions and attachments.
    • Internal approval view: cost, margin, discount rationale, risk flags, engineering effort and exception details.
    • Order or handoff package: validated configuration, item identifiers, BOM references, drawings, notes and required downstream fields.

    Conditional sections allow a common template family to support different products. For example, a valve quote may show pressure class and seat material, while a machine quote shows throughput, cycle time and footprint. The underlying layout can remain governed while product-specific sections appear only when relevant.

    Templates should also support localization, units of measure, currency, legal entity, language, tax treatment and regional terms. These concerns should be driven by controlled data rather than manual editing wherever possible.

    Implementation process

    1. Define the quote audiences and decisions

    Start by documenting who reads the quote and what decision each person must make. A customer needs confidence in scope and price. An engineer needs sufficient configuration detail. Finance needs margin and payment information. Operations may need a clear handoff into order processing.

    2. Inventory the source data

    List every field required in the quote and identify its owner. Mark whether it is entered by a user, selected by a rule, calculated, retrieved from another system or generated as an attachment. This exposes duplicated data and fields that cannot currently be trusted.

    3. Separate configuration, pricing and presentation logic

    Configuration rules should determine what is valid. Pricing logic should determine what the valid configuration costs. The template should present those results. Combining all three in document formulas makes testing, maintenance and auditability more difficult.

    4. Define product and document variants

    Group products by shared structure and identify where technical content differs. Avoid creating a separate template for every minor variation if conditional sections and reusable components can handle the difference. At the same time, do not force unrelated product families into one document that is difficult to read or maintain.

    5. Build test scenarios

    Test standard configurations, boundary values, incompatible options, engineering exceptions, discounts, currencies, tax conditions, revisions and failed integrations. Include cases where a CAD file, BOM, price or lead time is unavailable. The quote should fail safely rather than produce an apparently complete but inaccurate document.

    6. Govern changes

    Assign ownership for product rules, prices, legal clauses, technical text, document layouts and integrations. A template change can alter the commercial meaning of a quote even when the product model is unchanged. Version control and release approval are therefore important parts of CPQ governance. The CPQ implementation and governance guide covers data ownership, testing and ongoing maintenance.

    Common limitations and risks

    • Incomplete product models: A polished document cannot compensate for missing rules, options or engineering constraints.
    • Stale pricing: If material or supplier costs are not synchronized, margin calculations may be unreliable.
    • Unclear system ownership: Conflicting customer, item or revision data can create inconsistent quotes.
    • Overloaded templates: Including every internal attribute can make customer documents difficult to understand.
    • Uncontrolled free text: Manual technical promises may bypass approved rules and approval workflows.
    • False BOM confidence: A quote component list may not be sufficient for manufacturing release.
    • Unverified engineering automation: A CPQ platform may generate a quote without generating a valid CAD model or drawing.
    • Complex exception handling: ETO work may require engineering review before specifications, price or delivery can be finalized.
    • Integration failure: Missing ERP or PLM data can block generation or create documents with incomplete information.

    How to evaluate CPQ quote template capabilities

    When evaluating software, ask vendors to demonstrate a complete manufacturing scenario rather than a generic proposal editor. The demonstration should begin with a configured product and end with a customer document, approval record and downstream data package.

    • Can the template display configuration attributes selected during the session?
    • Can it distinguish customer-visible values from internal values?
    • Can it show option prices, surcharges, discounts, taxes and totals without duplicate calculations?
    • Can it include a configurable BOM, and what level of BOM detail is supported?
    • Can it conditionally include product-family-specific specifications?
    • Can it handle revisions, multiple quote versions and approval status?
    • Can it generate different customer, dealer, internal and order-handoff documents?
    • Can it attach or link configuration-specific drawings, models and datasheets?
    • How are currency, units, language, regional terms and legal entities handled?
    • What happens when an ERP, PLM, CAD or pricing service is unavailable?
    • Can template changes be tested without changing product rules?
    • Are APIs available for document generation and storage?

    Manufacturing CPQ software should be assessed on product modeling, rules, BOM behavior, engineering support, integrations, governance and maintainability, not only on the visual quality of its proposal editor. The manufacturing CPQ software guide and CPQ comparison resources can help structure this evaluation.

    Key performance measures

    Useful measures should assess document accuracy and the surrounding process, not just the number of quotes produced. Possible measures include quote turnaround time, percentage of quotes requiring rework, configuration-related order errors, approval cycle time, margin variance between quote and order, percentage of quotes generated without manual document editing, and time required to update a template or product rule.

    For technical products, also consider whether the quote-to-order handoff preserves configuration integrity, whether engineering receives complete information and whether customers receive consistent specifications across revisions.

    Conclusion

    CPQ quote templates for technical products are the document layer that makes complex configuration and commercial decisions understandable to customers and usable by internal teams. Their reliability depends on the quality of the product model, configuration rules, pricing and costing logic, BOM structures, approval controls and enterprise integrations behind them.

    The strongest implementations separate configuration, calculation, data ownership and presentation. They provide different views for customers, approvers and manufacturing handoff, while preserving a traceable relationship between the quote revision, configured product, pricing inputs and downstream order data. A template can improve clarity and speed, but it cannot replace accurate product engineering, disciplined data governance or validated manufacturing workflows.

    Frequently asked questions

    What is a CPQ quote template?

    It is a reusable document layout that presents configured product data, pricing, terms, technical details and approvals in a controlled quotation.

    How is a manufacturing CPQ quote template different from a generic sales template?

    It can include engineering specifications, configuration attributes, BOM references, calculations, delivery assumptions and technical exclusions in addition to price and commercial terms.

    Does a quote template configure the product?

    No. The product model and configuration rules determine whether a product is valid. The template presents the resulting data.

    Can a CPQ quote template generate a BOM?

    The template itself does not generate a BOM. Some CPQ systems can generate a configurable BOM, which the template may display or reference.

    Should a customer quote include the complete BOM?

    Usually not. Customers often need a major equipment schedule or selected component summary, while detailed BOM data may remain internal or move to ERP and manufacturing systems.

    What is the difference between a configurable BOM and an MBOM?

    A configurable BOM represents components selected by product rules. A manufacturing BOM, or MBOM, represents the structure and manufacturing information needed to produce the item and may require additional plant and routing data.

    Can quote templates show engineering calculations?

    They can display calculation results when the CPQ or connected engineering system produces them. Document generation alone does not provide engineering calculation capability.

    Can a CPQ system include CAD drawings in a quote?

    Some implementations attach or link configuration-specific CAD drawings, but this requires CAD or engineering integration and is not available in every CPQ platform.

    How should pricing be connected to a quote template?

    The pricing engine should calculate prices, discounts, surcharges and totals. The template should display those results rather than recreate pricing formulas independently.

    Should internal cost and margin appear in the customer document?

    No. Cost and margin are normally restricted to internal approval views unless a specific commercial process requires otherwise.

    How do quote templates support ETO products?

    They can show engineering scope, assumptions, milestones, exclusions and provisional delivery or price. Final values may depend on engineering review and design approval.

    Can one template support multiple product families?

    Yes, if conditional sections and reusable components are well designed. Unrelated product families may be better served by separate governed templates.

    What systems commonly provide data to a CPQ quote?

    CRM may provide customer and opportunity data, ERP may provide items and prices, PLM or PDM may provide product and document data, and CAD systems may provide drawings or models.

    How should quote revisions be managed?

    Each revision should preserve the configuration, pricing inputs, template version, approval status and generated document associated with that revision.

    What happens if ERP or engineering data is unavailable?

    The system should either prevent release, clearly mark the quote as provisional or route it for review. It should not silently generate a complete-looking document with missing data.

    Can dealer quotes use different templates?

    Yes. Dealer templates may apply channel pricing, dealer branding and simplified technical information while keeping internal costs and approval details hidden.

    What should manufacturers test before deploying quote templates?

    Test valid and invalid configurations, prices, discounts, currencies, taxes, revisions, approvals, missing integrations, attachments, units of measure and downstream order handoff.

    Semantic map

    The following relationships summarize how CPQ quote templates connect configuration, engineering, commercial data and manufacturing systems.

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration validates technical dependencies.
    • Guided selling collects customer requirements.
    • Configured products generate configurable BOMs.
    • Configurable BOMs support costing and order preparation.
    • Pricing engines calculate quote prices.
    • Costing provides internal margin inputs.
    • Quote templates present approved configuration data.
    • Approval workflows control commercial exceptions.
    • CAD automation generates product-specific drawings.
    • Engineering calculations validate product performance.
    • EBOMs describe engineering product structures.
    • MBOMs describe manufacturing product structures.
    • CPQ exchanges customer and order data with CRM and ERP.
    • PLM manages approved product and engineering revisions.
    • PDM manages CAD files and technical documents.
    • ETO quotes include engineering scope and assumptions.
    • CTO quotes use predefined product options.
    • Quote revisions preserve configuration and pricing history.

  • Automated Proposal Generation for Configured Products

    Automated proposal generation for configured products is the process of turning a validated product configuration into a customer-ready commercial proposal with accurate descriptions, prices, delivery assumptions, options, exclusions and supporting technical information. In manufacturing, this process is usually performed by a Configure, Price, Quote (CPQ) system connected to product rules, costing data, bills of material (BOMs), customer records and, where required, engineering or enterprise systems.

    A manufacturing CPQ configurator does more than place line items on a sales document. It can check whether a pump, machine, vehicle or electrical assembly is technically valid; calculate dimensions, capacity or performance; select compatible components; create a configurable BOM; apply costing and pricing logic; route exceptions for approval; and generate a proposal that reflects the actual product being sold. The exact scope varies by platform. Some CPQ products focus mainly on configuration and quoting, while others also support BOM generation, CAD automation, engineering calculations or engineer-to-order workflows.

    This article explains how the process works, what information it requires, how it connects to manufacturing systems and what buyers should verify before selecting a solution. For broader context, see the guide to manufacturing CPQ.

    What automated proposal generation means in manufacturing

    Automated proposal generation is the controlled creation of a proposal from structured product, customer and commercial data rather than from manually edited documents or spreadsheets. The proposal is generated after the system has processed the customer requirements and confirmed that the selected product combination is allowed.

    For a manufacturer, a proposal may include:

    • the configured product name, model and technical description;
    • selected options, accessories, materials, finishes and performance values;
    • quantity, unit price, discounts, surcharges, freight assumptions, taxes or payment terms;
    • estimated lead time or delivery conditions;
    • commercial terms, warranty information, validity period and exclusions;
    • configuration-specific images, diagrams, data sheets or drawings;
    • a summary of the resulting BOM or scope of supply;
    • approval notes for unusual margins, non-standard components or engineering work.

    In generic sales CPQ, proposal automation may primarily assemble products, prices and terms. Manufacturing CPQ adds another layer: the proposal may be based on engineering constraints, calculated values and production-relevant data. A quote for a standard office subscription is not equivalent to a quote for a centrifugal pump selected for a specified flow, pressure, temperature, material and motor arrangement.

    How the proposal-generation workflow works

    1. Capture customer requirements

    The workflow begins with information about the application and customer. Inputs may include required capacity, operating environment, dimensions, voltage, material, regulatory requirements, quantity, installation conditions and target delivery date. A guided selling interface may ask business-oriented questions, while a technical configurator may expose engineering parameters directly.

    Guided selling and product configuration are related but different. Guided selling helps a user identify a suitable product or configuration through questions and recommendations. Product configuration applies options, dependencies, constraints and calculations to create a valid product definition. A system may support one capability without fully supporting the other.

    2. Select and validate the configuration

    The configurator applies rules to the selected options. Rules may prevent incompatible combinations, require dependent components, set valid ranges or calculate derived values. For example, selecting a stainless-steel pump body may restrict available impellers, seals or temperature ranges. Choosing a high-voltage motor may require a compatible starter, enclosure and cable specification.

    Manufacturing CPQ implementations commonly combine several types of logic:

    Logic type Purpose Manufacturing example
    Rules-based configuration Allows, prevents or requires options A roof-mounted accessory requires a reinforced frame
    Constraint-based configuration Checks relationships, limits and technical conditions Motor power must match pump duty and available voltage
    Parameter calculations Derives values from customer inputs Calculate tank volume, belt length or heat exchanger area
    Guided selling Helps users reach a suitable choice Recommend a valve series based on pressure and fluid type

    More detail on product models, features, dependencies and constraints is available in the product configuration guide.

    3. Generate engineering and product data

    Once the configuration is valid, the CPQ system may generate or retrieve technical outputs. These can include a product description, calculated performance values, an option summary, a configurable BOM, a customer-facing image or a request for engineering review.

    The scope depends on the product and platform. A configure-to-order machine may use predefined modules and generate a production-ready structure. An engineer-to-order product may require a design task before the final BOM, drawing or delivery date can be confirmed. Some implementations connect CPQ with computer-aided design (CAD) systems to create product-specific models or drawings; others attach existing documents or provide only a textual summary.

    CAD automation should therefore be evaluated separately from proposal generation. A system that creates a PDF quote is not necessarily capable of generating parametric CAD geometry, manufacturing drawings or design calculations. The CAD and engineering automation guide explains these distinctions.

    4. Calculate cost and price

    The pricing stage converts the validated configuration into commercial values. Costing may use component costs, labor assumptions, outside processing, freight, tooling, engineering hours and overhead allocations. Pricing may then apply list prices, customer-specific agreements, markups, discounts, volume breaks, currency conversion, surcharges and margin rules.

    Cost and price are not interchangeable. Cost represents the manufacturer’s expected resource consumption or procurement expense. Price is the amount offered to the customer. A CPQ system may calculate both, but the quality of the result depends on the source data and pricing governance.

    For example, a configured industrial enclosure may include sheet metal, coating, hardware, wiring, assembly labor and testing. The proposal price could depend on material grade, enclosure dimensions, ingress protection, production location, order quantity and customer discount policy. If one of those drivers is missing or outdated, automated document generation can make an inaccurate quote look authoritative.

    5. Apply approvals and commercial controls

    Many manufacturers require approval before a proposal is sent. Approval conditions may include margin below a threshold, unusual discounts, non-standard terms, custom engineering, obsolete components, export restrictions or a delivery promise outside normal capacity.

    Approval workflows should preserve the relationship between the approved configuration and the issued proposal. If a sales representative changes the motor, quantity or discount after approval, the system should either recalculate the proposal or require a new approval. This is a key difference between controlled CPQ output and manually editing a document in a word processor.

    6. Assemble and deliver the proposal

    The final document is normally generated from templates containing structured fields. A template can insert the configuration summary, price tables, technical specifications, images, terms and attachments. It may produce a PDF, a web proposal or another controlled format. The document should have a revision, validity period and reference to the underlying quote and configuration.

    Document generation is the final presentation step, not the source of truth. Product rules, prices, customer data and engineering outputs should remain in governed systems rather than being maintained only inside proposal templates.

    Data architecture behind automated proposals

    Reliable automation depends on the relationship between several data domains. A typical architecture includes the following:

    Data domain Typical contents Role in the proposal
    Product model Features, options, modules, attributes and rules Defines what can be configured
    Technical data Dimensions, ratings, materials, calculations and specifications Describes the configured product accurately
    Configurable BOM Conditional components, quantities and relationships Represents the selected scope and supports costing
    Cost data Material, labor, supplier, freight and engineering costs Supports margin and profitability analysis
    Pricing data Base prices, adjustments, discounts and currencies Calculates the customer offer
    Customer and commercial data Accounts, contracts, terms, tax and delivery information Personalizes the proposal and applies policy
    Document templates Layouts, clauses, images and attachments Produces the customer-facing output

    A BOM, or bill of material, is the structured list of components and quantities required for a product. A configurable BOM contains alternatives or conditional items that are resolved by the selected configuration. An engineering BOM (EBOM) describes a product from a design perspective. A manufacturing BOM (MBOM) describes how it is assembled or produced. The proposal may use a sales-facing summary or a resolved technical structure without exposing the complete MBOM to the customer.

    Manufacturers should define which BOM is generated at quote time and which structure is released later for production. The BOM, pricing and quoting guide covers this relationship in more detail.

    Relationships with ERP, CRM, PLM, PDM, CAD, PIM and MES

    Automated proposal generation usually sits between customer-facing sales activity and engineering or enterprise systems. These systems are complementary, not interchangeable:

    • CRM (Customer Relationship Management): stores accounts, opportunities, contacts and sales activity.
    • ERP (Enterprise Resource Planning): manages items, inventory, purchasing, production, orders, finance and often standard pricing.
    • PLM (Product Lifecycle Management): governs product definitions, revisions, change processes and lifecycle data.
    • PDM (Product Data Management): manages design files, CAD documents, versions and access controls.
    • CAD (Computer-Aided Design): creates product geometry, assemblies and drawings.
    • PIM (Product Information Management): manages reusable commercial and technical product content across channels.
    • MES (Manufacturing Execution System): supports execution and tracking of production operations on the shop floor.

    A CPQ system may read released product and price data from ERP or PLM, receive an opportunity from CRM, call CAD automation services, and return a quote or order-ready structure to ERP. The exact integration pattern depends on system ownership and product complexity. Further guidance is available in the CPQ integration guide.

    Manufacturing examples

    Configured pump package

    A customer specifies flow, head, fluid temperature, material, seal type, motor voltage and installation arrangement. The CPQ system validates the duty point, restricts incompatible materials, selects a pump and motor combination, adds baseplate and coupling components, calculates cost and applies customer pricing. The proposal includes the selected performance, scope of supply, estimated delivery and commercial terms. If the duty point falls outside standard product rules, the quote is routed to an application engineer.

    Industrial HVAC unit

    The configuration may include airflow, static pressure, casing material, coil arrangement, filters, controls, heating or cooling capacity and electrical options. Rules determine compatible modules and calculate dimensions or performance. The generated proposal can present a readable schedule of equipment, while the underlying configurable BOM supports procurement and production planning.

    Specialty vehicle

    A vehicle proposal may combine chassis, body dimensions, payload, storage modules, electrical systems, safety equipment and customer-specific accessories. Selecting one body layout may remove incompatible storage modules or change wiring and mounting requirements. The proposal should show the exact option set and exclusions, because visually similar vehicles may have materially different costs and lead times.

    Benefits and limitations

    Potential benefits

    • Faster quote preparation: Reusable rules and templates reduce manual document assembly.
    • Fewer configuration errors: Invalid combinations can be blocked before a proposal reaches the customer.
    • More consistent pricing: Approved pricing logic can be applied across sales channels and regions.
    • Better engineering focus: Engineers can review genuine exceptions instead of checking every standard quote.
    • Clearer handoff: The configuration, price basis and technical scope can travel with the opportunity or order.
    • Traceability: Revisions, approvals and proposal outputs can be linked to a specific configuration.

    Important limitations

    • Automation cannot compensate for incomplete product data, obsolete costs or undocumented engineering knowledge.
    • A rules engine may validate combinations without proving that the design is manufacturable in every plant or process.
    • Proposal generation does not automatically create an accurate EBOM, MBOM, CAD model or production routing.
    • Complex engineer-to-order work may still require engineering review, design iterations and formal change control.
    • Templates can become difficult to maintain if commercial, technical and legal content is not governed.
    • ERP, PLM and CAD integrations introduce ownership, revision, synchronization and failure-handling issues.
    • Automated pricing can expose margin or contractual risks if approval thresholds and source data are poorly controlled.

    Implementation considerations

    Start with the product and quote scope

    Define which product families, sales channels and quote types will be automated first. A modular configure-to-order (CTO) product with stable options is usually a different implementation from an engineer-to-order (ETO) product requiring new design work. Make-to-order (MTO) products are produced for a specific order but may use standard designs, while assemble-to-order (ATO) products are assembled from stocked modules after demand is received. These distinctions affect rules, BOM timing, lead-time calculation and engineering involvement.

    Assign data ownership

    Decide who owns product options, technical attributes, costs, prices, terms, drawings and proposal content. Product engineering may own technical rules, finance may own margin policy, sales operations may own discounts and legal may own terms. Without explicit ownership, the CPQ model becomes a duplicate database that drifts from source systems.

    Model rules as testable logic

    Document each rule with its purpose, inputs, expected outcome and owner. Test positive cases, invalid cases, boundary values, combinations of options and changes to released products. Include regression tests so that adding a new motor or material does not silently invalidate existing configurations.

    Separate configuration, pricing and document logic

    These layers interact but should not be indistinguishable. Configuration determines what product is valid. Costing estimates the resources required. Pricing determines the commercial offer. Document templates present the result. Separating them makes it easier to change a discount policy without rewriting engineering rules or changing a product model without breaking the proposal layout.

    Plan revision and integration behavior

    Define what happens when a price, component, drawing or rule changes after a proposal is issued. The system should preserve the quoted revision and identify whether a new configuration or price calculation is required. Integration designs should also specify error handling, synchronization frequency, identifiers, unit conversions, currency behavior and ownership of master data.

    Implementation planning, migration, testing, governance and maintenance are covered in the CPQ implementation guide. For workflow design, see the guide to manufacturing CPQ workflows.

    How to evaluate proposal-generation capabilities

    When comparing CPQ configurators, ask vendors to demonstrate a complete manufacturing scenario rather than a generic quote screen. The demonstration should begin with customer requirements and end with an approved proposal and downstream handoff.

    • Can the product model represent options, dependencies, numeric ranges and calculated values?
    • Can the system distinguish invalid combinations from configurations requiring engineering review?
    • Does it generate a resolved BOM, a sales summary, an EBOM, an MBOM or only quote lines?
    • How are component costs, labor, freight, tooling and engineering effort calculated?
    • Can pricing rules vary by customer, channel, currency, region, quantity and validity date?
    • How are discounts, low margins, non-standard terms and exceptions approved?
    • Can the proposal include configuration-specific technical data, images, drawings or CAD outputs?
    • How are quote revisions, expired prices and changes to released products handled?
    • What integrations are documented for CRM, ERP, PLM, PDM, CAD, PIM and MES?
    • Can administrators test and maintain rules without relying on unrestricted custom code?
    • How does the system support CTO, ATO, MTO and ETO processes?
    • What APIs, audit records, permissions and deployment controls are available?

    The most suitable platform is not necessarily the one with the longest feature list. It is the one that can represent the manufacturer’s product logic, preserve data ownership, produce the required commercial and technical outputs, and remain maintainable as products change. Vendor profiles and selection material are available in the manufacturing CPQ software section and CPQ comparison guides.

    Semantic map

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

    • Customer requirements lead to a product configuration.
    • Product configuration is validated by rules and constraints.
    • A valid configuration determines technical attributes and selected components.
    • A configurable BOM represents the selected product structure.
    • Cost data supports cost and margin calculations.
    • Pricing rules convert cost and commercial policy into a customer price.
    • Approval workflows control discounts and exceptions.
    • Proposal templates present configuration, price and terms.
    • ERP supplies or receives enterprise product and order data.
    • PLM and PDM govern released product and design information.
    • CAD automation can generate product-specific models or drawings.
    • CPQ connects sales requirements with engineering and manufacturing processes.

    Frequently asked questions

    1. What is automated proposal generation for configured products?

    It is the automated creation of a customer proposal from a validated product configuration, calculated price, technical scope, terms and supporting documents.

    2. Is automated proposal generation the same as CPQ?

    No. Proposal generation is one CPQ output. Manufacturing CPQ may also manage configuration rules, engineering calculations, BOMs, costing, approvals and downstream integrations.

    3. Can a CPQ system generate a BOM?

    Some CPQ systems generate resolved or configurable BOMs, while others generate only quote lines or product summaries. This capability must be verified for each platform and product family.

    4. Does a generated proposal contain the complete manufacturing BOM?

    Not necessarily. A proposal may contain a customer-facing scope of supply, while the detailed EBOM or MBOM remains in PLM or ERP.

    5. How does configuration affect proposal pricing?

    Selected options, dimensions, materials, quantities, performance requirements and services can change component costs, labor, freight, surcharges, discounts and final price.

    6. What is the difference between cost and price in CPQ?

    Cost estimates what the manufacturer must spend or consume. Price is the amount offered to the customer after applying commercial policy and margin requirements.

    7. Can automated proposals include engineering calculations?

    Some manufacturing CPQ platforms support calculations or connect to external engineering services. Others require engineering software or manual review.

    8. Can CPQ automatically create CAD drawings?

    Only platforms with suitable CAD or design-automation capabilities can do this. A document generator alone cannot be assumed to create parametric geometry or manufacturing drawings.

    9. How does CPQ handle engineer-to-order products?

    It can capture requirements, create an initial scope, estimate engineering work and route the opportunity for review. Final design and delivery commitments may still depend on engineering completion.

    10. What happens when a configuration is invalid?

    The system may block the combination, explain the conflict, suggest an alternative or route the case to an engineer, depending on the configured workflow.

    11. Can proposals be generated from CRM opportunities?

    Yes, when the CPQ system integrates with the CRM. The opportunity can provide customer and sales context while CPQ manages the technical configuration and commercial calculation.

    12. Does ERP replace CPQ proposal generation?

    ERP may store items, prices, orders and production data, but it does not necessarily provide the product rules, guided configuration or proposal logic required for complex engineered products.

    13. How are quote approvals automated?

    Approval rules can trigger review based on margin, discount, non-standard terms, custom engineering, delivery risk or other defined conditions.

    14. Can the proposal show a 3D product image?

    It can if the CPQ implementation includes visualization or receives a configuration-specific image from a visualization or CAD service. This is not universal.

    15. How should manufacturers test automated proposals?

    Test standard, boundary and invalid configurations, pricing changes, revisions, approval paths, document output, integration failures and handoff to engineering or ERP.

    16. Who should own CPQ product rules?

    Ownership commonly involves product engineering, product management and sales operations, with defined responsibilities for technical rules, prices, content and approvals.

    17. Can automated proposals support dealers and distributors?

    Yes, some systems provide dealer portals, channel pricing and controlled self-service configuration. The specific workflow and permissions must be confirmed during evaluation.

    18. What is the main risk of automated proposal generation?

    The main risk is automating incorrect or outdated data. Rules, costs, prices, revisions and templates require governance and ongoing testing.

  • Manufacturing CPQ Capabilities Checklist

    Manufacturing CPQ software should do more than produce a sales quote. It should help a manufacturer configure a valid product, apply engineering and commercial rules, calculate cost and price, generate accurate manufacturing data and transfer the result to downstream systems.

    This manufacturing CPQ capabilities checklist covers the capabilities buyers should evaluate across product configuration, rules management, engineering automation, bills of materials, pricing, quoting, integrations, workflows, governance and implementation. Not every CPQ platform provides every capability. Some systems focus on guided selling and pricing, while others support deep product models, CAD automation, engineering calculations and production data.

    For a general explanation of the category, see the guide to manufacturing CPQ. The most important evaluation principle is to assess the complete flow from customer requirements to an accepted quote and, where appropriate, to an order-ready engineering and manufacturing package.

    What is manufacturing CPQ?

    Manufacturing CPQ is software for configuring, pricing and quoting complex products whose valid design, cost and production requirements depend on customer selections and technical parameters. CPQ stands for Configure, Price, Quote.

    In a manufacturing context, configuration may involve dimensions, materials, performance requirements, environmental conditions, motors, pumps, valves, electrical components, safety options, accessories and manufacturing constraints. The system may also calculate engineering values, generate a configurable bill of materials (BOM), create product-specific drawings or exchange data with enterprise systems.

    This is different from generic sales CPQ, which may primarily select products, apply discounts and produce a proposal. Manufacturing CPQ can include those functions, but must also address product validity, engineering effort, production structure and downstream data quality.

    Manufacturing CPQ capabilities checklist

    Use the following checklist as a starting point for requirements gathering, demonstrations and requests for proposal. Mark each capability as required, desirable, not required or requiring integration with another system.

    Capability area Questions to evaluate Typical manufacturing outcome
    Product model Can the system represent variants, options, dimensions, materials, accessories and custom requirements? A maintainable model of the product family
    Rules and constraints Can it prevent incompatible combinations and validate technical limits? Fewer invalid configurations and engineering corrections
    Engineering Can it perform calculations or invoke engineering services? Faster application engineering and more consistent sizing
    BOM Can it generate a configurable, engineering or manufacturing BOM? More accurate order and production data
    CAD Can it drive parametric CAD, drawings or 3D output? Product-specific engineering documentation
    Cost and price Can it calculate material, labor, overhead, freight, margin and discounts? More controlled and explainable pricing
    Quote Can it create proposals with technical and commercial content? Faster, more accurate customer documentation
    Integration Can it exchange data with ERP, CRM, PLM, PDM, CAD, PIM or MES? Less rekeying between systems
    Workflow Does it support configure-to-order, engineer-to-order and approval processes? A controlled path from opportunity to order
    Governance Can teams test, version, release and audit product logic? Safer maintenance of product models

    1. Product configuration and product modeling

    The product model is the foundation of manufacturing CPQ. It describes what can be sold, which options are available, what values are allowed and how a selected configuration affects engineering, pricing and production.

    Evaluate whether the system can represent:

    • Product families, models, platforms and variants
    • Features, options, components and accessories
    • Numeric inputs such as length, flow rate, capacity, voltage or payload
    • Ranges, increments, units of measure and tolerances
    • Materials, finishes, standards and certifications
    • Optional, mandatory, default and mutually exclusive selections
    • Customer-specific, regional, channel-specific or plant-specific availability
    • Revisions, effective dates and discontinued components
    • Reusable subassemblies and modular product structures

    A strong product model separates reusable product knowledge from the user interface. For example, a pump family may contain a common base model, selectable impellers, motor variants, seal materials and control options. The model should also capture technical relationships such as required motor capacity for a specified flow and head, rather than relying only on a salesperson’s memory.

    Read the detailed guide to product configuration, product models and configuration rules.

    2. Rules, constraints and configuration validation

    Rules determine whether a configuration is valid and what the system should do when a selection changes. A manufacturing CPQ evaluation should distinguish between rules-based configuration, constraint-based configuration and guided selling.

    Rules-based configuration

    Rules-based configuration uses explicit logic such as “if option A is selected, require component B” or “motor voltage 480 V is available only with control package C.” These rules are often suitable for product families with well-understood dependencies.

    Constraint-based configuration

    Constraint-based configuration evaluates technical relationships and limits. Examples include maximum shaft torque, allowable pressure, enclosure size, load capacity, temperature range or dimensional interference. A constraint engine may need to identify valid values within a range rather than simply show or hide a predefined option.

    Guided selling

    Guided selling asks questions about the customer’s application and recommends or narrows products. It can be useful for distributors and less technical sales users, but it does not automatically provide deep engineering validation. A guided questionnaire should be connected to authoritative product rules where technical correctness matters.

    Check for support for dependency rules, exclusions, compatibility, minimum and maximum values, conditional requirements, calculations, warnings, hard errors, substitutions and explanation messages. Ask how rules are tested, versioned and traced to product documentation.

    3. Engineering calculations and application logic

    Some products require calculations before a valid design or price can be determined. Examples include pump selection, heat exchanger sizing, structural capacity, cable sizing, airflow, pressure drop, motor selection, battery capacity and vehicle payload.

    Evaluate whether the CPQ system can:

    • Perform calculations using formulas, lookup tables, curves or external services
    • Handle units, conversions, rounding and engineering tolerances
    • Use customer inputs such as flow, pressure, temperature, load or operating environment
    • Return a recommended product, component or range of products
    • Store calculation inputs and outputs with the configuration
    • Explain assumptions and identify when engineering review is required
    • Pass calculated values into pricing, BOM, CAD or documentation outputs

    Calculation capability varies widely between platforms. A system may provide simple formulas but require a specialist engineering application for advanced sizing. Buyers should test representative calculations rather than accepting a generic claim that the platform supports engineering logic.

    4. BOM generation and production structure

    A bill of materials, or BOM, lists the components and quantities required for a product or assembly. Manufacturing CPQ may generate a configurable BOM, an engineering BOM (EBOM) or a manufacturing BOM (MBOM), but these terms are not interchangeable.

    • Configurable BOM: a rules-driven structure that resolves into a product-specific component list based on selected options and parameters.
    • EBOM: an engineering bill of materials organized around the designed product and its technical structure.
    • MBOM: a manufacturing bill of materials organized around how the product is assembled or produced, including manufacturing-specific items and operations where supported.

    Ask whether the CPQ system creates the BOM itself, resolves a BOM maintained in an ERP or product lifecycle management (PLM) system, or sends configuration data to another application that generates the BOM.

    Important questions include whether the system supports quantities, substitutions, phantom assemblies, alternates, effectivity dates, units of measure, scrap factors, routings, labor operations and plant-specific structures. Also verify how changes are synchronized with ERP and PLM. A visually correct quote is not enough if the resulting order contains an incomplete or obsolete component structure.

    Learn more about BOM generation, costing, pricing and quote automation.

    5. CAD automation and engineering documents

    Computer-aided design (CAD) automation uses configuration data to create or modify product-specific models, drawings or documentation. It is particularly valuable when dimensions, mounting arrangements, connections or component selections change from order to order.

    Potential capabilities include:

    • Driving parametric CAD dimensions and features
    • Selecting components from approved libraries
    • Generating 2D drawings, layouts or schematics
    • Creating 3D models or lightweight visualization output
    • Producing installation, manufacturing or customer approval documents
    • Returning geometry, mass, dimensions or other calculated attributes to CPQ
    • Submitting generated files to a product data management (PDM) or PLM system

    CAD automation is not a standard feature of every CPQ platform. In some architectures, CPQ sends parameters to a CAD automation service, which returns files and metadata. In others, the CPQ system only links to existing drawings. Evaluate file ownership, revision control, regeneration time, failure handling and engineering approval.

    See the guide to CAD and engineering automation in CPQ.

    6. Costing and pricing logic

    Pricing is separate from configuration. A system may validate a product without knowing its cost, and it may calculate a price for an invalid product if the two functions are not connected properly.

    Manufacturing pricing requirements may include:

    • Component, material and purchased-part costs
    • Labor, machine time, setup and outside-processing costs
    • Overhead, freight, packaging and installation charges
    • Quantity breaks and volume pricing
    • Customer, dealer, distributor and regional price lists
    • Currency, tax, exchange-rate and effective-date rules
    • Markup, margin and contribution calculations
    • Minimum order values and surcharge logic
    • Approval thresholds for discounts or margin exceptions
    • Estimated cost for engineered or nonstandard work

    Ask whether pricing uses real-time ERP costs, maintained CPQ tables, PLM data, supplier data or manual inputs. Determine how cost versions are controlled and whether a quote can preserve the price basis used at the time it was issued.

    7. Quote and proposal generation

    Quote generation should combine commercial terms with technically meaningful configuration information. A manufacturing quote may need to show performance data, dimensions, included accessories, exclusions, assumptions, delivery expectations, installation requirements and approval conditions.

    Evaluate support for configurable quote templates, multiple languages and currencies, revisions, alternate configurations, line-item explanations, attachments, terms and conditions, electronic approval and customer acceptance. Check whether the quote stores the underlying configuration rather than only a rendered PDF.

    A proposal document should not be treated as the system of record. The accepted configuration, price basis, revision and downstream identifiers should remain available for order processing and engineering handoff.

    8. Workflow support: CTO, ETO, MTO and ATO

    Manufacturing CPQ should reflect the company’s fulfillment model. The following terms describe different relationships between customer configuration and production.

    Workflow Meaning CPQ implication
    Configure-to-order (CTO) A product is assembled from predefined, validated options. Strong configuration rules and a reliable resolved BOM are central.
    Engineer-to-order (ETO) Engineering work is created or modified for a specific order. CPQ must capture requirements, trigger review and manage engineering deliverables.
    Make-to-order (MTO) Production begins after a customer order rather than from finished-goods stock. Configuration and demand data must reach planning and production systems.
    Assemble-to-order (ATO) Standard components are assembled after the order is received. Option compatibility and component availability are important.

    Some businesses use more than one model. A machinery manufacturer may use CTO for standard frame sizes, MTO for production scheduling and ETO for unusual process conditions. The CPQ workflow should route exceptions to application engineering instead of pretending every configuration is fully automatic.

    Review related manufacturing CPQ workflows.

    9. Integration capabilities

    CPQ normally operates as part of a wider technology stack. Integration requirements should describe specific data exchanges rather than simply listing system names.

    System Typical relationship with CPQ
    Customer relationship management (CRM) Receives opportunities and accounts; stores quote status, value and sales activity.
    Enterprise resource planning (ERP) Provides items, costs, prices, inventory or orders; receives configured order data and BOMs.
    Product lifecycle management (PLM) Manages product definitions, revisions, effectivity and engineering release information.
    Product data management (PDM) Stores and controls CAD files, drawings and related design data.
    CAD Receives parameters or configuration selections and returns models, drawings or attributes.
    Product information management (PIM) Provides commercial descriptions, media, specifications and channel content.
    Manufacturing execution system (MES) May receive production-relevant configuration, BOM or routing information.
    Ecommerce and dealer portals Expose approved configuration and pricing experiences to external users.

    Evaluate APIs, webhooks, batch interfaces, data ownership, error handling, authentication, monitoring and retry behavior. A technically possible integration may still be difficult if product identifiers, revisions, units or lifecycle states are inconsistent.

    The CPQ integrations guide explains these relationships in more detail.

    10. User experiences and channels

    Different users need different levels of product knowledge. Sales representatives may need guided questions and explanations. Application engineers may need detailed parameters and calculation results. Dealers may need restricted product ranges and customer-specific pricing. Customers using self-service configuration need clear validation messages and controlled choices.

    Check whether the platform supports role-based access, internal and external portals, dealer-specific catalogs, mobile or responsive interfaces, localization, accessibility, saved configurations, comparison of alternatives and assisted configuration. Channel flexibility should not allow an external user to bypass engineering rules or release uncontrolled products.

    11. Governance, testing and maintainability

    Product logic becomes a maintained engineering asset. Evaluate how administrators manage changes to rules, components, prices, documents and integrations.

    • Version control for product models and rules
    • Approval and release workflows
    • Effective dates and revision handling
    • Role-based permissions
    • Audit history and change ownership
    • Automated regression testing for common configurations
    • Test cases for invalid combinations and boundary values
    • Sandbox environments and controlled deployment
    • Monitoring for integration failures and calculation errors
    • Dependency analysis before retiring or changing a component

    Ask who can maintain the model after implementation. If every rule change requires custom development, the operating cost may be high. If too many users can change production rules without review, configuration risk increases.

    12. Analytics and operational measurement

    Useful analytics should connect commercial activity with product and operational outcomes. Examples include quote cycle time, configuration abandonment, use of engineering review, invalid selections, discount exceptions, win rate by product family, margin by configuration, frequently selected options and recurring manual corrections.

    Analytics should distinguish between a quote that was created quickly and a quote that was correct, profitable and accepted without downstream rework. Where possible, compare CPQ data with ERP orders, engineering changes and production issues.

    Benefits and limitations

    Potential benefits

    • Shorter turnaround for standard and moderately complex configurations
    • Fewer incompatible product selections
    • More consistent application of engineering and pricing rules
    • Reduced manual re-entry between sales, engineering and operations
    • More accurate BOM and order data
    • Better visibility into margins, exceptions and product demand
    • More scalable support for dealers and distributed sales teams

    Important limitations

    • A CPQ project cannot compensate for undocumented or contradictory product knowledge.
    • Deep ETO processes may still require engineering review and CAD work.
    • Complex rules can become difficult to maintain without ownership and testing.
    • Real-time cost and availability depend on the quality and responsiveness of source systems.
    • CAD automation requires stable templates, engineering standards and failure handling.
    • A generated BOM may not be equivalent to an ERP or PLM-approved production structure.
    • Highly customized user interfaces can increase implementation and maintenance effort.

    How to use the checklist in a CPQ evaluation

    1. Map the current workflow. Document how a requirement becomes a quote, order, engineering package and production record.
    2. Select representative products. Include a standard configurable machine, a dimension-driven product and an ETO example if those are part of the business.
    3. Capture rules and data sources. Identify product owners, component masters, cost sources, CAD templates, BOM authorities and approval roles.
    4. Separate required capabilities from integration responsibilities. Decide whether CPQ, ERP, PLM, CAD or another service owns each function.
    5. Test realistic scenarios. Include valid configurations, invalid combinations, boundary values, revisions, alternatives and exceptional engineering requests.
    6. Evaluate the operating model. Confirm who maintains models, tests changes, releases prices and handles errors.
    7. Measure business outcomes. Define KPIs such as quote lead time, engineering touches, correction rate, margin leakage and order-entry quality.

    For a broader project plan, use the manufacturing CPQ implementation guide. For software selection, compare documented capabilities using the criteria in the manufacturing CPQ comparisons and selection guidance.

    Semantic map

    The following relationships summarize how manufacturing CPQ connects product knowledge, engineering, commercial logic and enterprise execution.

    • Manufacturing CPQ connects customer requirements with product configuration, pricing and production data.
    • Product models define available features, components, dimensions and variants.
    • Configuration rules prevent invalid combinations and identify required dependencies.
    • Engineering calculations transform application requirements into technical selections.
    • A configured product resolves into a product-specific BOM.
    • CAD automation generates product-specific models, drawings or documentation.
    • Costing logic converts components, labor and overhead into estimated cost.
    • Pricing logic converts cost, margin, discounts and commercial terms into a quote price.
    • CRM supplies opportunity context while ERP manages order and resource transactions.
    • PLM and PDM manage released product and design information.
    • CTO uses validated options while ETO introduces engineering review and custom work.
    • Governance controls rule revisions, approvals, testing and release.

    Frequently asked questions

    1. What capabilities should manufacturing CPQ software have?

    At minimum, evaluate product modeling, configuration validation, pricing, quoting, version control and integration with the systems that own product and commercial data. Complex manufacturers may also require engineering calculations, BOM generation, CAD automation and ETO workflows.

    2. Is manufacturing CPQ the same as sales CPQ?

    No. Sales CPQ often focuses on selecting items, pricing, discounts and proposals. Manufacturing CPQ may also validate technical requirements, resolve components, calculate engineering values and create data for engineering or production.

    3. Does every CPQ system generate a BOM?

    No. Some systems generate or resolve BOMs, while others send configuration data to ERP, PLM or a dedicated product configuration service. Verify the exact BOM type, ownership and downstream process.

    4. What is the difference between a configurable BOM and an EBOM?

    A configurable BOM contains rules for resolving a product-specific structure. An EBOM is an engineering bill of materials organized around the designed product. A configurable BOM may produce an EBOM, but the two are not automatically identical.

    5. Can CPQ replace ERP?

    Usually not. CPQ manages configuration and quoting decisions, while enterprise resource planning (ERP) manages transactions such as orders, inventory, purchasing, production planning and financial records. The systems generally need an integration boundary.

    6. Can CPQ replace PLM or PDM?

    Not necessarily. Product lifecycle management (PLM) and product data management (PDM) typically govern released product definitions, engineering changes and CAD files. CPQ may consume or extend that information for selling and configuration.

    7. Does manufacturing CPQ support engineer-to-order products?

    Some platforms support ETO requirements capture, engineering review, task routing and document generation. Others are better suited to predefined CTO products. Buyers should test how custom requirements, approvals and engineering changes are handled.

    8. What engineering calculations can CPQ perform?

    Capabilities range from formulas and lookup tables to specialized sizing services. Examples include pump selection, motor sizing, load calculations, pressure drop and dimensional checks. The required depth must be tested using real engineering cases.

    9. Is CAD automation included in CPQ?

    Not always. Some platforms include or connect to CAD automation, while others only store links or attachments. Verify supported CAD tools, template requirements, output formats, revision handling and error management.

    10. How does CPQ improve BOM accuracy?

    It applies configuration rules consistently and resolves selected options into component quantities and structures. Accuracy still depends on maintained product data, correct rules, revision control and successful integration with the authoritative BOM system.

    11. Can CPQ calculate manufacturing cost?

    Many manufacturing-oriented systems can calculate or import cost elements, but the depth varies. Confirm support for materials, labor, machine time, overhead, outside processing, freight, scrap and plant-specific cost sources.

    12. What is the role of guided selling?

    Guided selling helps users reach an appropriate product by asking application questions and narrowing choices. It is useful for sales and dealers, but it should be backed by technical rules when an incorrect selection could create an invalid product.

    13. Should CPQ own product data?

    There is no universal answer. CPQ may own selling-specific options and rules, while PLM, ERP or PIM owns engineering, item or marketing data. The important requirement is explicit ownership, synchronization and revision control.

    14. How should manufacturers evaluate CPQ rules engines?

    Use realistic tests involving dependencies, exclusions, numeric ranges, calculations, warnings, hard errors, effective dates and revisions. Also evaluate how non-developers create, test, explain and release rules.

    15. What integrations are most important for manufacturing CPQ?

    Common integrations include CRM for opportunities, ERP for items and orders, PLM or PDM for product and CAD data, and sometimes MES for production execution. The priority depends on where product, cost, BOM and order data are mastered.

    16. Can CPQ support dealers and distributors?

    Yes, where the platform supports channel-specific catalogs, permissions, pricing, configuration guidance and quote workflows. Manufacturers should ensure dealer-facing choices remain within approved technical and commercial boundaries.

    17. How does CPQ handle product revisions?

    Better platforms support versioned product models, effective dates, approvals and audit history. Confirm how a previously issued quote retains the rules, prices and components that applied when it was created.

    18. What are common manufacturing CPQ implementation risks?

    Common risks include incomplete product knowledge, unclear system ownership, excessive custom rules, untested edge cases, unreliable integrations and insufficient governance. A phased implementation with representative products can expose these issues early.

    19. What KPIs should be used after implementation?

    Useful measures include quote turnaround time, engineering review effort, configuration error rate, order-entry corrections, margin exceptions, quote-to-order conversion and the time required to release product-model changes.

    20. Where does AI fit in manufacturing CPQ?

    AI may assist with natural-language requirements, recommendations, anomaly detection or configuration analysis. It should not bypass deterministic engineering constraints or release uncontrolled product and production data. See the guide to AI-assisted CPQ.

  • How to Build a Business Case for Manufacturing CPQ

    A business case for manufacturing CPQ should show how a Configure, Price, Quote (CPQ) system will improve the commercial and engineering process for configurable products, and whether those improvements justify the investment. The strongest business cases connect measurable operational problems—such as slow quotes, invalid configurations, repeated engineering work, pricing errors and incomplete bills of material—to financial outcomes.

    Manufacturing CPQ is broader than generic sales quoting software. Depending on the product and platform, it may manage product options and constraints, perform engineering calculations, calculate costs and prices, create quotes, generate a configurable bill of material (BOM), automate CAD outputs and exchange data with enterprise systems. A business case should not assume that every CPQ product provides all of these capabilities. It should identify the required capabilities, the expected benefits and the evidence needed to validate each assumption.

    This guide presents a practical method for building the case, including baseline measurement, benefit modelling, implementation costs, risks, KPIs and an example for an industrial equipment manufacturer.

    What a manufacturing CPQ business case must prove

    A CPQ proposal normally needs to answer four questions:

    1. What problem is the manufacturer solving? For example, application engineers spend several days validating pump selections and creating order-specific documentation.
    2. What will change in the future process? A governed product model may validate compatible motors, materials, pressure ratings and accessories before a quote is submitted.
    3. What measurable value will the change create? Benefits might include shorter quote cycles, fewer rework hours, improved margin protection or faster order entry.
    4. What will the change cost and what risks could reduce the return? Costs include software, implementation, product-data preparation, integrations, training, testing and ongoing governance.

    The business case should therefore describe a future operating model, not simply list CPQ features. A product model, rules engine, pricing logic, BOM process and integration architecture all affect the expected result.

    Start with the current-state manufacturing process

    Before calculating return on investment, document how a configurable product moves from customer request to production. Map the steps from inquiry through configuration, engineering review, pricing, quotation, order entry and manufacturing release.

    For a configurable industrial pump, the process may include:

    • sales or a distributor captures flow, pressure, fluid, temperature and installation requirements;
    • an application engineer selects a pump size, impeller, motor, seal, material and accessories;
    • engineering checks hydraulic performance, motor compatibility and operating limits;
    • commercial staff calculate material cost, labor, freight and margin;
    • the quotation team creates a proposal and obtains approval for non-standard terms;
    • order entry transfers the selected options into an enterprise resource planning (ERP) system;
    • engineering creates or verifies an engineering bill of material (EBOM), manufacturing bill of material (MBOM), drawings or work instructions.

    Record the systems, spreadsheets, documents and people involved at each step. Also record where information is re-entered. Re-keying a configuration into a customer relationship management (CRM) system, ERP system and engineering application creates both labor cost and data-quality risk.

    A useful process map distinguishes activities that CPQ may automate from activities that remain dependent on engineering judgement. Rules-based validation can prevent known invalid combinations, but it does not automatically replace design review for genuinely new or unusual products.

    Define the scope of the CPQ investment

    Manufacturing CPQ can cover different parts of the product and commercial lifecycle. Scope should be explicit because the expected benefits and implementation effort vary significantly.

    Scope area Typical capability Potential business outcome
    Product configuration Options, attributes, dependencies, constraints and validation Fewer invalid quotes and less manual checking
    Engineering calculations Sizing, performance calculations or application-specific selections Faster application engineering and more consistent selections
    Pricing and costing Material costs, labor, surcharges, discounts, currencies and approvals Better margin control and more consistent prices
    Quoting Quote documents, terms, revisions and approval workflows Shorter response times and better quote traceability
    BOM generation Configurable BOM, EBOM or MBOM outputs Less order-entry and engineering rework
    CAD and documentation Parametric drawings, models or product-specific documents Faster design preparation where supported
    Integrations Data exchange with CRM, ERP, PLM, PDM, CAD or MES Reduced duplicate entry and improved downstream continuity

    Define whether the project supports configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO) or assemble-to-order (ATO) products. CTO products normally use predefined options and can be highly suitable for rules-based configuration. ETO products require new or substantially modified engineering for individual orders, so CPQ may need to manage an engineering request rather than fully automate the design.

    Read the manufacturing CPQ guide for a broader explanation of CPQ architecture and use cases.

    Establish a measurable baseline

    Use actual operational data wherever possible. A baseline does not need to be perfect, but it should be transparent about sampling, assumptions and data quality.

    Quote and order metrics

    • average and median quote turnaround time;
    • number of quotes produced per month;
    • percentage of quotes requiring engineering review;
    • percentage of quotes revised because of configuration or pricing errors;
    • quote-to-order conversion rate, interpreted carefully because many factors influence it;
    • average number of revisions per quote;
    • time from accepted quote to order entry;
    • time from order entry to engineering release or production readiness.

    Engineering and commercial effort

    • hours spent validating standard configurations;
    • hours spent creating repeat drawings, calculations or BOMs;
    • time spent answering clarification requests;
    • number of engineering escalations per product family;
    • hours spent correcting pricing, discount or cost errors;
    • number of people maintaining spreadsheets, option matrices and price lists.

    Quality and financial metrics

    • orders delayed by incorrect or incomplete configuration data;
    • change orders caused by sales or order-entry errors;
    • scrap, rework or expedited procurement attributable to incorrect selections;
    • average gross margin by product family;
    • discount leakage and unauthorized price overrides;
    • cost of delayed production release;
    • revenue or contribution margin affected by slow responses to opportunities.

    Avoid counting the same benefit twice. For example, fewer engineering hours and faster quote turnaround may result from the same automation. The model should identify whether a benefit is a hard saving, an avoided cost, additional capacity or a commercial opportunity.

    Translate CPQ capabilities into financial benefits

    Each benefit should have a clear chain of reasoning: current problem, CPQ intervention, measurable change and financial value.

    Reduced engineering effort

    If application engineers spend time checking standard combinations, a product model and configuration rules may reduce that effort. A basic calculation is:

    Annual engineering capacity released = quotes per year × current engineering hours per quote × expected reduction in manual effort

    The value depends on how the released capacity is used. It may reduce overtime, defer hiring, increase the number of opportunities supported or allow engineers to focus on complex ETO work. Do not automatically treat all released hours as cash savings.

    Lower error and rework cost

    Configuration validation can prevent incompatible options, such as a motor that cannot meet the selected voltage, a valve material unsuitable for the fluid or a frame that cannot accommodate the specified assembly. Estimate:

    Annual avoided rework cost = affected orders × current error rate × average cost per error × expected reduction

    Include engineering correction, order administration, procurement changes, production disruption, freight and customer-service effort where those costs can be supported by records.

    Faster quoting and commercial capacity

    Faster configuration and quote generation can allow a team to respond to more opportunities. This is not the same as guaranteed new revenue. Model it as a scenario with assumptions about additional quote capacity, conversion rate and contribution margin.

    For example, a manufacturer might estimate that automation creates capacity for 200 additional qualified quotes per year. The business case should then test several conversion and margin assumptions rather than presenting the resulting revenue as certain.

    Improved margin protection

    A CPQ pricing engine may apply current costs, option prices, surcharges, discount limits and approval rules. The value may come from reducing omitted options, obsolete prices, unauthorized discounts or incorrect cost assumptions.

    Separate price accuracy from configuration accuracy. A system can produce a technically valid product with an incorrect price if cost data, labor assumptions or pricing rules are incomplete.

    Reduced order-entry and handoff effort

    Where CPQ generates a structured configuration and exchanges it with ERP, the business may reduce duplicate entry between sales, engineering and production. The benefit depends on the quality of the integration and on whether the target ERP can accept the required item, option, BOM and routing data.

    For a deeper treatment of BOMs, costing and quote automation, see BOM, pricing and quoting in manufacturing CPQ.

    Separate hard savings, capacity and strategic benefits

    Benefit type Example How to treat it
    Hard saving Reduced contractor or overtime expense supported by a staffing plan Include directly if the saving is realistic and attributable
    Avoided cost Fewer expedited shipments caused by incorrect configurations Use historical cost data and a conservative reduction assumption
    Capacity release Engineers spend fewer hours checking standard options Explain how capacity will be redeployed
    Margin protection Fewer omitted accessories or unauthorized discounts Use order and margin analysis; avoid assuming all errors are recoverable
    Strategic benefit Dealers can configure approved products without waiting for engineering Describe the operational value and define supporting KPIs

    Strategic benefits can be important, but they should not conceal weak financial assumptions. Present quantified benefits separately from qualitative outcomes such as better governance, improved customer experience or reduced dependence on individual experts.

    Estimate total cost of ownership

    The investment is more than a software subscription or license. A credible total cost of ownership model includes:

    • CPQ licenses, usage charges or other commercial fees;
    • implementation and solution design;
    • product-model creation and rule authoring;
    • cleansing and structuring of product, option, cost and pricing data;
    • ERP, CRM, product lifecycle management (PLM), product data management (PDM), CAD or manufacturing execution system (MES) integration;
    • CAD templates, calculations, document generation or visualization work where included in scope;
    • testing, security, environments and deployment;
    • training for sales, engineering, administrators, dealers and customer service;
    • change management and process redesign;
    • ongoing administration, rule maintenance, releases and support;
    • internal project time and temporary productivity loss during adoption.

    PLM manages product lifecycle information and change processes, while PDM commonly manages engineering files and product data. Neither should be treated as interchangeable with ERP, which normally manages transactions such as orders, inventory, procurement and production planning. The business case should state which system owns each data element.

    The manufacturing CPQ implementation guide provides a framework for estimating data, governance, testing and deployment work.

    Build the financial model

    Use a model that shows implementation-year costs, recurring costs and benefits by year. Common measures include:

    • Net annual benefit: annual benefits minus recurring operating costs.
    • Net present value: the current value of future cash flows after applying an approved discount rate.
    • Payback period: the time required for cumulative benefits to recover the investment.
    • Return on investment: a defined comparison of net benefits with the investment cost.

    Finance teams may have specific definitions for these measures. Use their approved assumptions for labor rates, discount rates, depreciation, revenue recognition and treatment of internal labor.

    Model at least three scenarios: conservative, expected and upside. Vary the assumptions most likely to change the result, such as adoption, quote volume, error reduction, implementation duration and the proportion of products that can be standardized.

    Assess product and data readiness

    CPQ value depends heavily on the quality and maintainability of the product model. A manufacturer should inventory:

    • product families and variants;
    • options, features, attributes and valid values;
    • dependencies and incompatibilities;
    • engineering constraints and calculation inputs;
    • price lists, cost sources, currencies and discount policies;
    • configurable BOM structures and effectivity dates;
    • CAD templates, drawings and document rules;
    • standard versus non-standard engineering processes.

    Product information often exists across spreadsheets, ERP item masters, PLM records, CAD files, manuals and individual engineering knowledge. The business case should include the cost of reconciling these sources. A CPQ project that simply transfers inconsistent data into a new interface is unlikely to deliver reliable results.

    Configuration rules also require ownership. Product management may own commercial options, engineering may own technical constraints, manufacturing may own BOM and routing implications, and finance may own pricing policy. The proposed governance model should define who approves, tests and releases changes.

    Learn more about product configuration, rules and constraint management.

    Evaluate integration and architecture assumptions

    Map the required data flows before assigning integration benefits. Typical flows include:

    • CRM opportunity data into CPQ;
    • customer and account information from CRM;
    • product, item, inventory or cost data from ERP;
    • engineering revisions and product structures from PLM or PDM;
    • CAD parameters and generated outputs between CPQ and CAD;
    • configured order and BOM data from CPQ into ERP or MES;
    • catalog and attribute data from a product information management (PIM) system;
    • configuration results exposed through dealer portals or ecommerce channels.

    For each interface, specify the system of record, data owner, frequency, error handling, security requirements and whether the integration is real-time or batch. Verify vendor capabilities rather than assuming that a product supports a particular connector or object model.

    Some projects need a programmable application programming interface (API) or headless architecture so configuration services can be used by multiple channels. Others can begin with a controlled internal application and limited integration. The business case should match the architecture to the operating model rather than adding interfaces without a measurable purpose. See CPQ integration with ERP, CRM, PLM, PDM, CAD and other systems.

    Account for limitations and implementation risks

    A balanced business case explains what CPQ will not solve automatically.

    • Incomplete product data: missing rules, inconsistent part numbers and obsolete prices can delay modelling.
    • ETO variability: novel designs may still require engineering review and CAD work.
    • Complex legacy systems: ERP and PLM interfaces may require custom mapping or middleware.
    • Rule maintenance: an unmanaged ruleset can become difficult to test and change.
    • Ownership conflicts: commercial and engineering teams may disagree about valid options or approval authority.
    • Adoption resistance: users may continue using spreadsheets if the model does not reflect real quoting practice.
    • Over-customization: reproducing every exception can create a costly application that is difficult to govern.
    • False automation expectations: generating a quote does not necessarily generate a manufacturing-ready BOM, drawing or routing.

    Mitigations include starting with a well-bounded product family, documenting rule ownership, using automated and scenario-based testing, establishing release controls and defining an exception path for engineering work.

    Choose a pilot that can demonstrate value

    The best pilot is usually neither the easiest product nor the entire catalogue. Select a product family with meaningful configuration complexity, measurable quote volume, known engineering effort and sufficiently reliable data.

    A suitable pilot might include a standard industrial control panel with configurable enclosure size, voltage, breakers, drives, communication modules and mounting options. The pilot could test configuration validation, pricing, quote output and ERP order transfer without attempting to automate every custom panel design.

    Define success criteria before implementation. Examples include:

    • percentage of pilot configurations passing validation without manual correction;
    • reduction in median quote preparation time;
    • reduction in engineering review hours for standard configurations;
    • accuracy of option pricing and discount approvals;
    • completeness of the downstream item or BOM data;
    • user adoption among the intended sales and engineering group.

    Present the business case to decision-makers

    Decision-makers usually need a concise investment narrative supported by an appendix of assumptions. Structure the proposal around:

    1. Executive problem statement: identify the operational constraint and its effect on customers, engineering and production.
    2. Scope: specify product families, channels, workflows, systems and capabilities included.
    3. Baseline: show current volumes, times, errors and costs.
    4. Future process: explain how product models, rules, pricing, quotes, BOMs and integrations will work.
    5. Benefits: distinguish hard savings, capacity, margin protection and strategic outcomes.
    6. Investment: include implementation, data, integration, training and ongoing ownership.
    7. Risks and dependencies: identify data, adoption, ETO, integration and governance risks.
    8. Pilot and decision gates: define what must be proven before broader rollout.

    Use conservative assumptions and show sensitivity to adoption and implementation delay. A credible business case is more valuable than an optimistic one that fails when product modelling or integration takes longer than expected.

    KPIs for measuring the realized value

    After approval, baseline metrics should become implementation and operational KPIs. Useful measures include quote turnaround time, first-time-right configuration rate, engineering hours per quote, quote revision count, order-entry cycle time, configuration-related change orders, gross margin variance, approval cycle time, BOM completeness and user adoption.

    Measure both leading and lagging indicators. Rule coverage, test pass rates and active usage are leading indicators. Reduced rework, shorter release times and improved margin are lagging outcomes. Review KPIs by product family because a standard CTO product and an ETO product should not be judged by identical targets.

    Related manufacturing CPQ concepts

    Understanding the wider architecture helps prevent an overly narrow business case. A CAD and engineering automation workstream may generate drawings or models, but only where templates, parameters and engineering rules are sufficiently defined. A configurable BOM may represent the selected structure, while the EBOM reflects engineering design and the MBOM reflects manufacturing assembly and process needs. These structures may be related but are not automatically identical.

    For workflow design, see manufacturing CPQ workflows, including CTO, ETO, MTO and ATO processes. For vendor evaluation after the business case is approved, use the manufacturing CPQ comparisons and selection guides and review relevant manufacturing CPQ software profiles.

    Semantic map

    The following relationships summarize the main entities and dependencies in a manufacturing CPQ business case:

    • CPQ supports manufacturing configuration and quoting.
    • Product models contain options, attributes and constraints.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations validate application requirements.
    • Validated configurations produce structured quote data.
    • Pricing rules convert configuration data into prices and margins.
    • Configured products may generate configurable BOMs.
    • EBOMs describe engineering product structures.
    • MBOMs describe manufacturing product structures.
    • CAD automation generates product-specific drawings or models where supported.
    • CPQ exchanges customer and opportunity data with CRM.
    • CPQ exchanges item, cost and order data with ERP.
    • PLM and PDM provide engineering product and file data.
    • Manufacturing CPQ supports CTO more directly when options are predefined.
    • ETO workflows retain engineering review for novel designs.
    • Business cases compare measurable benefits with implementation and ownership costs.

    FAQ

    What is a business case for manufacturing CPQ?

    It is a structured justification for investing in CPQ software to improve the configuration, engineering, pricing, quoting and downstream order process for complex products. It compares measurable benefits with implementation and ongoing ownership costs.

    How is a manufacturing CPQ business case different from a generic CPQ case?

    It includes engineering and production outcomes such as configuration validity, engineering effort, BOM quality, CAD automation, order release and ERP or PLM integration, not only quote speed and sales productivity.

    What should be the first step?

    Document the current process from customer requirements through quote, order entry, engineering release and production. Measure time, errors, rework, volumes and system handoffs before estimating benefits.

    Which benefits are easiest to quantify?

    Reduced manual configuration effort, fewer pricing or option errors, shorter quote preparation, lower order-entry effort and reduced rework are usually easier to measure than additional revenue or improved customer experience.

    Can faster quoting be counted as guaranteed revenue?

    No. Faster quoting creates capacity and may improve responsiveness, but revenue also depends on market demand, product competitiveness, sales execution and win rate. Model additional revenue as a scenario.

    How should engineering capacity be valued?

    Use loaded labor costs where appropriate, then explain whether released hours create cash savings, defer hiring, reduce overtime or support more complex engineering work.

    Does every CPQ system generate a BOM?

    No. BOM generation varies by platform and implementation. Verify whether the system supports the required configurable BOM, EBOM or MBOM output and whether it can transfer that structure to the target ERP, PLM or MES.

    Does manufacturing CPQ replace engineering?

    Usually not. It can automate repeatable validation, calculations and documentation, but non-standard ETO work, new designs and exceptions may still require engineering review.

    What data is needed to build the case?

    Useful data includes quote volumes, preparation times, engineering hours, error rates, revisions, change orders, rework costs, margins, discounts, product families, system interfaces and staffing assumptions.

    Should product data cleansing be included in the investment?

    Yes. Product options, part numbers, prices, costs, constraints, BOM relationships and engineering documents often require reconciliation before they can support a reliable product model.

    What is the role of configuration rules?

    Rules define valid and invalid combinations, dependencies, required selections and technical limits. They convert engineering and commercial knowledge into repeatable validation, but they require testing and ongoing ownership.

    How should CTO and ETO benefits be treated differently?

    CTO products with predefined options may support more automation and predictable cycle-time reductions. ETO products may benefit mainly from better requirements capture, engineering handoff and reuse rather than fully automated design.

    What systems should be included in the business case?

    Consider CRM, ERP, PLM, PDM, CAD, PIM and MES according to the intended workflow. Define which system owns each data element and what information must cross each interface.

    What are common hidden costs?

    Common hidden costs include product-model authoring, data migration, integration testing, rule maintenance, user training, change management, internal project time and support after deployment.

    How many product families should be included in a pilot?

    A pilot should be narrow enough to govern but complex enough to demonstrate value. One product family with measurable quote volume and credible data is often more useful than an attempt to model the complete catalogue.

    What KPIs should be tracked after implementation?

    Track quote turnaround, configuration first-time-right rate, engineering hours per quote, quote revisions, order-entry time, configuration-related change orders, margin variance, BOM completeness, rule coverage and user adoption.

    How can CPQ business-case assumptions be tested?

    Use a pilot, historical transaction analysis, time studies, user workshops and scenario modelling. Compare pre-implementation baselines with controlled pilot results before expanding the scope.

    What is the biggest risk in a manufacturing CPQ business case?

    A common risk is assuming that software features alone create value. Benefits depend on accurate product data, maintainable rules, clear ownership, user adoption, suitable processes and reliable integration with engineering and production systems.

  • Configure, Price, Quote (CPQ) Explained for Manufacturers

    Configure, Price, Quote (CPQ) software helps manufacturers convert customer requirements into a valid product definition, an accurate price and a formal quotation. In manufacturing, CPQ may also calculate engineering values, select compatible components, generate a configurable bill of materials, create product-specific drawings or CAD outputs, and transfer order data to enterprise systems.

    CPQ is not simply a tool for applying discounts to a sales opportunity. For an industrial pump, packaging machine, electrical enclosure, material-handling system or specialty vehicle, the quoted product may depend on dimensions, materials, performance calculations, certifications, environmental conditions, production methods and compatibility rules. Manufacturing CPQ manages these relationships so that sales, engineering and operations work from the same product logic.

    The exact scope varies by platform and implementation. Some products focus mainly on guided selling, pricing and proposal generation. Others include deep configuration rules, engineering calculations, configurable BOM generation, CAD automation and integrations with enterprise resource planning (ERP), product lifecycle management (PLM) or computer-aided design (CAD) systems.

    This guide explains the meaning of configure, price and quote in a manufacturing context, how CPQ fits into the technology stack, what data it requires, where it provides value and which limitations manufacturers should consider.

    For a broader overview, see the guide to manufacturing CPQ software.

    What does Configure, Price, Quote mean?

    Configure, Price, Quote describes three connected activities:

    • Configure: select a valid product structure and resolve technical requirements, options, dimensions, components and constraints.
    • Price: calculate material, labor, overhead, purchased components, services, margins, freight, discounts, taxes or other commercial values according to company policy.
    • Quote: present the configured solution, commercial terms, assumptions, delivery information and price in a customer-facing quotation.

    In a basic sales CPQ system, these steps may involve selecting predefined products and applying pricing rules. In manufacturing CPQ, the configure step can be an engineering activity. It may determine motor size, shaft diameter, structural capacity, heat-transfer area, electrical rating, enclosure dimensions or the components required to build the product.

    The three activities are related but not interchangeable. A product can be technically valid but priced incorrectly. A price can be accurate for a standard product but unsuitable for a custom design. A professional quote can still contain an invalid configuration. Manufacturing CPQ is valuable when it connects the technical, commercial and document processes rather than treating them as separate spreadsheets.

    How manufacturing CPQ works

    A manufacturing CPQ implementation usually combines a product model, rules, calculations, pricing data, document templates and integrations. The user interface may be used by an application engineer, salesperson, dealer, distributor, customer or internal estimator. The underlying model determines what can be selected and what downstream data is produced.

    1. Capture customer and application requirements

    The process often begins with requirements rather than a product number. A customer may specify flow rate, pressure, operating temperature, throughput, payload, travel distance, voltage, available space, material compatibility or regulatory requirements.

    A guided questionnaire can collect these values and recommend suitable product families. This is called guided selling. Guided selling helps users navigate choices, but it does not necessarily prove that a technically complex product is manufacturable. A deeper configuration model is required when selections affect engineering calculations, component compatibility or production data.

    2. Select and validate the product configuration

    The CPQ product model defines products, variants, options, features, attributes, dependencies and constraints. Rules can make an option mandatory, exclude an incompatible combination, require an additional component or calculate a value from other inputs.

    For example, a pump configuration may include a flow rate, pressure, fluid type, impeller material, seal arrangement, motor, baseplate and control panel. Rules could prevent a material choice that is incompatible with the fluid, require a particular seal for a temperature range, or select a motor based on calculated power.

    Rules-based configuration evaluates explicit conditions such as if-then relationships. Constraint-based configuration represents permissible relationships among variables and searches for solutions that satisfy those constraints. A platform may support one approach or a combination of both. Buyers should verify how rules are authored, tested, versioned and maintained.

    More information about product models and validation is available in the manufacturing product configuration guide.

    3. Perform calculations and engineering checks

    Some products can be configured by selecting catalog options. Others require calculations. A CPQ system may calculate required heating capacity, structural load, belt length, pressure drop, motor power, cable size or enclosure dimensions. It may call an external calculation service or exchange data with engineering software rather than performing every calculation internally.

    Calculation results can influence the configuration. For example, a conveyor length and payload may determine frame size, drive selection and support spacing. A configured air-handling unit may require a different coil, fan and casing based on airflow and temperature conditions.

    Calculation capability should not be assumed from the presence of a product configurator. Manufacturers should ask whether the system supports formulas, units, tolerances, engineering libraries, external calculation services, validation and auditability. The CAD and engineering automation guide covers related design and drawing workflows.

    4. Generate product and manufacturing data

    Once the configuration is valid, CPQ may generate structured product data. The output can include a configured product identifier, option codes, component quantities, routing choices, technical specifications and manufacturing notes.

    A bill of materials (BOM) is a structured list of the components and quantities required for a product. Manufacturing implementations must distinguish between different BOM types:

    • Configurable BOM: a rule-driven structure containing alternatives, options or conditional components before a specific order is finalized.
    • Engineering BOM (EBOM): a design-oriented structure managed by engineering, often representing how a product is designed.
    • Manufacturing BOM (MBOM): a production-oriented structure organized for assembly, fabrication, work instructions and manufacturing processes.

    CPQ may create a configurable BOM, a sales or order BOM, an EBOM, an MBOM, or an input for another system. These are not equivalent outputs. The target structure depends on the company’s ERP, PLM, PDM and manufacturing processes.

    5. Calculate cost and selling price

    The price engine combines the configured product with commercial rules. It may use component prices, supplier costs, labor estimates, machine time, overhead allocations, engineering charges, setup fees, freight, currency rules, customer agreements, volume breaks and margin policies.

    Cost and price should be modeled separately. Cost estimates help the manufacturer understand expected profitability. Selling price may include a margin, negotiated discount, risk allowance or market-specific adjustment. A quotation may also include non-product services such as installation, commissioning, training and maintenance.

    Pricing rules must account for effective dates and product revisions. A component cost may change without changing the engineering rule, while a product revision may change both the component and the valid options. Governance is needed so users cannot unintentionally quote obsolete prices or discontinued components.

    6. Generate and approve the quote

    The quote normally includes the configured product description, technical specifications, line items, price, currency, delivery assumptions, validity period, payment terms, exclusions, warranty information and commercial conditions. Document generation may use templates populated from the CPQ data.

    Approval workflows can route quotes for review when they exceed a discount threshold, contain non-standard terms, require unusual engineering work or fall below a target margin. Approval is a control mechanism, not a substitute for correct configuration rules.

    Manufacturing CPQ architecture

    Manufacturing CPQ generally sits between customer-facing sales channels and systems of record. It may be used inside a CRM, as a standalone application or through a web interface used by dealers and distributors. The architecture differs by vendor and implementation, but common data relationships include the following:

    System or capability Typical responsibility Relationship with CPQ
    CRM Customer, opportunity and account management Provides commercial context and receives quote or opportunity status
    ERP Items, inventory, purchasing, orders, costs and financial processes Receives configured items, prices, BOMs or sales orders where supported
    PLM Product definitions, revisions, lifecycle and engineering change control Provides governed product and revision data or receives approved configurations
    PDM Product data and document management, often for CAD files Stores or supplies controlled engineering files and metadata
    CAD Geometric design and engineering documentation May receive parameters from CPQ or generate product-specific models and drawings
    PIM Product information for catalogs and commerce channels May supply descriptions, media and attributes for customer-facing configuration
    MES Manufacturing execution, production tracking and shop-floor data May receive released product or order information through ERP or other integration

    These systems are not interchangeable. ERP is not a product rules engine, PLM is not automatically a quoting tool, and CAD does not by itself provide commercial pricing. CPQ can coordinate data between them, but the system of record for each data type must be defined.

    Manufacturing examples

    Industrial pump

    A customer provides flow, pressure, fluid, temperature and installation requirements. CPQ selects a pump family, calculates or validates duty requirements, filters materials and seals, selects an impeller and motor, and produces a price. It may generate a configurable BOM and technical datasheet. If the design requires a new casing or non-standard geometry, the configuration may trigger an engineering review rather than an automatic order.

    HVAC unit

    An air-handling unit may depend on airflow, external static pressure, temperature, humidity, filtration, coil arrangement, fan type, casing material, controls and site dimensions. A valid configuration can determine component selection, estimated performance, dimensions and price. CAD or drawing automation may produce a customer-specific layout, but only if the implementation connects the CPQ model to an appropriate engineering automation process.

    Electrical enclosure

    An enclosure configuration may include width, height, depth, ingress protection, material, door arrangement, gland plates, thermal management, mounting hardware and electrical accessories. Rules can prevent incompatible dimensions or require cooling equipment when heat dissipation exceeds a limit. The resulting BOM and drawings may need review before release to production.

    Specialty vehicle

    A vehicle builder may configure chassis, wheelbase, body modules, payload, drive system, seats, safety equipment and accessories. The product model must manage dependencies between physical space, load capacity, electrical systems and regulatory requirements. Dealer-facing configuration may be simpler than the engineering model, with restricted access to advanced options.

    Manufacturing CPQ compared with generic sales CPQ

    Generic sales CPQ often focuses on selecting products, applying discounts and generating proposals. That is useful for standard goods, but it may not address the technical consequences of configuration.

    Area Generic sales CPQ emphasis Manufacturing CPQ emphasis
    Product model Catalog items, bundles and options Variants, dimensions, dependencies, constraints and engineering attributes
    Validation Commercial eligibility and option compatibility Technical, dimensional, performance and manufacturability constraints
    Pricing List price, discounts and contracts Configured cost, labor, material, margin, engineering and production impacts
    Output Proposal and order details Proposal plus specifications, BOM, calculations, drawings or engineering work packages where supported
    Workflow Sales approval and contract process Sales, application engineering, design, planning and production handoff

    Not every manufacturing CPQ product supports every capability in the right-hand column. The term describes a use case and scope, not a guarantee of functionality. Evaluation should focus on the product complexity and downstream outputs the manufacturer actually requires.

    How CPQ relates to CTO, ETO, MTO and ATO

    Manufacturing organizations use several fulfillment models:

    • Configure-to-order (CTO): a customer selects from predefined options and the product is assembled or completed after the order.
    • Engineer-to-order (ETO): the customer requirement leads to new or substantially modified engineering work before production.
    • Make-to-order (MTO): production starts in response to a customer order rather than forecast stock, although the design may be standard.
    • Assemble-to-order (ATO): stocked or planned modules are assembled into a customer-selected combination.

    CPQ is often easiest to standardize for CTO and ATO products because the valid solution space is known. It can also support ETO by collecting requirements, applying standard rules, estimating engineering effort and creating an engineering handoff. However, CPQ does not eliminate the need for engineering judgment when a solution falls outside the product model.

    The manufacturing workflow guide explains how CPQ supports configure-to-order and engineer-to-order processes.

    Benefits of CPQ for manufacturers

    • Faster quote preparation: sales and application engineers can reuse controlled product logic instead of rebuilding calculations in spreadsheets.
    • Fewer configuration errors: rules can block incompatible options before a quote reaches engineering or production.
    • More consistent pricing: cost and price logic can be applied consistently across sales teams, regions and dealer channels.
    • Reduced engineering rework: standard configurations can arrive with structured requirements, calculations and component selections.
    • Better sales-to-engineering handoff: the technical decisions made during quoting can be retained as structured data.
    • Improved product governance: revisions, effective dates, approvals and rule ownership can be managed more systematically.
    • More complete customer communication: quotes can include relevant specifications, assumptions, images and configuration details.

    Limitations and risks

    CPQ does not repair poor product data automatically. If options, costs, drawings, part numbers or rules are incomplete, the system can produce incomplete or misleading results more quickly.

    Complexity is another risk. A product model that contains every historical exception may become difficult to understand and maintain. Manufacturers should separate standard configurable products from genuinely exceptional ETO work where possible.

    Integrations also require careful design. Duplicate item masters, inconsistent units, conflicting revision states and unclear ownership can create errors between CPQ, ERP, PLM, PDM and CAD. A successful quote does not necessarily mean that an order can be manufactured without additional translation.

    Finally, calculated outputs may need engineering approval. A CPQ result should not be treated as a certified design unless the organization has validated the formulas, design limits, applicable standards and release process.

    Implementation considerations

    Start with a defined product scope

    Select a product family with measurable business value and a manageable configuration boundary. Document standard options, variables, exceptions, calculations, component relationships, pricing inputs and required outputs.

    Assign ownership of rules and data

    Product management, engineering, sales operations, finance, manufacturing and IT may each own different parts of the model. Define who approves rules, who maintains costs, who controls revisions and who tests changes.

    Model the workflow, not just the screen

    Map the path from inquiry to quote, approval, order, engineering release and production. Identify when the configuration becomes authoritative and which system owns the resulting item, BOM, drawing or order.

    Test combinations and edge cases

    Testing should include valid combinations, invalid combinations, boundary values, discontinued components, unit conversions, currency changes, revision changes, discounts, approval thresholds and integration failures. Regression testing is important whenever product rules change.

    Measure operational outcomes

    Useful measures may include quote cycle time, first-pass configuration accuracy, engineering hours per quote, quote-to-order conversion, margin variance, approval time, percentage of quotes requiring rework and time from order to production release. The appropriate measures depend on the manufacturer’s baseline and process goals.

    For a structured approach, use the CPQ implementation guide and review the CPQ integration architecture guide.

    What to evaluate in manufacturing CPQ software

    Manufacturers should evaluate capabilities against actual product and workflow requirements rather than generic feature counts. Important questions include:

    • Can the system model dimensions, quantities, dependencies, exclusions and conditional components?
    • Can non-technical users maintain rules without uncontrolled custom code?
    • Does it support calculations, units, tolerances and external engineering services?
    • Which BOM types can it create, and how are revisions handled?
    • Can it connect to CAD, PLM, PDM, ERP and CRM systems through supported interfaces?
    • Does it support CTO, ATO, MTO or ETO workflows, and where are the boundaries?
    • Can it manage configurable costs, customer-specific pricing, currencies and approvals?
    • Can dealer, distributor, ecommerce or self-service users access a controlled subset of the model?
    • How are rules tested, versioned, released and audited?
    • What happens when a configuration requires engineering review or falls outside the standard model?

    Vendor capabilities must be verified in product documentation, demonstrations using representative products and, where appropriate, a proof of concept. A platform that generates attractive quotes may still be unsuitable if it cannot produce the manufacturing data or integration outputs required by the business. See the manufacturing CPQ comparison and selection resources for additional evaluation criteria.

    Semantic map

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

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration validates technical relationships.
    • Guided selling collects customer requirements.
    • Engineering calculations determine product parameters.
    • A configured product generates structured product data.
    • A configured product may generate a BOM.
    • An EBOM represents the engineering product structure.
    • An MBOM represents the manufacturing product structure.
    • Pricing rules calculate selling prices.
    • Cost data supports margin analysis.
    • CPQ generates customer quotations.
    • CAD automation generates product-specific drawings.
    • CPQ exchanges item and order data with ERP.
    • CPQ exchanges lifecycle data with PLM.
    • CPQ supports sales-to-engineering handoff.
    • CTO uses predefined configurable options.
    • ETO requires engineering work for non-standard requirements.

    Frequently asked questions

    What is CPQ software for manufacturing?

    Manufacturing CPQ software models configurable products, validates technical choices, calculates costs and prices, generates quotes and may produce BOMs, calculations, drawings or integration data for downstream systems.

    What does CPQ stand for?

    CPQ stands for Configure, Price, Quote: configure a valid solution, calculate its commercial value and produce a formal quotation.

    Is manufacturing CPQ the same as sales CPQ?

    No. Sales CPQ may focus on catalog selection, discounts and proposals. Manufacturing CPQ may also manage engineering constraints, calculations, BOMs, CAD outputs and production handoffs.

    Does every CPQ system generate a BOM?

    No. BOM generation varies by product. Some systems produce configurable or order BOMs, while others integrate with ERP or PLM and leave BOM creation to those systems.

    Can CPQ replace an ERP system?

    No. ERP systems manage broader processes such as inventory, purchasing, finance, production orders and fulfillment. CPQ may exchange configured product and order data with ERP.

    Can CPQ replace PLM?

    No. Product lifecycle management (PLM) manages product definitions, revisions, changes and lifecycle governance. CPQ may consume approved PLM data or return configuration information.

    Can CPQ automate CAD?

    Some platforms support CAD or engineering automation, directly or through integrations. Others only generate specifications and quotes. CAD automation must be verified for the required CAD system and product family.

    What is the difference between product configuration and pricing?

    Product configuration determines what can technically be sold or built. Pricing determines the cost and selling price of that selected solution. The two processes can share data but solve different problems.

    What is a configuration rule?

    A configuration rule defines a relationship between product choices or values. For example, selecting a high-temperature fluid may require a particular seal and exclude a standard elastomer.

    What is constraint-based configuration?

    Constraint-based configuration represents limits and relationships among variables, such as capacity, dimensions and compatibility, and validates or searches for solutions that satisfy those constraints.

    What is guided selling in CPQ?

    Guided selling uses questions, recommendations and simplified choices to help a user identify a suitable product. It may assist configuration but is not automatically a complete engineering validation method.

    Can CPQ support engineer-to-order products?

    Yes, in some implementations. CPQ can collect requirements, apply standard rules, estimate engineering effort and create a handoff, but it does not remove the need for engineering design and approval.

    What is the difference between EBOM and MBOM?

    An EBOM is organized around the engineering design. An MBOM is organized around how the product is manufactured and assembled. A CPQ output may be either, neither or an input to another system.

    How does CPQ connect with CRM?

    Customer relationship management (CRM) systems manage accounts, opportunities and sales activities. CPQ may run within or alongside CRM and attach configurations, prices and quotes to the opportunity.

    How does CPQ connect with CAD?

    CPQ can pass configuration parameters to CAD automation, receive engineering attributes or link product-specific files. The exact integration depends on the platform, CAD system and data model.

    Who maintains CPQ product rules?

    Ownership is usually shared. Engineering may own technical rules, product management may own options, finance may own pricing policies and IT may own integrations. Governance must define approval and release responsibilities.

    How long does a manufacturing CPQ implementation take?

    There is no universal timeframe. Scope depends on product complexity, data quality, integrations, calculations, CAD requirements, workflow changes and the number of channels or product families.

    What is the biggest CPQ implementation risk?

    A common risk is trying to automate an unclear or poorly governed product model. Manufacturers should establish product boundaries, rule ownership, data quality and downstream requirements before scaling the implementation.

    Can customers configure products directly online?

    Some CPQ implementations support ecommerce or self-service configuration. The customer-facing model usually needs controlled options, clear explanations and safeguards so that sensitive engineering or pricing logic is not exposed unnecessarily.

    How should a manufacturer test CPQ rules?

    Testing should cover valid and invalid combinations, boundary conditions, revisions, costs, discounts, units, approvals, integration failures and representative products. Regression testing is needed after rule changes.

  • CPQ Software for Manufacturing: The Complete Guide

    CPQ software for manufacturing is a system that helps manufacturers configure complex products, apply engineering and commercial rules, calculate costs and prices, generate quotes, and transfer accurate product data to engineering, enterprise and production systems. CPQ means configure, price, quote, but manufacturing CPQ usually extends beyond sales quoting. Depending on the platform and implementation, it may also generate bills of material, support engineering calculations, automate computer-aided design (CAD), create product-specific drawings, and support configure-to-order or engineer-to-order workflows.

    For example, a manufacturer of industrial pumps may use CPQ to select a pump family, flow rate, pressure rating, motor, seal, material, connection standard and accessories. The system can reject incompatible combinations, calculate the required pump configuration, determine a cost and selling price, produce a quotation, and send a manufacturing bill of material (MBOM) or engineering bill of material (EBOM) to connected systems. Not every CPQ product supports every step, so buyers must evaluate documented capabilities rather than assume that all CPQ platforms are engineering automation systems.

    This guide explains how manufacturing CPQ works, where it fits in the technology stack, which capabilities matter, how it differs from generic sales CPQ, and how to plan an implementation.

    What is manufacturing CPQ software?

    Manufacturing CPQ software is a product configuration, pricing and quoting application designed for companies that sell products with many options, dependencies, dimensions, materials, performance requirements or engineering variations. It converts customer and sales requirements into a valid product definition and a commercially usable quote.

    The central object is usually a product model. A product model represents a configurable product family, its features, options, parameters, rules, calculations, prices, costs and downstream outputs. A model for a conveyor system might include belt width, length, speed, frame material, motor size, controls, guarding and installation requirements. These choices may affect one another and may also affect the BOM, CAD geometry, labor, lead time and price.

    Manufacturing CPQ can sit between customer-facing sales channels and operational systems. It may be used by sales engineers, application engineers, dealers, distributors, customers through self-service channels, or internal customer service teams. The system can be connected to customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), CAD, product information management (PIM), manufacturing execution systems (MES) and ecommerce platforms.

    These integrations are not automatic characteristics of the CPQ category. The available integration method, data ownership and level of automation depend on the selected product, connectors, APIs and implementation design.

    How manufacturing CPQ differs from generic sales CPQ

    Generic sales CPQ often focuses on selecting sellable items, applying discounts and producing a proposal. Manufacturing CPQ may perform those functions, but it must also represent physical products and engineering constraints.

    Area Generic sales CPQ Manufacturing CPQ
    Configuration Selects products, packages and commercial options Models technical parameters, dependencies, dimensions, materials and performance constraints
    Validation Prevents incompatible commercial selections May validate mechanical, electrical, hydraulic, thermal, safety and manufacturing constraints
    Pricing Uses price books, discounts and approvals May combine material, labor, purchased components, overhead, freight, margin and project-specific calculations
    Outputs Quote, proposal and order data Potentially quote, configurable BOM, EBOM, MBOM, drawings, CAD files, calculations and manufacturing attributes
    Downstream systems Usually CRM, ERP and payment or order systems May include CRM, ERP, PLM, PDM, CAD, MES, PIM, dealer portals and engineering applications
    Workflow Sales opportunity to quote Customer requirements to configuration, engineering validation, quote, order, production and service data

    The distinction is important when selecting software. A platform that produces attractive proposals may not be able to calculate a shaft diameter, create an engineering BOM or generate a production-ready drawing.

    The main capabilities of manufacturing CPQ

    Product configuration and product models

    Configuration is the process of selecting and defining a valid product from a product family. The product model should identify available features, options, values, ranges, units of measure, defaults, dependencies and exclusions. It may also contain revisions, effective dates, regional availability and customer-specific restrictions.

    A robust model separates reusable product knowledge from presentation logic. The same configuration logic might be used in an internal engineering application, a dealer portal and a guided sales experience, although each channel may expose different questions.

    Manufacturers should document whether a platform supports discrete options, numeric ranges, formulas, modular structures, variant management, version control and reusable rules. These details affect model maintainability as much as the number of advertised features.

    See the guide to product configuration for product models, options, dependencies and validation rules.

    Rules, constraints and guided selling

    Rules determine what the system should allow, recommend, calculate or require. Common rule types include:

    • Compatibility rules: prevent combinations such as a motor that cannot deliver the required torque.
    • Dependency rules: require a variable-frequency drive when a particular motor control option is selected.
    • Exclusion rules: prevent two incompatible materials or connection standards from being selected together.
    • Calculation rules: derive motor size, vessel volume, cable length, structural dimensions or other values.
    • Validation rules: check technical limits, regulatory requirements, tolerances and required customer inputs.
    • Recommendation rules: suggest an option based on application conditions or operating requirements.
    • Commercial rules: apply customer pricing, territory restrictions, minimum margins or approval thresholds.

    Rules-based configuration evaluates explicit if-then logic. Constraint-based configuration describes permitted relationships and searches for solutions that satisfy those constraints. Guided selling asks questions in a business-friendly sequence and uses the answers to narrow the product choices. A manufacturing implementation may use all three, but they solve different problems.

    Engineering calculations

    Some products require calculations before a valid configuration can be selected. Examples include pump duty, heat exchanger capacity, pressure drop, load capacity, airflow, cable sizing, battery capacity and structural loading.

    Calculation logic may be implemented directly in the CPQ product model, called from an external engineering service, or handled by a connected application. The implementation should identify input units, formulas, assumptions, rounding, tolerances, standards and approval ownership. A price calculator is not automatically an engineering calculator, and a basic option dependency is not equivalent to a validated physical design.

    Costing and pricing

    Pricing determines what the customer is charged; costing estimates what the manufacturer expects to spend. The two should be modeled separately even when they use related data.

    Cost inputs can include raw materials, purchased components, labor operations, machine time, subcontracting, freight, tooling, installation and overhead. Price logic may include list prices, customer agreements, regional prices, volume breaks, currency, surcharges, discounts, target margins and approval thresholds.

    Manufacturers should ask whether the CPQ system calculates costs itself, retrieves them from ERP, or supports both approaches. They should also define which system is authoritative for prices, costs, currencies, exchange rates and commercial approvals. More detail is available in the guide to BOM generation, pricing and quoting.

    Quote and proposal generation

    A quote usually contains the configured product description, quantities, price, discounts, validity period, delivery assumptions, terms, exclusions and commercial notes. Manufacturing quotes may also require technical specifications, performance data, drawings, compliance statements, installation scope and customer-specific documentation.

    Document generation should use the validated configuration rather than allow sales users to manually retype technical details. Approval workflows can route exceptions such as low margin, non-standard materials, unusual lead times or configurations outside an approved product model.

    Bill of material generation

    A bill of material (BOM) is a structured list of components and quantities needed for a product or assembly. A CPQ system may generate a configurable BOM directly, map configuration choices to ERP items, or send a configuration identifier for downstream resolution.

    An EBOM, or engineering bill of material, describes the product from an engineering design perspective. An MBOM, or manufacturing bill of material, organizes components and operations for production. A configurable BOM represents possible or selected variants before a specific order is finalized. These structures are related but not interchangeable.

    For a configured control cabinet, the BOM may depend on enclosure size, incoming voltage, motor starters, terminal blocks, safety devices and cable requirements. The CPQ output must specify the intended structure, item identifiers, quantities, revisions, attributes and ownership. The system should not be described as generating a production-ready MBOM unless that capability and the required integration have been verified.

    CAD automation and visualization

    CAD automation links configuration choices to geometry, assemblies, drawings or models. A configured agricultural implement might produce a model with a selected working width, hitch type, hydraulic circuit and frame option. A configured machine enclosure might generate dimensions, panel cutouts and mounting positions.

    Possible outputs include a 2D drawing, 3D model, neutral CAD file, rendered image, installation layout or technical document. Some systems provide native parametric CAD automation; others integrate with CAD or design automation services. Three-dimensional visualization can improve understanding, but a visual configurator alone does not prove that the underlying geometry is manufacturable.

    Review CAD and engineering automation in CPQ for design automation, visualization, drawings and calculations.

    Where CPQ fits in the manufacturing technology stack

    CPQ is typically an orchestration and decision layer rather than a replacement for every enterprise application. A clear data ownership model is essential.

    System Typical responsibility Possible CPQ relationship
    CRM Accounts, opportunities, contacts and sales activities Starts a configuration from an opportunity and receives quote status or value
    ERP Items, inventory, purchasing, orders, production planning and financial data Supplies item, cost and price data or receives configured order and BOM data
    PLM Product structures, revisions, lifecycle states and engineering governance Provides approved product data or receives new engineered variants
    PDM CAD files, documents, metadata and design revisions Stores or retrieves CAD outputs and related documents
    CAD Geometry, assemblies, drawings and design attributes Receives parameters and returns generated design outputs
    PIM Product descriptions, media, attributes and channel content Provides customer-facing product information
    MES Shop-floor execution, work instructions and production tracking May receive manufacturing data or configuration identifiers
    Ecommerce or dealer portal Customer or channel ordering experience Provides a front end for guided configuration and quoting

    For integration planning, see the manufacturing CPQ integration guide. It covers APIs, data exchange and relationships with ERP, CRM, PLM, PDM, CAD, PIM and MES.

    Manufacturing workflows supported by CPQ

    Configure-to-order

    Configure-to-order (CTO) uses an approved product model to select a valid variant from predefined options. The manufacturer may stock or plan the underlying components, while the final product is configured after the order. A standard pump family with selectable seals, motors and connections is a common example.

    Make-to-order and assemble-to-order

    Make-to-order (MTO) begins production after a customer order and may use a standard or configurable design. Assemble-to-order (ATO) combines stocked modules after the order. CPQ can capture the selected modules and pass the resulting structure to ERP, but it does not by itself determine inventory policy or production scheduling.

    Engineer-to-order

    Engineer-to-order (ETO) requires new or substantially modified engineering for a customer order. CPQ can capture requirements, perform preliminary calculations, create a commercial estimate and initiate an engineering review. It may also create a preliminary BOM or CAD starting point. ETO requires controlled handoff and technical approval; CPQ should not be treated as a substitute for engineering sign-off.

    These workflows are explained in the manufacturing CPQ workflow guide.

    Example: configuring an industrial air-handling unit

    Consider an air-handling manufacturer selling units for commercial buildings. The configuration may include airflow, external static pressure, unit orientation, casing material, filter class, heating or cooling coil, fan type, motor, controls, access doors and environmental rating.

    1. The salesperson or dealer enters application requirements and site constraints.
    2. The CPQ model checks whether the selected fan can meet the airflow and pressure requirement.
    3. The system applies dependencies, such as requiring a particular control panel for a selected voltage or a corrosion-resistant casing for a specified environment.
    4. An engineering calculation determines a suitable coil or fan range, subject to the manufacturer’s approved methods.
    5. The configuration maps to components, quantities, costs, lead-time attributes and a price.
    6. The system generates a technical quote and may request approval for non-standard selections.
    7. If supported, a CAD or selection tool generates a layout, schedule or drawing.
    8. Approved order data is sent to ERP, PLM, CAD or another downstream system according to the implementation design.

    The example shows why configuration, engineering, pricing and BOM generation must be considered separately. A system may perform the first five steps well but require another application for CAD output or production BOM creation.

    Benefits of CPQ for manufacturers

    • Faster quote preparation: reusable models and automated calculations reduce manual work on repeatable configurations.
    • Fewer configuration errors: rules prevent or identify invalid combinations before an order reaches engineering or production.
    • More consistent pricing: cost and price logic can be applied consistently across sales channels.
    • Reduced engineering effort: approved configurations and automated documents can reduce routine application-engineering tasks.
    • Better sales-to-engineering handoff: the selected options, parameters and assumptions are captured as structured data rather than free-text notes.
    • Improved manufacturing data: supported implementations can produce or transmit item selections, BOM structures, drawings and configuration identifiers.
    • Channel control: dealers and distributors can receive guided access to approved products, prices and quoting permissions.
    • Traceability: configuration versions, approvals and quote revisions can be recorded for later review.

    Benefits depend on product-model quality, data accuracy, integration depth, user adoption and governance. Implementing a CPQ application without maintaining the rules and product data will not remove the underlying complexity.

    Limitations and risks

    Manufacturing CPQ projects often fail or underperform for reasons that are not caused by the user interface. Product knowledge may be distributed across spreadsheets, drawings, ERP records, engineering workbooks and individual employees. Converting that knowledge into tested, maintainable rules is a substantial modeling task.

    • Model complexity: large product families can create thousands of interactions and difficult testing requirements.
    • Data ownership: conflicting item, price, revision and description data can produce inconsistent outputs.
    • Engineering boundaries: a CPQ model may cover standard configurations but not novel ETO designs or specialist calculations.
    • Integration limitations: a connector may transfer basic order data without supporting revisions, BOM structures, documents or real-time validation.
    • Rule maintenance: product changes, supplier substitutions, regulations and pricing updates require controlled releases.
    • Performance: complex calculations, CAD generation and large product models may require asynchronous processing or specialized architecture.
    • Governance: unclear ownership can allow obsolete or unapproved options to remain available.
    • User experience: exposing engineering terminology without guidance can make configuration difficult for sales or dealers.

    Buyers should request demonstrations using representative products, including difficult configurations and negative test cases, rather than relying only on feature checklists.

    How to evaluate CPQ software for manufacturing

    Evaluation should begin with the product and workflow, not with generic sales automation features. Create representative scenarios for a standard configurable product, a calculation-driven product, a product with CAD output and an ETO or exception workflow.

    Evaluation area Questions to verify
    Product modeling Can the system model options, parameters, ranges, modules, revisions, units and effective dates?
    Rules and constraints Can technical, commercial and manufacturing rules be expressed, tested and maintained by appropriate users?
    Calculations Can the platform run required formulas, use external services and record assumptions and units?
    BOM Does it generate a configurable BOM, EBOM or MBOM, or does it map choices to ERP items?
    CAD and documents Can it generate drawings, models, layouts or technical documents, and under whose ownership?
    Pricing and costing Can it handle material costs, labor, margins, currencies, discounts, agreements and approvals?
    Workflow Does it support CTO, ATO, MTO, ETO, engineering review and exception handling?
    Integration What APIs, connectors, events, batch processes and error-handling mechanisms are available?
    Governance Are versioning, permissions, testing, audit history and release controls adequate?
    Scale How does performance change with large models, many rules, multiple regions and several channels?

    Use the manufacturing CPQ software profiles and CPQ comparison and selection resources to structure vendor research. Capability descriptions should be checked against product documentation, demonstrations and contractual scope.

    Implementation approach

    1. Define the business case and scope

    Choose an initial product family and workflow with measurable problems, such as long quote preparation, frequent configuration errors or excessive engineering review. Define the intended users, channels, outputs and systems involved.

    2. Inventory product and commercial data

    Collect option lists, dimensions, formulas, compatibility rules, item numbers, revisions, costs, prices, documents, lead times and approval policies. Identify duplicate and contradictory sources before loading data into the product model.

    3. Establish ownership and governance

    Assign owners for product rules, engineering calculations, prices, costs, CAD templates, ERP mappings and integrations. Define who can propose, approve, publish and retire a change.

    4. Model a representative product

    Start with a product that is valuable but not impossibly broad. Include normal configurations, boundary values, invalid combinations, substitutions, regional differences and exception paths. This exposes model and architecture issues early.

    5. Design integrations and data contracts

    Specify what each system sends and receives, which identifier links a quote to an order, how revisions are represented, how errors are retried, and how users are notified when an external system is unavailable.

    6. Test rules and outputs

    Use automated and manual tests for valid configurations, invalid combinations, boundary calculations, price changes, revisions, BOM quantities, documents and integration failures. Business users and engineers should review the outputs.

    7. Deploy in controlled releases

    Train users on the configuration process and the boundaries of automation. Monitor quote cycle time, error rates, approval volume, engineering rework, model defects and integration failures. Add product families only after the operating model is stable.

    See the CPQ implementation guide for requirements, migration, testing, deployment, maintenance and performance measures.

    Key questions to ask before buying

    • Which product families are genuinely configurable, and which require ETO engineering?
    • Which rules are safety-critical or legally significant?
    • Does the business need a quote only, or also BOM, CAD and manufacturing outputs?
    • Which system owns items, revisions, costs, prices and approved product structures?
    • Who will maintain the model after implementation?
    • Can the solution support internal sales, dealers, distributors and customer self-service without duplicating rules?
    • How will non-standard configurations be routed to engineering?
    • What happens when ERP, PLM, CAD or pricing services are unavailable?
    • How will old quotes and configurations remain reproducible after a product revision?

    Semantic map

    The following relationships summarize how manufacturing CPQ connects product knowledge, commercial decisions and downstream execution:

    • CPQ configures configurable products.
    • Product models contain options, parameters and rules.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration satisfies technical requirements.
    • Guided selling translates customer requirements into selections.
    • Engineering calculations validate product performance.
    • A configured product determines component selections.
    • A configured product can generate or resolve a BOM.
    • EBOM represents an engineering product structure.
    • MBOM represents a manufacturing product structure.
    • Pricing logic calculates the selling price.
    • Costing logic estimates manufacturing and delivery cost.
    • CAD automation generates product-specific drawings or models.
    • CPQ exchanges configuration data with ERP.
    • PLM governs product revisions and lifecycle states.
    • CRM provides opportunity and customer context.
    • ETO routes non-standard requirements to engineering.
    • CTO selects approved product variants for order execution.

    Frequently asked questions

    What does CPQ stand for in manufacturing?

    CPQ stands for configure, price, quote. In manufacturing, it usually includes technical product configuration and may connect quoting with engineering, BOM, CAD and enterprise workflows.

    What is the main purpose of manufacturing CPQ?

    Its main purpose is to turn customer requirements into a valid, priced and documented product configuration that can move efficiently toward order fulfillment.

    Is manufacturing CPQ the same as sales CPQ?

    No. Sales CPQ may focus on products, discounts and proposals, while manufacturing CPQ must often manage technical parameters, constraints, calculations, BOMs and engineering handoff.

    Can CPQ generate a bill of material?

    Some platforms can generate or resolve configurable BOMs, while others pass configuration selections to ERP or PLM for BOM resolution. The specific output and production readiness must be verified.

    What is the difference between an EBOM and an MBOM?

    An EBOM organizes a product from an engineering perspective. An MBOM organizes materials and operations for manufacturing. A CPQ implementation may produce one, both, or neither directly.

    Can CPQ create CAD drawings?

    Some manufacturing CPQ solutions integrate with CAD or design automation tools to generate drawings, models or layouts. Others provide visualization without generating manufacturing CAD.

    Does CPQ replace ERP?

    No. ERP typically manages items, inventory, purchasing, orders, production planning and financial transactions. CPQ usually supplies validated configuration and commercial data to ERP.

    Does CPQ replace PLM?

    No. Product lifecycle management (PLM) governs product data, revisions, lifecycle states and engineering processes. CPQ may consume approved PLM data or initiate controlled engineering work.

    Can CPQ support engineer-to-order products?

    It can support the front end of ETO by capturing requirements, estimating price and routing exceptions. Full ETO still requires engineering design, review, revision control and production preparation.

    What products benefit most from manufacturing CPQ?

    Products with many technical options, dependencies, dimensions, materials or application-specific calculations benefit most. Examples include machinery, pumps, valves, HVAC units, electrical equipment and specialty vehicles.

    What is a product model in CPQ?

    A product model is the structured representation of a configurable product family, including features, options, parameters, rules, calculations, prices, costs and outputs.

    What is the difference between configuration rules and constraints?

    Rules commonly express explicit actions such as requiring or excluding an option. Constraints describe relationships or limits that a valid solution must satisfy. Platforms may support one or both approaches.

    Can manufacturers use CPQ for dealer and distributor sales?

    Yes, if the platform supports the required channels, permissions, customer-specific pricing, product visibility and approval workflows. The same governed product logic should ideally be reused across channels.

    How does CPQ reduce engineering workload?

    It can automate repeatable selections, calculations, documents and standard configurations. It does not eliminate engineering review for novel designs, safety-critical decisions or unsupported exceptions.

    How long does a manufacturing CPQ implementation take?

    There is no reliable universal duration. Scope, product complexity, data quality, integrations, CAD automation, governance and the number of channels all affect the timeline.

    What data is needed to implement CPQ?

    Typical data includes product structures, options, parameters, compatibility rules, formulas, item identifiers, revisions, costs, prices, documents, lead times, customer rules and integration mappings.

    How should CPQ rules be maintained?

    Rules should have named owners, version control, test cases, approval gates, release procedures and an audit trail. Engineering, product management, commercial teams and IT may share governance responsibilities.

    What should a CPQ proof of concept include?

    It should include a representative product, difficult and invalid configurations, pricing, required calculations, expected BOM or CAD outputs, user roles and at least one realistic downstream integration.

    Can CPQ be used for configure-to-order and make-to-order?

    Yes. CPQ can define approved variants and pass configuration data into order and production processes. It does not independently determine inventory, scheduling or shop-floor execution.

    Is 3D visualization required for manufacturing CPQ?

    No. Visualization is useful when spatial understanding affects buying or configuration, but a rules engine, validated data model and reliable downstream outputs may be more important for many products.