CPQ Guide

Tag: Quote-to-production

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