CPQ Guide

Tag: PLM integration

  • From Quote to Production: The Manufacturing CPQ Workflow

    Manufacturing CPQ—Configure, Price, Quote software for complex products—connects the commercial quote with the engineering and production information needed to fulfill an order. A typical workflow starts when a salesperson, dealer or customer selects product options and ends when validated configuration data, pricing, a bill of materials (BOM), engineering outputs and order information are transferred to the appropriate enterprise systems.

    The important distinction is that manufacturing CPQ does more than calculate a price and generate a proposal. It may validate technical combinations, perform engineering calculations, identify components, create a configurable BOM, initiate CAD automation and distinguish between a standard configure-to-order product and an engineer-to-order project. The exact scope depends on the CPQ platform, product model and integrations implemented by the manufacturer.

    For example, a pump manufacturer might use CPQ to select pump type, impeller diameter, motor rating, materials, seals, connection standards and control options. The system can reject incompatible combinations, calculate performance requirements, determine price and produce a quote. After order acceptance, it may send the validated configuration to an enterprise resource planning (ERP) system, generate an engineering bill of materials (EBOM), request drawings from a computer-aided design (CAD) system or route an exception to an engineer.

    This article follows that process from initial requirements through production handoff. For a broader introduction, see the guide to manufacturing CPQ.

    What the manufacturing CPQ workflow does

    The manufacturing CPQ workflow transforms customer requirements into progressively more detailed business and technical records:

    1. Requirements are captured: the customer need is translated into product choices, dimensions, performance requirements and commercial conditions.
    2. The product is configured: a product model applies features, options, dependencies and constraints.
    3. The configuration is validated: the system checks whether the selected product can be designed, priced and manufactured within defined rules.
    4. Price and cost are calculated: list prices, discounts, material costs, labor assumptions, margins, freight or other commercial factors are applied.
    5. The quote is generated: the customer receives a commercial proposal describing the configured product, assumptions, price and delivery conditions.
    6. The order is released: an accepted quote becomes an order or sales order after approvals and commercial checks.
    7. Engineering and manufacturing data are produced: BOMs, specifications, drawings, calculations or work instructions are generated where supported.
    8. Enterprise systems are updated: ERP, product lifecycle management (PLM), product data management (PDM), CAD, manufacturing execution system (MES) or customer relationship management (CRM) systems receive the relevant data.

    Not every CPQ application performs every step. Some systems focus mainly on guided selling, pricing and quote documents. Others include product configuration, BOM generation, CAD automation and engineering workflow capabilities. A buyer must verify each downstream capability rather than treating CPQ as a single standardized product category.

    Stage 1: Capture the customer requirement

    The process begins with a business or technical requirement. This may be a salesperson selecting options, an application engineer entering operating conditions, a dealer using a web portal or a customer configuring a product through ecommerce.

    Manufacturing requirements often include more than a product name and quantity. A configuration may require:

    • capacity, flow rate, pressure, temperature or load;
    • overall dimensions, working envelope or installation constraints;
    • material, coating, ingress protection or environmental requirements;
    • motor voltage, frequency, power rating and control method;
    • connection standards, mounting arrangements or interface dimensions;
    • regulatory, safety or documentation requirements;
    • quantity, delivery location and requested date;
    • commercial terms, currency, discount authority and service requirements.

    Guided selling can help a user reach a suitable product by asking questions in business language. It may recommend a pump family based on flow and pressure, or an industrial enclosure based on environment and dimensions. Guided selling is not the same as a complete engineering rules engine. It may guide selection without proving that every detailed design constraint, component relationship or manufacturing requirement has been satisfied.

    Stage 2: Configure the product

    Product configuration is the selection and validation of a particular product variant from a defined product model. The model describes the product structure, features, options, components, relationships and rules.

    A product model for an industrial air-handling unit might contain:

    • unit size and airflow range;
    • fan type and motor selection;
    • coil arrangement and heat-transfer requirements;
    • filter class and access configuration;
    • casing material and insulation;
    • control panel and sensor options;
    • service access, mounting and connection options.

    Rules determine what can be selected together and what must happen when a choice is made. For example, selecting a high-temperature application may require a particular seal material, exclude a standard coating and trigger a special documentation requirement. Selecting a larger motor may require a different starter, cable size, enclosure or mounting arrangement.

    Manufacturers should distinguish three related approaches:

    Approach How it works Typical manufacturing use
    Rules-based configuration Explicit if-then logic controls options, dependencies and required selections. Preventing incompatible motor, material and accessory combinations.
    Constraint-based configuration Variables and constraints describe technical limits, ranges and relationships. Selecting a machine size based on load, dimensions or performance requirements.
    Guided selling Questions and recommendations help a user navigate a product family. Helping a dealer identify a suitable equipment model before detailed validation.

    These approaches can coexist, but they solve different problems. A recommendation is not necessarily a valid engineering design, and a valid configuration is not necessarily a complete manufacturing order.

    Detailed terminology and examples are covered in the guide to product configuration and configuration rules.

    Stage 3: Validate technical feasibility

    Before a quote is released, the configuration should be checked against technical and commercial rules. Validation may happen continuously as the user makes selections or as a final pre-quote step.

    Validation can include:

    • option compatibility and mandatory dependencies;
    • minimum and maximum dimensions;
    • capacity, load, flow, pressure or temperature limits;
    • material compatibility with the operating environment;
    • motor, drive, power supply and control compatibility;
    • component availability or approved-part restrictions;
    • regulatory and documentation requirements;
    • manufacturing plant, tooling or process constraints;
    • approval requirements for non-standard selections.

    Some requirements can be evaluated directly by the CPQ rules engine. Others require calculations, a lookup service, engineering review or a connected CAD, PLM or ERP system. A manufacturer should document which validations are authoritative and which are advisory.

    When the configuration falls outside the product model, the workflow may branch. The system can reject the request, offer an approved alternative, create an exception for engineering or convert the opportunity into an engineer-to-order (ETO) process. This is preferable to silently allowing a technically invalid order to reach production.

    Stage 4: Perform engineering calculations and automation

    Engineering automation is the point at which manufacturing CPQ can extend beyond sales configuration. Depending on the implementation, the system may calculate performance, size components, select standard parts, create design parameters or call an external engineering application.

    For a conveyor, calculations might involve belt width, speed, load, drive power and frame dimensions. For a pressure vessel, the design may depend on volume, pressure, material, wall thickness and applicable design rules. For a control cabinet, the configuration may determine enclosure size, heat dissipation, component count and wiring requirements.

    CAD automation can use configuration values to update a parametric model, produce a product-specific drawing or generate a three-dimensional representation. Some systems create only a visual preview; others can initiate more substantial design automation through a CAD or engineering integration. These capabilities must be verified for the specific CAD system, product model and release process.

    Engineering outputs may include:

    • calculated dimensions and performance values;
    • equipment specifications and technical datasheets;
    • product-specific 2D drawings or 3D models;
    • assembly instructions or manufacturing notes;
    • engineering change or review tasks;
    • approved component selections and design parameters.

    See CAD and engineering automation in CPQ for the relationship between product configuration, calculations, parametric CAD and drawings.

    Stage 5: Calculate cost and price

    Pricing is related to configuration but is not the same activity. Configuration determines what the product is. Pricing determines what the customer is charged under defined commercial rules.

    A manufacturing pricing model may include:

    • base product and option prices;
    • quantity breaks and customer-specific price lists;
    • material, size or performance surcharges;
    • labor, setup or engineering charges;
    • freight, installation, commissioning or service fees;
    • currency, tax and regional rules;
    • discount limits and approval thresholds;
    • target margin or cost-plus calculations.

    Costing may use standard costs, component costs, routing assumptions, purchased-part prices or other internal data. A CPQ system may calculate cost directly, retrieve it from ERP or another source, or use a simplified commercial model. Cost and price should be traceable so that users understand why an unusual configuration changes the quote.

    For example, selecting stainless steel wetted parts on a pump may change material cost, supplier lead time, manufacturing operations and selling price. The pricing logic should not be treated as an isolated discount table if the selection also affects the BOM and engineering work.

    Stage 6: Generate and approve the quote

    Once the configuration, calculations and price are acceptable, CPQ generates a quote or proposal. The document should describe the configured product clearly enough for the customer and internal reviewers to understand what is being offered.

    A manufacturing quote may contain:

    • configured product description and option summary;
    • technical specifications and operating assumptions;
    • quantity, unit price, extended price and discounts;
    • delivery estimate or lead-time assumptions;
    • drawings, images or datasheets where appropriate;
    • exclusions, exceptions and customer responsibilities;
    • validity period, payment terms and approval conditions.

    Approval workflows can be triggered by margin, discount, non-standard components, unusual delivery requirements, contractual terms or engineering exceptions. Approval does not automatically mean the configuration is production-ready. It confirms that the organization accepts the commercial and, where applicable, technical conditions of the quote.

    Stage 7: Convert the accepted quote into an order

    After customer acceptance, the quote becomes an order or sales order. This conversion should preserve the exact configuration version that was quoted. Re-keying options manually into an ERP system creates a risk that the ordered product differs from the approved product.

    Important order data can include:

    • product model and configuration identifier;
    • selected options, values and quantities;
    • calculated dimensions and engineering parameters;
    • price, discount, currency and commercial terms;
    • customer, ship-to and billing information;
    • requested delivery date and manufacturing location;
    • attached drawings, specifications and approval records;
    • status of engineering exceptions and customer approvals.

    Version control matters when product rules or prices change between quote and order. The manufacturer should decide whether the order uses the rules and prices from the quotation date, order date or a controlled product release.

    Stage 8: Generate the BOM and manufacturing data

    A bill of materials is a structured list of parts, assemblies, quantities and relationships required for a product. Manufacturing CPQ may generate or select a BOM, but the result must be defined carefully.

    An engineering bill of materials (EBOM) represents the product from an engineering design perspective. A manufacturing bill of materials (MBOM) represents how the product is assembled or produced, including manufacturing structure, operations or plant-specific requirements. A configurable BOM contains rules or option relationships that resolve into a product-specific structure after configuration.

    For a configured electrical enclosure, the resolved data might include the enclosure, mounting plate, circuit breakers, contactors, terminal blocks, wiring accessories, labels and documentation. The MBOM may additionally reflect assembly cells, kits, consumables or production steps that are not organized in the same way as the EBOM.

    Data object Purpose Typical owner or system
    Product model Defines features, options, rules and configuration behavior. CPQ, product management or configuration engineering.
    EBOM Describes the engineered product structure. PLM, PDM or engineering system.
    MBOM Describes the production structure and assembly view. ERP, MES or manufacturing engineering system.
    Sales order Records the commercial commitment and ordered configuration. ERP or order management system.
    CAD output Provides product-specific geometry, drawings or models. CAD, PDM or PLM system.

    Some CPQ implementations create a complete resolved BOM. Others send configuration parameters to ERP, PLM or an engineering application that owns BOM generation. The integration contract should specify which system is authoritative for each object.

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

    Stage 9: Handoff to ERP, PLM, PDM, CAD and MES

    Manufacturing CPQ is usually part of a wider application architecture:

    • CRM stores customer, opportunity and sales activity information. It may launch the CPQ process but is not normally the authoritative source for manufacturing structures.
    • ERP manages enterprise transactions such as sales orders, inventory, purchasing, production planning, costing and financial data.
    • PLM manages product lifecycle information, revisions, approvals, changes and engineering collaboration.
    • PDM manages product data and CAD files, often with controlled revisions and document relationships.
    • CAD creates or modifies product geometry, drawings and models.
    • PIM, or product information management, manages product content and attributes for publishing and sales channels.
    • MES, or manufacturing execution system, manages or records production execution on the shop floor.

    Integration can be synchronous, such as a real-time availability or pricing call, or asynchronous, such as sending an approved order to an ERP queue. Common exchange methods include application programming interfaces (APIs), middleware, files, webhooks and controlled batch processes.

    The integration should define identifiers, ownership, revision behavior, error handling, retries, security and audit history. A successful API call does not prove that the receiving system accepted a technically complete order. Reconciliation and exception monitoring are necessary.

    See the guide to CPQ integrations with ERP, CRM, PLM, PDM, CAD, PIM and MES.

    How CTO, ETO, MTO and ATO fit the workflow

    The downstream process depends on the manufacturer’s fulfillment model:

    Model Meaning CPQ and production implication
    Configure-to-order (CTO) A product is selected from approved options and assembled or produced after the order. Strong configuration validation and resolved order data are important; engineering intervention may be limited.
    Engineer-to-order (ETO) Engineering work creates or adapts the product for a specific customer. CPQ captures requirements, defines the commercial baseline and routes exceptions or projects to engineering.
    Make-to-order (MTO) Production begins after the order rather than from finished-goods stock. CPQ must provide accurate specifications, lead-time assumptions and order data.
    Assemble-to-order (ATO) Predefined modules are assembled after the order. Configuration resolves the correct modules, components and assembly instructions.

    These categories can overlap. An industrial machine may be configure-to-order at the module level but engineer-to-order for its foundation, guarding or site interfaces. The CPQ workflow should expose that boundary rather than promise that every configuration can be fulfilled without engineering.

    The relationship between sales configuration and fulfillment is explained further in the guide to CTO, ETO, MTO, ATO and order-to-production workflows.

    Practical example: configuring an industrial pump skid

    Consider a pump manufacturer selling packaged pump skids. A sales engineer enters required flow, discharge pressure, fluid temperature, fluid composition, power supply and installation environment.

    1. The product model recommends a suitable pump family and available frame size.
    2. Rules require a compatible impeller range, seal material and motor configuration.
    3. A calculation checks the duty point and identifies whether a standard or special impeller is appropriate.
    4. The configuration adds valves, gauges, base frame, coupling guard and control panel options.
    5. Pricing applies component prices, a skid assembly charge, engineering fees and an approved discount.
    6. The quote includes the selected pump, duty assumptions, exclusions and expected delivery conditions.
    7. After acceptance, the configuration is transferred to ERP and the engineering system.
    8. A resolved EBOM is created or requested, while manufacturing engineering prepares the MBOM and routing.
    9. CAD automation may produce a layout drawing if the skid dimensions and interfaces are within the supported model.
    10. If the customer requires an unusual nozzle location or a non-standard material, the order is routed for ETO review instead of being released automatically.

    This example shows why quote accuracy depends on more than a price calculation. The same option can affect technical feasibility, cost, lead time, BOM structure, drawings and production work.

    Benefits of connecting quote and production

    • Fewer transcription errors: validated configuration data can flow into order and engineering systems without repeated manual entry.
    • Faster engineering response: standard configurations and calculations can be automated, leaving engineers to review exceptions.
    • More reliable pricing: option, material, labor and engineering effects can be represented in a controlled model.
    • Clearer customer expectations: the quote can show the exact product assumptions, limitations and deliverables.
    • Better production readiness: BOMs, specifications and drawings can be prepared earlier in the order lifecycle.
    • Improved product governance: changes to options, rules and approved components can be managed centrally.

    Limitations and common failure points

    CPQ does not eliminate the need for product data governance or engineering judgment. Common failure points include:

    • incomplete or contradictory product rules;
    • old price lists, costs or supplier data;
    • product models that do not reflect current engineering revisions;
    • unclear ownership between CPQ, ERP, PLM and CAD;
    • an EBOM that cannot be transformed into a usable MBOM;
    • calculations that work only for a narrow range of products;
    • uncontrolled manual overrides and undocumented exceptions;
    • integration failures that are not visible to sales or operations;
    • attempting to model genuinely new ETO designs as if they were standard options.

    A quote can be commercially valid but not production-ready. Production readiness requires agreed technical data, correct revisions, manufacturable structures, approved exceptions and a reliable handoff to the systems that execute the order.

    Implementation considerations

    Manufacturers planning a quote-to-production CPQ workflow should begin with a representative product family rather than attempting to model the entire catalog at once.

    Define ownership and scope

    Document which system owns product options, rules, prices, costs, revisions, BOMs, CAD files, customer data and order status. Decide whether CPQ generates a BOM or sends parameters to another system. Define the point at which a configuration becomes an engineering project.

    Build and test the product model

    Capture option definitions, dependencies, constraints, calculations, default values, units of measure and exception paths. Test valid configurations, invalid combinations, boundary values, changed revisions and manually approved exceptions. Include product experts, sales engineering, manufacturing engineering, IT and operations in testing.

    Control data and releases

    Rules, prices, components, drawings and integration mappings need controlled release processes. A change to a motor, material or accessory may affect configuration logic, cost, lead time, BOM, CAD and documentation. Treat the product model as an engineered asset, not merely a sales form.

    Measure the complete workflow

    Useful measures include quote cycle time, configuration error rate, engineering hours per order, percentage of quotes requiring manual correction, order-entry rework, quote-to-order conversion, BOM accuracy, integration failure rate and time from order acceptance to production release. Metrics should cover downstream quality, not only sales speed.

    More guidance is available in the manufacturing CPQ implementation guide.

    FAQ: manufacturing CPQ from quote to production

    1. What is the manufacturing CPQ workflow?

    It is the process of capturing requirements, configuring a product, validating technical choices, calculating price, generating a quote, converting the accepted quote into an order and transferring production-relevant data to engineering and manufacturing systems.

    2. How is manufacturing CPQ different from sales CPQ?

    Sales CPQ usually emphasizes guided selling, pricing, approvals and quote documents. Manufacturing CPQ may also manage technical rules, calculations, BOMs, CAD outputs, engineering exceptions and ERP, PLM or production handoffs.

    3. Does CPQ always generate a BOM?

    No. Some CPQ platforms generate resolved BOMs, while others send configuration parameters to ERP, PLM or an engineering system that owns BOM creation. This capability must be verified for the product and platform.

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

    A configurable BOM contains rules or option relationships that resolve for a selected product. An EBOM is the engineering view of a specific product structure. A configured product may use a configurable BOM to produce an EBOM.

    5. Does a CPQ system create an MBOM?

    Not necessarily. An MBOM represents the manufacturing view of the product and may be created in ERP, MES or a manufacturing engineering system. CPQ may supply the resolved product and component data needed to create it.

    6. Can CPQ automate CAD drawings?

    Some implementations can drive parametric CAD or generate drawings through an integration. Others provide only images or configuration data. The manufacturer should verify supported CAD systems, model complexity, revision control and approval workflows.

    7. When should a configuration become an ETO project?

    It should become ETO when the request requires new design work, an unsupported geometry, unusual interfaces, non-standard calculations or an engineering decision outside the approved product model.

    8. Can CPQ calculate product performance?

    It can, if the platform includes suitable calculation logic or connects to an engineering calculation service. Calculations should be validated against engineering methods and defined operating ranges.

    9. What information should move from CPQ to ERP?

    Typical data includes the customer and ship-to details, ordered configuration, item identifiers, quantities, prices, dates, commercial terms, configuration version and references to drawings or technical documents.

    10. Is CRM the same as CPQ?

    No. CRM manages customer and opportunity relationships. CPQ manages product selection, configuration, pricing and quoting. The systems may be integrated, but they have different purposes.

    11. What is the role of PLM in the workflow?

    Product lifecycle management (PLM) manages product definitions, revisions, approvals, changes and engineering information. It may be the authoritative source for product structures or CAD-related data that CPQ uses during configuration.

    12. Can a dealer use manufacturing CPQ?

    Yes. A dealer can use a controlled CPQ interface to configure products, apply permitted commercial rules and submit orders or opportunities. Access, pricing authority and technical complexity should be governed by the manufacturer.

    13. How are non-standard options handled?

    The system can block them, suggest an approved alternative, require an approval or route the request to engineering. The correct approach depends on risk, product strategy and the manufacturer’s ETO process.

    14. What happens if product rules change after a quote is issued?

    The manufacturer should preserve the quote’s configuration and rule version, then define whether the accepted order is revalidated against the new release. Any material change should be visible and controlled.

    15. Can CPQ manage lead times?

    It can display or calculate lead-time assumptions when connected to reliable component, capacity or planning data. Many systems use estimated lead times rather than a complete production schedule, so the source and accuracy of the value must be understood.

    16. Does CPQ replace ERP or PLM?

    No. CPQ complements ERP, PLM, CAD and other systems. It manages the configuration and commercial workflow, while each enterprise system retains its defined operational or engineering responsibilities.

    17. What is the biggest implementation risk?

    A common risk is automating an incomplete product model. If rules, components, prices, revisions and exception paths are not governed, CPQ can reproduce errors faster rather than create production-ready orders.

    18. How should a manufacturer start a CPQ project?

    Select a representative product family, document the current quote-to-production process, define system ownership, model the rules and test the complete handoff through order and engineering release before expanding scope.

    Semantic map

    The article connects the following entities and relationships:

    • Customer requirements lead to product configuration.
    • Product configuration applies options, dependencies and constraints.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations validate technical feasibility.
    • Validated configuration determines cost and price.
    • Configured products generate product-specific order data.
    • Resolved configurations can generate or select BOM structures.
    • EBOM represents the engineered product structure.
    • MBOM represents the manufacturing product structure.
    • CAD automation can generate product-specific drawings.
    • Accepted quotes become sales orders.
    • CPQ exchanges configuration and commercial data with ERP.
    • PLM manages product revisions and engineering changes.
    • ETO handles designs outside the approved product model.
    • MES can receive production-relevant information from enterprise systems.

    A manufacturing CPQ workflow is successful when the accepted quote remains consistent with the product that engineering and production are asked to build. The objective is not simply a faster proposal. It is a controlled chain from customer requirement to validated configuration, accurate commercial commitment and usable production data.

  • CPQ for Engineer-to-Order Manufacturing

    CPQ for engineer-to-order manufacturing helps manufacturers convert a customer requirement into a technically valid, priced and manufacturable order. It does more than generate a sales quote. A manufacturing CPQ system can capture application data, apply product rules, perform engineering calculations, identify standard and custom components, create a configurable bill of materials (BOM), initiate CAD or engineering work, and transfer approved order data to enterprise systems.

    Engineer-to-order (ETO) products are designed or substantially engineered for a specific customer after the order or quotation process begins. Examples include custom pumping systems, industrial machinery, material-handling equipment, process skids, large electrical assemblies and specialty vehicles. In these environments, the central question is not simply “What is the price?” It is “Can this product be designed, manufactured and delivered within the stated requirements, and what data is needed to do so?”

    This guide explains how CPQ fits into that process, which data and rules it requires, how it connects with engineering and production systems, and where its limitations must be managed.

    What is CPQ for engineer-to-order manufacturing?

    CPQ for engineer-to-order manufacturing is software that supports the configuration, pricing, quoting and engineering handoff of products that require customer-specific design or validation. CPQ means configure, price, quote. In an ETO context, configuration usually defines the design basis and requirements rather than producing a completely finished product definition without engineering involvement.

    A suitable CPQ process should distinguish between three outcomes:

    • Standard configuration: The selected options fit an existing product model and can often proceed through configure-to-order or make-to-order production.
    • Configured variant: The selection is valid but requires a product-specific BOM, calculation, drawing or engineering review.
    • New or exceptional design: The requirements exceed the approved product model and must be handled as an engineering project, with controlled assumptions, approvals and design work.

    CPQ does not replace computer-aided design (CAD), product lifecycle management (PLM), enterprise resource planning (ERP) or manufacturing execution system (MES). Instead, it coordinates information between these systems when the product model and integrations are designed appropriately. Not every CPQ platform supports BOM generation, CAD automation, engineering calculations or ETO workflows, so each capability must be verified during software evaluation.

    See the broader manufacturing CPQ guide for an overview of CPQ architecture and use cases.

    How ETO CPQ differs from generic sales CPQ

    Generic sales CPQ typically focuses on selecting commercial options, applying discounts and producing a proposal. That may be adequate for standardized products or subscription services. ETO manufacturing requires a deeper product and engineering model.

    Concern Generic sales CPQ ETO manufacturing CPQ
    Configuration Option selection and compatibility checks Technical requirements, dimensions, materials, ratings, capacities and constraints
    Pricing List prices, discounts and commercial rules Material, labor, purchased parts, engineering effort, risk, overhead, freight and margin
    Output Quote or proposal Validated requirements, configuration data, cost basis, BOM inputs and engineering work package
    Engineering Usually outside the CPQ workflow Calculations, CAD parameters, design review and controlled exceptions may be included
    Production handoff Order details for fulfillment Production-relevant master data, revisions, documents and approval status
    Exceptions Often handled manually Classified as standard, configurable, configurable-with-review or new design

    The distinction is important when selecting software. A platform may be strong at guided selling and proposal generation while having limited support for engineering calculations or manufacturing BOMs.

    The ETO CPQ workflow from requirement to production

    The exact workflow varies by industry and product architecture, but a practical ETO process usually contains the following stages.

    1. Capture the customer requirement

    The process begins with application and technical requirements rather than only a product name. A sales engineer may record flow rate, pressure, temperature, fluid properties, operating environment, required capacity, footprint, voltage, compliance requirements and delivery constraints for a pumping system. For a conveyor, the inputs may include load, length, elevation, throughput, belt type, motor characteristics and site conditions.

    Requirements should be represented as structured data wherever possible. Free-text notes are useful for context, but they are difficult to validate, calculate or transfer reliably to engineering and ERP systems.

    2. Apply product rules and constraints

    The CPQ product model evaluates whether the requested combination is allowed. Rules can express dependencies, exclusions, required selections, ranges and conditional behavior. For example:

    • A high-temperature seal requires a compatible elastomer and may exclude a standard coating.
    • A pump operating above a specified pressure requires a particular casing material and inspection level.
    • A vehicle body length may require a different chassis, axle rating and braking package.
    • A motor voltage must match the selected electrical enclosure and control system.
    • A structural span above a defined length may require an additional support assembly.

    Rules-based configuration uses explicit product logic such as “if option A is selected, require component B.” Constraint-based configuration evaluates permitted values and relationships, such as dimensional, capacity or compatibility limits. Guided selling leads a user through questions and recommendations but does not, by itself, guarantee complete engineering validation. These approaches may be combined.

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

    3. Perform engineering calculations

    Many ETO products cannot be priced or selected correctly without calculations. A CPQ application may contain calculation logic, call an external engineering service or pass requirements to a specialized application. Possible calculations include pump head and flow selection, heat-exchanger sizing, motor power, structural loading, pressure ratings, cable sizing, storage capacity and vehicle payload.

    Calculations should identify their inputs, formulas, units, assumptions, valid ranges and revision. A result such as “recommended motor: 30 kW” should be traceable to the requirements and calculation version that produced it. If the calculation is only advisory, the workflow should make clear that engineering approval remains necessary.

    4. Determine the engineering path

    After validation, the system can classify the order. A standard configuration may proceed automatically. A valid but unusual configuration may require an engineering review. A genuinely new design may create an engineering task with requirements, assumptions, selected reference products and customer documents.

    This classification prevents two common mistakes: sending an invalid order directly to production, or sending every order through a slow manual engineering process even when the design is already covered by approved rules.

    5. Calculate cost and price

    ETO pricing may include material, purchased components, manufacturing labor, engineering hours, testing, documentation, tooling, freight, installation and project risk. CPQ can calculate a target cost and apply pricing policies, but the calculation depends on reliable source data.

    Costing and pricing are related but different. Costing estimates what the manufacturer is expected to spend. Pricing determines what the customer is charged after considering margin, market conditions, commercial policy and risk. Engineering changes after quotation may require a revised cost and price.

    For related concepts, see the guide to BOM generation, pricing and quote automation.

    6. Generate quote and approval data

    The quotation should describe the technical basis of the offer. It may include selected options, operating assumptions, performance values, exclusions, delivery assumptions, documentation, testing and validity conditions. A technically detailed quote reduces ambiguity when the order moves from sales to engineering.

    Approval rules may be triggered by discount level, margin, non-standard materials, unusual delivery requirements, export restrictions, contractual terms or technical risk. Approvals should preserve the configuration revision and the price version used to create the offer.

    7. Create the engineering and manufacturing handoff

    When the customer accepts the quote, the approved configuration becomes an order baseline. The handoff may contain:

    • customer and project identifiers;
    • requirements and operating conditions;
    • selected options and parameter values;
    • calculation results and assumptions;
    • approved exceptions and deviations;
    • cost and price information where appropriate;
    • component and material requirements;
    • BOM or BOM-generation instructions;
    • CAD parameters, reference models or drawing requests;
    • required certificates, inspections and documentation;
    • revision, approval and change-control status.

    The goal is not merely to send a PDF to engineering. It is to send structured, versioned data that can be reused by PLM, CAD, ERP and production processes.

    How product data becomes production-ready

    A central ETO CPQ design question is how a commercial configuration becomes an engineering and manufacturing definition. This normally requires several related data structures.

    Product model

    The product model defines features, options, parameters, relationships, rules, calculations and outputs. It may include a machine family, allowable dimensions, compatible materials, standard assemblies and approved alternatives. The model should describe what users may select and what the organization is prepared to support.

    Configurable BOM

    A configurable BOM contains rules or selection logic that expands into a product-specific list of components. For example, a pump model may include one of several impellers, a selected seal package, a motor, coupling, baseplate, instrumentation and documentation package.

    The configurable BOM is not necessarily the final manufacturing BOM. It may be an intermediate structure used to derive an engineering BOM (EBOM) or manufacturing BOM (MBOM).

    • EBOM: An engineering bill of materials organized around the designed product and its functional or design structure.
    • MBOM: A manufacturing bill of materials organized around how the product is assembled, fabricated, inspected and produced.
    • Configurable BOM: A rule-driven structure that resolves into selected components based on configuration inputs.

    Some CPQ systems generate a complete BOM. Others send configuration parameters to ERP or PLM, where the BOM is expanded. The ownership of each structure must be defined rather than assumed.

    CAD and engineering outputs

    CAD automation can use configuration values to select models, set dimensions, create assemblies or generate drawings. In an enclosure project, for example, the configured width, height, mounting pattern and cable-entry arrangement may drive a parametric CAD model.

    However, CAD automation has technical prerequisites: stable templates, controlled parameters, naming conventions, compatible revisions and a way to handle geometry that falls outside the template. A CPQ platform that displays a 3D product image is not necessarily capable of generating production CAD.

    Read more about CAD, engineering and design automation.

    System architecture and integrations

    ETO CPQ normally sits between customer-facing processes and engineering or enterprise systems. The architecture should define which system owns each type of data.

    System Typical responsibility Possible CPQ exchange
    CRM Customer, opportunity, contacts and sales activity Opportunity context, account, quote status and acceptance
    CPQ Configuration, calculations, pricing, quote and handoff logic Validated configuration and commercial outputs
    CAD Geometric design and engineering models Parameters, references, models and drawing requests
    PDM Product data and CAD document control Files, metadata, revisions and approved references
    PLM Product structures, lifecycle, revisions and change management EBOM, requirements, specifications and engineering status
    ERP Items, inventory, purchasing, costing, orders and planning Items, sales order, BOM, routing and pricing data
    MES Shop-floor execution and production records Released work instructions, routings or production identifiers
    PIM Commercial product information and content Descriptions, attributes and customer-facing content

    CRM, ERP, PLM, PDM, PIM and MES are not interchangeable. Integration should specify data ownership, identifiers, revision behavior, error handling, security and timing. The CPQ integration guide covers these system relationships in more detail.

    CTO, ETO, MTO and ATO in one process

    Manufacturers often support several fulfillment models. Configure-to-order (CTO) uses predefined options and generally approved product structures. Engineer-to-order (ETO) requires customer-specific engineering. Make-to-order (MTO) means production starts after an order but may use an established design. Assemble-to-order (ATO) combines stocked or prebuilt modules after the order.

    Model Design status at order Typical CPQ role
    CTO Defined by approved options Validate selections, price and generate order configuration
    ETO Requires customer-specific engineering Capture requirements, calculate, price, route engineering and control revisions
    MTO Established design, produced after order Validate demand, price and trigger production supply
    ATO Modules already available Configure the finished combination and reserve or trigger assembly

    One product family may move between these models. A standard pump package may be CTO, while a custom skid with site-specific piping, controls and structural requirements is ETO. The CPQ workflow should make this distinction explicit.

    See the guide to CTO, ETO, MTO, ATO and order-to-production workflows.

    Benefits of CPQ in ETO manufacturing

    • Earlier technical validation: Invalid combinations and missing requirements can be identified before order entry.
    • Faster engineering triage: Engineers can focus on exceptions and new designs rather than rechecking routine selections.
    • More consistent costing: Material, labor, engineering and risk inputs can be calculated from the same configuration.
    • Better quote quality: Assumptions, exclusions and technical outputs are tied to a specific revision.
    • Reduced order-entry errors: Structured configuration data is less ambiguous than manually rekeyed descriptions.
    • Improved reuse: Approved product rules, calculations and templates can be reused across sales channels.
    • Traceable handoff: Sales, engineering, purchasing and production can reference the same approved order basis.

    Limitations and risks

    ETO CPQ is not a shortcut around product governance or engineering complexity. Its effectiveness is limited by the quality and scope of the product model.

    • Incomplete rules: Undocumented engineering knowledge still produces manual review and order risk.
    • Rule explosion: A large number of exceptions can make the model difficult to test and maintain.
    • Unbounded customization: A product that is effectively redesigned for every customer may not be suitable for full automation.
    • Unreliable source data: Incorrect costs, item identifiers, dimensions or revisions undermine every downstream output.
    • Integration complexity: Different systems may use different item structures, units, revisions and approval states.
    • False confidence: A configuration can be logically valid while still requiring engineering judgment, regulatory review or site verification.
    • Maintenance burden: Product changes, supplier substitutions and manufacturing changes must be reflected in rules and outputs.

    A useful design principle is to automate repeatable decisions and expose uncertain decisions for controlled human review. The system should show why an option is unavailable, which assumption produced a result and what remains unapproved.

    Implementation approach

    Start with a bounded product family

    Select a product family with meaningful configuration volume, recurring engineering work and reasonably stable rules. Avoid beginning with the entire catalog or with a product whose design process is still changing rapidly.

    Document the decision model

    Work with sales engineering, design engineering, manufacturing, costing and IT to document inputs, constraints, calculations, outputs and exceptions. Identify rules that are mandatory, advisory or subject to approval.

    Define data ownership

    Decide whether CPQ, ERP, PLM, PDM or another system owns items, descriptions, revisions, costs, BOMs, CAD files and manufacturing structures. Define how approved data moves between systems.

    Separate reusable logic from customer-specific data

    Product rules and approved templates should not be mixed indiscriminately with customer notes or project assumptions. This separation makes the model easier to govern and reuse.

    Test engineering edge cases

    Testing should include valid standard configurations, invalid combinations, boundary values, unit conversions, unavailable components, obsolete items, manual overrides, revision changes and integration failures. Test the generated quote, BOM, CAD request and ERP transaction—not only the screen flow.

    Establish release governance

    Assign owners for product rules, calculations, pricing, item data, templates and integrations. Use version control, approval status and change-impact analysis. A product change that affects a seal, motor, material or regulatory requirement may affect configuration rules, costs, CAD and production data simultaneously.

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

    How to evaluate ETO CPQ software

    Manufacturers should evaluate an ETO-capable CPQ platform against actual product and engineering scenarios rather than generic feature counts. Ask vendors to demonstrate:

    • multi-level product models and reusable rules;
    • dimensional, capacity and compatibility constraints;
    • unit handling and engineering calculations;
    • configuration statuses and human approval steps;
    • configurable BOM expansion and EBOM or MBOM handoff;
    • CAD parameters, drawing requests or documented CAD integrations;
    • cost and price separation;
    • revision and change-control behavior;
    • ERP, PLM, PDM, CRM and CAD integration patterns;
    • API availability and error handling;
    • performance with large product models;
    • rule testing, audit trails and model governance;
    • support for dealer, distributor and internal engineering users;
    • handling of configurations that exceed the approved product model.

    Ask the vendor to identify which capabilities are native, which require configuration, which depend on partner or external systems, and which are not supported. A product configurator, quoting tool and engineering automation platform may be combined in one product or implemented as separate components.

    Practical example: engineer-to-order pump package

    Consider a manufacturer quoting a pump package for a chemical-processing site. The customer provides flow, differential pressure, fluid temperature, fluid properties, hazardous-area requirements, voltage, materials, instrumentation and delivery conditions.

    1. CPQ captures the structured requirements and checks units and required fields.
    2. A selection or calculation service identifies suitable pump families and motor ranges.
    3. Rules require compatible casing, impeller, seal, motor, controls and hazardous-area components.
    4. The product model identifies standard components and flags the custom base frame and piping arrangement for engineering.
    5. Costing includes purchased items, fabrication, engineering, testing and documentation.
    6. The quote records operating assumptions, exclusions and the technical approval status.
    7. After acceptance, the approved configuration and calculation results create an engineering work package.
    8. Engineering produces or approves the design, while PLM or PDM controls drawings and revisions.
    9. ERP receives the order and the appropriate product, BOM, purchasing and production information.

    In this example, CPQ does not need to pretend that every design decision is automated. Its value is to validate what can be validated, preserve the requirements, identify the engineering boundary and prevent the approved commercial configuration from being lost during handoff.

    Semantic map

    The following relationships summarize how ETO CPQ connects commercial, engineering and manufacturing concepts:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations validate application requirements.
    • A configured product generates or drives a configurable BOM.
    • A configurable BOM can produce an EBOM or provide inputs to one.
    • An EBOM can be transformed into an MBOM for production.
    • CAD automation generates product-specific models or drawings.
    • CPQ exchanges customer and order data with CRM.
    • CPQ exchanges items, orders and BOM data with ERP.
    • PLM manages product structures, revisions and lifecycle status.
    • PDM controls CAD files and engineering documents.
    • ETO requires customer-specific engineering.
    • CTO uses approved configuration options.
    • Pricing converts cost and commercial rules into a customer price.
    • An approved quote becomes an order baseline for engineering and production.

    Frequently asked questions

    1. What does CPQ mean in engineer-to-order manufacturing?

    CPQ means configure, price, quote. In ETO manufacturing, it captures technical requirements, validates selections, supports calculations and produces a controlled quote and engineering handoff.

    2. Can CPQ replace engineering in an ETO business?

    No. CPQ can automate repeatable decisions and route exceptions, but engineering judgment remains necessary for new designs, unusual conditions, compliance and final approval.

    3. Does every CPQ system support engineer-to-order workflows?

    No. Some products focus on sales configuration and quoting. Buyers must verify support for calculations, approvals, BOMs, CAD, revisions, engineering handoff and relevant integrations.

    4. How does ETO CPQ differ from configure-to-order CPQ?

    Configure-to-order generally selects from approved product options. ETO CPQ must also capture requirements, manage customer-specific design work and control the transition from quote to engineering.

    5. Can CPQ generate a manufacturing BOM?

    Some systems can generate or expand BOMs, while others send configuration data to ERP or PLM. The buyer must verify whether the system creates an EBOM, MBOM, configurable BOM or only BOM instructions.

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

    An EBOM represents the designed product structure. An MBOM represents how the product is assembled or manufactured. They may contain related but differently organized information.

    7. Can CPQ automate CAD for custom products?

    Some CPQ solutions support CAD parameters, model generation or drawing workflows through native or external tools. A visual configurator alone does not prove production CAD automation.

    8. What engineering calculations can ETO CPQ perform?

    Depending on the platform and implementation, calculations may cover sizing, capacity, pressure, power, loading, dimensions, materials or compatibility. Each calculation must be validated for its intended engineering use.

    9. How does CPQ handle a requirement outside the product model?

    It may reject the input, flag an exception, route the opportunity for engineering review or create a new design task. The correct behavior depends on company policy and product risk.

    10. Should CPQ own product data or should PLM own it?

    Ownership varies. CPQ commonly owns configuration and quote logic, while PLM owns product structures and lifecycle data. The architecture must explicitly define ownership and synchronization.

    11. Is ERP integration required for ETO CPQ?

    It is not technically mandatory, but integration is often important for item data, costs, sales orders, purchasing, inventory, BOMs and production planning.

    12. What role does CRM play in an ETO workflow?

    CRM typically provides account, opportunity and customer context. CPQ adds technical configuration and commercial calculation, then returns quote status and value to CRM.

    13. Can CPQ calculate the price of engineering effort?

    Yes, if engineering effort is modeled through estimated hours, task types, rates, complexity factors or project rules. The resulting estimate should be distinguished from actual labor recorded later.

    14. How should manufacturers test an ETO CPQ model?

    Test standard, boundary, invalid and exceptional configurations, along with calculations, prices, revisions, BOM outputs, CAD requests and system integration failures.

    15. What data is needed to implement ETO CPQ?

    Typical inputs include product options, rules, dimensions, materials, item masters, costs, prices, engineering formulas, BOM structures, CAD templates, approval policies and integration identifiers.

    16. Can one CPQ system support both CTO and ETO?

    Potentially. A product family can use automated CTO paths for approved variants and route more complex selections into ETO review. The platform must support different statuses and workflows.

    17. How does CPQ reduce sales-to-engineering errors?

    It replaces ambiguous manual descriptions with structured requirements, validated selections, explicit assumptions, revision information and reusable order data.

    18. What is the biggest implementation risk?

    A common risk is automating an incomplete or poorly governed product model. The software cannot reliably compensate for undocumented rules, inconsistent item data or unclear engineering ownership.

    19. Should every ETO exception be automated?

    No. Automation is appropriate for repeatable and well-understood decisions. Novel, high-risk or poorly bounded designs should remain subject to controlled human review.

    20. What should a manufacturer ask during a CPQ demonstration?

    Use a real product scenario and ask the vendor to show requirements capture, constraints, calculations, costing, quote revision, engineering review, BOM output, integration behavior and handling of an out-of-model request.

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

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

    The basic flow is:

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

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

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

    What is a BOM in CPQ?

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

    A typical BOM line may contain:

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

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

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

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

    How BOM generation fits into the CPQ architecture

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

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

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

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

    From customer selections to a configured BOM

    1. Capture requirements and configuration inputs

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

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

    2. Validate the configuration

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

    There are several related approaches:

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

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

    3. Resolve components and quantities

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

    For example, selecting a dual-pump skid might:

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

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

    4. Apply calculations and attributes

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

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

    5. Calculate cost and price

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

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

    6. Produce the quote and route approvals

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

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

    EBOM, MBOM and configurable BOM

    Manufacturers should distinguish among several BOM concepts.

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

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

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

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

    Manufacturing examples

    Industrial pump configuration

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

    The configuration model can validate that:

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

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

    HVAC equipment

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

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

    Specialty vehicle

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

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

    How BOM data supports costing and pricing

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

    Costing inputs

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

    Pricing inputs

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

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

    BOMs and CAD, PLM and ERP integration

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

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

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

    Important integration questions include:

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

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

    CTO, ETO, MTO and ATO BOM workflows

    BOM behavior depends on the manufacturing strategy.

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

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

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

    Benefits of BOM-driven CPQ

    More accurate configuration and pricing

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

    Faster sales-to-engineering handoff

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

    Better visibility of scope

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

    Improved approval control

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

    Reusable product knowledge

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

    Limitations and risks

    A commercial BOM may not be production-ready

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

    Product models become difficult to maintain

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

    Data synchronization is complex

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

    Engineering calculations require validation

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

    Variant explosion can affect performance

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

    Quote and order revisions can diverge

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

    Implementation guidance

    Define the purpose of the BOM first

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

    Establish data ownership

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

    Model the product before copying spreadsheets

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

    Use stable identifiers

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

    Test combinations, not just individual rules

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

    Define release states

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

    Measure operational outcomes

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

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

    What to ask CPQ vendors about BOM capability

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

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

    Semantic map

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

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

    Frequently asked questions

    What does BOM mean in CPQ?

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

    Does every CPQ system generate a BOM?

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

    How does CPQ create a BOM?

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

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

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

    Is a CPQ BOM the same as an EBOM?

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

    Is a CPQ BOM the same as an MBOM?

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

    Can BOM data be used to calculate price?

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

    Can CPQ calculate manufacturing cost?

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

    How does configuration affect the BOM?

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

    What is an example of a BOM rule?

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

    Can CPQ generate a CAD model from a BOM?

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

    How does CPQ support engineer-to-order products?

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

    What happens when an item changes in ERP?

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

    Can a BOM appear on the customer quote?

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

    How does a BOM affect quote approvals?

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

    What BOM data should CPQ send to ERP?

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

    Why are BOM revisions important in CPQ?

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

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

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

    How should manufacturers test BOM generation?

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

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

  • Quote Automation for Complex Manufactured Products

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

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

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

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

    What quote automation means in manufacturing

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

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

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

    How automated quoting works

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

    1. Capture customer requirements

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

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

    2. Select and validate the product configuration

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

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

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

    3. Perform engineering calculations

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

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

    4. Generate a product structure or BOM

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

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

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

    5. Calculate cost

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

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

    6. Apply pricing and commercial rules

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

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

    7. Route exceptions and approvals

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

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

    8. Generate the quote document

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

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

    Reference architecture for manufacturing quote automation

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

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

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

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

    Manufacturing example: quoting a configured industrial pump

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

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

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

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

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

    Where quote automation fits different manufacturing workflows

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

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

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

    Benefits of quote automation for manufacturers

    Shorter response cycles

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

    Fewer configuration and pricing errors

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

    Better engineering capacity

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

    More consistent manufacturing data

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

    Improved margin visibility

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

    Traceable decisions

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

    Limitations and risks

    Incorrect product models produce repeatable errors

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

    Engineering knowledge is difficult to encode

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

    Cost data may not be current

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

    BOM maturity may be misunderstood

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

    ETO remains partially manual

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

    Integration creates operational dependencies

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

    Rules can become difficult to maintain

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

    Data required for automated quoting

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

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

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

    Implementation approach

    Define the first product scope

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

    Document the current quote process

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

    Build a governed product model

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

    Separate configuration, cost and price

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

    Design the system handoff

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

    Test combinations and revisions

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

    Release and govern the model

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

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

    How to evaluate quote automation software

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

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

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

    Key measures after deployment

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

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

    Related concepts

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

    Semantic map

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

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

    Frequently asked questions

    What is quote automation for complex manufactured products?

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

    How is manufacturing quote automation different from sales CPQ?

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

    Does quote automation generate a BOM?

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

    Can CPQ calculate the cost of a configured product?

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

    What is the difference between costing and pricing in CPQ?

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

    Can quote automation handle engineer-to-order products?

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

    Can a CPQ system create CAD drawings?

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

    What product data is needed to automate quotes?

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

    Where should configuration rules be maintained?

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

    How does quote automation connect with ERP?

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

    Does quote automation replace application engineers?

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

    How are invalid configurations prevented?

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

    Can quote automation manage different currencies and customer prices?

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

    What is a configurable BOM?

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

    How should manufacturers test an automated quoting model?

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

    What are the main risks of automated quoting?

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

    How should a manufacturer choose a quote automation platform?

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

    What is the first product family to automate?

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

    How can a manufacturer measure quote automation success?

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

  • Product Bundles and Solution Pricing in Manufacturing CPQ

    Product bundles and solution pricing in manufacturing CPQ allow a company to quote a complete engineered solution rather than pricing isolated parts. A bundle may combine a base machine, drive system, control panel, safety equipment, installation accessories and service coverage. The CPQ system validates whether the selected components work together, calculates costs and prices, produces the relevant bill of materials (BOM), routes exceptions for approval and generates a customer-ready quote.

    In this context, CPQ means configure, price, quote. Manufacturing CPQ extends beyond generic sales quoting: it can connect product rules and engineering calculations to configurable BOMs, computer-aided design (CAD) outputs, enterprise resource planning (ERP), product lifecycle management (PLM) and production processes. Not every CPQ platform supports all of these capabilities, so manufacturers must verify the depth of product modeling, bundle logic, costing, downstream integration and engineering automation before selecting a system.

    A useful starting point is the guide to CPQ software for manufacturing. For the specific product-modeling foundation, see product configuration, and for the downstream commercial and manufacturing data flow see BOM, pricing and quoting.

    What are product bundles and solution pricing?

    A product bundle is a commercially and technically related group of products, assemblies, options, services or consumables sold as one solution. A bundle can be fixed, configurable or partially configurable. A fixed bundle always contains the same items. A configurable bundle allows choices such as capacity, material, voltage, motor, enclosure, accessories or service level. A solution bundle can also include multiple related products that must be engineered or delivered together.

    Solution pricing is the calculation of a price for the complete configured solution rather than simply adding unrelated item prices. It may include component prices, configuration-dependent costs, engineering effort, labor, freight, installation, warranty, risk margins, discounts and commercial adjustments.

    For example, a pump manufacturer might sell a chemical-transfer package containing:

    • a centrifugal pump selected by flow rate, head and fluid compatibility;
    • a motor selected by power, voltage and hazardous-area requirements;
    • a baseplate and coupling guard;
    • valves, strainers and instrumentation;
    • a control panel and variable-frequency drive;
    • documentation, testing and commissioning services.

    The bundle is not valid merely because every item exists in the catalog. The motor must match the pump duty, the materials must be compatible with the fluid, the control panel must support the selected voltage and the enclosure may need to meet a specified environmental or hazardous-location rating. The final price must reflect the resulting engineering and manufacturing requirements.

    How bundles differ from simple product kits

    Manufacturers should distinguish a commercial bundle from a manufacturing kit, sales package or configured solution. The terms are sometimes used interchangeably, but they can represent different data and operational behavior.

    Concept Meaning in manufacturing Typical CPQ requirement
    Fixed bundle A predefined group of items sold together. Bundle definition, price and component availability.
    Configurable bundle A package with selectable options and dependencies. Rules, constraints, option pricing and validation.
    Solution A combination of products, assemblies, services and engineering work that addresses a customer requirement. Cross-product compatibility, calculations, approvals and often project-level pricing.
    Kit A set of parts grouped for picking, assembly or delivery. Kit structure, inventory behavior and possibly a configurable BOM.
    Package or system A technically integrated equipment group delivered as a functional unit. System rules, interfaces, engineering outputs and production handoff.

    A simple sales bundle may only add several stock items to a quote. A manufacturing solution model may need to create a new assembly structure, select engineered components, calculate dimensions and send data to ERP or PLM. The implementation should therefore define whether the bundle is only a commercial construct, a manufacturing structure, or both.

    How manufacturing CPQ models a bundle

    A bundle model normally contains a hierarchy of products and assemblies. At the top is the solution or package. Under it are mandatory components, optional modules, substitution groups, accessories, services and engineering outputs.

    Bundle structure

    A typical industrial equipment bundle might be modeled as follows:

    • Solution: packaged water-treatment skid.
    • Primary equipment: pump, tank, filter and heat exchanger.
    • Drive and controls: motor, variable-frequency drive, panel and sensors.
    • Mechanical integration: frame, piping, fittings, guards and supports.
    • Commercial options: extended warranty, spare-parts kit, commissioning and training.
    • Engineering outputs: configured BOM, specification sheet, layout drawing and installation requirements.

    Each node can have attributes, valid values, quantities, dependencies, costs, prices and fulfillment behavior. A component may be included automatically when another option is selected. For example, selecting a high-temperature application may require a different seal material, insulation package and temperature-rated sensor.

    Rules and constraints

    Rules-based configuration uses explicit conditions such as “if voltage is 480 V, use a 480 V control package.” Constraint-based configuration evaluates permitted relationships and limits, such as motor power, shaft speed, flow, pressure and enclosure requirements. Guided selling asks questions in a sequence that helps a user reach a valid configuration, but it may not provide the same depth of technical constraint solving.

    A bundle model may contain several types of rules:

    • Inclusion rules: selecting a fire-rated enclosure adds a fire-rated door assembly and approved cable glands.
    • Exclusion rules: two incompatible communication modules cannot be selected together.
    • Dependency rules: a remote monitoring option requires a gateway and a suitable network connection.
    • Quantity rules: a long conveyor requires additional supports at defined intervals.
    • Calculation rules: pump size, motor rating, material thickness or cable size is calculated from technical inputs.
    • Approval rules: a nonstandard material, discount or delivery commitment requires review.

    Detailed guidance on product options, dependencies and validation is available in the product configuration guide.

    Solution pricing architecture

    Solution pricing should separate the different reasons why a price changes. This makes the model easier to test, explain and maintain.

    Pricing layer Examples Manufacturing considerations
    Component price Pump, motor, valve or panel list price. Item revisions, currencies, units and effective dates.
    Option price Stainless-steel construction, upgraded controls or additional sensors. May replace a standard component rather than add to it.
    Quantity price Additional conveyors, filters or spare parts. Quantity may be calculated from dimensions or capacity.
    Configuration surcharge Special coating, hazardous-area compliance or nonstandard testing. Should be tied to a clear technical trigger.
    Engineering price Application engineering, design work or custom documentation. Often depends on ETO complexity and approval.
    Service price Installation, commissioning, training or maintenance. May depend on site, duration, travel and scope.
    Commercial adjustment Customer discount, dealer margin or project-level adjustment. Requires authority limits, approval thresholds and auditability.

    The price engine may calculate a list price, net price, cost, gross margin and price explanation. A manufacturer should preserve the distinction between cost and price. Cost may include purchased components, labor, overhead, freight and engineering effort. Price is the amount offered to the customer after margins, discounts and commercial policies are applied.

    Bundle pricing strategies

    Several pricing approaches can be combined:

    • Component aggregation: add the prices of all selected items and services.
    • Bundle price: assign a defined price to a valid combination.
    • Replacement pricing: subtract the standard component and add the upgraded component.
    • Tiered pricing: apply different prices based on quantity, capacity or order volume.
    • Formula pricing: calculate price from dimensions, power, material weight or processing time.
    • Cost-plus pricing: apply a margin or markup to calculated cost.
    • Project pricing: combine equipment, services, risk allowances and commercial terms at solution level.

    Pricing rules should also handle effective dates, currencies, units of measure, regional price lists, customer-specific agreements and channel margins. If the CPQ price differs from ERP or finance data, the integration must define which system is authoritative for each value.

    From configured bundle to BOM

    A configured solution can generate one or more BOM structures. A configurable BOM represents possible components and selection logic before a customer configuration is finalized. An engineering BOM (EBOM) represents the product from an engineering and design perspective. A manufacturing BOM (MBOM) represents how the product is assembled and produced. These structures may be related but are not interchangeable.

    For a packaged machine, CPQ might generate:

    • a quote-level commercial BOM showing customer-visible assemblies;
    • an EBOM for engineering review and design release;
    • an MBOM or ERP order structure for purchasing, routing and production;
    • a spare-parts list and service BOM for after-sales use.

    Whether CPQ directly creates an EBOM or MBOM depends on the platform architecture and integration design. Some systems produce a structured order configuration that ERP, PLM or a product data management (PDM) system transforms into the appropriate downstream structure. Others can generate production-relevant BOM lines directly. This capability must be verified rather than assumed.

    For a deeper treatment of BOM structures and quote generation, see BOM, pricing and quoting in manufacturing CPQ.

    Relationship with CAD and engineering automation

    Bundles become more valuable when technical selections drive engineering outputs. A CPQ platform may pass configuration parameters to CAD automation, a rules-based design service or a separate engineering application. Possible outputs include a parametric 3D model, 2D drawing, dimensional specification, load calculation or equipment layout.

    For example, a conveyor solution may use belt width, length, incline angle, product weight and throughput to determine frame sections, drive power, support spacing and guarding. The resulting dimensions can affect both the BOM and the price. If the system only changes the quote description without updating engineering data, the bundle is commercially configured but not fully engineered.

    CAD automation is not a universal CPQ feature. Manufacturers should verify whether a prospective system can:

    • store or calculate the parameters required by the CAD model;
    • call an external CAD or engineering service;
    • generate drawings or neutral files;
    • maintain revision and approval status;
    • return calculated dimensions and components to the CPQ model;
    • handle failures, incomplete inputs and manual engineering review.

    The CAD and engineering automation guide explains how these capabilities fit beside configuration and quoting.

    Approvals and commercial governance

    Solution pricing often creates approval requirements that do not exist for standard products. Approval triggers may include a margin below threshold, an unusual payment term, a nonstandard material, a custom delivery date, a safety-critical application or a large engineering commitment.

    A practical approval workflow should show:

    1. which rule or threshold triggered the approval;
    2. what cost, price, margin or technical value is affected;
    3. which person or role must review the exception;
    4. whether the approval changes the configuration, price or terms;
    5. which version of the configuration and pricing model was approved.

    Approvals should not be used to compensate for missing product rules. If sales repeatedly requests approval for a combination that is always valid, the product model may need a new rule or standard option. Conversely, an approval should not override a genuine safety or technical constraint without a controlled engineering process.

    Quote documents for bundled solutions

    The quote should communicate enough detail for the customer to understand the proposed solution without exposing internal manufacturing structures unnecessarily. A bundle quote may contain:

    • solution summary and application assumptions;
    • selected equipment and major options;
    • technical specifications and exclusions;
    • commercial price by system, assembly or service category;
    • delivery, installation and commissioning scope;
    • warranty, payment and validity terms;
    • drawings, rendered views or preliminary layouts where available;
    • approval notes and revision information.

    Customer-facing descriptions and internal BOM descriptions should be governed separately. A sales quote might describe “stainless-steel product-contact construction,” while the internal structure contains specific grades, fasteners and purchased parts. Both representations must remain linked to the same approved configuration.

    Enterprise-system relationships

    Bundle pricing normally involves several systems with different responsibilities.

    System Typical responsibility Example exchange with CPQ
    CRM, or customer relationship management Accounts, opportunities, contacts and sales activity. Opportunity context, customer and quote status.
    ERP, or enterprise resource planning Items, inventory, purchasing, orders, finance and production transactions. Item masters, costs, orders, availability and order structures.
    PLM, or product lifecycle management Product revisions, engineering releases, change control and lifecycle data. Released options, revisions, EBOMs and engineering status.
    PDM, or product data management CAD files, drawings and design metadata. CAD references, revisions and generated design files.
    CAD Geometry, drawings and design calculations. Parameters, models, layouts and drawings.
    PIM, or product information management Descriptions, attributes, media and channel content. Customer-facing product information and option content.
    MES, or manufacturing execution system Shop-floor execution, work instructions and production status. Released orders, routings or configuration-specific instructions.

    These systems are not interchangeable. A CPQ platform may own the selling configuration and calculated quote, while ERP owns the order and financial transaction. PLM may own engineering revisions, and CAD or PDM may own design files. The integration architecture should document ownership, synchronization frequency, identifiers, revision behavior and error handling. More guidance is available in CPQ integrations for manufacturing.

    Bundle workflows by manufacturing strategy

    Bundles can support several operating models, but the required depth differs.

    • Assemble-to-order (ATO): standard modules are assembled after the order. CPQ must select compatible modules and produce an order structure.
    • Make-to-order (MTO): the product is made after the order using a relatively standard design. Pricing, availability and production data are central.
    • Configure-to-order (CTO): customers select from predefined options and constraints. A valid configuration can usually map to known BOM and routing patterns.
    • Engineer-to-order (ETO): the order requires new or materially changed engineering. CPQ must capture requirements, estimate engineering work and hand off controlled inputs for design.

    A bundle can begin as CTO and become ETO when a customer requests a nonstandard capacity, interface or material. The system should make that transition explicit rather than pretending every solution is a standard configuration. See manufacturing CPQ workflows for related order-to-production patterns.

    Benefits and limitations

    Potential benefits

    • Fewer incompatible combinations reach the customer or engineering team.
    • Prices reflect selected options, calculated quantities and engineering scope.
    • Sales engineers can quote complete solutions with less manual spreadsheet work.
    • Configured BOM data can reduce re-entry between sales, engineering and ERP.
    • Approval decisions become traceable and tied to configuration and margin data.
    • Quote documents can present consistent technical and commercial information.

    Important limitations

    • A CPQ model is only as accurate as its product, cost and rule data.
    • Complex engineering calculations may require specialist applications or manual review.
    • Dynamic pricing can become difficult to maintain if formulas are undocumented.
    • Different BOM structures may require transformation between CPQ, PLM and ERP.
    • Frequent product changes create governance and regression-testing demands.
    • Large bundles can produce performance, usability and version-control challenges.
    • Commercial bundling does not automatically solve inventory, capacity or scheduling constraints.

    Implementation approach

    A successful implementation starts with a defined scope rather than attempting to model every product and exception at once.

    1. Select a representative bundle: choose a product family with meaningful configuration, pricing and downstream impact.
    2. Map the current workflow: document how requirements, options, costs, approvals, BOMs, drawings and orders move between teams.
    3. Define system ownership: identify where items, costs, prices, rules, revisions, CAD files and customer data are maintained.
    4. Separate standard and engineered content: mark which choices are CTO-valid and which trigger ETO review.
    5. Build the product model: create attributes, options, dependencies, constraints, calculations and bundle structures.
    6. Design the price model: define cost sources, price lists, formulas, discounts, margins, currencies and approval thresholds.
    7. Define output structures: specify quote lines, configurable BOMs, EBOM or MBOM mappings, drawings and ERP order data.
    8. Test realistic scenarios: include valid, invalid, boundary, obsolete, partially specified and exception configurations.
    9. Establish governance: assign rule ownership, release procedures, version control, audit records and change-impact testing.
    10. Measure operational results: track quote cycle time, configuration corrections, approval delays, engineering rework and order-data errors.

    Implementation planning should include data migration, integration testing, user adoption and ongoing maintenance. The manufacturing CPQ implementation guide covers these concerns in more detail.

    Evaluation checklist for manufacturing buyers

    When evaluating CPQ software for bundled industrial solutions, ask vendors to demonstrate a complete scenario rather than isolated features:

    • Can the system model nested bundles, substitutions and cross-product dependencies?
    • Can technical constraints prevent invalid combinations before quote submission?
    • Can calculated dimensions, capacities or quantities affect both BOM and price?
    • Can the system distinguish customer-visible bundle lines from internal component structures?
    • Can it calculate cost, margin, price and discount independently?
    • Can approval rules identify technical, commercial and engineering exceptions?
    • Can it produce the required quote, specification, BOM or order outputs?
    • Which capabilities are native, and which require custom development or external services?
    • How are product revisions, effective dates and obsolete options governed?
    • How are ERP, CRM, PLM, PDM, CAD, PIM and MES integrations implemented and monitored?
    • Can the model support dealer, distributor, internal sales engineering and customer self-service channels?
    • How are failed calculations, integration errors and incomplete ETO requirements handled?

    Vendor profiles and comparisons can help structure research, but manufacturers should validate documented capabilities through a scenario-based demonstration and technical proof of concept. See manufacturing CPQ software profiles and CPQ comparison and selection guidance.

    Semantic map

    The following relationships summarize how product bundles connect configuration, pricing, engineering and manufacturing execution:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Product bundles combine products, assemblies and services.
    • Solution pricing calculates a commercial price for a configured solution.
    • Configured products generate configurable BOMs.
    • Engineering rules determine component compatibility.
    • Cost calculations inform solution pricing.
    • Approval rules govern commercial and technical exceptions.
    • CAD automation generates product-specific drawings.
    • EBOMs represent engineering product structures.
    • MBOMs represent manufacturing assembly structures.
    • CPQ exchanges item and order data with ERP.
    • CPQ exchanges revisions and released structures with PLM.
    • CRM provides opportunity and customer context to CPQ.
    • ETO requirements trigger engineering review.
    • Quote documents communicate approved solution scope.

    Frequently asked questions

    1. What is a product bundle in manufacturing CPQ?

    A product bundle is a group of related equipment, components, options and services sold as one configurable solution. It may also produce a structured BOM for engineering or production.

    2. How is solution pricing different from adding item prices?

    Solution pricing can include compatibility-driven substitutions, calculated quantities, engineering effort, services, risk allowances, discounts and project-level approvals in addition to component prices.

    3. Can a bundle contain products from different product families?

    Yes. A pump package, for example, may contain a pump, motor, valves, controls, piping and services. Cross-family rules must validate interfaces, capacities, materials and electrical requirements.

    4. Does every CPQ system generate a BOM?

    No. Some CPQ platforms generate quote lines or order configurations only. Others generate configurable BOMs or integrate with ERP and PLM to create downstream structures. This must be verified for each product.

    5. What is a configurable BOM?

    A configurable BOM describes possible components and selection logic before a specific customer configuration is finalized. It differs from an EBOM or MBOM, which represent engineering or manufacturing structures.

    6. Can CPQ generate an EBOM?

    Some systems can generate or export engineering-oriented structures, while others pass configuration data to PLM or engineering tools. The supported revision, release and transformation process should be documented.

    7. Can CPQ generate an MBOM?

    Some platforms or integrations can create manufacturing-relevant structures, but this is not universal. ERP or manufacturing systems may own the MBOM and transform data received from CPQ or PLM.

    8. How do bundle rules prevent configuration errors?

    Rules enforce inclusions, exclusions, dependencies, quantities, technical limits and required approvals. They can prevent incompatible motors, materials, controls or accessories from reaching the quote.

    9. What happens when a bundle requires custom engineering?

    The configuration can be routed to an ETO workflow. CPQ may capture requirements, estimate engineering effort, flag assumptions and hold the quote for engineering review.

    10. Can solution pricing include installation and commissioning?

    Yes. Services can be modeled as bundle components or calculated charges. The model may use site conditions, duration, travel, labor rates and scope assumptions.

    11. How should costs and prices be separated?

    Costs represent internal or supply-side economic inputs such as materials, labor and engineering. Prices are customer charges after margins, discounts, terms and commercial policies are applied.

    12. Can bundle pricing vary by customer or region?

    It can, provided the pricing model supports customer agreements, regions, currencies, channels, effective dates and approval controls. The authoritative source for each price should be defined.

    13. Is CAD automation required for manufacturing bundles?

    No. Many bundles can be quoted without automated CAD. CAD automation becomes important when selections change geometry, dimensions, drawings, layouts or engineering calculations.

    14. How does CPQ connect bundles to ERP?

    Depending on the architecture, CPQ may exchange item identifiers, prices, configuration data, BOM lines, customer information and order details with ERP. Ownership and error handling must be designed explicitly.

    15. How does PLM differ from ERP in a bundle workflow?

    PLM generally manages product revisions, engineering releases and lifecycle data. ERP manages transactions such as purchasing, inventory, costing, orders and production. Both may receive different outputs from CPQ.

    16. Can distributors use manufacturing CPQ bundles?

    Yes. A dealer or distributor channel can use a controlled bundle model with permitted options, channel pricing, customer-specific discounts and quote outputs while protecting technical rules.

    17. What approval triggers are common for solution pricing?

    Common triggers include low margin, unusual discounts, nonstandard materials, safety-sensitive applications, custom delivery commitments, large engineering effort and exceptional commercial terms.

    18. How should bundle models be tested?

    Test valid and invalid combinations, boundary values, substitutions, obsolete options, price changes, revision changes, incomplete requirements, integration failures and ETO escalation paths.

    19. What is the main limitation of a bundle model?

    It can become difficult to maintain when rules, prices, BOM mappings and engineering exceptions are undocumented or owned by different teams without coordinated governance.

    20. What should manufacturers ask during a CPQ demonstration?

    Ask the vendor to configure a realistic multi-product solution, apply technical rules, calculate cost and price, trigger an approval, generate the required BOM and quote, and show the ERP, PLM or CAD handoff.

  • Price Books and Product Configuration in Manufacturing CPQ

    In manufacturing CPQ, a price book is a controlled set of prices, discounts, surcharges, costs, currencies and commercial conditions that a Configure, Price, Quote (CPQ) system applies to a valid product configuration. Product configuration determines what can be sold; the price book determines how that valid configuration is valued for a particular market, customer, channel or date.

    The two functions must work together. A configured industrial pump may require a specific motor, seal, impeller material and control panel. Configuration rules confirm that the combination is technically valid. The price book then assigns prices to the selected options, applies quantity or customer terms, adds engineering or freight charges where appropriate and produces a quote. In manufacturing CPQ, the same configuration may also generate a bill of materials (BOM), engineering outputs and data for enterprise systems.

    This is different from a generic sales CPQ application that simply selects products from a catalogue and applies discounts. Manufacturing price management often depends on dimensions, materials, capacity, regional conditions, production costs, engineering effort and downstream manufacturing data.

    What is a price book in manufacturing CPQ?

    A manufacturing CPQ price book is a structured pricing model containing the commercial values and rules used to price products and options. It can include base prices, component prices, calculated prices, customer-specific prices, channel discounts, minimum margins, validity dates, currencies, taxes, freight, installation and non-recurring engineering charges.

    A price book is not the product model itself. The product model defines products, features, options, dependencies and constraints. The price book references those product elements and supplies monetary values or pricing logic.

    Element Primary question Manufacturing example
    Product model What can be configured? Which pump sizes, materials and seal types are compatible?
    Configuration rules Which combinations are valid? A high-temperature seal is required for a specified fluid temperature.
    Price book What should the valid configuration cost or sell for? A stainless-steel casing adds a defined amount or uses a calculated rate.
    Cost model What does the manufacturer expect to spend? Material, labor, machining and purchased-component costs.
    Quote document How is the commercial offer presented? Line items, options, terms, delivery assumptions and totals.

    How product configuration and price books work together

    The normal sequence is configuration first, pricing second, although the user interface may show indicative prices while the product is being configured.

    1. Select a product family. A salesperson or dealer starts with a pump, conveyor, switchgear assembly, industrial vehicle or other configurable product.
    2. Capture requirements. Inputs may include flow, pressure, voltage, load, dimensions, temperature, material, environment and required delivery date.
    3. Apply configuration rules. The CPQ system filters invalid options, recommends compatible choices or blocks combinations that cannot be engineered or manufactured.
    4. Resolve the configuration. The system records selected options, calculated values, quantities and any unresolved engineering questions.
    5. Calculate costs and prices. Price rules read the configuration and retrieve or calculate the values required for the commercial offer.
    6. Generate downstream outputs. Depending on the platform, CPQ may create a configurable BOM, engineering request, CAD output, order payload or ERP quote.
    7. Route approvals. Discounts, low margins, unusual terms, non-standard options or engineering effort can trigger approval workflows.
    8. Generate the quote. The final document presents the configured product, included and excluded items, price, delivery assumptions and commercial terms.

    The configuration result should be the shared reference for pricing, BOM generation and quoting. Re-keying selected options into a separate spreadsheet or ERP screen creates opportunities for discrepancies between what was quoted and what is eventually manufactured.

    See the detailed guide to product configuration and configuration rules for a deeper explanation of product models, dependencies and constraints.

    Price book architecture for configurable products

    Base product prices

    A base price represents a standard product or starting configuration. For example, a centrifugal pump family may have base prices for each frame size. The base price should have a clear scope: it may include a standard motor and coupling, or it may represent only the bare pump.

    Option and component prices

    Options can be priced as fixed additions, replacements, quantities or formula-driven values. A stainless-steel wetted-part package may add a fixed amount. A longer conveyor frame may be priced per metre. A larger motor may replace the standard motor rather than add its full list price.

    Formula-based pricing

    Some products cannot be priced accurately with a simple option table. Formula-based pricing can use dimensions, capacity, surface area, weight, power, material grade or production time. An enclosure might be priced from width, height, depth and material. A heat exchanger may require a calculation based on area and selected metallurgy.

    Formula inputs must be governed carefully. A pricing formula should not be used to approve a technically invalid configuration. Engineering rules validate the product; pricing formulas value the valid result.

    Customer, channel and market price books

    Manufacturers may maintain different commercial views for direct sales, distributors, original equipment manufacturers (OEMs), service partners or export markets. A price book can be selected by customer account, sales channel, territory, currency, contract or business unit.

    These variations should not create hidden product rules. A distributor discount may change the selling price, while a voltage option or material restriction belongs in the product model. Separating commercial rules from engineering rules improves maintenance and auditability.

    Effective dates and version control

    Price books normally require effective-from and effective-to dates. A quote created before a raw-material price increase may need to retain the earlier price, while a new quote uses the current book. Version control is particularly important when open opportunities, blanket orders and engineering revisions overlap.

    Pricing, costing and margins

    Pricing and costing are related but not identical. Costing estimates what the manufacturer expects to spend. Pricing determines what the customer is charged. A CPQ system may support one, both or neither in depth, so buyers should verify the documented capability.

    Calculation Typical inputs Purpose
    Material cost Material type, quantity, weight, waste and current rates Estimate direct material expenditure
    Purchased-part cost Supplier item, quantity, currency and procurement price Value motors, valves, drives and other bought-in parts
    Labor or process cost Operations, work centres, setup and run time Estimate manufacturing effort
    Engineering charge Design hours, review effort and non-standard requirements Recover ETO or application-engineering effort
    Sell price Cost, margin, market, customer terms and discount Produce the commercial offer

    A manufacturer may use a cost-plus model, target margin, price matrix, market price, contract price or a combination. For example, the cost of a custom mounting frame may be calculated from steel weight and fabrication hours, while the sell price is controlled by a product-family margin policy.

    Discounting should be applied after the system has established the applicable list or calculated price, unless the commercial model explicitly requires another sequence. Approval thresholds may use gross margin, absolute discount, total order value, contribution margin or deviation from an approved price corridor.

    How configuration affects BOM generation and quoting

    A valid configuration can drive a configurable BOM. A BOM is a bill of materials: the list of components, quantities and relationships required for a product. In manufacturing, it is important to distinguish an engineering BOM (EBOM), which describes the product from an engineering perspective, from a manufacturing BOM (MBOM), which organizes items and operations for production.

    CPQ may generate a sales or configured BOM that is later transformed into an EBOM or MBOM by PLM, ERP or manufacturing engineering systems. Other implementations may generate a production-ready structure directly. This depends on the product model, integration architecture and platform capability.

    For a configurable electrical cabinet, the selected enclosure size, breaker ratings, busbar arrangement, cable-entry position and accessories can determine:

    • which components appear in the configured BOM;
    • the quantity of breakers, terminals and cable glands;
    • the estimated material cost;
    • the description shown on the quote;
    • the engineering or panel-layout work required;
    • the data sent to ERP or a manufacturing system.

    Pricing and BOM logic should be coordinated but not conflated. A line item may be commercially bundled while remaining several manufacturing components. Conversely, a component can appear in the BOM without being shown as a separate quoted line.

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

    Rules that connect configuration to price

    Manufacturing CPQ commonly uses several types of rules. They solve different problems.

    Rule type Function Example
    Compatibility rule Prevents invalid combinations A motor voltage must match the selected control panel.
    Selection rule Adds or removes dependent options Selecting outdoor installation adds a weatherproof enclosure requirement.
    Calculation rule Derives a technical or commercial value Frame length is calculated from conveyor travel distance.
    Pricing rule Assigns or modifies a price A hazardous-area certification adds a defined surcharge.
    Approval rule Routes an exception for review A discount below the approved margin requires management approval.

    Rules should have clear ownership. Product engineering may own compatibility and technical calculations. Product management may own standard option structures. Finance or commercial operations may own discount policies and price-book governance. IT or a CPQ administrator may implement and test the rules, but should not become the only person who understands the product model.

    Illustrative example: pricing a configurable industrial pump

    Consider a pump configured for a chemical-processing application. The user selects flow rate, discharge pressure, casing material, impeller material, seal type, motor power, hazardous-area certification and control method.

    The configuration model may enforce the following:

    • the selected impeller must meet the required operating point;
    • the motor must provide sufficient power with an engineering margin;
    • the seal material must be compatible with the fluid and temperature;
    • hazardous-area certification requires an approved motor and terminal arrangement;
    • the selected control method must be compatible with the motor and drive;
    • some casing materials may be unavailable for the selected pressure class.

    After validation, the pricing engine can calculate the base pump price, material upgrades, motor price, seal package, certification surcharge, control-panel price, engineering charge and freight assumption. The configured BOM can include the casing, impeller, shaft, seal, motor, coupling, baseplate, instrumentation and documentation package.

    If the customer requests a non-standard operating point, the system may create an engineer-to-order (ETO) task rather than silently pricing the configuration as standard. The quote can show a provisional price or an allowance, with final approval required after engineering review.

    Quote documents and commercial transparency

    A quote document should make the relationship between configuration and price understandable without exposing unnecessary internal logic. Depending on the sales process, it may include:

    • configured product name and description;
    • key technical parameters and selected options;
    • included accessories and exclusions;
    • quantity, unit price and extended price;
    • discounts, surcharges, taxes and freight assumptions;
    • estimated lead time or delivery conditions;
    • engineering, installation, commissioning or documentation charges;
    • validity period and applicable terms;
    • approval notes or conditions for non-standard requirements.

    A customer-facing document should not imply that an engineering drawing, delivery date or certification is final if those items still require review. Quote templates need status indicators and carefully defined language for provisional configurations.

    Integration with ERP, CRM, PLM, PDM and CAD

    Each enterprise system has a different responsibility. Customer relationship management (CRM) software manages accounts, opportunities and sales activities. Enterprise resource planning (ERP) manages commercial transactions, inventory, purchasing, production and financial processes. Product lifecycle management (PLM) manages product structures, revisions and engineering lifecycle information. Product data management (PDM) commonly manages CAD files and related design data. Computer-aided design (CAD) systems create engineering models and drawings.

    CPQ can sit between customer requirements and these systems, but the exact boundary must be designed rather than assumed.

    System Potential exchange with CPQ
    CRM Opportunity, account, salesperson, quote status and commercial activity
    ERP Items, prices, customers, inventory context, orders, costs and financial data
    PLM Product revisions, approved structures, lifecycle status and engineering definitions
    PDM CAD documents, files, metadata and revision references
    CAD Parameters, model selections, drawings, layouts and design outputs
    MES Manufacturing execution data, operations or production instructions in selected architectures
    PIM Product descriptions, attributes and commercial content for channels

    Integration can be real-time, scheduled, event-driven or file-based. A price book may be mastered in CPQ, ERP or a dedicated pricing system. Product attributes may be mastered in PLM or PIM. Duplicating the same price and product rule in multiple systems creates version conflicts, so every important data element should have an identified system of record.

    See the guide to CPQ integrations with ERP, CRM, PLM, PDM, CAD and other systems.

    Manufacturing workflows: CTO, ETO, MTO and ATO

    Price-book design depends partly on the manufacturing strategy.

    • Configure-to-order (CTO): the customer selects from a controlled product model and the resulting configuration can be produced using known structures and processes.
    • Engineer-to-order (ETO): the sale triggers new or modified engineering work. Pricing may need engineering estimates, assumptions and later revision.
    • Make-to-order (MTO): production starts in response to an order, often using a defined product or configuration.
    • Assemble-to-order (ATO): standard modules are stocked or prepared and assembled after the order.

    In CTO and ATO, price books can often be relatively deterministic. In ETO, the price model may need allowances, engineering hours, risk factors, review stages and change control. A CPQ implementation should show where automated pricing ends and engineering quotation begins.

    Learn more about configure-to-order, engineer-to-order and related manufacturing workflows.

    Benefits of integrating price books with configuration

    • Faster quoting: sales engineers do not need to rebuild option prices manually for every valid configuration.
    • Fewer commercial errors: incompatible options, omitted accessories and incorrect replacement pricing are easier to control.
    • More consistent margins: discounts and surcharges can be evaluated against cost and policy.
    • Better engineering handoff: the selected configuration and assumptions accompany the quote.
    • Traceable BOM and price relationships: commercial line items can be connected to the components that drive cost.
    • Controlled regional and channel pricing: different books can be governed without cloning the entire product model.
    • More reliable quote documents: the document can be generated from the validated configuration rather than manually re-entered data.

    Limitations and implementation risks

    Connecting price books to a product configurator does not automatically produce accurate manufacturing prices. Common risks include:

    • Incomplete product data: missing option relationships or obsolete items lead to invalid configurations and inaccurate prices.
    • Ambiguous ownership: no team knows who approves price changes, engineering rules or product revisions.
    • Overly complex formulas: pricing logic becomes difficult to test and explain.
    • Duplicated masters: CPQ, ERP and spreadsheets contain different versions of prices or components.
    • Bundling problems: a customer-facing bundle hides manufacturing components needed for costing or production.
    • Unmanaged exceptions: sales teams use manual overrides for non-standard products without recording the reason.
    • Weak effective dating: old opportunities are repriced unintentionally after a new price release.
    • Insufficient testing: a price change fixes one product family but breaks a related configuration or channel.

    A price book should not be treated as a spreadsheet import alone. It is part of a governed product and commercial data model.

    Implementation approach

    1. Define the commercial and engineering scope

    Start with a limited product family and document the quote-to-order process. Identify which options are standard, which require engineering review and which are not currently supported.

    2. Map product and price data

    Inventory product families, option codes, units of measure, revisions, costs, price lists, currencies, discount schedules, customer agreements and quote templates. Identify duplicates and obsolete records before migration.

    3. Separate rule categories

    Document compatibility, selection, calculation, pricing and approval rules separately. This makes testing and ownership clearer.

    4. Establish systems of record

    Decide whether CPQ, ERP, PLM, PDM or another system owns each product, price, cost, customer and revision attribute. Define synchronization frequency and conflict handling.

    5. Model the BOM and quote views

    Specify which components are shown to the customer, which remain internal, how configurable BOMs map to EBOM or MBOM structures and how replacements, quantities and phantom assemblies are handled.

    6. Test combinations and commercial scenarios

    Test valid and invalid configurations, boundary dimensions, price-book dates, currencies, customer discounts, low-margin cases, engineering exceptions and revisions. Recalculate the same quote after a price release to confirm intended behavior.

    7. Govern releases

    Use controlled changes, approvals, effective dates and audit history. A price release should identify affected product families, customers, quotes and integrations. Product and commercial teams should be able to review changes without relying on undocumented code.

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

    How to evaluate a CPQ configurator for price-book use

    When evaluating a CPQ configurator, ask vendors and implementation partners to demonstrate a real manufacturing scenario rather than a simple catalogue discount. Useful tests include:

    • Can the system represent dependencies between dimensions, materials, motors and accessories?
    • Can a price be fixed, formula-based, quantity-based or derived from a replacement component?
    • Can different price books be selected by customer, channel, currency, region and effective date?
    • Can the system distinguish cost, list price, net price and margin?
    • Can a configuration generate a BOM or pass structured data to another system?
    • Can non-standard configurations be routed to engineering without being treated as standard?
    • Can users see why an option is unavailable or why approval is required?
    • Can rules and prices be tested independently and audited after release?
    • Can quote documents show technical selections and commercial conditions accurately?
    • What is documented for ERP, CRM, PLM, PDM, CAD and API integration?

    Do not assume that a platform offering price books also provides deep product configuration, CAD automation, BOM generation, engineering calculations or PLM integration. Verify each capability, its data requirements and the implementation responsibility.

    Semantic map

    Price books and product configuration form a connected manufacturing data chain: customer requirements lead to a validated product configuration; the configuration drives prices, costs and potentially BOM and CAD outputs; the resulting quote can move through approval into ERP, PLM, CRM or production workflows.

    • Product requirements connect to product configuration.
    • Product configuration connects to compatibility and calculation rules.
    • Validated options connect to price-book entries and pricing formulas.
    • Configured products connect to configurable BOMs.
    • Configurable BOMs connect to EBOM, MBOM or ERP structures.
    • Configuration parameters can connect to CAD automation and engineering calculations.
    • Price and cost results connect to margin and approval rules.
    • Approved configurations connect to quote documents and order processes.
    • CPQ connects commercial, engineering and manufacturing systems through integrations.

    Frequently asked questions

    What is the difference between a price book and a product configurator?

    A price book supplies prices and commercial rules. A product configurator determines which product options and combinations are valid. Manufacturing CPQ connects the two so that a valid engineered configuration receives an appropriate price.

    Can a price book contain configuration rules?

    It can contain price-dependent conditions, but technical compatibility rules should normally reside in the product model or rules engine. Keeping technical and commercial logic separate makes both easier to govern.

    Does every CPQ system generate a BOM?

    No. Some CPQ systems generate configurable BOMs, while others pass selections to ERP, PLM or an engineering application that creates the structure. This capability must be verified for the specific product and integration architecture.

    How does configuration affect product pricing?

    Configuration selects the components, dimensions, materials and services that drive the price. The pricing engine can then apply fixed option prices, replacement prices, formulas, customer terms and discounts.

    Can one product have multiple price books?

    Yes. Manufacturers commonly maintain books for regions, currencies, distributors, OEM contracts, customer accounts or sales channels. Effective dates and selection priorities should be explicitly governed.

    Should costs and prices be stored in the same price book?

    They may be managed in the same CPQ model, but cost and sell price should remain distinct data elements with separate visibility and governance. Costs support margin analysis; prices support the commercial offer.

    How are dimensions used in a manufacturing price book?

    Dimensions can select a price tier or feed a formula. For example, conveyor length may determine material quantity, fabrication effort, freight class and selling price.

    How are discounts applied to configured products?

    Discounts can be applied by product family, customer, channel, quantity, contract or total quote value. Approval rules should evaluate the resulting margin and any exceptions.

    What happens when a configuration requires engineering work?

    The CPQ process can create an ETO or engineering-review task, include an allowance or estimate, and prevent the quote from being treated as fully final until engineering confirms the design.

    Can CPQ price a configurable BOM?

    Yes, where the platform supports BOM-driven pricing. It can value components, quantities, replacements and assemblies, although the final production BOM may be created or transformed in ERP or PLM.

    How do EBOM and MBOM affect CPQ pricing?

    An EBOM describes the engineered product, while an MBOM organizes production requirements. CPQ may use a sales BOM or configured structure and pass it to systems that create or manage the EBOM and MBOM.

    Can price books include freight and installation?

    They can, if the CPQ design includes those commercial elements. Freight may depend on weight, dimensions, destination and shipping class, while installation may depend on scope, location and engineering assumptions.

    How should price-book revisions be controlled?

    Use version numbers, effective dates, approvals, audit history and regression testing. Define whether existing quotes retain their original price or are recalculated under a new release.

    What is a price override in manufacturing CPQ?

    A price override is a deliberate change to the calculated or approved price. It should record the user, reason, amount, margin impact and approval status rather than silently replacing the system result.

    Can a CRM own the manufacturing price book?

    A CRM may display or consume pricing, but it is not automatically the best system of record for complex product, cost and manufacturing logic. Ownership should be selected according to data complexity, governance and integration requirements.

    How does CAD automation relate to price books?

    CAD automation uses configuration parameters to create product-specific models or drawings. Its outputs may affect BOM content, engineering effort and price, but CAD generation and price-book management are separate capabilities.

    What should manufacturers test before launching a price book?

    Test valid and invalid configurations, formula boundaries, replacements, currencies, discounts, effective dates, customer contracts, margin approvals, BOM results, quote documents and integration payloads.

  • 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.

  • 3D CPQ Software: Complete Guide for Manufacturers

    3D CPQ software combines Configure, Price, Quote (CPQ) capabilities with three-dimensional product visualization and, in some implementations, CAD and engineering automation. For manufacturers, it can show customers and sales teams what a configured machine, vehicle, enclosure or assembly will look like while validating configuration rules, calculating price and producing downstream engineering data.

    The most important distinction is that 3D visualization and manufacturing CPQ are not the same thing. A 3D viewer may display selectable options without understanding engineering constraints or producing manufacturing data. A manufacturing-oriented 3D CPQ system connects the visual model to a product model, configuration rules, calculations, pricing, bills of material (BOMs), computer-aided design (CAD) outputs and enterprise systems where those capabilities are implemented.

    This guide explains how 3D CPQ works, what data it requires, how it supports the sales-to-engineering handoff, where it fits in the technology stack, and what manufacturers should verify before selecting a platform. For the broader subject, see the guide to manufacturing CPQ software.

    What is 3D CPQ software?

    3D CPQ software is a product configuration and quoting system that represents configurable products in three dimensions while applying product rules, engineering logic, pricing and quoting workflows. Depending on the architecture, the 3D model may be a visual representation only, a parametric model driven by configuration values, or a connected CAD output used to generate drawings and manufacturing data.

    A typical 3D CPQ interaction might allow a user to select a pump type, alter connection orientation, choose a motor, set dimensions and add accessories. The system can update the three-dimensional view, reject incompatible combinations, calculate price and produce a quote. More advanced implementations can also create a configurable BOM, an engineering BOM (EBOM), a manufacturing BOM (MBOM), product-specific drawings or a CAD file.

    These capabilities are not automatically included in every CPQ product. Buyers should evaluate visualization, configuration, CAD automation, BOM generation, engineering calculations and integrations as separate capabilities.

    How 3D CPQ differs from generic sales CPQ

    Generic sales CPQ usually focuses on selecting commercial products, applying discounts and producing a proposal. Manufacturing CPQ must often model the physical product and its engineering consequences. A configuration can affect dimensions, materials, structural loads, motor sizing, electrical requirements, production operations and compliance documentation.

    Capability Generic sales CPQ Manufacturing-oriented 3D CPQ
    Product selection Options and packages Options, dimensions, components, materials and engineering parameters
    Validation Commercial dependencies Commercial, geometric, mechanical, electrical and manufacturing constraints
    Visualization Optional product images Interactive 3D representation of the configured product or assembly
    Outputs Quote and proposal Quote plus BOM, configuration record, CAD outputs or engineering handoff where supported
    Downstream systems Customer relationship management (CRM) and enterprise resource planning (ERP) CRM, ERP, product lifecycle management (PLM), product data management (PDM), CAD and manufacturing systems

    The distinction matters because a visually attractive configurator can still leave engineering teams with incomplete or untrusted data. The objective is not simply to rotate a model on a web page. The objective is to connect customer intent with a valid product definition and repeatable operational outputs.

    How a 3D CPQ architecture works

    A 3D CPQ solution normally contains several related layers. They may be delivered by one platform or connected through application programming interfaces (APIs) and integration services.

    1. Product model

    The product model defines the configurable structure. It may contain product families, modules, features, options, dimensions, materials, components, accessories and dependencies. For example, an industrial air-handling unit model could include fan type, casing width, filter section, heating coil, control panel, access doors and insulation.

    The model should identify which values are customer-selectable, which are calculated, which are inherited from a product family and which are controlled by engineering. It should also distinguish commercial options from physical components. Selecting a premium warranty is not the same kind of event as selecting a larger motor.

    2. Rules and constraints

    Rules determine which combinations are valid and what the system should do when a selection changes. Rules-based configuration uses explicit conditions such as “if option A is selected, option B is required.” Constraint-based configuration represents permitted or prohibited relationships across values, ranges and dependencies. Guided selling helps a user reach a suitable product by asking questions, but it may not provide the full engineering validation required for production.

    Typical rules include:

    • Preventing a pump motor from exceeding the available electrical supply.
    • Requiring a reinforced frame when a machine exceeds a specified load.
    • Limiting enclosure dimensions based on transport or manufacturing constraints.
    • Adding a mounting kit when a selected valve requires a particular connection standard.
    • Preventing two accessories from occupying the same physical position.
    • Changing available materials based on temperature, pressure or chemical exposure.

    Good rule design is central to product configuration and configuration validation. Rules should be testable, traceable to a business or engineering requirement and assigned to an owner.

    3. 3D representation and visualization

    The visualization layer maps configuration values to geometry, colors, materials, labels and assembly states. It may hide or display components, change dimensions, substitute models, update camera views or show connection points.

    There are several common approaches:

    • Configured image or scene: pre-rendered images or simple scene changes provide visual guidance but have limited geometric intelligence.
    • Component-based 3D viewer: the system assembles reusable component models and applies visibility or placement rules.
    • Parametric 3D model: dimensions and geometry respond to configuration parameters.
    • CAD-connected configuration: the CPQ process sends validated parameters to a CAD or design automation service that generates product-specific geometry, drawings or files.

    The correct approach depends on the product and required output. A distributor may need a clear visual explanation of a standard conveyor configuration. An engineer-to-order machine builder may need validated dimensions and CAD data rather than only a visual model.

    4. Engineering calculations

    Some products require calculations before they can be quoted. Examples include pump duty and motor selection, pressure drop, structural capacity, thermal performance, cable sizing, airflow, lifting capacity and vehicle payload.

    Calculations can be embedded in the CPQ model, called from an external engineering service or performed in a connected design application. The implementation should record inputs, formulas, assumptions, units and results. A 3D view should not be treated as proof that the selected product is technically suitable.

    5. Pricing, costing and quoting

    The CPQ system can use configuration results to determine component prices, labor, services, freight assumptions, margins, discounts and approval requirements. Pricing remains a separate concern from geometric visualization. A model can look correct while a price is wrong, and a correct price does not prove that the configuration is manufacturable.

    For a deeper treatment of this data flow, see BOM generation, costing, pricing and quote automation.

    6. Downstream outputs

    A completed configuration may produce a quote, proposal, configuration summary, BOM, CAD file, drawing request, engineering task or order payload. The exact output depends on the product and the systems connected to CPQ.

    An EBOM is an engineering bill of material that describes the product from a design perspective. An MBOM is a manufacturing bill of material organized for production, including manufacturing structure, operations or assembly requirements. A configurable BOM may contain rules or placeholders that resolve into a specific product BOM after configuration. These structures should not be assumed to be interchangeable.

    Typical data flow from configuration to production

    1. Start with requirements: a customer, dealer or sales engineer enters application requirements such as capacity, dimensions, environment, voltage or material.
    2. Apply product logic: the system proposes valid options and prevents incompatible combinations.
    3. Update the 3D model: the visual representation changes to reflect selected modules, dimensions and accessories.
    4. Run calculations: sizing, performance or compliance calculations determine whether the configuration satisfies technical requirements.
    5. Calculate cost and price: component costs, labor, margins, discounts and commercial rules are applied.
    6. Generate outputs: the system creates the quote and, where supported, configuration data, BOMs, CAD outputs or engineering documents.
    7. Transfer information: approved data moves to CRM, ERP, PLM, PDM, manufacturing execution system (MES) or another production process.
    8. Release and maintain: engineering and product teams manage revisions, effective dates and rule changes.

    This process supports a controlled sales-to-engineering and order-to-production workflow. It does not eliminate the need for engineering review in every situation. Instead, it helps distinguish standard or configure-to-order work from exceptions that require engineer-to-order handling.

    Manufacturing examples of 3D CPQ

    Industrial machinery

    A machinery builder may configure frame length, guarding, conveyor width, drive package, sensors and control architecture. The 3D model can show the machine footprint and selected modules. Rules can prevent a motor or guard from conflicting with the chosen frame, while CAD automation may generate a layout drawing for customer approval.

    Pumps and valves

    A pump configuration may depend on flow, head, fluid, temperature, materials, seal type, motor, connection standard and mounting arrangement. The system may use engineering calculations to narrow compatible models, display the selected assembly and generate a component list. The visualization is useful, but hydraulic and mechanical validation remain essential.

    Electrical equipment and enclosures

    An enclosure configurator may manage width, height, depth, doors, gland plates, cooling, disconnects and internal components. Three-dimensional placement can reveal clashes and improve communication with the customer. The system may also need to calculate heat dissipation, verify space requirements and generate a panel layout or manufacturing request.

    Specialty vehicles

    A vehicle builder may configure chassis, body modules, seating, storage, lifting equipment, electrical packages and safety options. A 3D view helps stakeholders understand the final vehicle, while rules protect payload, clearance, mounting and electrical constraints. The downstream result may be a vehicle-specific BOM and engineering task rather than a fully automated production package.

    Benefits of 3D CPQ for manufacturers

    • Clearer customer communication: customers can see the effect of dimensions, modules and accessories before order approval.
    • Earlier detection of configuration issues: visual and rule-based validation can expose missing, overlapping or incompatible selections.
    • Less repetitive engineering work: standard calculations, model assembly and document generation can be automated where the product model is mature.
    • More accurate sales-to-engineering handoff: engineering receives structured configuration data instead of relying only on free-text notes or marked-up proposals.
    • Faster quoting for repeatable products: valid configurations can be priced and documented without restarting the design process for every inquiry.
    • Better dealer and distributor support: channel users can configure products consistently without needing to know every internal engineering rule.
    • Improved change control: product teams can update rules, components, geometry and pricing through governed releases.

    Limitations and risks

    3D CPQ is not a substitute for a product strategy, clean engineering data or a controlled product lifecycle. Common limitations include:

    • High modeling effort: configurable geometry, dependencies and calculations require detailed analysis and maintenance.
    • Incomplete product data: inconsistent part numbers, outdated CAD files, missing dimensions or unreliable costs undermine the result.
    • Rule complexity: unmanaged exceptions can create contradictory rules, slow performance and difficult testing.
    • Visualization gaps: a model may be visually persuasive without representing every internal component, tolerance or manufacturing process.
    • Integration boundaries: data may not transfer cleanly between CPQ, CAD, PLM, ERP or MES if identifiers, revisions and ownership are not defined.
    • Performance and usability: large assemblies and detailed models can create browser, mobile or network performance problems.
    • Over-automation: forcing unusual engineer-to-order products through a standard configurator can create risk instead of removing it.

    Manufacturers should define when a configuration is automatically released, when it requires engineering approval and when it must enter a separate design process.

    3D CPQ and CTO, ETO, MTO and ATO

    Production strategy affects the right level of automation. Configure-to-order (CTO) uses predefined modules and rules to produce a valid product after customer selection. 3D CPQ is often a strong fit when the product architecture is modular and repeatable.

    Engineer-to-order (ETO) creates or significantly changes the design for a specific order. A 3D CPQ system may capture requirements, create a preliminary model and initiate engineering work, but it may not fully automate the final design.

    Make-to-order (MTO) means production starts in response to an order, while assemble-to-order (ATO) combines stocked or predefined modules after ordering. These terms describe production and fulfillment approaches; they do not by themselves prove that a product can be configured automatically.

    Integration with enterprise systems

    3D CPQ usually sits between customer-facing processes and engineering or operational systems. The integration design should identify the system of record for each data type.

    System Typical relationship with 3D CPQ
    CRM Opportunity, account, contact, sales process and quote context
    ERP Item masters, inventory, costs, prices, orders, customers and financial processing
    PLM Product structures, revisions, lifecycle states, engineering changes and released definitions
    PDM CAD files, document metadata, versions and controlled design data
    CAD Parametric models, assemblies, drawings and design automation
    Product information management (PIM) Commercial product descriptions, attributes, media and channel content
    MES Production execution, work instructions, status and manufacturing data

    For integration patterns and ownership questions, see the guide to CPQ integration with ERP, CRM, PLM, PDM, CAD and MES. A practical design should define part-number ownership, revision behavior, configuration identifiers, error handling, security and whether data moves synchronously or through approved release events.

    How to evaluate 3D CPQ software

    Manufacturers should evaluate the complete workflow rather than judging a platform by the presence of a 3D viewer. Important questions include:

    • Can the product model represent modules, variants, dimensions, materials and optional components?
    • Can rules express cross-component, geometric, electrical and engineering constraints?
    • Is the 3D model visual-only, component-based, parametric or connected to CAD?
    • Can the system expose configuration values to CAD automation or engineering calculations?
    • What outputs are supported: quote, configuration record, configurable BOM, EBOM, MBOM, drawing or CAD file?
    • How are part numbers, revisions, units and engineering attributes managed?
    • Can users distinguish standard CTO configurations from ETO exceptions?
    • How are rule changes tested, approved, versioned and rolled back?
    • What happens when an ERP, PLM or CAD service is unavailable?
    • Can the system support sales engineers, dealers, distributors and customer self-service without exposing uncontrolled data?
    • How are large assemblies, mobile devices and high-resolution models handled?
    • Which capabilities are native, which require customization and which depend on third-party applications?

    Vendor claims should be validated with a representative product model and real outputs. A useful proof of concept should include incompatible selections, dimensional changes, a pricing change, a BOM comparison, a CAD or drawing requirement and an exception that requires engineering review. The manufacturing CPQ comparison and selection guidance can help structure this evaluation.

    Implementation approach

    Define the first product scope

    Start with a product family that has meaningful configuration volume and reasonably stable rules. Avoid beginning with the most customized product if its design logic is not yet documented.

    Establish data ownership

    Document who owns item numbers, CAD models, prices, costs, technical attributes, product rules, revisions and released BOMs. A CPQ system should not become an uncontrolled duplicate of ERP or PLM.

    Separate visual logic from engineering logic

    Some rules control what appears in the viewer; others determine whether the product is technically valid. Keep these concerns identifiable even when they are evaluated in one transaction.

    Build and test representative configurations

    Test normal, boundary, invalid, discontinued and exception scenarios. Include unit conversions, missing data, revision changes, integration failures and products with large assemblies. A visual inspection alone is not sufficient; compare expected BOMs, prices, calculations and CAD outputs.

    Define release and exception workflows

    Decide when a quote is valid, when an engineering approval is required and how a changed configuration affects an existing quote. This is especially important when a 3D CPQ system supports both CTO and ETO workflows.

    Plan ongoing governance

    Product models require maintenance as components, suppliers, prices, regulations, CAD models and manufacturing processes change. Establish release management, regression testing, rule ownership, usage monitoring and a process for retiring obsolete options. The CPQ implementation guide covers requirements, migration, testing, governance and maintenance in more detail.

    Semantic map

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

    • 3D CPQ software connects product configuration, visualization, engineering and quoting.
    • Product models define configurable products, modules, options, dimensions and components.
    • Configuration rules prevent invalid combinations and trigger dependent selections.
    • 3D visualization represents the selected product configuration.
    • Engineering calculations evaluate technical requirements such as capacity, load, flow or heat.
    • CAD automation generates product-specific geometry, drawings or design files when supported.
    • A configured product can generate a BOM, configuration record or engineering request.
    • An EBOM represents an engineering product structure.
    • An MBOM represents a manufacturing-oriented product structure.
    • CPQ exchanges customer and commercial data with CRM.
    • CPQ exchanges item, price, cost and order data with ERP.
    • CPQ exchanges released product and revision data with PLM or PDM.
    • CTO uses predefined modules and rules for repeatable products.
    • ETO requires engineering work for product-specific designs or exceptions.
    • Sales-to-engineering handoff transfers validated configuration data to downstream teams.

    Frequently asked questions

    1. What is 3D CPQ?

    3D CPQ is CPQ software that combines product configuration and quoting with three-dimensional visualization. In manufacturing, it may also connect configuration values to engineering calculations, BOMs, CAD automation and production systems.

    2. Is a 3D product configurator the same as 3D CPQ?

    No. A 3D configurator may only display product variants. 3D CPQ adds commercial and operational processes such as validation, pricing, quoting and potentially BOM or engineering outputs.

    3. Does every 3D CPQ system generate CAD files?

    No. Some systems provide visualization only, while others connect to CAD or design automation tools. CAD generation must be verified for the specific CAD system, product model and output format required.

    4. Can 3D CPQ generate a manufacturing BOM?

    Some platforms can generate or export BOM data, but not every CPQ system creates an MBOM. The buyer should verify whether the output is an EBOM, MBOM, configurable BOM or simple component list.

    5. Can a 3D model validate engineering requirements?

    Not by itself. Geometry can help identify visual or spatial issues, but technical validation usually requires configuration rules, engineering calculations, simulation or engineering review.

    6. What products benefit most from 3D CPQ?

    It is often useful for configurable machinery, equipment, vehicles, enclosures, HVAC systems, material handling products, electrical assemblies and other products where options affect geometry or customer understanding.

    7. How does 3D CPQ support sales engineers?

    It gives sales engineers a structured way to collect requirements, select valid options, explain the resulting product and produce a quote with clearer engineering information.

    8. Can dealers use 3D CPQ?

    Yes, if the platform supports dealer or distributor workflows and provides appropriate access controls. The manufacturer must decide which options, prices, technical data and outputs each channel user can access.

    9. Does 3D CPQ replace engineering?

    No. It can automate repeatable configuration and documentation, but engineering remains necessary for new products, unusual requirements, exceptions and changes outside the validated product model.

    10. How is 3D CPQ related to PLM?

    Product lifecycle management (PLM) manages product definitions, revisions and lifecycle processes. 3D CPQ uses selected product and engineering data to configure and quote products, with integration required to keep definitions aligned.

    11. How is 3D CPQ related to PDM?

    Product data management (PDM) commonly manages CAD files, documents, metadata and revisions. A 3D CPQ system may retrieve controlled models or send parameters to design automation through a PDM or CAD environment.

    12. Can 3D CPQ support engineer-to-order products?

    It can support ETO by capturing requirements, creating preliminary configurations and initiating engineering tasks. Full automated design generation is not appropriate for every ETO product.

    13. What is the difference between a 3D viewer and a parametric model?

    A viewer displays geometry, while a parametric model changes geometry according to defined parameters. A viewer may show options without being able to calculate or generate the corresponding engineering design.

    14. What data is needed to implement 3D CPQ?

    Typical inputs include product structures, options, rules, dimensions, component identifiers, CAD models, technical attributes, costs, prices, calculations, BOM logic and integration mappings.

    15. How should 3D CPQ configurations be tested?

    Test valid and invalid combinations, boundary values, dimensional changes, pricing, BOM results, CAD outputs, revision changes, integration errors and cases that should be routed to engineering.

    16. Can 3D CPQ work with ERP?

    Many manufacturing CPQ implementations integrate with ERP, but the depth varies. The integration may exchange items, prices, costs, customers, orders, inventory or configuration identifiers. These capabilities must be verified for the chosen platform.

    17. Is 3D CPQ suitable for customer self-service?

    It can be suitable for self-service when the product is sufficiently standardized and the user interface hides unnecessary engineering complexity. Products with frequent exceptions may need sales or engineering involvement.

    18. What is the biggest implementation risk?

    A major risk is attempting to automate an undocumented or unstable product model. Rule ownership, clean data, controlled CAD assets and a clear exception process are prerequisites for reliable results.

    19. How does 3D CPQ affect quote accuracy?

    It can improve accuracy by linking valid configuration selections to prices, components and calculations. It does not guarantee accuracy if source costs, rules, CAD data or integration mappings are incomplete.

    20. What should a 3D CPQ proof of concept include?

    Use a real product family with option dependencies, dimensional changes, an invalid combination, a price change, a BOM requirement, a representative 3D output and at least one engineering exception.

  • Photorealistic Product Visualization in CPQ: Manufacturing Guide

    Photorealistic product visualization in CPQ is the generation of realistic images, interactive 3D models or rendered views of a configured product during the configure, price, quote process. In manufacturing, the visual output should reflect the selected product options, dimensions, materials, finishes, accessories and major engineering decisions rather than showing a generic marketing image.

    A manufacturing CPQ system may use a product model, configuration rules, parametric CAD data, 3D assets and rendering services to show a pump skid, industrial enclosure, material-handling vehicle, HVAC unit or machine assembly as it is configured. The visualization can support guided selling and customer approval, while the same configuration may also produce pricing, a configurable bill of materials (BOM), engineering calculations, CAD outputs or an order handoff.

    Not every CPQ platform includes photorealistic rendering, interactive 3D, CAD automation or manufacturing BOM generation. Buyers should evaluate these capabilities separately and verify how visual data is synchronized with the product model, engineering systems and downstream manufacturing processes.

    What photorealistic visualization means in manufacturing CPQ

    Photorealistic visualization is a rendered representation of a configured product that aims to resemble the physical product in shape, proportion, color, material, lighting and component placement. It is more than displaying a static catalog photograph. The image or 3D scene changes when the user selects valid product options.

    For example, a configurable industrial air-handling unit might change visually when a user selects a different casing width, access-door arrangement, filter section, fan type, roof package or exterior finish. A realistic view can help a sales engineer confirm that the selected arrangement matches the customer requirement. It can also expose misunderstandings before an order reaches engineering.

    In manufacturing CPQ, visualization is normally one part of a larger product definition. The visual representation should be linked to configuration attributes and not maintained as an unrelated illustration. A selection such as stainless steel casing may affect the rendered material, price, weight, BOM components and manufacturing instructions.

    How visual CPQ differs from generic sales CPQ

    Generic sales CPQ often focuses on selecting products, applying discounts and producing a quote. Visual CPQ adds an interactive or rendered product representation, but manufacturing applications usually require a deeper relationship between the visual model and engineering data.

    Area Generic sales CPQ Manufacturing visual CPQ
    Primary purpose Select items and calculate a commercial offer Represent and validate a technically configurable product
    Product data Catalog products, options and prices Features, dimensions, materials, components, geometry and engineering attributes
    Visual output Product image or basic option image Configuration-specific 2D, 3D or photorealistic representation
    Rules Compatibility and commercial rules Compatibility, dimensional, structural, performance and manufacturing constraints
    Downstream output Quote, proposal or sales order Quote plus BOM, CAD files, drawings, calculations or engineering handoff where supported
    Typical users Sales representatives Sales engineers, application engineers, dealers, customers and manufacturing teams

    A visually attractive interface does not automatically make a CPQ system suitable for engineered products. The important question is whether the displayed configuration is controlled by the same governed data and rules used for pricing and downstream outputs.

    Where visualization fits in the CPQ architecture

    A visual CPQ solution commonly contains several connected layers. The exact architecture varies by platform and implementation, but the following components are typical.

    1. Product model: Defines families, variants, options, attributes, dimensions, components and relationships. The product model is the basis for the configuration rules and product configuration.
    2. Rules and constraints: Determine which combinations are valid. Rules may control compatibility, required components, allowable dimensions, material restrictions, performance limits or manufacturing feasibility.
    3. Configuration state: Stores the selected options and calculated values for a specific product instance. This state should be identifiable and reusable by pricing, visualization, BOM and engineering services.
    4. Visual asset library: Contains 2D images, 3D geometry, textures, materials, decals, animations and camera views. Assets may represent complete products, subassemblies or interchangeable components.
    5. Geometry or CAD service: Updates parametric geometry, assembles components or calls a computer-aided design (CAD) automation process. Some systems use lightweight 3D geometry for performance while others generate more detailed engineering outputs separately.
    6. Rendering engine: Produces a browser-based 3D scene, real-time view, still image or high-quality rendered output. Rendering may occur in the browser, on a server or through an external visualization service.
    7. Commercial and engineering services: Calculate price and cost, generate a BOM, perform engineering calculations or create drawings when those capabilities are available.
    8. Enterprise integrations: Exchange data with customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES) or CAD platforms.

    The CAD and engineering automation layer may be tightly embedded in CPQ or connected through application programming interfaces (APIs). A visual model is not necessarily an engineering model. The implementation must define which system owns dimensions, part numbers, geometry, materials and revision status.

    Data required for photorealistic product visualization

    Realistic visualization depends on more than a collection of photographs. A maintainable implementation normally requires structured product and visual data.

    Data type Examples Why it matters
    Configuration attributes Width, height, capacity, motor size, voltage, orientation Controls valid choices and visual changes
    Component mappings Fan, valve, guard, access panel, bracket, cable tray Determines which components appear in the scene or assembly
    Geometry Parametric CAD, lightweight meshes, assembly transforms Controls dimensions, placement and proportions
    Materials Paint, stainless steel, galvanized steel, glass, rubber Controls surface appearance and may affect price or manufacturing
    Appearance assets Textures, decals, labels, logos and finishes Improves realism and supports customer-specific presentation
    Camera and scene data Views, lighting, environments and exploded positions Creates consistent product views for quotes and approvals
    Revision metadata Effective date, product revision, asset revision, status Prevents obsolete or visually incorrect representations

    Manufacturers should also decide whether the visual model is authoritative for any business decision. For example, a rendered pipe route may be illustrative while the CAD assembly and engineering calculation remain authoritative. This distinction should be clear to users and documented in the implementation.

    How configuration rules control the visual output

    Visualization should respond to the same valid configuration state used elsewhere in CPQ. This requires a clear relationship between options and visual behavior.

    Rules-based configuration

    Rules-based configuration uses explicit logic such as: if a roof-mounted fan is selected, show the fan assembly; if a left-hand access door is selected, place the door on the left side; if a high-voltage motor is selected, show the associated control cabinet label.

    Constraint-based configuration

    Constraint-based configuration evaluates permitted values and relationships, often across dimensions, performance requirements and engineering limits. For example, a pump selection may need to satisfy flow, head, fluid temperature, motor availability and pipe connection constraints. The visual model can show the selected pump and connected fittings, but the constraint engine determines whether the combination is technically valid.

    Guided selling

    Guided selling asks users requirement-oriented questions and recommends or restricts product choices. It may hide technical complexity from a customer or dealer. Guided selling can drive visualization, but it is not the same as a complete engineering rules engine. A guided question such as “What airflow is required?” may lead to a product selection, while engineering rules still need to validate fan, casing and electrical combinations.

    When the configuration changes, the system may update the scene through one or more methods:

    • showing or hiding a predefined component;
    • changing the position or orientation of an assembly;
    • scaling a parametric section within permitted limits;
    • swapping a mesh or CAD representation;
    • changing material, finish or color;
    • updating labels, dimensions or callouts;
    • regenerating a CAD assembly or engineering drawing.

    Relationship between visualization, CAD and engineering automation

    Photorealistic visualization and CAD automation are related but different capabilities. Visualization prioritizes understandable presentation and interactive performance. CAD automation prioritizes geometric accuracy, engineering reuse, drawings and manufacturing outputs.

    A manufacturer may use lightweight visual geometry in the browser while generating a precise CAD model on the server after configuration approval. In another architecture, a parametric CAD model may drive both the visual scene and the engineering output. The right approach depends on product complexity, rendering performance, required accuracy and the systems already used by engineering.

    Output Typical purpose Accuracy expectation
    Photorealistic still image Quote, proposal or customer presentation Visual and configuration accuracy; not necessarily manufacturing geometry
    Interactive 3D model Option selection, review and spatial understanding Correct component presence, placement and proportions
    Parametric CAD assembly Engineering validation and design reuse Engineering geometry and controlled parameters
    2D drawing Manufacturing, installation or approval documentation Defined dimensions, views, annotations and revision control
    Manufacturing BOM Procurement, production and assembly Correct parts, quantities, revisions and manufacturing structure

    More information about this distinction is covered in the guide to CAD automation and engineering automation in CPQ. A rendering should not be presented as a certified drawing unless it has passed the required engineering and document-control process.

    Example: visualizing a configurable pump skid

    Consider a manufacturer selling packaged pump skids. The configuration includes pump type, flow range, motor rating, base-frame length, pipe material, valve arrangement, instrumentation, enclosure and paint finish.

    The CPQ workflow may operate as follows:

    1. The user selects the required duty point and installation environment.
    2. Configuration logic restricts pumps, motors and materials that do not satisfy the requirements.
    3. The system selects or recommends a pump and motor combination.
    4. The visual scene displays the pump, motor, frame, valves, gauges and pipe arrangement.
    5. Changing the discharge orientation moves the connected pipework and valve group.
    6. Selecting stainless steel changes the appearance and may update material-related pricing and components.
    7. The system calculates price and cost and creates a configurable BOM if supported.
    8. After review, the configuration is passed to engineering for CAD regeneration, drawing creation or further ETO work.

    ETO means engineer-to-order: the product is configured from a platform but requires additional engineering before production. CTO means configure-to-order: the product is assembled from predefined, validated options with limited design work. Photorealistic visualization can support both models, but it does not remove the engineering work required by an ETO product.

    Sales-to-engineering handoff

    The strongest manufacturing use case is not simply showing a product in 3D. It is preserving the approved configuration as a structured handoff. The quote, visual approval and engineering request should refer to the same configuration identifier and revision.

    A handoff may include:

    • selected options and calculated dimensions;
    • configuration rules or validation status;
    • customer-approved images or 3D views;
    • part numbers and quantities;
    • preliminary or manufacturing BOM, clearly identified by type;
    • performance calculations and assumptions;
    • CAD generation parameters;
    • exceptions requiring engineering review;
    • commercial information and approval status.

    An engineering bill of materials (EBOM) describes the product from an engineering perspective. A manufacturing bill of materials (MBOM) organizes the product for production, including manufacturing assemblies, operations or shop-floor requirements. A configurable BOM may contain rules or placeholders that resolve after selections are made. These structures should not be treated as interchangeable. The guide to BOM generation, pricing and quoting explains how these outputs relate to CPQ.

    Benefits of photorealistic visualization in manufacturing CPQ

    Better understanding of complex options

    Industrial products can contain hidden components, multiple orientations and unfamiliar technical terms. A visual representation helps users understand the physical result of a selection such as an access side, discharge position or enclosure type.

    Earlier detection of configuration misunderstandings

    A customer may approve a configuration more confidently when the quote shows the selected door arrangement, material finish, control panel location or accessory package. Visual review can reveal an incorrect assumption before order entry, although it does not replace technical validation.

    More useful proposals and dealer tools

    Dealers and distributors can present a configuration-specific proposal instead of combining generic product photographs with manually written descriptions. This is particularly useful when a product has many visible options.

    Reduced manual illustration work

    Where visual assets and rules are well maintained, the system can generate views for many valid variants without requiring an engineer or marketing specialist to create every image manually.

    Improved continuity from quote to order

    When the approved visual state is connected to the configuration record, sales, engineering and production can work from a common reference. The benefit depends on data governance and integration quality rather than rendering quality alone.

    Limitations and risks

    • Visual accuracy can lag product changes. New components, finishes or revisions require corresponding asset and rule updates.
    • A realistic image can create false confidence. A product may look correct while violating a load, clearance, electrical or performance constraint if those rules are not implemented.
    • Visual geometry may not be manufacturing geometry. Lightweight meshes may omit internal structure, tolerances, fasteners or production details.
    • Large assemblies can affect performance. High-resolution models and textures can cause slow loading, especially in browser-based configurators or dealer environments.
    • Rendering is not a substitute for engineering approval. ETO products may still require calculations, design review and controlled drawings.
    • Asset maintenance can be expensive. Each family of components may require geometry, materials, lighting, camera and rule mappings.
    • Color and material representation is approximate. Screens, lighting and rendering settings affect how paint, metal and surface treatments appear.
    • Integration boundaries can cause inconsistencies. If CAD, PLM and CPQ use different revisions or identifiers, the visual output may not match the released product.

    Implementation approach

    1. Select a product family with a clear business case

    Start with a product that has visible configuration complexity and repeatable option structures. Industrial enclosures, pumps, HVAC units, conveyors and specialty vehicles are common candidates. Avoid beginning with a product whose geometry is still unstable or whose rules are undocumented.

    2. Define the source of truth

    Document which system owns product attributes, engineering revisions, CAD geometry, visual assets, prices and BOM structures. A product lifecycle management (PLM) or PDM system may govern engineering data, while CPQ manages the selling configuration. An ERP system may own released item and order data. These responsibilities must be explicit.

    3. Build the product model before polishing the visuals

    Identify features, options, dependencies, dimensions, constraints and component mappings. Separate configuration rules from presentation rules where possible. For example, “a stainless-steel option is available” is a product rule; “use a brushed-metal texture” is a visual mapping.

    4. Create a reusable visual asset strategy

    Use modular components and standard naming. Define coordinate systems, attachment points, material names, camera conventions, texture resolution and versioning. Reusable assets reduce duplication when the same motor, valve or control box appears across several product families.

    5. Define accuracy levels

    Decide whether each output is illustrative, configuration-accurate, dimensionally indicative or engineering-authoritative. These labels should appear in requirements and user guidance. A quote image may have a different accuracy requirement from a drawing released to production.

    6. Connect the visual state to downstream outputs

    Test whether the selected options that change the image also change price, BOM, CAD parameters and engineering documentation where appropriate. The CPQ integration architecture should define identifiers, APIs, error handling, revision handling and synchronization timing.

    7. Test combinations and revisions

    Test valid and invalid combinations, boundary dimensions, component substitutions, discontinued parts, material changes and regional variants. Compare the visual result with the configuration record and, where applicable, the generated CAD assembly and BOM.

    8. Establish governance

    Assign ownership for rules, product data, CAD assets, visual assets, pricing, integrations and release approval. A change to a component can affect geometry, appearance, cost, lead time, BOM and technical documentation. Governance should cover all of these dependencies.

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

    Evaluation checklist for visual CPQ software

    When evaluating a platform, ask vendors and implementation partners specific questions rather than accepting “3D visualization” as a complete capability.

    • Can the system display configurable 3D assemblies, or only swap static images?
    • Can visuals respond to dimensions, orientations, materials and component selections?
    • Is the visual model linked to the same configuration state used for pricing and BOM generation?
    • Does the platform support browser-based viewing, server rendering, downloadable images or all three?
    • Can it use CAD, mesh or lightweight geometry, and how are those assets imported?
    • Can it generate or exchange CAD parameters and drawings, or is it visualization-only?
    • How are visual assets versioned when an engineering revision is released?
    • How are invalid, incomplete or engineering-review configurations represented?
    • Can users create approved views for proposals, customer sign-off and order records?
    • What APIs are available for CAD, PLM, PDM, ERP, CRM and document systems?
    • How does the platform handle large assemblies and mobile or dealer access?
    • Which BOM types can it generate: configurable BOM, EBOM or MBOM?
    • Can the system support CTO, ETO, make-to-order (MTO) or assemble-to-order (ATO) workflows?
    • What tools exist for testing rules and visual mappings after a product change?
    • Which capabilities are native, which require customization and which require third-party software?

    These questions help distinguish a genuine manufacturing visualization workflow from a catalog image feature. Vendor profiles and comparisons should document the answers for each platform rather than infer them from marketing terminology.

    Key performance and quality measures

    Manufacturers can evaluate the implementation with operational measures such as:

    • percentage of valid configurations that produce the expected visual state;
    • number of visual mismatches found during engineering review;
    • time required to create a configuration-specific proposal;
    • time required to update visual assets after a product revision;
    • frequency of manual corrections to configuration, BOM or CAD data;
    • user completion rate for dealer or customer configuration;
    • rendering and model-load performance for representative assemblies;
    • percentage of approved configurations transferred without rekeying;
    • number of engineering exceptions generated after sales approval.

    These measures should be interpreted with product complexity in mind. A visual configurator for a small set of modular enclosures will have different targets from one supporting engineered machinery or specialty vehicles.

    Semantic map

    The following relationships summarize how photorealistic product visualization fits into manufacturing CPQ:

    • CPQ configures configurable industrial products.
    • Configuration rules prevent invalid product combinations.
    • Configuration attributes control visual component mappings.
    • Visual component mappings assemble a 3D product scene.
    • Photorealistic rendering presents configured product appearance.
    • CAD automation generates product-specific engineering geometry.
    • Configured products generate pricing and quote outputs.
    • Configured products may generate configurable BOMs.
    • EBOMs describe engineering product structures.
    • MBOMs organize products for manufacturing.
    • CPQ exchanges configuration data with ERP systems.
    • PLM and PDM systems govern engineering product data.
    • Approved configurations support sales-to-engineering handoff.
    • ETO workflows require additional engineering after configuration.
    • CTO workflows use predefined and validated product options.

    Frequently asked questions

    What is photorealistic product visualization in CPQ?

    It is the generation of realistic images or interactive 3D views that represent a configured product during the CPQ process. In manufacturing, the view should respond to relevant options, dimensions, materials and component selections.

    Is photorealistic visualization the same as 3D product configuration?

    No. 3D product configuration describes the interactive selection and assembly of product components. Photorealistic visualization focuses on rendering appearance. A 3D configurator may use simplified geometry, while a photorealistic viewer emphasizes materials, lighting and realism.

    Does every manufacturing CPQ platform support visualization?

    No. Some platforms provide static images or basic option images, while others support interactive 3D, rendered scenes or CAD-linked visualization. Each capability should be verified in the vendor documentation and evaluated against the target product.

    Does visual CPQ generate CAD files?

    Not necessarily. Visualization and CAD automation are separate capabilities. Some platforms integrate with CAD systems or generate engineering geometry, while others only present visual assets.

    Can a rendered image be used as a manufacturing drawing?

    Usually not. A rendered image is generally a presentation or review output. Manufacturing drawings require controlled dimensions, annotations, tolerances, revisions and engineering approval.

    How do configuration rules affect visualization?

    Rules determine which options are valid and how the visual model changes. They may show or hide components, move assemblies, change dimensions, swap materials or trigger a new CAD representation.

    What is the difference between visual rules and product rules?

    Product rules control technical or commercial validity, such as whether a motor is compatible with a voltage. Visual rules control representation, such as which motor model or material texture appears in the scene.

    Can photorealistic visualization support engineer-to-order products?

    Yes, but it does not eliminate engineering work. It can communicate the intended configuration and support customer approval, while engineers may still need to calculate, design, validate and release the final product.

    What is a configurable BOM in a visual CPQ workflow?

    A configurable BOM is a product structure that resolves into specific components and quantities based on selected options. The visual model may help users understand the result, but the BOM must be generated and governed independently according to manufacturing requirements.

    How does an EBOM differ from an MBOM?

    An EBOM, or engineering bill of materials, represents the design structure. An MBOM, or manufacturing bill of materials, organizes components for production and may include manufacturing assemblies or operations. A visualization does not determine which BOM structure is correct.

    What systems typically integrate with visual CPQ?

    Depending on the implementation, visual CPQ may integrate with CAD, PLM, PDM, ERP, CRM, product information management (PIM), MES and document systems. The presence and depth of each integration varies by platform.

    Should CPQ or PLM own visual assets?

    There is no universal answer. PLM or PDM may govern engineering-linked assets, while CPQ may manage selling-specific mappings. The important requirement is clear ownership, revision control and reliable synchronization.

    What are the main costs of implementing photorealistic visualization?

    Costs may include product-model analysis, CAD or mesh preparation, material and texture creation, rule mapping, integration, rendering infrastructure, testing and ongoing maintenance. The effort increases with product variety, geometry complexity and required accuracy.

    Can customers configure products directly in a browser?

    Yes, if the platform supports browser-based configuration and the manufacturer chooses to expose it. Access may be provided to customers, dealers or internal sales teams, with different levels of technical detail and approval control.

    How should manufacturers test a visual configurator?

    Test valid and invalid combinations, dimensional boundaries, materials, orientations, component substitutions, product revisions, rendering performance and agreement between the visual result, price, BOM and engineering outputs.

    What happens when an engineering revision changes a visible component?

    The manufacturer should update the relevant geometry, visual asset, rule mapping and revision metadata, then retest affected configurations. The system should prevent obsolete assets from appearing in new quotes where appropriate.

    Does photorealistic visualization improve configuration accuracy?

    It can improve user understanding and expose visible misunderstandings, but it does not guarantee technical accuracy. Configuration rules, engineering calculations and controlled product data remain necessary.