CPQ Guide

Tag: BOM generation

  • CPQ for Heat Exchanger Manufacturers

    CPQ for heat exchanger manufacturers is software that combines product configuration, engineering validation, costing, pricing and quote generation for configurable heat transfer equipment. A suitable system can guide a user through shell-and-tube, plate, air-cooled or other exchanger designs, reject technically invalid combinations, calculate or capture engineering requirements, and pass the resulting product definition to enterprise systems.

    Heat exchanger configuration is a manufacturing problem rather than a simple sales quoting exercise. A quote may depend on duty, flow rates, temperatures, pressure, materials, corrosion allowances, tube dimensions, pass arrangements, nozzle locations, codes, testing requirements and production constraints. The CPQ system must therefore connect commercial inputs with engineering rules and manufacturing data.

    This guide explains how manufacturing CPQ applies to heat exchangers, which rules and data it requires, what outputs it can produce, how it integrates with ERP, CRM, PLM, PDM and CAD systems, and what manufacturers should verify before implementation. The general principles also apply to related equipment such as boilers, condensers, pressure vessels, evaporators and process skids.

    What is CPQ for heat exchanger manufacturing?

    CPQ means configure, price, quote. In heat exchanger manufacturing, it is an application or connected software architecture that represents product families, validates customer requirements, selects compatible components and materials, calculates costs and prices, and produces a technically controlled quotation.

    Generic sales CPQ may combine products, apply discounts and create a proposal. Manufacturing CPQ goes further when required. It can represent engineering relationships such as heat transfer duty, allowable pressure drop, design pressure, design temperature, material compatibility, tube count, surface area and nozzle arrangement. Depending on the platform and implementation, it may also create a configurable bill of material, an engineering bill of material, CAD parameters, datasheet outputs or an engineer-review package.

    Not every CPQ product supports thermal calculations, mechanical design, CAD automation or production BOM generation. Buyers should evaluate each capability as a documented feature or integration rather than assuming it is included because a vendor uses the term manufacturing CPQ.

    Why heat exchangers are difficult to configure

    A heat exchanger is usually a family of related products rather than a single standard item. The commercial model may offer a catalog of standard sizes, but the final design can still be specific to the application, fluid pair, duty and site conditions.

    Configuration area Typical heat exchanger inputs Possible downstream effect
    Thermal duty Heat load, inlet and outlet temperatures, flow rates, fouling factors and allowable approach temperature Heat transfer area, tube count, plate count, exchanger size or selected model
    Fluid and process data Fluid identity, concentration, viscosity, density, phase, solids content and corrosiveness Materials, velocity limits, pressure drop and construction method
    Mechanical design Design pressure, operating pressure, design temperature, vacuum conditions and cyclic service Wall thickness, heads, tubesheets, gaskets, seals and code requirements
    Materials Carbon steel, stainless steel, nickel alloys, titanium, special coatings and elastomers Component eligibility, cost, lead time, welding and procurement requirements
    Geometry Shell diameter, tube length, tube diameter, pass arrangement, frame size and nozzle orientation CAD dimensions, manufacturing operations, footprint and installation fit
    Compliance and testing Applicable pressure vessel code, inspection class, hydrotest, radiography, certification and documentation Engineering review, test plan, labor, subcontracted services and price
    Commercial requirements Quantity, currency, delivery location, warranty, spare parts and service scope Cost, margin, freight, terms and final quote

    These variables are interdependent. Increasing the required duty may increase surface area and exchanger size. A more corrosive fluid may require a different alloy, which changes cost, welding procedures and availability. A lower allowable pressure drop may require more flow area or a different arrangement. A CPQ implementation must model these relationships explicitly or route them to a validated engineering calculation.

    Core CPQ capabilities for heat exchanger manufacturers

    Product models and configuration structure

    The product model defines the exchanger families, options, attributes, components and relationships that users can select. A manufacturer may create separate models for fixed-tube-sheet shell-and-tube exchangers, U-tube exchangers, floating-head exchangers, gasketed plate heat exchangers and welded plate units.

    Each model can contain mandatory inputs, optional features and derived values. For example, a user may select a shell-and-tube family, enter the service conditions, choose a tube material and specify a nozzle standard. The system can derive a candidate size, restrict incompatible tube materials and expose only the head and gasket options that suit the selected pressure and temperature range.

    Product configuration is different from pricing. Configuration determines what product is technically and commercially valid. Pricing then assigns costs, prices, margins, discounts and commercial adjustments to that valid configuration. Keeping the two concerns distinct makes rule testing and maintenance easier. The product configuration guide explains product models, options, dependencies, constraints and validation in greater depth.

    Rules and constraints

    Rules prevent invalid or incomplete designs. Common rule types include:

    • Compatibility rules: a gasket material must be compatible with the selected fluid and temperature range.
    • Range rules: a design pressure, temperature, flow rate or velocity must remain within an approved range.
    • Dependency rules: a floating-head construction requires a compatible shell, tubesheet and maintenance arrangement.
    • Exclusion rules: a particular coating, tube material or nozzle option cannot be combined with a selected code or manufacturing process.
    • Calculation rules: surface area, tube count, shell diameter, estimated pressure drop or weight is derived from input values or an engineering service.
    • Approval rules: non-standard materials, unusual dimensions or ETO requirements require engineering review.

    Rules-based configuration applies explicit if-then relationships. Constraint-based configuration evaluates multiple conditions and seeks a valid combination within a solution space. Guided selling simplifies the user experience by asking a sequence of business or application questions. A heat exchanger CPQ implementation may use all three: guided selling for sales users, constraint validation for technical compatibility, and calculation or engineering services for design outputs.

    Thermal and mechanical engineering calculations

    Some manufacturers use CPQ to collect engineering inputs and pass them to specialist calculation software. Others implement selected calculations directly in the CPQ model. The right boundary depends on calculation complexity, certification requirements, platform capabilities and the manufacturer’s engineering governance.

    Potential calculations include heat transfer area, estimated overall heat transfer coefficient, temperature approach, flow velocity, pressure drop, tube count, pass arrangement, exchanger weight and preliminary dimensions. Mechanical design may require separate analysis for pressure boundary thickness, tubesheets, supports, expansion, vibration or code compliance.

    A commercial configurator should not be treated as a certified design tool merely because it performs arithmetic. Manufacturers should identify which calculations are preliminary, which are design-authoritative, which require engineering approval and which must be performed in validated specialist software. The CAD and engineering automation guide covers the relationship between CPQ, calculations, parametric design and engineering outputs.

    Materials, standards and compliance

    Material selection is often central to heat exchanger configuration. The product model may need to distinguish material grade, product form, corrosion allowance, cladding, surface treatment, weld procedure and traceability requirements. A material that is valid for one fluid or temperature range may be unsuitable for another.

    Rules may also reference pressure vessel codes, customer specifications, inspection requirements and regional documentation. CPQ should capture these requirements as structured data rather than leaving them only in free-text notes. However, the system should distinguish a customer-requested standard from an approved engineering design. Standards, code editions and internal policies require controlled ownership and review.

    Pricing and quoting for heat exchangers

    Heat exchanger pricing usually combines material, fabrication, engineering, testing, purchased components and commercial adjustments. A quote may need to account for metal weight, tube or plate quantity, weld length, machining, surface treatment, inspection, documentation, freight, installation support and expected engineering effort.

    Cost or price driver Example CPQ data Pricing consideration
    Raw materials Shell plate, tubes, plates, frames, heads, nozzles, gaskets and fasteners Quantity, grade, market price, scrap factor and supplier lead time
    Fabrication Rolling, forming, welding, machining, assembly and finishing Labor standards, routing, machine time and setup requirements
    Engineering Thermal design, mechanical checks, drawings and review hours Standard versus non-standard design and ETO complexity
    Testing and certification Hydrostatic testing, non-destructive examination, certificates and witnessed inspection Internal labor and external inspection costs
    Commercial terms Margin, currency, freight, payment terms, warranty and risk allowance Customer, region, project and delivery requirements

    Costing and pricing should use the configured product as their source rather than relying only on a manually selected price list. The system may calculate a standard price for a catalog configuration while flagging a custom design for engineering review and quotation adjustment. The BOM, pricing and quoting guide explains configurable BOMs, costing logic, quote generation and approvals.

    BOM, CAD and manufacturing outputs

    A bill of material, or BOM, lists the components required for a product. Heat exchanger CPQ can produce different BOM representations depending on the business process:

    • Configurable BOM: a rule-driven structure containing selectable components and alternatives.
    • Engineering BOM (EBOM): the engineering view of the designed product, including components, specifications and design relationships.
    • Manufacturing BOM (MBOM): the production view, organized for assembly, operations, work centers, consumables and manufacturing execution.

    An exchanger CPQ system might generate a preliminary EBOM containing shell sections, tubes, tubesheets, baffles, heads, nozzles, gaskets and supports. ERP or manufacturing planning systems may then transform or enrich this into an MBOM with routings, operation sequences and shop-floor requirements. Some platforms can generate a production-ready BOM; others only return a configured item, option codes or a structured data payload for another system.

    CAD automation may create a model or drawing by passing parameters such as shell diameter, tube length, nozzle orientation, support location and plate count to a parametric CAD template. It may also generate a datasheet or dimensional drawing. These outputs require controlled templates, naming conventions, revision management and engineering approval. Visualization can help users understand orientation and footprint, but a 3D image is not necessarily a manufacturing drawing.

    Typical CPQ workflow for a heat exchanger

    1. Capture the application: the user enters fluids, flow rates, temperatures, duty, pressure, installation constraints and applicable standards.
    2. Select a product family: the system proposes or guides the user toward a shell-and-tube, plate, air-cooled or other suitable family.
    3. Validate requirements: rules check ranges, materials, pressure and temperature compatibility, options and mandatory technical data.
    4. Run calculations or engineering services: the system derives a preliminary size or sends the requirements to an approved calculation engine.
    5. Complete configuration: the user selects construction details, materials, nozzles, supports, instruments, insulation, testing and documentation.
    6. Generate cost and price: the system calculates material, labor, engineering, testing and commercial values, applying approved pricing rules.
    7. Route exceptions: non-standard conditions, low margin, unusual materials or code requirements trigger engineering or commercial approval.
    8. Create outputs: the system produces a quote, technical datasheet, assumptions, exclusions, preliminary BOM and, where supported, CAD or drawing data.
    9. Transfer the order: an accepted configuration is sent to CRM, ERP, PLM, PDM, CAD or manufacturing systems with a controlled identifier and revision.

    This workflow can support configure-to-order (CTO), where the manufacturer assembles a validated product from known options, or make-to-order (MTO), where production begins after an order but uses a defined product model. Engineer-to-order (ETO) applies when substantial engineering is required for a specific project. Assemble-to-order (ATO) uses stocked or pre-engineered modules assembled after the order. Heat exchanger businesses often use a mixture of these modes across product families.

    Integration architecture

    CPQ normally sits between customer-facing and engineering or operational systems. A customer relationship management system, or CRM, may provide the opportunity and account context. CPQ manages the configuration, commercial calculation and quote. An enterprise resource planning system, or ERP, may manage items, inventory, purchasing, production orders, finance and fulfillment.

    Product lifecycle management (PLM) manages product definitions, revisions, approvals and lifecycle processes. Product data management (PDM) commonly manages CAD files and engineering documents. Computer-aided design (CAD) tools create models and drawings. A product information management system (PIM) may manage descriptive product and channel content. A manufacturing execution system (MES) manages production execution and shop-floor data. These systems are related but not interchangeable.

    System Typical relationship with CPQ
    CRM Opportunity, customer, account, sales stage and quote context
    ERP Items, costs, prices, inventory, orders, purchasing, production and finance
    PLM Approved product structures, revisions, engineering change and lifecycle governance
    PDM CAD files, drawings, documents and revision-controlled engineering data
    CAD Parametric models, drawings and product-specific geometry
    PIM Descriptions, specifications and channel content for products and options
    MES Production operations, execution instructions, labor and shop-floor feedback

    Integration may use APIs, middleware, files, event messages or direct database processes. The key design question is ownership. For example, CPQ may own the commercial configuration while PLM owns released engineering structures and ERP owns manufacturing items and costs. The CPQ integration guide provides a broader framework for defining these boundaries.

    Benefits and limitations

    Potential benefits

    • Faster preparation of technically consistent quotations.
    • Fewer invalid combinations of materials, dimensions and pressure or temperature requirements.
    • More consistent pricing for material-intensive and engineering-intensive products.
    • Earlier visibility of engineering effort, testing requirements and non-standard work.
    • Improved handoff from sales engineering to design, purchasing and production.
    • Reusable product knowledge instead of dependence on individual experts and spreadsheets.
    • Structured quote data that can support BOM generation, CAD automation and ERP order creation where integrations exist.

    Important limitations

    • A CPQ system cannot compensate for incomplete or contradictory product data.
    • Complex thermal and mechanical design may remain in specialist engineering software.
    • Rules can become difficult to maintain when product families, standards and exceptions are poorly governed.
    • Automatic BOM generation does not guarantee a correct MBOM or production routing.
    • CAD automation depends on robust templates, valid parameters and revision control.
    • Legacy ERP, PLM and CAD systems may make integration more difficult than configuration itself.
    • Sales users may bypass the system if it asks for too many technical inputs without suitable guidance.

    Implementation considerations

    Start with a product family that has meaningful quote volume, repeatable rules and measurable engineering effort. Do not begin by attempting to model every exchanger, customer exception and historical quotation. Establish a controlled scope such as a standard shell-and-tube family or a defined plate exchanger range.

    Build a governed product model

    Document attributes, option values, units, valid ranges, dependencies, default values and approval states. Identify which data is customer input, which is derived, which is calculated externally and which comes from ERP or PLM. Assign ownership for thermal rules, mechanical rules, material compatibility, pricing, drawings and release decisions.

    Separate standard and engineered paths

    A standard configuration can move through automated validation and pricing. A custom configuration may require a calculation package, design review, supplier confirmation or management approval. Both paths can use the same CPQ front end, but they should not pretend to have the same level of automation.

    Test engineering and commercial logic

    Test normal configurations, boundary values, incompatible materials, missing inputs, unit conversions, currency changes, revisions and exception routes. Use real historical requirements where possible, but verify them against current engineering standards. Test both the visible quote and the hidden outputs: BOM lines, item codes, dimensions, calculation results, approvals and integration messages.

    Plan maintenance and change control

    Heat exchanger rules change when materials, suppliers, codes, costs, design policies and product families change. A governance process should define who can change rules, how changes are reviewed, how versions are released and how old quotes remain reproducible. The CPQ implementation guide covers requirements, data migration, testing, deployment, governance and maintenance.

    How to evaluate CPQ software for heat exchangers

    Manufacturers should evaluate the actual product and implementation architecture against representative exchanger cases. A useful demonstration should include a standard design, an invalid material combination, a non-standard pressure requirement, a customer-specific nozzle arrangement, a price change and an ETO approval path.

    • Can the system model multi-level exchanger families and reusable options?
    • Can it express dependencies, exclusions, ranges and conditional requirements?
    • Can it call an external thermal or mechanical calculation service?
    • Can it represent units, formulas, tolerances and engineering assumptions?
    • Can it produce a configurable BOM, EBOM or item structure, and under what conditions?
    • Can it pass parameters to CAD or generate drawings through an approved integration?
    • Can it separate material cost, labor, engineering, testing, freight and margin?
    • Can it support standard CTO or MTO designs alongside ETO exceptions?
    • How are ERP, CRM, PLM, PDM and CAD ownership and revisions handled?
    • How are rules tested, versioned, audited and maintained by internal teams?

    Vendor comparisons should focus on documented capabilities, implementation responsibilities and integration boundaries rather than feature-count claims. The manufacturing CPQ software section and CPQ comparison guides can support a broader selection process.

    Semantic map

    The following relationships summarize how CPQ connects heat exchanger requirements with engineering and manufacturing outputs:

    • Heat exchanger CPQ connects application requirements to product configurations.
    • Configuration rules prevent incompatible materials, dimensions and service conditions.
    • Thermal inputs influence heat transfer area and exchanger selection.
    • Mechanical requirements influence pressure boundary components and construction.
    • Configured products generate structured BOM data when the platform supports BOM generation.
    • CPQ pricing uses configuration data, cost data and commercial rules.
    • CAD automation uses approved parameters to generate product-specific models or drawings.
    • CRM provides opportunity context for the CPQ quote.
    • ERP receives order, item, pricing or BOM data according to the integration design.
    • PLM and PDM govern engineering revisions and released design information.
    • ETO exceptions trigger engineering review rather than uncontrolled automatic release.
    • Manufacturing workflows transform an accepted quote into engineering and production work.

    Frequently asked questions

    1. What does CPQ mean for a heat exchanger manufacturer?

    It means using configure, price, quote software to manage heat exchanger requirements, technical options, validation, pricing and quotation outputs. Depending on the platform, it may also connect to calculations, BOM, CAD and enterprise systems.

    2. Can CPQ calculate the required heat transfer area?

    Some implementations perform selected thermal calculations directly, while others send inputs to specialist engineering software. The calculation method, validation status and engineering approval process must be verified.

    3. Can CPQ replace thermal design software?

    Usually not in every situation. CPQ may handle preliminary sizing or orchestrate a calculation service, but complex or code-controlled designs may still require dedicated thermal and mechanical engineering tools.

    4. Which heat exchanger types can CPQ model?

    It can be configured for shell-and-tube, gasketed plate, welded plate, brazed plate, air-cooled and other product families if their options, rules and calculations are properly modeled.

    5. Does CPQ generate a BOM for a heat exchanger?

    Some platforms generate configurable BOMs or engineering BOMs. Others pass option selections to ERP or PLM for BOM resolution. A buyer should confirm whether the output is an EBOM, MBOM, configurable structure or only an item code.

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

    An EBOM is the engineering view of the designed exchanger. An MBOM is organized for manufacturing, including production structure, operations, consumables or work-center needs. They may not be identical.

    7. Can CPQ automate heat exchanger CAD drawings?

    Some CPQ architectures integrate with parametric CAD or document-generation tools. Automation depends on stable templates, supported parameters, revision control and engineering approval; it is not a universal CPQ feature.

    8. How does CPQ handle material compatibility?

    The product model can use compatibility rules based on fluid, concentration, temperature, pressure, corrosion requirements and approved material lists. Engineering review may still be required for unusual services.

    9. Can CPQ support pressure vessel codes?

    It can capture code selections and apply related options or approval rules. Code compliance calculations and certification should remain under the manufacturer’s controlled engineering process unless specifically validated.

    10. Can CPQ price custom heat exchangers?

    Yes, if cost drivers and commercial rules are modeled. Custom designs may require engineering hours, supplier quotations, material risk allowances or manual approval rather than a fully automatic price.

    11. Is CPQ suitable for engineer-to-order heat exchangers?

    It can support ETO by capturing structured requirements, identifying exceptions and creating an engineering handoff. It does not eliminate the engineering work required for genuinely novel designs.

    12. What is the role of ERP in a heat exchanger CPQ architecture?

    ERP commonly manages items, costs, purchasing, inventory, production orders, finance and fulfillment. CPQ may send the accepted configuration, price, item data or BOM to ERP, depending on system ownership.

    13. What is the role of PLM or PDM?

    PLM manages product lifecycle, revisions and engineering approvals. PDM commonly manages CAD files and documents. They help control released design information that CPQ should not independently duplicate or release.

    14. Can distributors use heat exchanger CPQ?

    Yes. A distributor-facing configuration can expose approved product choices, application questions, pricing and quotation workflows while hiding internal engineering complexity. Complex exceptions should route to the manufacturer.

    15. How should a manufacturer start a CPQ project?

    Start with one product family, define its rules and data ownership, map the quote-to-production process, establish integration boundaries and test representative configurations before expanding scope.

    16. What are the biggest CPQ implementation risks?

    Common risks include incomplete product data, undocumented engineering knowledge, over-complex rules, unclear system ownership, weak testing, poor revision control and attempting to automate ETO designs too early.

    17. How is manufacturing CPQ different from generic sales CPQ?

    Manufacturing CPQ must often represent engineering constraints, materials, dimensions, calculations, BOMs, CAD outputs and production handoffs in addition to price and quote documents.

    18. What should be included in a heat exchanger CPQ proof of concept?

    Use a standard exchanger, a boundary condition, an incompatible material case, a custom nozzle or dimension request, a cost change, an approval route and a downstream output such as a BOM, datasheet or ERP payload.

  • CPQ for Conveyor System Manufacturers

    CPQ software for conveyor system manufacturers helps sales and engineering teams configure valid conveyor systems, calculate pricing, produce accurate quotations and pass structured product data to engineering and manufacturing. Unlike generic sales CPQ, manufacturing CPQ can model conveyor dimensions, capacities, materials, drives, transfers, guarding, controls and installation requirements, then generate a configurable bill of materials (BOM), engineering outputs or order data when the selected platform supports those capabilities.

    Conveyor projects are rarely defined by one product number. A quote may combine straight conveyors, curves, inclines, transfers, elevators, hoppers, sensors, controls and safety systems into a material-handling solution designed for a particular layout and operating environment. The commercial value of CPQ depends on how accurately it represents those relationships and how reliably it transfers the result into enterprise and engineering systems.

    This guide explains the configuration complexity, rules, pricing logic, CAD and BOM outputs, integrations, workflows, benefits and implementation considerations for conveyor manufacturers evaluating CPQ.

    Why conveyor manufacturers use CPQ

    Conveyor manufacturers often sell configurable equipment rather than a single standardized item. The final system may be configured for a specific product size, throughput, footprint, elevation change, temperature, washdown requirement, load, speed or site layout. Sales engineers must therefore combine commercial decisions with mechanical, electrical and operational constraints.

    A manufacturing CPQ application can provide a controlled product model in which users select options and enter engineering parameters. The system validates those choices, applies calculations and produces a quote based on the resulting configuration. Depending on its architecture, it may also generate a configurable BOM, manufacturing BOM (MBOM), engineering BOM (EBOM), CAD model, drawings, work instructions or data for an enterprise resource planning (ERP) system.

    Problem How CPQ can help
    Sales teams select incompatible conveyor components Rules and constraints prevent invalid combinations or require engineering review.
    Prices depend on dimensions, materials and options Pricing and costing logic calculates the commercial result from configuration data.
    Engineering repeatedly rebuilds similar proposals Reusable product models and design automation reduce manual re-entry.
    Quotes do not contain manufacturing-ready detail Supported systems can generate structured BOM data and downstream order information.
    Dealers lack access to engineering expertise Guided configuration can expose approved choices while hiding unsafe complexity.

    Conveyor system configuration complexity

    A conveyor CPQ model should represent the product architecture, not only a list of selectable accessories. The architecture may include conveyor families, modules, assemblies, options, dimensions, materials, drive packages and controls. It should also distinguish choices that are visible to a customer from technical parameters calculated by the system.

    Typical conveyor parameters

    • Conveyor type, such as belt, roller, chain, screw, slat, drag, overhead or flexible conveyor.
    • Overall length, width, height, elevation, incline angle and transfer spacing.
    • Product dimensions, product weight, load distribution and required throughput.
    • Belt, chain, roller, slat or flight material and surface specification.
    • Frame construction, support arrangement, leg spacing, mounting and access requirements.
    • Motor type, gearbox, drive location, speed range, torque and electrical supply.
    • Controls, variable-frequency drives, sensors, starters, programmable logic controller interfaces and network requirements.
    • Guarding, emergency stops, pull cords, covers, interlocks and other safety-related equipment.
    • Environmental requirements, including washdown, corrosion resistance, dust, temperature and hazardous-area considerations.
    • Ancillary equipment such as hoppers, chutes, transfers, turntables, diverters, lifts and accumulation zones.
    • Finish, coating, stainless-steel grade, fastener material and hygienic design requirements.
    • Installation, commissioning, documentation, spare parts and service options.

    These parameters are related. Increasing width can change belt selection, frame size, motor requirements, guarding dimensions and price. A longer conveyor may require additional supports, splice points, drives or structural analysis. An incline may require cleats, sidewalls, a higher-capacity drive and specific product-retention rules.

    Rules and constraints in conveyor CPQ

    Configuration rules determine which choices are allowed, required, recommended or calculated. In conveyor manufacturing, rules should cover both commercial dependencies and engineering constraints.

    Examples of conveyor configuration rules

    • If the conveyor is configured for an incline above a defined angle, require cleated belting, sidewalls or another approved product-retention solution.
    • If product weight exceeds the capacity of a roller or belt selection, reject the combination or require a higher-capacity component.
    • If washdown service is selected, restrict frame, bearing, motor and fastener choices to approved materials and protection ratings.
    • If a conveyor includes a transfer, require compatible elevations, transition dimensions and control logic.
    • If the selected length exceeds a manufacturing or transport limit, split the conveyor into sections and add connection hardware.
    • If a hazardous environment is specified, require an approved electrical and motor package and route the configuration for specialist review.
    • If a variable-speed drive is selected, add the drive, enclosure requirements, controls and associated wiring or documentation.
    • If a specific product family is selected, limit available widths, speeds, belt types or support arrangements to validated values.

    It is useful to distinguish three related approaches. Rules-based configuration uses explicit conditions such as “if A, require B.” Constraint-based configuration evaluates relationships such as capacity, dimensions, compatibility and limits. Guided selling simplifies the user experience by asking business-oriented questions and presenting recommended choices. A conveyor CPQ implementation may use all three, but guided selling alone does not prove that engineering constraints are being validated.

    Product configuration should also be separated from pricing and quoting. Configuration determines what the conveyor system is. Pricing determines what that configuration costs or should be sold for. Quoting presents the commercial offer, terms, assumptions, delivery information and approvals. These functions may be integrated in one CPQ product, but they require different data and governance.

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

    Pricing and costing for conveyor systems

    Conveyor pricing often combines discrete components, dimensional calculations, purchased items, labor assumptions, engineering effort and commercial policies. A pricing engine may calculate a result from the configured BOM, while a costing model estimates the internal cost of materials, fabrication, assembly, testing and services.

    Pricing input Conveyor example
    Dimensional quantity Price per meter of belt, frame, chain, cable track or guarding.
    Component selection Motor, gearbox, sensor, roller, bearing, drive or control package.
    Material and finish Carbon steel, painted steel, stainless steel, coating or hygienic finish.
    Engineering calculation Drive sizing, belt selection, capacity, supports or structural requirements.
    Commercial adjustment Customer segment, dealer discount, project margin, currency or volume pricing.
    Project services Layout design, site survey, installation, commissioning, training and documentation.

    Pricing should be traceable. Users should be able to understand whether a change in price came from length, material, a required component, a discount, an engineering charge or a project service. Manufacturers should also define which values are authoritative in the CPQ system and which remain in ERP or another financial system.

    A quote can contain a system-level price for customer readability while retaining detailed line items for costing, procurement and production. The implementation should define how these views remain synchronized and how revisions are controlled.

    BOM, CAD and engineering outputs

    A configured conveyor can produce several types of product data, and these should not be treated as interchangeable.

    • Configurable BOM: a product structure containing variable components and rules that resolve according to the selected configuration.
    • Engineering BOM (EBOM): an engineering-oriented structure describing the designed product, often managed in a product lifecycle management (PLM) or product data management (PDM) system.
    • Manufacturing BOM (MBOM): a production-oriented structure arranged for fabrication, assembly, routing and manufacturing operations.
    • CAD output: a product-specific three-dimensional model, two-dimensional drawing, layout or parameter set generated through computer-aided design automation where supported.

    Not every CPQ platform generates these outputs. Some systems create a quote and pass selected options to ERP, while others include product configuration, BOM generation, engineering calculations and CAD automation. Buyers should verify the documented scope, supported CAD systems, revision handling, output formats and ownership of the resulting data.

    For example, a CPQ configuration may calculate a 12-meter stainless-steel belt conveyor with two drives, three support sections, a washdown motor package and guarding. The output could include a resolved component list for pricing, an EBOM for engineering review, an MBOM for fabrication and a CAD layout showing section lengths and elevation. In another implementation, CPQ may only create the commercial configuration and leave BOM and CAD generation to an ERP, PLM or engineering application.

    Read more about CAD and engineering automation and BOM, pricing and quote automation.

    Example workflow for a conveyor manufacturer

    1. Opportunity and requirements: A sales engineer records product dimensions, load, throughput, layout, elevation, environment and delivery requirements.
    2. Product family selection: The CPQ application identifies a suitable conveyor family, such as belt, powered roller or chain conveyor.
    3. Guided configuration: The user selects dimensions, materials, drive arrangement, controls, guarding and ancillary modules.
    4. Validation: Rules check capacity, dimensions, component compatibility, environmental requirements and mandatory safety options.
    5. Engineering calculations: Where supported, the system calculates or retrieves values such as speed, power, torque, belt selection or support requirements.
    6. Cost and price: The system resolves components, applies costs, labor assumptions, discounts, margin rules and project services.
    7. Review and approval: Non-standard selections, low-margin quotes or engineered exceptions are routed to the appropriate reviewer.
    8. Quote generation: The customer receives a proposal containing scope, configuration summary, price, assumptions, exclusions, delivery terms and relevant drawings.
    9. Order conversion: Approved data is transferred to CRM, ERP, PLM, PDM, CAD or manufacturing systems according to the target architecture.
    10. Engineering and production: The order is finalized through design review, procurement, fabrication, assembly, testing, installation and commissioning.

    This workflow can support configure-to-order (CTO), make-to-order (MTO) or engineer-to-order (ETO) processes. CTO uses pre-engineered products selected from an approved model. MTO manufactures an item after the order, often with limited design variation. ETO requires engineering work for the specific order. A conveyor manufacturer may use CTO for standard modules, MTO for dimensional variants and ETO for unusual layouts, capacities or site conditions within the same commercial process.

    The distinction between assemble-to-order (ATO) and CTO is also important. ATO typically assembles stocked or prebuilt modules after an order, whereas CTO emphasizes configuring an approved product definition. A single conveyor business may use both approaches for different product families.

    Integration architecture

    CPQ usually sits between customer-facing or commercial systems and engineering or operational systems. The exact architecture depends on which application owns product, customer, price, BOM and order data.

    System Typical relationship with conveyor CPQ
    CRM, or customer relationship management Provides accounts, opportunities, contacts and sales context; receives quote status and commercial results.
    ERP, or enterprise resource planning Manages items, inventory, purchasing, manufacturing orders, finance and order execution.
    PLM, or product lifecycle management Controls product definitions, revisions, approvals and lifecycle information.
    PDM, or product data management Manages engineering files, CAD documents, revisions and relationships.
    CAD, or computer-aided design Provides models, drawings, layouts or parameters for product-specific engineering outputs.
    PIM, or product information management Maintains reusable product descriptions, specifications, images and commercial content.
    MES, or manufacturing execution system May receive production instructions, work-order data or execution information.
    Ecommerce or dealer portal Exposes an appropriate subset of configuration and pricing to external users.

    Integration design should define the system of record for item numbers, revisions, prices, customer data, configuration versions, drawings and BOMs. It should also define whether CPQ sends a complete resolved BOM or only a configuration identifier, and how changes are handled after a quote becomes an order.

    Explore CPQ integrations with ERP, CRM, PLM, PDM and CAD before selecting an architecture.

    Dealer, distributor and self-service configuration

    Conveyor manufacturers may sell through distributors, integrators, material-handling specialists or regional dealers. A dealer-facing CPQ application can expose approved product families, standard dimensions, pricing rules and proposal templates without exposing every engineering variable.

    Access controls may be needed for territory, currency, discount authority, product availability and customer-specific pricing. A dealer configuration should be able to identify when an application exceeds standard limits and requires manufacturer review. Self-service or ecommerce configuration is most appropriate for well-defined conveyor modules and accessories; complex integrated systems may still require an application engineer.

    Benefits and limitations

    Potential benefits

    • Fewer invalid configurations caused by incompatible dimensions, components or operating conditions.
    • Shorter quote preparation for repeatable conveyor families.
    • More consistent pricing, discounts, margins and commercial assumptions.
    • Less duplicate entry between sales, engineering and order administration.
    • Better visibility of the configured scope before manufacturing begins.
    • Faster creation of BOMs, drawings or engineering requests where the platform supports them.
    • More controlled dealer and distributor access to configurable products.

    Important limitations

    • A CPQ system cannot compensate for an incomplete or incorrect product model.
    • Complex site layouts, unusual loads and safety questions may still require specialist engineering.
    • CAD automation can be difficult when conveyor designs contain extensive custom geometry or legacy drawings.
    • Pricing accuracy depends on current item costs, labor assumptions, supplier data and revision control.
    • Rules may become difficult to maintain if product logic is duplicated across CPQ, CAD, ERP and spreadsheets.
    • Integration does not automatically resolve ownership conflicts between ERP, PLM, PDM and CPQ.
    • Overly restrictive rules can prevent legitimate engineered solutions, while weak rules allow unsafe or unprofitable configurations.

    Implementation considerations

    A conveyor CPQ project should begin with a representative product family rather than an attempt to model every product and exception at once. Choose a family with meaningful configuration volume, known rules, measurable quote effort and a manageable downstream process.

    Recommended implementation questions

    • Which conveyor families are standard, configurable, make-to-order or engineer-to-order?
    • Which parameters are entered by sales, calculated by CPQ or determined by engineering?
    • Which rules are safety-critical, capacity-related, commercial or merely advisory?
    • Who owns product rules and who approves changes?
    • What is the authoritative source for item masters, costs, prices, revisions and CAD files?
    • Does the required output need to be a quote, resolved BOM, EBOM, MBOM, drawing, layout, order or engineering request?
    • How will non-standard configurations be escalated and tracked?
    • How will the model be tested against historical orders and known invalid combinations?
    • How will product changes, supplier substitutions and discontinued components be released?
    • What permissions are required for sales engineers, dealers, engineering, finance and administrators?

    Testing should include normal configurations, boundary values, incompatible options, missing data, revision changes, discounts, currency, partial assemblies and exception workflows. Manufacturers should test not only whether a quote looks correct, but whether the resulting item data, BOM, drawings and ERP transaction are usable by downstream teams.

    Governance is an ongoing responsibility. Product managers may own commercial options, engineering may own technical constraints, manufacturing may own MBOM structures and finance may own margin policies. A clear change process prevents one team from changing a rule without understanding its impact on quoting, design, procurement or production.

    For planning, migration, testing, deployment and governance, see the manufacturing CPQ implementation guide.

    How to evaluate CPQ software for conveyor manufacturing

    Manufacturers should evaluate the depth of the product model rather than count generic quote features. A suitable assessment should demonstrate a real conveyor configuration, including dimensional calculations, options, exceptions, price changes, BOM behavior and downstream handoff.

    Evaluation area Questions to verify
    Configuration depth Can the system model modules, dimensions, dependencies, calculations and nested assemblies?
    Rules and constraints Can it prevent invalid combinations and explain or route exceptions?
    BOM support Can it generate or exchange the required configurable BOM, EBOM or MBOM?
    CAD and engineering Does it support the required CAD automation, drawings, layouts or calculations, and under what conditions?
    Pricing and costing Can it handle dimensional pricing, purchased components, labor, services, currency and margin rules?
    Workflow Can it support sales review, engineering approval, dealer access and order conversion?
    Integration Are APIs and documented connectors available for the required ERP, CRM, PLM, PDM or CAD systems?
    Governance Can product experts maintain and test rules without uncontrolled code changes?

    Ask vendors to distinguish standard functionality, configuration, custom development, third-party applications and roadmap items. A platform that is strong at sales quoting may not generate manufacturing BOMs or CAD. Conversely, an engineering configurator may require additional work for customer-facing proposals, approvals or dealer pricing. These distinctions should be recorded in the selection process. Related selection guidance is available in the manufacturing CPQ comparisons and selection resources.

    Semantic map

    The following relationships summarize how CPQ connects conveyor product configuration with engineering, commercial and manufacturing processes:

    • CPQ connects conveyor configuration, pricing, quoting and downstream manufacturing data.
    • Conveyor product models contain modules, dimensions, materials, drives, controls and safety options.
    • Configuration rules prevent incompatible conveyor combinations.
    • Constraint-based configuration validates capacity, dimensions, speed and environmental requirements.
    • Guided selling presents approved conveyor choices to sales engineers and dealers.
    • Configured conveyor systems generate resolved component data when BOM functionality is available.
    • EBOM represents the engineered conveyor product structure.
    • MBOM represents the conveyor structure for production and assembly.
    • CAD automation generates product-specific conveyor models, layouts or drawings when supported.
    • Pricing engines calculate conveyor prices from dimensions, components, materials and services.
    • ERP receives or supplies item, cost, order and manufacturing data.
    • PLM and PDM manage product revisions, engineering definitions and CAD information.
    • CRM provides opportunity and customer context for conveyor quotations.
    • CTO uses approved conveyor configurations for repeatable products.
    • ETO routes non-standard conveyor requirements to engineering.

    Frequently asked questions

    What is CPQ for conveyor system manufacturers?

    It is software that configures conveyor products or systems, validates technical choices, calculates prices and creates quotes. Depending on the platform, it may also generate BOMs, CAD outputs or data for ERP and engineering systems.

    How is manufacturing CPQ different from generic sales CPQ?

    Generic sales CPQ often focuses on options, discounts and quote documents. Manufacturing CPQ must also represent product structures, engineering constraints, dimensions, materials, calculations, BOMs, revisions and production handoffs where required.

    What conveyor products can be modeled in CPQ?

    Models may cover belt, roller, chain, slat, screw, overhead, drag, flexible and modular conveyors, along with transfers, curves, inclines, drives, controls, guarding and ancillary equipment.

    Can CPQ calculate conveyor motor size?

    Some platforms support engineering calculations or integrations that can assist with motor, torque, speed or power selection. This must be verified for the specific product and calculation method; it should not be assumed from the presence of a CPQ label.

    Can CPQ generate a conveyor BOM?

    Some manufacturing CPQ systems can generate a resolved or configurable BOM. Others only pass configuration data to ERP, PLM or another application. Buyers should verify the BOM type, structure, revision behavior and export method.

    What is the difference between an EBOM and an MBOM for conveyors?

    An EBOM describes the engineered conveyor product, while an MBOM organizes materials and assemblies for production. They may contain different structures, quantities, references and manufacturing information.

    Can CPQ automate conveyor CAD drawings?

    Some systems support CAD automation or integration with parametric design tools. Automation is more predictable for standardized product families and may require engineering review for unusual layouts or custom geometry.

    How does CPQ price a conveyor system?

    It can combine dimensional rates, component prices, material selections, labor, engineering services, installation, discounts, currency and margin rules. The exact calculation depends on the implemented pricing model and connected data.

    Can a conveyor CPQ system support custom projects?

    It can support standard configuration and route non-standard requirements to engineering. Fully engineered conveyor projects may require an ETO workflow, manual design work or integration with CAD and PLM.

    Does conveyor CPQ replace sales engineers?

    No. It can automate repeatable configuration and calculations, but sales engineers remain important for applications, site conditions, safety, layout interpretation and exceptions.

    Can dealers use CPQ to configure conveyors?

    Yes, when the platform supports external users, permissions, pricing controls and approval workflows. Dealer access should expose approved choices and escalate configurations outside standard limits.

    What integrations are important for conveyor manufacturers?

    Common integration targets include CRM, ERP, PLM, PDM, CAD, PIM and MES. The priority depends on whether the business needs customer context, item and order processing, engineering control, product content or production execution.

    Should conveyor pricing live in CPQ or ERP?

    Many architectures use CPQ for configuration-dependent pricing and ERP for financial, item and order processes. The correct split depends on data ownership, update frequency, costing requirements and integration design.

    How should conveyor configuration rules be maintained?

    Assign ownership to product, engineering, manufacturing and commercial stakeholders according to the rule type. Use version control, approval, regression testing and documented release processes.

    What is a good first CPQ project for a conveyor manufacturer?

    A good pilot is a repeatable product family with significant quoting volume, known configuration rules and a manageable number of downstream outputs. It should be complex enough to demonstrate value without including every custom project.

    How can manufacturers test conveyor CPQ accuracy?

    Test historical orders, valid and invalid combinations, boundary dimensions, capacity limits, discounts, BOM outputs, drawings, revisions and ERP transactions. Include engineering and production users in acceptance testing.

    Can CPQ support conveyor configure-to-order and engineer-to-order workflows?

    Yes, if the platform and process support both approved configurations and exception routing. CTO can handle repeatable products, while ETO requires engineering tasks, review and often additional CAD or PLM work.

    What are the main risks of implementing conveyor CPQ?

    Common risks include incomplete product data, duplicated rules, inaccurate costs, excessive customization, unclear ownership and weak integration testing. A disciplined product-model and governance process reduces these risks.

  • Manufacturing CPQ Implementation Guide

    Implementing manufacturing CPQ is a product-modeling and operational transformation project, not simply a software installation. A successful implementation connects configurable products, engineering rules, pricing, quotations and downstream manufacturing data while preserving clear ownership of product information.

    CPQ means configure, price, quote. In a manufacturing environment, the system may also validate technical requirements, calculate dimensions or performance, generate a configurable bill of materials (BOM), create engineering outputs and exchange order data with enterprise systems. The exact scope depends on the selected platform and the manufacturer’s processes; not every CPQ product supports CAD automation, engineering calculations, BOM generation or engineer-to-order workflows.

    The recommended approach is to begin with a defined product and process scope, establish a governed product model, separate configuration from pricing logic, integrate systems through explicit data contracts, test realistic product combinations and roll out in controlled stages. The implementation should be owned jointly by sales, engineering, manufacturing, finance and information technology rather than by sales operations alone.

    What manufacturing CPQ implementation involves

    Manufacturing CPQ implementation is the process of designing, configuring, integrating, testing and deploying a CPQ system so that it can produce valid commercial and technical outputs for configurable products.

    A manufacturing implementation typically covers several connected capabilities:

    • Product configuration: selecting valid models, options, dimensions, materials, accessories and performance characteristics.
    • Rules and constraints: preventing incompatible combinations and deriving required components or settings.
    • Engineering calculations: sizing or validating products when supported by the platform or connected engineering services.
    • Pricing and costing: calculating list prices, discounts, surcharges, estimated costs, margins and currencies.
    • Quoting: generating commercial quotations, proposals, approvals and validity dates.
    • Manufacturing data: producing a configurable BOM, engineering bill of materials (EBOM), manufacturing bill of materials (MBOM), routing information or order attributes where supported.
    • CAD and documents: creating drawings, models or technical documents through CAD automation or connected applications where available.
    • Integration: exchanging data with customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES), product information management (PIM) systems and CAD tools.

    This is broader than generic sales CPQ, which may focus mainly on selecting commercial products, applying discounts and producing a proposal. A manufacturing CPQ project must also address technical validity, engineering ownership, production requirements and the lifecycle of product rules. The manufacturing CPQ guide provides a broader overview of this distinction.

    Define the implementation scope before selecting features

    Manufacturers often start with an ambitious list that includes configuration, visual selection, calculations, CAD, BOMs, costing, pricing, dealer portals and ERP integration. Treating every capability as a first release increases modeling and testing risk. Define the business problem and release boundaries first.

    Document the current process

    Map how a quote is created today. Identify where a salesperson selects options, where an application engineer checks feasibility, where prices are calculated, where a BOM is created and how the order reaches production. Record manual spreadsheets, email approvals, engineering overrides and duplicate data entry.

    For an industrial pump manufacturer, the process may include selecting flow, head, fluid, temperature, materials, motor type, seal arrangement and connection standard. A valid selection may require a hydraulic calculation, a motor check, a material compatibility rule, a pump assembly BOM and a customer-specific price. Each activity should be assigned to a system or person rather than assumed to belong in CPQ.

    Choose a focused first product family

    A good pilot product has meaningful configuration complexity, visible commercial value and reasonably reliable source data. Avoid beginning with an entire portfolio containing unrelated product families, inconsistent part numbering and undocumented exceptions.

    Define whether the initial release supports configure-to-order (CTO), make-to-order (MTO), assemble-to-order (ATO) or engineer-to-order (ETO). CTO uses predefined options and rules. ATO assembles stocked subassemblies or modules. MTO produces a configured product after the order. ETO requires new or substantially modified engineering work for a particular order. A CPQ system may support more than one model, but the data and workflow requirements differ.

    Establish the implementation team and decision rights

    CPQ product models contain commercial, technical and operational decisions. A cross-functional team should therefore include:

    • a business owner responsible for measurable outcomes;
    • a product manager or configuration owner responsible for product structure;
    • sales or application engineering representatives who understand customer requirements;
    • design and manufacturing engineering representatives;
    • pricing, costing and finance representatives;
    • ERP, CRM, PLM, PDM, CAD and integration specialists as applicable;
    • quality assurance and data migration personnel;
    • change management and training owners.

    Define who can approve a new option, change a compatibility rule, modify a price, release a CAD template or change an ERP mapping. Without decision rights, the system becomes a collection of undocumented exceptions. The CPQ implementation and governance guide can be used to structure roles, milestones, testing and operational ownership.

    Build a manufacturing product model

    The product model is the structured representation of what can be sold and how it behaves. It should not be a direct copy of a marketing brochure or a flat list of part numbers.

    Separate product concepts

    Product-model element Purpose Industrial example
    Product family Groups related products with common logic Horizontal centrifugal pumps
    Feature or parameter Captures a customer or engineering decision Flow rate, voltage or enclosure rating
    Option Represents a selectable value or component Stainless-steel casing
    Dependency Connects one selection to another A high-temperature seal requires a compatible material
    Constraint Prevents an invalid combination A motor cannot be selected below the calculated power requirement
    Derived value Calculates or assigns a result from inputs Recommended impeller diameter
    Output mapping Translates selections into downstream data ERP item, BOM component or CAD parameter

    Keep customer-facing language separate from internal codes. A user may select “outdoor stainless enclosure,” while the system must map that choice to an approved item, engineering attribute and ERP value. This separation supports clearer interfaces and reduces disruption when internal part numbering changes.

    Model rules in layers

    Use different rule types for different decisions:

    • Selection rules determine which options are visible or available.
    • Validation rules identify invalid combinations, such as incompatible voltage and motor selections.
    • Dependency rules add required accessories, components or features.
    • Calculation rules derive dimensions, capacities, quantities or performance values.
    • Commercial rules apply prices, discounts, surcharges and approval thresholds.
    • Output rules map a configuration to a BOM, drawing parameter, ERP material or manufacturing instruction.

    Rules-based configuration evaluates explicit conditions. Constraint-based configuration evaluates relationships and permissible values, which can be more appropriate for products with many interacting technical variables. Guided selling helps a user arrive at a product by asking questions in a controlled sequence, but it does not by itself replace engineering constraints. These approaches can coexist and should not be treated as interchangeable.

    Prepare and govern product data

    Most implementation difficulty comes from incomplete or contradictory product data rather than from the configuration screen. Before modeling, create a source-of-truth inventory for options, components, prices, units, revisions, documents and engineering constraints.

    Important preparation activities include:

    1. identify duplicate and obsolete part numbers;
    2. standardize units, naming, currencies and attribute values;
    3. identify effectivity dates and product revisions;
    4. classify options as configurable, mandatory, derived, obsolete or engineering-only;
    5. document approved substitutes and regional variations;
    6. separate standard products from ETO exceptions;
    7. define ownership for product, price, engineering and manufacturing data;
    8. record the source system for each attribute and identifier.

    Do not migrate every historical exception into the new model. A quote history may contain one-off engineering decisions that should remain controlled exceptions rather than become permanent selectable options. Data migration should preserve required history while creating a cleaner structure for future transactions.

    Design pricing, costing and quoting separately from configuration

    Configuration answers whether and how a product can be built. Pricing determines what the customer is charged. Costing estimates the economic impact of the configuration. Quoting presents the result commercially. These concerns are related but should be designed separately.

    A configured machine might require a base model price, option prices, material surcharges, freight, installation, commissioning and a project-specific discount. Its estimated cost may include purchased components, labor, manufacturing overhead and external services. The quote may also require approval if the margin falls below a threshold.

    Define:

    • price books and effective dates;
    • customer, region, currency and channel rules;
    • discount authority and approval levels;
    • cost sources and whether costs are estimates or actual values;
    • tax, freight, installation and service treatment;
    • quotation revisions, expiration dates and audit history;
    • how prices are synchronized with ERP or finance systems.

    Pricing data should not be embedded invisibly in configuration rules. A rule stating that a 400-volt motor is required for a certain configuration is technical. A rule applying a regional surcharge to that motor is commercial. Keeping these concerns distinct makes testing and future price changes safer. See the guide to BOM generation, pricing and quote automation for related design considerations.

    Design BOM, CAD and engineering outputs

    A bill of materials is a structured list of components. An engineering bill of materials (EBOM) describes the product from an engineering perspective, while a manufacturing bill of materials (MBOM) organizes components for production. A configurable BOM may contain rules that include, exclude or quantity-adjust components based on the selected configuration.

    Decide whether CPQ will:

    • create a sales or reference BOM only;
    • generate an EBOM for engineering review;
    • produce or contribute to an MBOM;
    • send component selections to ERP or PLM;
    • trigger an engineering workflow for non-standard requirements.

    Do not assume that a CPQ-generated BOM is automatically production-ready. Manufacturing may need routings, work centers, effectivity, packaging, quality instructions and plant-specific substitutions that belong in ERP, PLM or MES. Define which system owns each downstream structure.

    CAD automation can generate product-specific models, drawings or documents by passing configuration parameters to a CAD system or template. This requires stable parameter names, validated design templates, controlled revisions and error handling. If CAD automation is not supported, CPQ may instead produce engineering inputs for a separate design process. The CAD and engineering automation guide explains these distinctions.

    Plan the integration architecture

    CPQ rarely replaces the systems that manage all enterprise data. It should exchange the right data with each system and avoid becoming an uncontrolled master for information owned elsewhere.

    System Typical relationship with CPQ Questions to resolve
    CRM Opportunity, account, contact and quote context Which system owns the opportunity and quote status?
    ERP Items, prices, customers, orders, inventory and financial data How are configured items and orders represented?
    PLM Product revisions, engineering structures and release status Which released attributes and structures can CPQ use?
    PDM CAD files, documents and design metadata How are approved files and revisions referenced?
    CAD Parameters, models, drawings and technical outputs What inputs are required and how are failures handled?
    PIM Product descriptions, media and channel content Which system owns customer-facing content?
    MES Production execution data and manufacturing status Does CPQ send production instructions or only order data?

    Specify identifiers, data ownership, interface direction, timing, error handling, security and version behavior for every integration. A synchronous API may be appropriate for validation or pricing, while batch synchronization may be sufficient for catalog data. The CPQ integration guide covers these system boundaries in more detail.

    Build and test the product model

    Testing must cover more than whether a user can complete a quote. It should confirm that the configuration is technically valid, commercially accurate and usable by downstream teams.

    Use structured test cases

    Create test cases from real products, historical quotes, engineering calculations and known failure modes. Include:

    • minimum and maximum dimensions;
    • each required option and major option family;
    • incompatible materials, voltages, pressures or ratings;
    • regional, currency and customer-specific pricing;
    • substitutions and obsolete components;
    • calculation boundary conditions;
    • standard CTO configurations;
    • ETO triggers and manual engineering review;
    • ERP, CRM, PLM, CAD or document-generation failures;
    • revisions made after a quote has been issued.

    Test in layers

    1. Unit testing: test individual rules, calculations and mappings.
    2. Model testing: test interactions among features, options and constraints.
    3. Integration testing: verify messages, identifiers, revisions and error responses between systems.
    4. End-to-end testing: configure, price, approve, quote, order and produce representative products.
    5. User acceptance testing: have sales, engineering, manufacturing and finance perform real tasks.
    6. Regression testing: repeat a controlled test suite after every significant model or integration change.

    Test both valid and invalid configurations. A system that produces a quote quickly but allows an impossible pump, unsafe electrical combination or incomplete machine BOM has not passed manufacturing acceptance.

    Plan rollout, adoption and operational support

    Rollout should reflect the organization’s ability to maintain the model. A phased deployment may begin with internal application engineers, then expand to sales, dealers, distributors or customers. Each phase should have explicit entry and exit criteria.

    Training should explain not only which buttons to use, but why the system asks particular questions, what an error means and when to request engineering review. Provide different guidance for sales users, application engineers, product administrators, pricing specialists and integration support.

    During hypercare, monitor configuration failures, manual overrides, quote rework, approval queues, integration errors and questions from users. A temporary support process should identify whether an issue is a data defect, a rule defect, a user-interface problem, a training gap or a legitimate product exception.

    Governance and lifecycle maintenance

    Manufacturing products change continuously. New motors, materials, suppliers, standards, plants, currencies and customer requirements can make a CPQ model inaccurate unless changes are controlled.

    Establish a release process that includes:

    • change request and business justification;
    • impact analysis across rules, prices, BOMs, CAD and integrations;
    • review by technical and commercial owners;
    • versioning and effectivity dates;
    • automated and manual regression testing;
    • deployment approval and rollback planning;
    • communication to affected users;
    • post-release monitoring.

    Measure the quality of the model as well as the speed of the application. Useful indicators include quote cycle time, engineering touches per quote, invalid configuration attempts, manual overrides, pricing corrections, BOM errors, approval duration, order re-entry and the percentage of quotes completed without engineering intervention. Metrics should be interpreted in context; a rise in engineering reviews may indicate better detection of complex ETO work rather than a failed implementation.

    Common implementation limitations and failure modes

    Failure mode Why it occurs Prevention
    Modeling every exception as an option Historical quotes contain undocumented one-off decisions Separate standard configuration from controlled ETO review
    Starting with the user interface Teams design screens before defining product logic Model data, rules, ownership and outputs first
    Ignoring downstream structures Sales BOM is assumed to be a manufacturing BOM Define EBOM, MBOM and ERP ownership explicitly
    Embedding prices in technical rules Commercial and engineering changes become coupled Separate pricing tables and configuration logic
    Relying on undocumented overrides Users work around incomplete rules Capture exceptions, approvals and reasons
    Underestimating data cleanup Duplicate, obsolete or inconsistent source records are migrated Profile, cleanse and classify data before migration
    Assuming integrations are interchangeable CRM, ERP, PLM, PDM, MES and CAD have different purposes Define system-of-record responsibilities and interface contracts
    Skipping regression testing A price or rule change breaks an unrelated product family Maintain reusable test cases and release gates

    Recommended implementation sequence

    1. Set objectives: define the business problems, product scope, workflow and measurable outcomes.
    2. Map the current state: document quoting, engineering, pricing, order entry and production handoffs.
    3. Assess data: inventory product, option, component, price, CAD, BOM and customer data.
    4. Design the target model: define features, options, constraints, calculations, outputs and ownership.
    5. Choose the first release: select a product family and workflow that can be tested end to end.
    6. Configure and integrate: build the model, interfaces, documents and required engineering services.
    7. Test with real scenarios: include valid, invalid, boundary, revised and exception cases.
    8. Train and pilot: use controlled users and capture operational feedback.
    9. Deploy in phases: expand product families and channels only when governance is ready.
    10. Operate and improve: monitor rules, data, integrations, user adoption and business outcomes.

    A detailed project plan should also address security, environments, release management, backup and recovery, audit trails, supplier data, localization and regulatory requirements where applicable. These concerns vary by platform and industry and should be verified during vendor evaluation rather than assumed.

    Semantic map

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

    • Manufacturing CPQ connects product configuration with pricing, quoting and downstream engineering or production processes.
    • Product models contain features, options, parameters, dependencies, constraints and output mappings.
    • Configuration rules prevent invalid combinations and derive required components or values.
    • Configured products can generate BOM data when the selected CPQ platform supports BOM generation.
    • EBOM structures describe engineering intent, while MBOM structures organize production requirements.
    • Pricing rules calculate commercial values separately from technical configuration rules.
    • CAD automation can generate product-specific drawings or models when templates and integrations are available.
    • ERP manages enterprise transactions and may receive configured items, prices or orders from CPQ.
    • PLM and PDM manage product revisions, engineering structures, documents and CAD data.
    • ETO workflows route non-standard requirements to engineering review rather than forcing every exception into a standard model.
    • Governance controls changes to product rules, prices, BOMs, integrations and engineering outputs.
    • Regression testing verifies that model changes do not invalidate existing product families.

    Frequently asked questions

    1. What is manufacturing CPQ implementation?

    It is the process of modeling configurable products, rules, calculations, prices, quotes and downstream outputs in a CPQ system, then integrating, testing and operating that system within manufacturing workflows.

    2. How is manufacturing CPQ different from sales CPQ?

    Sales CPQ generally emphasizes product selection, pricing, discounts and proposals. Manufacturing CPQ may additionally validate technical combinations, calculate requirements, generate BOM data, automate CAD work and connect configuration with engineering and production.

    3. How long does a manufacturing CPQ implementation take?

    Duration depends on product complexity, data quality, number of product families, integrations, engineering automation and governance requirements. A focused pilot is usually more predictable than a portfolio-wide deployment.

    4. Which product family should be implemented first?

    Choose a product with meaningful configuration complexity, reliable source data, clear business ownership and measurable quoting or engineering problems. Avoid a product family dominated by undocumented exceptions.

    5. Who should own the CPQ product model?

    Ownership is usually shared, but one accountable product or configuration owner should coordinate decisions. Engineering, product management, pricing, manufacturing and IT should approve changes within their areas of responsibility.

    6. Should configuration rules be stored in ERP?

    ERP may own items, inventory, orders and financial data, but it is not automatically the best place for customer-facing configuration logic. Define system ownership based on the required workflow and the capabilities of the selected platforms.

    7. Can CPQ generate a manufacturing BOM?

    Some CPQ systems can generate or map configurable BOMs, while others produce only sales or engineering outputs. Verify whether the platform supports the required EBOM, MBOM, effectivity, plant and routing requirements.

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

    An EBOM represents an engineering view of the product, often organized by design structure. An MBOM represents how the product is assembled or manufactured. They may contain different groupings, quantities, consumables and production information.

    9. Can CPQ support engineer-to-order products?

    It can support ETO by capturing requirements, identifying standard versus non-standard work and routing exceptions to engineering. It does not eliminate engineering design work unless the product has been sufficiently standardized and automated.

    10. Does every CPQ system provide CAD automation?

    No. CAD automation may be native, delivered through an integration or unavailable. Confirm supported CAD systems, parameter handling, template control, revision management, output formats and failure handling.

    11. How should pricing and configuration logic be separated?

    Technical rules should determine what can be configured and what components or values are required. Pricing logic should calculate commercial amounts using prices, costs, discounts, currencies, surcharges and approval policies.

    12. What data should be migrated into CPQ?

    Migrate approved and useful product attributes, options, rules, identifiers, prices, documents and mappings. Do not automatically migrate every historical exception or obsolete record.

    13. How should CPQ integrations be tested?

    Test valid and invalid messages, identifiers, revisions, timing, authentication, error responses and retries. Include end-to-end scenarios from configuration and quote creation through order transfer and downstream processing.

    14. What is a good CPQ implementation pilot?

    A good pilot covers one product family and one complete workflow, such as configuration through approved quote or configuration through ERP order. It should include real rules, pricing, representative outputs and defined acceptance criteria.

    15. How can manufacturers reduce CPQ rule complexity?

    Standardize product options, remove obsolete choices, separate technical and commercial rules, identify reusable submodels and route genuine ETO requirements to engineering instead of encoding every exception as a selectable option.

    16. What testing is required before go-live?

    Use unit, model, integration, end-to-end, user acceptance and regression testing. Include boundary values, incompatible selections, price changes, product revisions, BOM outputs, document generation and integration failures.

    17. How should CPQ changes be governed after launch?

    Use controlled change requests, impact analysis, approvals, versioning, effectivity dates, regression testing, deployment records and post-release monitoring. Assign clear owners for rules, prices, product data and interfaces.

    18. What KPIs are useful after implementation?

    Useful measures include quote cycle time, engineering effort per quote, configuration errors, manual overrides, pricing corrections, BOM errors, approval time, order re-entry and the proportion of standard quotes completed without engineering intervention.

    19. Can CPQ replace PLM, ERP or CAD?

    Usually not. CPQ may exchange data with these systems, but ERP, PLM, PDM and CAD have distinct responsibilities. The implementation should define boundaries rather than treating CPQ as a replacement for every enterprise application.

    20. When should a manufacturer consider a custom-built CPQ solution?

    Consider build versus buy after documenting product complexity, integrations, governance, lifecycle cost and internal capability. A custom solution may fit unique requirements, but the manufacturer must also maintain rules, security, testing, infrastructure and upgrades.

  • CPQ CRM Integration for Manufacturing

    CPQ CRM integration for manufacturing connects customer and opportunity data in a customer relationship management (CRM) system with the product configuration, engineering validation, pricing and quotation processes managed by a configure, price, quote (CPQ) system. The integration can allow a sales representative to open a CRM opportunity, launch a valid configuration, calculate a price, generate a quote and return the commercial result to CRM.

    Manufacturing integration is more than embedding a quote button in a sales application. A configured industrial pump, machine, vehicle or electrical assembly may require dimensional rules, material selections, motor calculations, engineering approval, a configurable bill of materials (BOM), computer-aided design (CAD) outputs and manufacturing data. CRM normally manages the customer relationship and sales process; it should not automatically become the authority for engineering or production data.

    The most reliable architecture gives each system a defined responsibility. CRM owns accounts, contacts, opportunities and sales activities. CPQ owns the interactive configuration and commercial transaction, while ERP, product lifecycle management (PLM), product data management (PDM), CAD and manufacturing execution systems (MES) retain the records appropriate to their roles.

    See the broader CPQ integration guide for related ERP, PLM, PDM, CAD, product information management (PIM), MES and API patterns.

    What is CPQ CRM integration?

    CPQ CRM integration is the exchange of customer, opportunity, product, configuration, price, quote and status data between a CPQ platform and a CRM platform. It usually supports a workflow such as:

    1. A salesperson creates or selects an account, contact and opportunity in CRM.
    2. CRM launches CPQ with the relevant customer, channel, currency and opportunity context.
    3. CPQ guides the user through a valid product configuration.
    4. CPQ applies configuration rules, engineering calculations, costs, discounts and approval policies.
    5. CPQ produces a quote and, where supported, a configurable BOM, engineering request or CAD output.
    6. Selected quote data, status and documents are returned to CRM.
    7. When the customer accepts the offer, the approved transaction is transferred to ERP or another order-management process.

    Generic sales CPQ may focus mainly on product selection, discounts and proposal documents. Manufacturing CPQ may additionally validate technical constraints, calculate dimensions or performance, create manufacturing-relevant structures and support configure-to-order (CTO) or engineer-to-order (ETO) work. The integration design must therefore account for technical data, revisions and downstream fulfillment, not only sales fields.

    Why manufacturing CRM integration is different

    In a simple commercial sale, a quote may contain a product, quantity, price and discount. In industrial manufacturing, the quote can represent a unique or semi-unique product. A sales engineer configuring a pump package may select flow, pressure, fluid, temperature, impeller material, motor type, seal arrangement, controls and certification requirements. Each choice can affect compatibility, cost, lead time, documentation and the resulting BOM.

    CRM provides valuable context: the customer, site, opportunity value, sales stage, territory, sales representative and expected close date. It usually does not provide the complete product model or engineering rule set. CPQ must obtain the appropriate product and pricing data, validate the configuration and preserve a reproducible version of the quote.

    Business responsibility Typical system Manufacturing relevance
    Accounts, contacts and opportunities CRM Identifies the customer, project and sales process.
    Options, dependencies and configuration validation CPQ or configuration engine Prevents technically invalid product combinations.
    Prices, discounts and quote documents CPQ, sometimes with ERP input Produces a commercial offer based on the selected design and policies.
    Released product and engineering revisions PLM or PDM Controls approved product definitions and design data.
    Inventory, manufacturing items, costs and orders ERP Supports supply, production, financial and order processes.
    Geometry, drawings and design outputs CAD or engineering automation Creates product-specific technical information where supported.
    Shop-floor execution MES Uses production and execution data after order release.

    Reference architecture and system responsibilities

    CRM as the commercial context

    CRM should normally remain the system of record for accounts, contacts, opportunities, activities and sales stages. It can store a reference to the CPQ quote, quote status, total value, currency, validity date, approval state and document links. It may also store a summary of the configuration for search and reporting.

    Storing every rule, engineering parameter and BOM line in CRM is often difficult to maintain. CRM data models are generally designed for relationship and sales management, not for large product structures or revision-controlled engineering logic. A CRM record can point to the authoritative CPQ quote and configuration rather than duplicating every technical detail.

    CPQ as the configuration and quotation layer

    CPQ typically manages the interactive product model, configuration session, rules, calculations, price logic, quote versions and proposal content. Some platforms also create configurable BOMs, engineering requests, drawings or CAD outputs. These capabilities vary by product and must be verified during software evaluation.

    A CPQ configuration should be identifiable and reproducible. Useful identifiers include a configuration ID, quote ID, quote revision, product model revision, rule-set version, currency, price list and timestamp. Without version information, it may be impossible to explain why a quote calculated differently after product rules changed.

    ERP as the transaction and fulfillment authority

    An enterprise resource planning (ERP) system commonly manages item masters, inventory, manufacturing costs, orders, purchasing, production and financial transactions. ERP may provide price lists, customer terms, item availability or lead-time information to CPQ. After acceptance, CPQ or an integration layer may send an order, order lines, configuration attributes, attachments or a manufacturing structure to ERP.

    Whether CPQ creates a new engineered item, references existing items or sends a structured configuration depends on the manufacturer’s operating model. This is particularly important for ETO products, where the final engineering definition may not exist before the order.

    PLM, PDM and CAD in the engineering chain

    Product lifecycle management (PLM) governs product definitions, lifecycle states, revisions and change processes. Product data management (PDM) commonly manages engineering files and CAD-related structures. CAD is used to create product geometry, assemblies and drawings. These systems are related but not interchangeable.

    CPQ may use approved product options from PLM, retrieve document references from PDM, or send selected parameters to a CAD automation service. In a mature architecture, CPQ does not silently create an uncontrolled engineering revision. It sends a clear engineering request or uses an approved automation process with defined release and review gates.

    The CAD and engineering automation guide explains how configuration parameters can connect to drawings, calculations and design outputs.

    Common CPQ CRM integration data flows

    Launching a configuration from an opportunity

    The CRM opportunity can pass an opportunity ID, account ID, contact, sales organization, channel, currency, region, language and salesperson to CPQ. CPQ uses this context to apply customer-specific price lists, channel rules, tax treatment or approval policies where configured. It should not assume that all commercial policies belong in CRM; pricing ownership must be explicitly defined.

    Returning configuration and quote results

    CPQ can return a quote reference, version, status, total price, recurring or one-time components where relevant, validity date, discount summary, approval state and document links. For manufacturing, the integration may also return a configuration summary, product family, selected options, estimated lead time, engineering status and a reference to the generated BOM or CAD package.

    Large technical structures are often better retained in CPQ, ERP or PLM and referenced from CRM. Sending every BOM component into CRM can create synchronization, performance and reporting problems.

    Synchronizing customer and commercial master data

    Customer and account data may originate in CRM, ERP or a master-data service. The integration should define which system creates and updates legal customer names, addresses, payment terms, tax identifiers, ship-to locations and contacts. Duplicate customer creation is a common failure mode when both CRM and ERP can create accounts independently.

    Converting an accepted quote into an order

    An accepted quote can trigger an order process. The handoff may include the quote version, customer identifiers, order lines, prices, discounts, delivery terms, configuration attributes, attachments, BOM references and engineering status. The receiving ERP should validate that required items, units, currencies and customer records are available before creating an order.

    For CTO, or configure-to-order, the configuration may map to an established product model and known manufacturing structure. For ETO, engineering work may be required before the final order structure is released. The integration should not treat these workflows as identical.

    Product configuration, pricing and quoting are separate concerns

    Product configuration determines what can be selected together and what technical result is produced. Pricing determines what the result costs or what the customer is charged. Quoting packages the commercial offer, terms, documents and approvals. These concerns interact but should not be collapsed into a single undifferentiated CRM process.

    • Rules-based configuration: explicit rules such as “if 400-volt motor, require the compatible starter.”
    • Constraint-based configuration: a solver evaluates limits and relationships such as pressure, flow, dimensions, load or power ranges.
    • Guided selling: questions and recommendations help a user select a suitable product, but guided selling alone does not prove that every technical combination is manufacturable.
    • Pricing logic: calculates base prices, option prices, costs, markups, discounts, freight and other commercial values.
    • Quote generation: creates a customer-facing proposal and approval record.

    These distinctions matter in integration testing. A CRM opportunity may be successfully created even though the configuration is invalid, the price is stale or the quote contains no manufacturing-ready structure.

    BOM and engineering data in the integration

    A bill of materials (BOM) is a structured list of components and quantities. An engineering BOM (EBOM) represents the design view, while a manufacturing BOM (MBOM) represents how the product is assembled or produced. A configurable BOM may contain rules or alternatives that resolve only after the user selects options.

    CPQ may generate a configurable BOM, an EBOM-like engineering structure, an MBOM-ready structure or only a summary of selected options. These outputs are not equivalent. The receiving ERP, PLM or manufacturing process must define the required structure, item numbers, revisions, units, quantities, effectivity and ownership.

    For example, a configured conveyor may include a frame length, belt material, drive motor, guard package and control panel. CPQ may calculate the selected options and produce a component list. PLM may own the released engineering assembly, while ERP owns the manufacturing items and MBOM. The CRM opportunity should generally store references and commercial summaries rather than becoming the master BOM repository.

    Read more about BOM generation, pricing and quote automation.

    Integration patterns and APIs

    Common integration patterns include direct point-to-point connections, middleware or integration-platform workflows, event-driven messaging and API-based orchestration. The appropriate choice depends on system capabilities, transaction volume, security requirements and the number of connected applications.

    Pattern Suitable use Risk or limitation
    REST or SOAP API calls Launching CPQ, retrieving quote status or creating an order. Requires stable contracts, authentication and error handling.
    Middleware orchestration Mapping CRM, CPQ, ERP and PLM data across several systems. Adds a platform that must be monitored and governed.
    Webhooks or events Notifying CRM when a quote is approved, revised or accepted. Events can arrive out of order or be delivered more than once.
    Scheduled batch exchange Synchronizing price lists, item data or reference data. Data may not be current between synchronization cycles.
    Embedded CPQ interface Keeping users in the CRM experience while CPQ performs the work. Browser security, session, performance and user-interface coupling require attention.

    Regardless of pattern, integration contracts should define field names, identifiers, units of measure, currencies, revision behavior, required fields, error responses, retry rules, duplicate handling and ownership. Idempotency is important: repeating a message should not unintentionally create multiple quotes or orders.

    Benefits of CPQ CRM integration for manufacturers

    • Less re-entry: account, opportunity and project details can flow into the configuration process.
    • Better sales visibility: CRM users can see quote status, value, approval state and next actions.
    • Faster technical response: valid configurations and automated calculations can reduce avoidable engineering questions.
    • Improved traceability: the opportunity can be linked to the exact quote revision and configuration used.
    • More consistent handoff: accepted commercial data can move toward ERP, PLM or engineering workflows in a defined format.
    • Better channel support: dealers and distributors can receive controlled configuration access without receiving unrestricted engineering logic.

    These benefits depend on product data quality and process design. Integration cannot correct contradictory product rules, obsolete price lists, duplicate item masters or unclear ownership.

    Limitations and implementation risks

    Unclear data ownership

    Conflicts arise when CRM, CPQ, ERP and PLM each contain their own version of products, prices or customer terms. A data-ownership matrix should identify the authoritative source for every important object and attribute.

    Overloading CRM with technical data

    CRM is useful for commercial reporting, but storing full configurations, CAD files and large BOMs there can create maintenance and performance problems. Use references to authoritative records where possible.

    Stale product and pricing data

    A configuration may be technically valid but priced incorrectly if CPQ has an obsolete cost, price list or exchange rate. Product, cost and price updates need controlled publication and effective dates.

    ETO complexity

    ETO processes often require engineering review, new parts, drawings or approvals after the initial quote. The CRM integration should represent intermediate states such as “engineering required,” “design in progress” and “released for order,” rather than treating the first quote as a finished manufacturing definition.

    Security and access control

    Customer, pricing and engineering data may have different access requirements. Role-based permissions, API credentials, encryption, audit logs and document access rules should be designed across the complete flow.

    Implementation approach

    1. Map the current workflow: document how an opportunity becomes a configuration, quote, approval, order and engineering or production request.
    2. Define system ownership: create a matrix for accounts, products, options, rules, costs, prices, BOMs, revisions, documents and order status.
    3. Start with identifiers: agree on customer IDs, opportunity IDs, quote IDs, item numbers, configuration IDs, revision IDs and external references.
    4. Specify the minimum viable payload: transfer only the fields needed for each process step, then expand after validation.
    5. Model workflow states: include draft, configured, technically reviewed, approved, sent, accepted, expired, cancelled and superseded where applicable.
    6. Test manufacturing scenarios: include valid and invalid combinations, option changes, revised quotes, currency changes, unavailable components, ETO requests and rejected orders.
    7. Monitor integration behavior: log requests, responses, correlation IDs, failures, retries and manual interventions without exposing unnecessary sensitive data.
    8. Govern product-model changes: test configuration rules, price changes and ERP or PLM revisions before release.

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

    How to evaluate a CPQ CRM integration

    Manufacturers should evaluate the integration using real product and workflow scenarios rather than a generic feature checklist. Ask vendors and implementation teams:

    • Can the system launch a configuration from a CRM opportunity and preserve the opportunity context?
    • How are product-model revisions and quote revisions identified?
    • Which system owns customer, item, price, cost and engineering data?
    • Can the platform distinguish a valid configuration from a merely selected product bundle?
    • What configuration outputs are available: option summary, configurable BOM, EBOM, MBOM, CAD parameters or engineering request?
    • How are CTO, ETO, make-to-order (MTO) and assemble-to-order (ATO) workflows represented?
    • How are failed API calls, duplicate messages and partial order creation handled?
    • Can dealers, distributors and internal sales engineers receive different permissions?
    • How are quote documents, CAD files and technical attachments secured?
    • What testing and deployment controls exist for rules, pricing and integration mappings?

    Profiles in the manufacturing CPQ software section can be assessed using these criteria, but documented capabilities should be verified for each specific product and edition.

    Semantic map

    The relationships below summarize the entities and responsibilities discussed in this article.

    • CRM provides customer and opportunity context to CPQ.
    • CPQ validates configurable products and produces commercial quotes.
    • Configuration rules prevent invalid combinations of options.
    • Pricing logic converts configuration choices into commercial values.
    • CPQ exchanges customer and order data with ERP.
    • PLM governs approved product definitions and engineering revisions.
    • PDM manages engineering files and product data references.
    • CAD automation can generate product-specific drawings when supported.
    • Configured products can generate configurable BOMs when supported.
    • EBOM describes an engineering product structure.
    • MBOM describes a manufacturing product structure.
    • ETO requires engineering work before a final manufacturing definition.
    • APIs connect CRM, CPQ, ERP, PLM, PDM and CAD services.
    • Quote revisions preserve the commercial and technical history of an opportunity.

    Frequently asked questions

    1. What is CPQ CRM integration in manufacturing?

    It connects CRM customer and opportunity data with CPQ configuration, pricing, quoting and approval processes for manufactured products.

    2. Should CRM or CPQ own the product configuration?

    CPQ normally owns the interactive configuration model and validation logic. CRM usually stores the sales context and references to the resulting quote.

    3. Can CRM generate a manufacturing BOM?

    CRM is not normally the BOM authority. A CPQ system may generate a BOM, but the resulting structure may need validation or release through PLM, ERP or manufacturing engineering.

    4. Does every CPQ platform integrate with CAD?

    No. CAD integration and automation vary considerably. Buyers should verify supported CAD systems, parameters, outputs, versioning and release controls.

    5. What data should CRM send to CPQ?

    Typical data includes account, contact, opportunity, sales channel, region, currency, language, salesperson, ship-to location and relevant commercial terms.

    6. What data should CPQ return to CRM?

    Common results include quote ID, revision, status, total value, validity date, approval state, document links, configuration summary and engineering status.

    7. Should prices come from CRM or CPQ?

    The ownership model depends on the architecture. CPQ often calculates configuration-dependent pricing, while ERP or a pricing master may provide costs, price lists or customer terms.

    8. How does ERP differ from CRM in a CPQ architecture?

    CRM manages customer relationships and sales processes. ERP manages operational and financial transactions such as items, inventory, manufacturing, purchasing and orders.

    9. How does PLM differ from CPQ?

    PLM manages product lifecycle, engineering definitions and revisions. CPQ uses product models to configure and quote a sellable result, although some platforms exchange data with PLM.

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

    An EBOM represents the engineering design structure. An MBOM represents the structure and operations used to manufacture or assemble the product.

    11. How should ETO quotes be integrated?

    The integration should support engineering review, design tasks, new or revised items, approvals and a later release of the manufacturing definition rather than assuming the initial quote is production-ready.

    12. Can CPQ CRM integration support configure-to-order?

    Yes, when the configuration maps to approved product options, items and manufacturing structures. The specific CPQ and ERP capabilities must be verified.

    13. Should a full CAD file be stored in CRM?

    Usually it is better to store the CAD file in the appropriate PDM, PLM or document system and place a controlled reference in CRM or CPQ.

    14. What are common integration errors?

    Frequent problems include duplicate customers, mismatched item IDs, stale prices, missing units, unsupported currencies, lost quote revisions and failed order retries.

    15. How are quote revisions handled?

    Each revision should have a unique identifier and preserve its configuration, price inputs, rule-set version, approvals and documents. CRM should link to the relevant revision rather than overwrite history.

    16. Can dealers use the same CRM and CPQ integration?

    They can, if the architecture supports channel permissions, approved product models, territory pricing, document access and controlled visibility of engineering information.

    17. Is an API required for CPQ CRM integration?

    Not always. APIs are common for real-time exchange, but middleware, events or scheduled data transfers may also be appropriate depending on the systems and workflow.

    18. How should manufacturers test the integration?

    Test valid and invalid configurations, price changes, quote revisions, approvals, rejected orders, unavailable components, ETO handoffs, duplicate messages and system downtime.

    19. Can integration eliminate engineering involvement?

    It can reduce avoidable engineering effort for approved configurations, but unusual products, ETO work, safety requirements and new designs may still require engineering review.

    20. What is the first step in an implementation?

    Map the quote-to-order workflow and define data ownership before selecting fields, APIs or middleware. This prevents the integration from reproducing unclear processes.

    For a broader explanation of manufacturing CPQ architecture, see the manufacturing CPQ guide and the guide to manufacturing CPQ workflows.

  • Webhooks and Event-Driven CPQ Integrations

    Webhooks and event-driven integrations connect a manufacturing Configure, Price, Quote (CPQ) system to the wider product and production technology stack. Instead of relying only on users or scheduled data transfers, systems publish events when important actions occur, such as a configuration being validated, a quote being approved, a product model changing or a manufacturing bill of materials becoming available.

    In a manufacturing environment, this can connect product configuration with customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD), manufacturing execution systems (MES) and ecommerce platforms. The objective is not simply to move sales data faster. It is to keep configuration, engineering, commercial and production processes coordinated while preserving data ownership in each system.

    A webhook is an HTTP callback sent from one application to another when a defined event occurs. An event-driven CPQ integration uses events as the basis for communication and workflow orchestration. For example, a CPQ platform might publish a quote.approved event. An ERP integration can use that event to create or update an order, while a document service generates a proposal and a manufacturing workflow starts a review of the resulting bill of materials (BOM).

    Webhooks are useful, but they are not a complete integration architecture. Reliable manufacturing integrations also require clear event definitions, ownership of product data, stable identifiers, version control, authentication, retry handling, monitoring and rules for resolving failures.

    What are webhooks in CPQ integration?

    A webhook is a notification sent automatically from a source system to a destination URL when something happens. The source system usually sends an HTTP request containing an event name, timestamp, identifier and relevant data. The receiving system accepts the request and starts an action or passes the event to another service.

    For example, after a sales engineer configures an industrial pump, the CPQ system may emit an event containing the quote identifier, configuration identifier, product model version, selected options, calculated price and workflow status. A downstream service can then retrieve the full configuration through an application programming interface (API), rather than relying on the webhook payload to contain every field.

    Webhooks normally support near-real-time notification. They differ from a traditional polling integration, in which a receiving system repeatedly asks whether anything has changed. Polling can be adequate for low-frequency processes, but it may create unnecessary traffic, delay updates or miss changes when polling logic is poorly designed.

    Webhook example for a configurable machine

    Suppose a manufacturer sells a configurable conveyor system. The CPQ product model includes conveyor length, belt material, motor size, frame finish, guarding and control-voltage options. After the configuration passes validation, CPQ publishes configuration.validated.

    1. A configuration service records the valid configuration and its model version.
    2. A pricing service calculates the commercial price using the selected motor, length and options.
    3. A CAD automation service creates a product-specific layout or drawing if supported by the implementation.
    4. A BOM service produces a configurable engineering bill of materials or passes the configuration to an engineering system.
    5. When the customer accepts the quote, CPQ publishes quote.accepted.
    6. ERP creates the sales order or requests confirmation from an order-management workflow.

    The event does not mean that every receiving system must immediately create production data. Each subscriber applies its own business rules and confirms whether the event is relevant.

    What is event-driven CPQ architecture?

    Event-driven architecture is an integration approach in which systems communicate through business events. An event records that something happened, such as a product model being published, a quote being approved or an engineering review being required. Other systems subscribe to events they need.

    A simple implementation may use direct webhooks from CPQ to ERP, CRM or a document service. A larger implementation may place an event broker or message bus between the systems. The broker receives events, stores or routes them, and delivers them to multiple consumers. This reduces direct point-to-point dependencies and allows new consumers to subscribe without changing the CPQ application.

    Integration approach How it works Manufacturing use Important limitation
    Polling A system repeatedly asks another system for changes. Checking periodically for new approved quotes or updated product records. Can introduce delay, unnecessary traffic and duplicate processing.
    Direct API call One system synchronously requests data or an action from another. CPQ requests current material cost or creates an ERP customer record. The source may be blocked by downtime or a slow response.
    Direct webhook A source sends an event notification to a subscribed endpoint. Notify ERP when a quote is accepted or notify CAD when a design job is ready. Requires reliable delivery, security and retry management.
    Event broker Events are published to a managed topic or queue for multiple consumers. Distribute configuration, approval and engineering events across ERP, PLM, MES and analytics. Adds architecture, operations and governance requirements.

    Event-driven integration is usually complementary to APIs. An event can notify a system that a change occurred, while an API provides the authoritative details. This separation is useful when configurations contain large option sets, calculated values, drawings or versioned BOM structures.

    Where webhooks fit in the manufacturing CPQ stack

    Manufacturing CPQ is broader than generic sales quoting. A generic sales CPQ system may focus mainly on selecting products, applying discounts and generating a proposal. Manufacturing CPQ may also validate engineering constraints, perform calculations, create a configurable BOM, trigger CAD automation and hand production-ready information to downstream systems. Not every CPQ platform provides all of these capabilities, so the integration design must reflect the actual product scope.

    System Typical ownership Useful CPQ events
    CRM Accounts, opportunities, contacts and sales activity Configuration started, quote created, quote submitted and quote accepted
    ERP Items, customers, inventory, purchasing, orders, financial data and manufacturing transactions Quote accepted, order released, item unavailable and price update
    PLM Product structures, revisions, change processes and lifecycle status Product model published, revision released and engineering change approved
    PDM CAD files, metadata, document relationships and design revisions CAD job requested, drawing generated and file revision released
    CAD Parametric geometry, assemblies, drawings and design outputs Configuration ready for design automation and output completed
    MES Shop-floor execution, work instructions, routing and production status Order released to production and manufacturing data available
    PIM Commercial product content, descriptions, images and channel data Option content published and product information updated

    Data ownership should be explicit. For example, CPQ may own the selectable product model and configuration rules, while PLM owns released engineering revisions, ERP owns item and order records, and CAD or PDM owns design files. A webhook should not silently make one system the master of data it does not govern.

    Common manufacturing CPQ events

    Event names should describe business facts rather than technical implementation details. The exact names depend on the platform and integration design, but common event categories include:

    • Product model events: product-model.draft-created, product-model.published and product-model.retired.
    • Configuration events: configuration.started, configuration.validated, configuration.invalidated and configuration.revised.
    • Engineering events: engineering-review.required, cad-generation.requested, cad-generation.completed and bom.generated.
    • Commercial events: quote.created, quote.recalculated, quote.submitted, quote.approved and quote.expired.
    • Order events: quote.accepted, order.requested, order.created and order.released.
    • Integration events: erp-synchronization.failed, plm-revision.changed and customer-data.updated.

    An event should identify the business object, its version and the source of truth. A useful event envelope may include an event identifier, event type, occurrence time, source application, schema version, tenant or business unit, correlation identifier and object identifiers.

    {  "eventType": "configuration.validated",  "eventId": "evt-12345",  "occurredAt": "2025-01-15T10:30:00Z",  "source": "manufacturing-cpq",  "schemaVersion": "1.0",  "configurationId": "cfg-7842",  "quoteId": "q-3109",  "productModelVersion": "pump-series-4.2",  "correlationId": "quote-q-3109"}

    The example is illustrative. A production schema must be agreed by the participating systems and documented as part of the integration contract.

    How configuration, pricing, BOM and CAD events relate

    Configuration, pricing, quoting and engineering output are related but distinct processes. A valid configuration does not automatically mean that a final price, engineering BOM or production order exists.

    Configuration validation

    The product model defines features, options, dependencies, constraints and calculations. Rules may prevent incompatible combinations, such as selecting a motor that cannot provide the required torque or choosing a material unsuitable for the specified temperature range. Learn more in the guide to product configuration and rules.

    Pricing and costing

    A pricing event may trigger list-price lookup, customer-specific pricing, discount approval, freight calculation, currency conversion or cost-margin validation. Cost data may come from ERP, purchasing or a costing service. A configuration can be technically valid while still requiring commercial approval because the margin is below a threshold.

    BOM generation

    A bill of materials (BOM) lists components and quantities for a product or assembly. An engineering bill of materials (EBOM) represents the engineering product structure, while a manufacturing bill of materials (MBOM) represents how the product is assembled or produced. A configurable BOM may contain rules that select components based on the configuration.

    CPQ may generate a BOM directly, generate a preliminary structure, or pass configuration data to PLM or ERP for authoritative BOM creation. These alternatives must not be treated as equivalent. The BOM, pricing and quoting guide explains the relationship in more detail.

    CAD and engineering automation

    Some manufacturing CPQ implementations trigger parametric CAD generation, drawing creation, sizing calculations or engineering review. Others only send selected options to an external engineering system. An event such as cad-generation.requested should therefore represent a workflow request, not an assumption that the CPQ platform itself creates CAD files. See the guide to CAD and engineering automation.

    Webhook and event-driven workflow example

    Consider a configurable centrifugal pump. The user selects flow rate, head, fluid properties, materials, seal type, motor voltage and mounting arrangement.

    1. CPQ evaluates configuration rules and engineering calculations.
    2. If the selection is valid, CPQ emits configuration.validated.
    3. A pricing service obtains material and motor costs and returns a commercial calculation.
    4. CPQ emits quote.recalculated with the pricing version and margin status.
    5. If the pump requires a product-specific drawing, CPQ emits cad-generation.requested.
    6. The CAD service generates a drawing or returns an engineering-review requirement.
    7. A BOM service creates an EBOM or sends the configuration to PLM for structure resolution.
    8. The salesperson submits the quote and an approval workflow evaluates discount, risk and margin rules.
    9. After customer acceptance, CPQ emits quote.accepted.
    10. ERP creates or updates the order and returns an ERP order identifier.
    11. MES receives production-relevant information only after the order is released and the required engineering data is approved.

    This sequence supports configure-to-order (CTO) when the product is selected from an established product model. If the pump requires new engineering work, the same architecture may support engineer-to-order (ETO), but an engineering review and design release must be explicit. Make-to-order (MTO) concerns production triggered by a customer order, while assemble-to-order (ATO) uses stocked modules assembled after the order. These workflows can share events but have different data and approval requirements. The manufacturing workflows guide provides further context.

    Benefits of event-driven CPQ integrations

    • Faster handoffs: An approved configuration can notify engineering, ERP or document generation without manual re-entry.
    • Lower duplication: Systems exchange identifiers and structured data instead of relying on emailed spreadsheets or copied quote lines.
    • Better process visibility: Events reveal where a configuration is waiting, such as pricing approval, CAD generation or PLM release.
    • Selective processing: Each subscriber receives only the events relevant to its responsibility.
    • Looser coupling: A CPQ system does not need synchronous connections to every downstream application for every action.
    • Improved auditability: Event identifiers, timestamps and correlation identifiers help reconstruct the path from configuration to order.
    • Support for multiple channels: Direct sales, dealers, distributors and ecommerce applications can use the same event contracts where appropriate.

    Limitations and risks

    Event-driven integration does not remove complexity; it moves some complexity into message delivery, data contracts and operational control.

    • Events can be duplicated: Receiving applications must be idempotent, meaning processing the same event more than once does not create duplicate orders, BOMs or customers.
    • Events can arrive out of order: A quote acceptance event may arrive before a related customer update. Consumers need sequence information, dependency checks or reconciliation logic.
    • Delivery is not the same as completion: A webhook accepted by an endpoint does not prove that an ERP order or CAD file was successfully created.
    • Payloads can become stale: Product rules, prices and engineering revisions may change between event creation and processing. Version identifiers are essential.
    • Failures may be invisible: Without dead-letter queues, alerts and operational dashboards, failed integrations can remain unnoticed.
    • Security exposure increases: Public webhook endpoints require authentication, signature validation, encryption, rate controls and careful payload handling.
    • Distributed transactions are difficult: A quote may be accepted while ERP is temporarily unavailable. The business must define retry, compensation or manual recovery procedures.

    Implementation considerations

    Define ownership and integration boundaries

    Document which system owns each object and field. For example, CRM may own the opportunity, CPQ may own the active configuration, PLM may own the released product structure, ERP may own the sales order and PDM may own the CAD document. Do not use webhooks to create competing masters without a clear reconciliation process.

    Design stable event contracts

    Use durable identifiers rather than display names. Include product model version, configuration version, currency, unit system and relevant revision information. Separate stable business events from internal implementation details. Version schemas when fields or meanings change.

    Use event notification with API retrieval where appropriate

    A compact webhook can notify a system that a configuration changed and provide a link or identifier for retrieving the authoritative record. This reduces payload size and avoids embedding large CAD, BOM or document structures in every message.

    Plan for retries and idempotency

    Transient failures should be retried with controlled backoff. Permanent failures should be placed in a dead-letter queue or exception worklist. Each consumer should record processed event identifiers and use business keys to prevent duplicate ERP orders, repeated CAD jobs or multiple approval records.

    Secure the endpoints

    Use transport encryption, authentication, signed requests, allowlists where practical and least-privilege access. Validate the event source and schema before processing. Do not include unnecessary customer, pricing or engineering data in a webhook payload.

    Test business scenarios, not only connectivity

    Integration testing should include invalid configurations, price changes, product-model revisions, withdrawn components, ERP downtime, duplicate messages, rejected quotes, partial CAD failures and engineering-review exceptions. Test both the normal path and the recovery path.

    Implementation planning should also cover data migration, governance, deployment and maintenance. The CPQ implementation guide and manufacturing CPQ integrations guide provide related planning topics.

    How to evaluate webhook support in a CPQ platform

    Buyers should verify documented capabilities rather than assume that an API automatically includes event-driven integration. Useful questions include:

    • Which business events are available, and can administrators define custom events?
    • Are events available for product-model publication, configuration validation, pricing, quote approval, BOM generation and order acceptance?
    • Does the platform support outbound webhooks, inbound webhooks, event subscriptions or an event broker?
    • Are event schemas documented and versioned?
    • Are retries, signatures, delivery logs and replay supported?
    • Can events include product-model, configuration and revision identifiers?
    • Can the platform distinguish quote acceptance from order creation and production release?
    • Does the system generate BOMs or only transmit configuration data to another system?
    • Does it support CAD or PLM workflows directly, through an integration platform or through custom APIs?
    • How are failed integrations monitored and reconciled?
    • Can dealer, distributor and ecommerce channels subscribe without exposing internal engineering data?

    These questions should be evaluated alongside configuration depth, rules maintenance, BOM behavior, CAD automation, ERP integration and governance. A feature checklist alone does not show whether the event model can support the manufacturer’s actual order-to-production workflow.

    Semantic map

    The following relationships summarize the main entities and dependencies discussed in this article:

    • CPQ publishes business events about configurations, quotes and product models.
    • Webhooks deliver event notifications between CPQ and connected applications.
    • Configuration rules prevent invalid combinations of product options.
    • Validated configurations can trigger pricing, engineering and BOM workflows.
    • ERP owns many order, inventory, item and financial transactions.
    • PLM owns released product structures, revisions and engineering change processes.
    • PDM manages CAD documents and design metadata.
    • CAD automation can generate product-specific drawings when supported by the architecture.
    • EBOM represents an engineering product structure.
    • MBOM represents a manufacturing-oriented assembly structure.
    • Event brokers distribute CPQ events to multiple subscribing systems.
    • Idempotency prevents duplicate processing of webhook deliveries.
    • Correlation identifiers connect configuration, quote, engineering and order records.

    Frequently asked questions

    1. What is a webhook in a CPQ system?

    A webhook is an HTTP notification sent when a CPQ event occurs, such as configuration validation, quote approval or customer acceptance. The receiving application uses the notification to start processing or retrieve more data.

    2. Are webhooks the same as APIs?

    No. An API usually supports a request initiated by a client, while a webhook pushes a notification from the source system. Manufacturing integrations often use both: the webhook signals a change and the API returns authoritative configuration, BOM or quote details.

    3. What is event-driven CPQ integration?

    It is an integration model in which CPQ publishes business events and connected systems respond to the events they subscribe to. It can coordinate CRM, ERP, PLM, CAD, PDM and MES workflows.

    4. Can webhooks create an ERP sales order?

    They can trigger an ERP order-creation process, but the webhook itself does not guarantee that the order was created. The integration should return an outcome, store the ERP identifier and provide recovery handling for failures.

    5. Should CPQ send the complete BOM in a webhook?

    Not necessarily. A webhook may provide the configuration and BOM identifiers while the receiving system retrieves the detailed structure through an API. The correct approach depends on payload size, ownership and whether CPQ or another system is authoritative for the BOM.

    6. How do webhooks support configure-to-order manufacturing?

    After a standard product configuration is validated and accepted, events can trigger pricing, order creation, BOM resolution and production preparation. The workflow should still distinguish a valid configuration from an approved and released order.

    7. Can event-driven integrations support engineer-to-order products?

    Yes, if engineering review, design generation, change approval and release states are modeled explicitly. An ETO workflow usually requires more than a simple quote-accepted webhook because new engineering work may be required.

    8. What is an idempotent webhook consumer?

    It is a receiving process that can safely handle the same event more than once without creating duplicate business records. This is important for ERP orders, CAD jobs, BOM releases and approval tasks.

    9. How should duplicate webhook messages be handled?

    Record the event identifier and business object version before completing processing. If the identifier has already been processed, return a successful response or perform a safe no-op rather than creating another transaction.

    10. What happens if ERP is unavailable when CPQ publishes an event?

    The integration should queue the event, retry according to defined rules and alert an operator if delivery continues to fail. It should not silently mark the order as complete merely because the webhook was accepted.

    11. Can a webhook trigger CAD automation?

    It can request a CAD job where the implementation supports CAD automation. The result may be a drawing, model, error or engineering-review request. CPQ should not be assumed to generate CAD files unless that capability is documented and implemented.

    12. What is the difference between an EBOM and an MBOM in event-driven workflows?

    An EBOM describes the engineering product structure, while an MBOM describes how manufacturing assembles or produces the product. A CPQ event may trigger either process, but the receiving system and approval rules may be different.

    13. Are webhooks suitable for price updates?

    They can notify CPQ or downstream systems that a price, cost or customer agreement changed. Price recalculation should use the applicable effective date, currency, contract and product-model version rather than blindly applying the latest value.

    14. What security controls are needed for CPQ webhooks?

    Use encrypted transport, authentication, request-signature validation, input validation, access controls, rate limiting and monitoring. Payloads should contain only the data needed by the receiving system.

    15. What should a CPQ event schema contain?

    Useful fields include event type, unique event identifier, timestamp, source, schema version, object identifiers, product-model version and correlation identifier. Additional fields depend on the event and data-ownership rules.

    16. Should every CPQ event be sent to every connected system?

    No. Subscribers should receive only events relevant to their responsibilities. Filtering reduces unnecessary coupling and limits exposure of commercial, customer or engineering information.

    17. How do webhooks differ from polling for manufacturing data?

    Webhooks notify a system when a change occurs, while polling repeatedly checks for changes. Webhooks can reduce delay and unnecessary requests, but polling may remain useful for reconciliation or systems that cannot receive callbacks.

    18. What should manufacturers test before deploying webhook integrations?

    Test normal processing, duplicate messages, out-of-order events, product-model revisions, invalid configurations, ERP downtime, CAD failures, rejected quotes, partial transactions and manual recovery. Connectivity testing alone is not sufficient.

  • REST APIs for Product Configuration in Manufacturing CPQ

    REST APIs for product configuration connect a manufacturing CPQ system with the applications that manage product data, customers, engineering, production and commercial transactions. A configurator can receive product options from a web application or CRM, validate the selections against engineering rules, calculate price and cost, and return a configured product, bill of materials (BOM), quote or engineering request through an API.

    In manufacturing, a REST API is not simply a way to submit a list of sales options. The API may need to represent dimensions, materials, motors, electrical ratings, performance calculations, revision-controlled components, manufacturing structures and the distinction between a standard configured product and an engineer-to-order design. The quality of the product model and ownership of data are therefore as important as the API technology itself.

    This article explains where REST APIs fit in a manufacturing CPQ architecture, which resources and operations are commonly required, how CPQ exchanges data with enterprise systems, and what implementation risks buyers and project teams should evaluate. For a broader introduction, see the guide to CPQ integrations and the manufacturing CPQ guide.

    What is a REST API for product configuration?

    A REST API for product configuration is a web-based application programming interface that lets software systems create, read, validate, update and complete configurations of configurable products using standard HTTP requests and structured data, commonly JSON.

    REST, or Representational State Transfer, is an architectural style in which clients interact with resources through operations such as GET, POST, PUT, PATCH and DELETE. In a manufacturing CPQ environment, resources may include product models, options, rules, configuration sessions, configured products, prices, quotes, BOMs, documents and engineering requests.

    The API separates the user interface from the configuration engine. A dealer portal, CRM screen, ecommerce application, mobile application or custom engineering tool can call the same configuration services instead of reproducing product rules in each application. The CPQ system remains responsible for the rules and calculations that it owns, while ERP, PLM, CAD and other systems remain authoritative for the data they own.

    How REST APIs fit into a manufacturing CPQ architecture

    A manufacturing CPQ architecture commonly contains several distinct layers:

    • Experience layer: sales portals, dealer applications, ecommerce, CRM screens and internal engineering tools.
    • Configuration layer: the product model, options, constraints, dependencies, calculations and validation logic.
    • Commercial layer: pricing, discounting, costing, currencies, approvals, taxes and quote generation.
    • Engineering layer: CAD automation, drawings, technical calculations, engineering review and design outputs where supported.
    • Manufacturing data layer: configurable BOMs, engineering BOMs (EBOMs), manufacturing BOMs (MBOMs), routings and production attributes.
    • Enterprise systems: customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), manufacturing execution systems (MES) and product information management (PIM).

    A REST API can operate between any of these layers, but the integration should have a defined purpose. For example, a CRM may create a configuration session and receive a price, while an ERP may receive an order-ready configuration and manufacturing BOM. A PLM system may provide approved component revisions, while a CAD service may generate a product-specific drawing.

    These systems are not interchangeable. CRM generally manages accounts, opportunities and customer interactions. ERP manages orders, inventory, purchasing, production and financial transactions. PLM manages product structures, revisions and lifecycle processes. PDM focuses primarily on engineering files and product data. CAD creates geometry and drawings. MES controls or records shop-floor execution. A CPQ API integration must identify which system is authoritative for each data element.

    Typical REST API product configuration workflow

    A configuration transaction usually follows a sequence rather than a single request.

    1. Identify the product model: the client requests an available model, market version or product family and specifies a model revision or effective date.
    2. Create a configuration session: the CPQ system returns a session identifier and an initial state containing required choices, defaults and selectable options.
    3. Submit choices incrementally: the client sends values such as pump flow, pressure, material, motor voltage, enclosure rating or mounting arrangement.
    4. Validate the state: the rules engine identifies valid, invalid, required and conditionally available selections.
    5. Run engineering calculations: the system may calculate performance, capacity, dimensions, power, heat load or other values. Some implementations call an external calculation service.
    6. Calculate price and cost: the CPQ system applies price lists, regional adjustments, labor, material cost, freight assumptions, discounts and approval rules as appropriate.
    7. Generate outputs: the result may include a configured product identifier, configurable BOM, EBOM, MBOM, technical summary, CAD request, quote or order payload.
    8. Persist and transfer the result: the configuration is saved with a revision or status and transferred to CRM, ERP, PLM, MES or another downstream process.

    Not every CPQ platform performs every step. A product configuration API may only validate options and return a product code. BOM generation, CAD automation, engineering calculations and production integration must be verified as separate capabilities.

    Core API resources for a configurator

    Resource names differ between products, but a manufacturing-oriented API commonly needs concepts similar to the following.

    Resource Purpose Manufacturing example
    Product model Defines a configurable product family and its revision Horizontal centrifugal pump, model revision 2025.1
    Option or feature Represents a selectable characteristic 316 stainless steel wetted parts
    Configuration session Stores choices, state, validation messages and calculated values A pump selection for a specific customer duty point
    Rule Controls compatibility, dependency, exclusion or requirement High-temperature seal required above a defined fluid temperature
    Configured product Represents a completed or partially completed result Pump with motor, seal, baseplate and controls
    Price or cost result Returns commercial calculations and assumptions Material cost, list price, discount and margin
    BOM Returns selected components and quantities Impeller, casing, motor, coupling and fasteners
    Document or output Provides generated files or references Datasheet, quotation PDF, drawing or CAD file

    Versioning is particularly important. A request that identifies only a product family may produce different results after rules, prices or component revisions change. APIs should support explicit model versions, effective dates or configuration snapshots where repeatability matters.

    Configuration data and rules exchanged through REST

    Configuration data should distinguish between the customer’s selections, values derived by the system and messages generated by validation. For example, a customer may select a flow rate and liquid temperature. The system may derive impeller diameter and motor size, then return a warning that the selected motor requires a different electrical enclosure.

    Common rule categories include:

    • Compatibility rules: prevent combinations that cannot be assembled, such as a motor frame incompatible with a selected pump adapter.
    • Dependency rules: make one option required when another is selected, such as requiring a temperature sensor when a monitoring package is chosen.
    • Exclusion rules: remove incompatible options, such as excluding a material that is unsuitable for a specified chemical.
    • Calculation rules: derive dimensions, capacity, power, weight or component quantities from inputs.
    • Manufacturing rules: enforce minimum dimensions, available processes, standard stock sizes or plant-specific constraints.
    • Commercial rules: apply price lists, customer agreements, regional currencies or approval thresholds.

    These rules should be executed by the configuration authority rather than duplicated in a CRM, website and dealer portal. Duplicated logic creates divergent results and makes product changes difficult to govern. A client may use API responses to improve the user experience, but it should not assume that client-side filtering is sufficient validation.

    It is also useful to distinguish rules-based configuration, which evaluates explicit product logic, from constraint-based configuration, which resolves a network of allowable relationships and constraints. Guided selling is a user experience that asks business-oriented questions and recommends suitable products. Guided selling may call a rules or constraint engine, but it is not a substitute for the underlying product model.

    Example API interaction

    The following simplified sequence illustrates the separation between a configuration session and a final result. The endpoint names are illustrative; actual paths and payloads depend on the CPQ platform.

    POST /api/configuration-sessions

{
  "productModel": "industrial-pump",
  "modelRevision": "2025.1",
  "context": {
    "currency": "EUR",
    "customerId": "CUST-1042"
  }
}

PATCH /api/configuration-sessions/SESSION-782/options

{
  "flowRate": 120,
  "flowUnit": "m3/h",
  "pressure": 8,
  "wettedMaterial": "316L",
  "motorVoltage": "400V"
}

POST /api/configuration-sessions/SESSION-782/validate

GET /api/configuration-sessions/SESSION-782/outputs

    A useful validation response should identify the state, not merely return a generic error. It may include valid selections, blocking errors, warnings, derived values, rule identifiers and the affected fields. This allows a client to explain why a 400 millimetre impeller is unavailable or why a particular motor must be upgraded.

    REST APIs and BOM, CAD and engineering outputs

    Product configuration and BOM generation are related but distinct functions. A configuration may be valid without producing a complete manufacturing BOM. Some systems return a sales BOM or configurable BOM, while others create an EBOM or MBOM.

    • Configurable BOM: a structure containing alternatives, conditions or placeholders that are resolved by configuration.
    • EBOM: an engineering bill of materials representing the product from a design perspective.
    • MBOM: a manufacturing bill of materials organized for production, assembly and process execution.

    A REST API may return BOM lines directly, return an asynchronous job identifier, or return a reference to an ERP or PLM object. The response should make clear whether quantities are final, whether phantom items are included, which revisions apply and whether the structure is intended for sales, engineering or production.

    CAD integration is similarly variable. A CPQ system may pass parameters to a CAD automation service, request a drawing, retrieve a 3D model or simply store a reference to a pre-existing file. CAD automation can generate product-specific geometry and drawings, but it normally requires controlled templates, parameter mappings, naming conventions, revision handling and engineering validation. More information is available in the CAD and engineering automation guide.

    For products that require engineering review, the API should support an explicit ETO, or engineer-to-order, state. A completed configuration may create an engineering request rather than an immediately orderable product. This is different from CTO, or configure-to-order, where approved modules and rules are intended to produce a repeatable product without new design work.

    Integration patterns with ERP, PLM, CRM and other systems

    System Common API interaction Important ownership question
    CRM Starts configuration from an opportunity and receives price, summary and quote status Does CRM own the configuration or only the customer and opportunity?
    ERP Receives order-ready product data, item numbers, prices, BOMs or manufacturing attributes Which system creates the material, sales order and production structure?
    PLM Provides approved product structures, revisions and lifecycle status Which revision is valid for a quote or order date?
    PDM Provides engineering files and document metadata How are file versions linked to a configured product?
    CAD Receives parameters and returns geometry, drawings or technical documents Who validates generated design output?
    PIM Provides descriptions, images and channel-oriented product information Are marketing attributes confused with engineering attributes?
    MES Receives production-relevant configuration, instructions or identifiers Is the API sending a released manufacturing structure or only a sales result?

    Some integrations use synchronous REST calls for short operations such as retrieving options or validating a field. Long-running activities such as CAD generation, complex pricing, BOM release or ERP order creation are better handled asynchronously. The API can return a job identifier and provide a status endpoint or callback mechanism. This prevents a browser or CRM transaction from waiting indefinitely for an engineering process.

    API design considerations for manufacturing

    Use stable identifiers and external references

    Option labels can change, and translations may differ by market. Integrations should use stable identifiers for product models, options, values, revisions, units and business objects. External references can map a CPQ configuration to a CRM opportunity, ERP order, PLM change or CAD document.

    Handle units, precision and validation

    Industrial products use dimensions, pressures, temperatures, flow rates, weights and electrical values. Every numeric value should have a defined unit, precision and rounding policy. Converting 120 litres per minute to another unit is not equivalent to interpreting the number without its unit. API contracts should define accepted ranges and whether rounding occurs before or after engineering calculations.

    Make operations idempotent where appropriate

    An idempotent operation can be safely retried without creating duplicate business objects. This is important when a network failure occurs after an ERP order or quote request was submitted. Idempotency keys, correlation identifiers and clear transaction states help prevent duplicate orders, duplicate configurations and inconsistent handoffs.

    Return meaningful errors

    HTTP status codes are useful, but manufacturing users need business-level detail. A response should distinguish authentication failure, malformed data, unavailable product revision, invalid combination, missing approval and downstream ERP failure. Error messages should identify the affected field or rule without exposing sensitive implementation details.

    Separate configuration state from quote state

    A configuration can be edited many times before a quote is issued. A quote may then become versioned, approved or expired. APIs should avoid treating every configuration update as a new commercial quote and should provide clear transitions between draft, validated, priced, submitted, approved and ordered states.

    Security and governance

    REST APIs expose valuable product, customer and commercial data. Security design should include authenticated clients, authorization by role and business context, encrypted transport, rate limits, audit logs and monitoring. A dealer may be permitted to configure only products for a specific market, while an internal engineer may access more technical options.

    API governance should define who can publish product model revisions, change rules, approve price logic and retire endpoints. Product configuration changes should be tested against representative configurations, boundary values and known invalid combinations. Where rules affect safety, compliance or manufacturing feasibility, the organization should retain an audit trail showing which model revision and rule set produced a result.

    API versioning is necessary when payloads, identifiers or business behavior change. Backward compatibility is especially important for dealer portals, ecommerce applications and plant integrations that may not be upgraded at the same time as the CPQ system.

    Benefits and limitations

    Potential benefit What it requires
    One configuration service for multiple channels A maintained product model and consistent authorization
    Faster transfer from sales to engineering Structured configuration data and clear handoff states
    Fewer manual entry errors Stable identifiers, validation and controlled mappings
    More accurate pricing and costing Reliable price, cost, currency and approval data
    Automation of BOM and CAD outputs Supported downstream capabilities, templates and revision control
    Channel flexibility Well-designed APIs and clients that do not duplicate core rules

    REST APIs do not repair poor product data. If options are inconsistently named, rules are undocumented, revisions are missing or BOM ownership is unclear, an API will transfer the inconsistency faster. APIs also introduce operational dependencies: a product configuration may be blocked by an unavailable pricing service, ERP outage, expired token or incompatible model revision.

    Implementation approach

    1. Map the configuration journey: document where product selection starts, which decisions are made, and when price, engineering and production data are required.
    2. Assign data ownership: identify the authoritative source for product options, revisions, prices, customers, materials, BOMs, drawings and orders.
    3. Define the canonical configuration model: agree on identifiers, units, statuses, option values, derived values and validation messages.
    4. Design the API contract: document resources, operations, payloads, authentication, errors, versioning and synchronous versus asynchronous behavior.
    5. Build representative product slices: begin with a product family that includes real dependencies, dimensions, materials and downstream requirements.
    6. Test across systems: verify valid and invalid configurations, revision changes, prices, BOM structures, CAD outputs and ERP handoffs.
    7. Monitor and maintain: measure failures, response times, abandoned sessions, rule errors and downstream reconciliation issues.

    Implementation planning should include product data migration, governance, testing and adoption, not only endpoint development. The CPQ implementation guide covers these broader project concerns.

    REST APIs compared with other integration approaches

    REST is common because it works well with web applications and distributed systems, but it is not the only option. SOAP services may still exist in enterprise applications. GraphQL can allow clients to request specific data shapes. Messaging and event-driven integration can notify systems that a configuration was completed or an engineering job finished. Batch file exchange may remain practical for controlled ERP or manufacturing transfers.

    The correct approach depends on transaction volume, latency, reliability, existing systems and the need for immediate validation. A hybrid architecture is common: REST for interactive configuration, asynchronous messaging for long-running outputs, and scheduled reconciliation for master data.

    Semantic map

    The relationships below show how REST APIs connect product configuration with the wider manufacturing technology stack.

    • CPQ connects sales channels with product configuration and manufacturing data.
    • Product models define options, attributes, dependencies and configuration states.
    • Configuration rules prevent invalid combinations and enforce engineering constraints.
    • Configuration sessions store selections, derived values, validation messages and context.
    • Engineering calculations transform customer requirements into technical selections.
    • Configured products can generate prices, quotes, BOMs and engineering requests.
    • CAD automation can generate product-specific drawings and models when supported.
    • PLM provides approved product structures and revision-controlled engineering data.
    • ERP receives order, item, price, BOM and production-relevant information.
    • CRM provides customer, opportunity and commercial context for configuration.
    • MES consumes released manufacturing information for production execution.
    • API governance controls security, versioning, ownership, testing and auditability.

    Frequently asked questions

    1. What does a REST API do in a CPQ configurator?

    A REST API lets another application create configuration sessions, submit product choices, validate combinations, retrieve prices and request outputs such as quotes, BOMs or engineering documents.

    2. Is a REST API the same as a CPQ configurator?

    No. The configurator contains the product model, rules and calculations. The REST API is an interface that allows other applications to use those capabilities.

    3. Can a REST API generate a manufacturing BOM?

    It can if the CPQ platform supports BOM generation and exposes that function. The response should identify whether the result is a sales BOM, configurable BOM, EBOM or MBOM.

    4. Can REST APIs automate CAD drawings?

    Yes, where the CPQ and CAD architecture supports automation. The API may submit parameters, start a generation job and return a drawing or CAD-file reference, but templates and engineering validation are still required.

    5. Should product rules be stored in the CRM?

    Usually not. Core configuration rules should generally be maintained in the configuration authority so CRM, dealer and ecommerce clients receive consistent validation.

    6. How does a CPQ API connect with ERP?

    It can exchange product identifiers, customer data, prices, order lines, BOMs, configuration attributes and status information. The integration must define which system creates and owns each business object.

    7. What is the difference between a configuration session and a quote?

    A configuration session records product choices and validation state. A quote is a commercial document or transaction that may contain approved prices, terms, validity dates and customer information.

    8. Are REST APIs suitable for engineer-to-order products?

    Yes, but the API may need to create an engineering request rather than an immediately orderable product. ETO workflows require engineering status, document references, approvals and revision control.

    9. What is the difference between CTO and ETO in an API workflow?

    Configure-to-order uses approved modules and rules to produce a repeatable product. Engineer-to-order creates or modifies engineering content for a specific requirement, often through an additional review process.

    10. Should validation happen in the browser or on the server?

    Basic browser validation can improve usability, but authoritative validation should occur in the server-side configuration engine because clients can be outdated or bypassed.

    11. How should an API represent invalid product combinations?

    It should return a structured response identifying the affected fields, blocking rules, explanatory messages and any suggested valid alternatives where the platform supports them.

    12. Why are units important in product configuration APIs?

    Industrial configurations use dimensions, pressure, flow, temperature, power and weight. The API must define units and conversion rules so that identical numbers do not produce different engineering results.

    13. Should a product configuration API be synchronous?

    Short operations such as retrieving options and validating choices can be synchronous. CAD generation, complex pricing, BOM release and ERP order creation are often better handled as asynchronous jobs.

    14. How do APIs handle product revisions?

    They can use model revision identifiers, effective dates or immutable configuration snapshots. This allows an old quote or order to be traced to the rules and component revisions that produced it.

    15. What security controls are important for CPQ APIs?

    Important controls include authenticated clients, authorization, encrypted transport, rate limiting, audit logging, secret management and restrictions based on role, market, dealer or product family.

    16. Can one CPQ API serve sales, dealers and ecommerce?

    It can, if the API supports the different permissions, product visibility, pricing contexts and user experiences. The underlying product rules should remain consistent while channel-specific policies are applied separately.

    17. What is the biggest implementation risk?

    A common risk is unclear data ownership. If CPQ, ERP, PLM and CRM each contain conflicting product, price or revision data, the API may create technically successful but operationally incorrect transactions.

    18. How should REST API integrations be tested?

    Test valid and invalid configurations, boundary values, rule changes, units, revisions, price calculations, BOM results, permissions, retries, outages and reconciliation with downstream ERP, PLM or CAD records.

  • Product Catalog Design for Manufacturing CPQ

    Product catalog design for manufacturing CPQ is the process of structuring products, options, rules, technical attributes, prices and downstream manufacturing data so that a Configure, Price, Quote (CPQ) system can create valid and commercially accurate configurations. In a manufacturing environment, the catalog is not simply a sales list. It is part of the product and enterprise data architecture connecting sales, engineering, production and business systems.

    A well-designed catalog can help a sales engineer configure a pump package, industrial machine or specialty vehicle without selecting incompatible components. It can calculate a technically appropriate model, produce a quote, generate a configurable Bill of Materials (BOM), send order data to Enterprise Resource Planning (ERP), and—where supported—trigger CAD automation or engineering review. A poorly designed catalog usually creates duplicated products, hidden exceptions, manual engineering work and inconsistent prices.

    This article explains how to design a manufacturing CPQ catalog, what data belongs in it, how it should interact with ERP, Product Lifecycle Management (PLM), Customer Relationship Management (CRM), Computer-Aided Design (CAD) and other systems, and how to govern it over time.

    What is a manufacturing CPQ product catalog?

    A manufacturing CPQ product catalog is a structured product model containing the sellable offerings, configurable options, technical attributes, dependencies, constraints, calculations, pricing inputs and outputs required to configure and quote a manufactured product.

    The catalog normally represents a product family rather than only individual stock-keeping units (SKUs). A centrifugal pump family, for example, might include flow range, head, impeller diameter, casing material, seal type, motor rating, voltage, mounting arrangement and certification options. The catalog defines which combinations are valid and how the selected values affect price, cost, BOM content, lead time and engineering outputs.

    This differs from a generic sales catalog that may contain product names, descriptions, images and prices. Manufacturing CPQ requires technical relationships and downstream data. A catalog may need to represent mutually exclusive options, dimensional limits, engineering formulas, replacement components, manufacturing variants and approval requirements.

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

    Why catalog design matters in manufacturing CPQ

    The product catalog is often the central model used by the configuration experience, rules engine, pricing engine and quote process. It also acts as a controlled translation layer between commercial language and engineering or manufacturing data.

    Catalog responsibility Manufacturing purpose Example
    Product structure Organize families, models, variants and modules Base conveyor, drive package, guarding and controls
    Configuration data Capture technical selections and dimensions Belt width, conveyor length and motor voltage
    Rules Prevent invalid or unsafe combinations A high-temperature seal is required above a specified fluid temperature
    Calculations Convert requirements into engineering or commercial results Motor size calculated from load, speed and duty cycle
    Pricing Calculate price, cost, discounts and surcharges Material surcharge and regional labor adjustment
    Downstream mapping Generate or select production and engineering records Configured components mapped to an ERP BOM

    Catalog structure directly affects maintainability. If every possible product combination is created as a separate SKU, the organization may face a large and difficult-to-govern item master. If the model is too abstract, sales and engineering may lack the information needed to validate a configuration or build the product.

    Core layers of a manufacturing CPQ catalog

    1. Product families and models

    Start with a hierarchy that reflects how the manufacturer sells and engineers products. A typical structure may be product family, platform, model series, module, option group, component and service.

    For an industrial air-handling unit, the hierarchy could include the unit family, frame size, airflow range, coil section, fan assembly, filter bank, controls package and installation accessories. The hierarchy should support navigation for users while preserving the technical relationships needed by the rules engine.

    Do not assume that the commercial hierarchy and engineering hierarchy are identical. Sales may describe a product as a packaged system, while engineering manages it as a collection of assemblies and subassemblies. The catalog should provide a deliberate mapping between the two views.

    2. Features, options and attributes

    Features describe meaningful configuration decisions, while options are the selectable values within those features. Attributes describe measurable or descriptive properties such as length, material, rating, capacity, color or certification.

    For a valve assembly, features might include valve type, body material, connection standard, actuator and positioner. Attributes could include nominal diameter, pressure class, temperature range and flow coefficient. Some attributes are entered by the user; others are calculated or inherited from selected components.

    Use controlled values and units wherever possible. A free-text field for motor voltage or pipe diameter makes validation, pricing and integration difficult. Numeric values should have defined units, ranges, precision and conversion rules.

    3. Configuration rules and constraints

    Rules determine whether a configuration is valid and what the system should do when a selection changes. Common rule types include:

    • Compatibility rules: allow a component only with compatible models or interfaces.
    • Dependency rules: require one option when another is selected.
    • Exclusion rules: prevent two incompatible options from being selected together.
    • Range rules: restrict dimensions, capacity or ratings to supported limits.
    • Calculation rules: derive values such as motor size, wall thickness or required accessories.
    • Default rules: suggest a standard selection without preventing alternatives.
    • Approval rules: route unusual configurations to engineering or management review.

    Rules-based configuration evaluates explicit conditions defined by the manufacturer. Constraint-based configuration evaluates relationships and limits among variables, which is useful when a product has many interacting dimensions or performance requirements. Guided selling focuses on helping a user reach a suitable product through questions and recommendations; it does not necessarily provide the engineering validation required for a buildable product.

    Rules should be written so that their ownership and purpose are clear. A rule such as “Option X requires Option Y” is easier to test than an undocumented script that changes several fields and silently modifies the price.

    4. Technical and engineering data

    A manufacturing catalog may contain or reference dimensions, materials, performance curves, tolerances, ratings, environmental limits, standards, drawings, calculation coefficients and engineering classifications.

    Not every engineering record should be copied into CPQ. Product Lifecycle Management (PLM) or Product Data Management (PDM) may remain the system of record for released specifications, revisions and CAD documents. CPQ should receive the subset of data needed to configure, validate, price and hand off the product.

    For example, a pump catalog may store available impeller diameters, operating ranges and material compatibility in CPQ, while detailed design documents and approved CAD files remain managed in PLM or PDM.

    5. Commercial data

    Commercial data includes list prices, cost inputs, currencies, customer-specific agreements, discounts, surcharges, freight assumptions, labor factors, tax classifications and effective dates. Pricing should be separated conceptually from configuration. A product may be technically valid but commercially unavailable in a region, or a valid selection may require a special surcharge.

    Pricing ownership must be defined. In some architectures, CPQ calculates the quote price while ERP provides standard costs and item prices. In others, a pricing service or commercial master-data system supplies pricing conditions. The catalog should identify the source, update frequency and authority for each value.

    Product catalog relationships with enterprise systems

    Manufacturing CPQ should be designed as part of the wider technology stack rather than as an isolated sales application.

    System Typical responsibility Catalog relationship
    CRM Accounts, opportunities and customer interactions Starts the opportunity or stores the resulting quote
    ERP Items, inventory, purchasing, costing, orders and production transactions Provides or receives item, pricing, BOM and order data
    PLM Product lifecycle, revisions, released structures and technical change control Supplies approved product and revision information
    PDM CAD files, documents and design metadata Links configured selections to approved design records
    CAD Geometric and engineering design data May receive parameters and return drawings or models
    PIM Product information for channels and commerce Publishes descriptions, media and channel attributes
    MES Manufacturing execution and shop-floor activity May receive production-relevant configuration or routing information

    These systems are not interchangeable. ERP item records do not replace engineering configuration rules. PLM revision control does not automatically provide quote pricing. CRM opportunity data does not contain a complete manufacturing BOM. A successful architecture defines which system owns each data domain and how changes are synchronized.

    The manufacturing CPQ integration guide covers integration patterns, APIs and system boundaries in more detail.

    Catalog design and BOM generation

    A configured product may generate one or more BOM representations. An Engineering BOM (EBOM) describes the product from an engineering perspective, often emphasizing design structure and functional assemblies. A Manufacturing BOM (MBOM) describes how the product is built, including manufacturing assemblies, consumables, operations or plant-specific structures. A configurable BOM uses rules or selection logic to derive the relevant components for a particular configuration.

    CPQ may generate a complete BOM, select an existing ERP BOM, create a configuration-specific BOM request, or pass structured selections to another system that performs the final expansion. The correct approach depends on product complexity, ERP capabilities, manufacturing process and governance requirements.

    For a configurable electrical enclosure, CPQ could select the enclosure size, gland plate, breakers, cooling unit and control components. The resulting structure may be sufficient for quoting but not yet sufficient for manufacturing if routing, plant-specific substitutes or work instructions are managed elsewhere.

    Do not treat a quote BOM as automatically equivalent to a released production MBOM. The data may require engineering approval, revision validation and plant-specific transformation.

    See BOM, pricing and quoting in manufacturing CPQ for related architecture and workflow considerations.

    Catalog design and CAD automation

    Some manufacturing CPQ implementations connect configuration choices to parametric CAD, drawings, models or engineering calculations. When available, this can reduce repetitive design work and support faster handoff from sales to engineering.

    A catalog may pass parameters such as length, hole pattern, motor position, material thickness or mounting orientation to a CAD automation process. The CAD system may then generate a product-specific model or drawing. However, CAD automation is not a standard capability of every CPQ platform and should be evaluated separately.

    The catalog must define which parameters are safe for automated generation, which combinations have approved templates, and when engineering review is required. A visual 3D model can improve understanding, but visualization alone does not prove that a product is manufacturable.

    Read the CAD and engineering automation guide for more on parametric models, drawings, calculations and design-system integration.

    Catalog patterns for CTO, ETO, MTO and ATO

    Catalog design should reflect the manufacturer’s fulfillment model.

    • Configure-to-order (CTO): the customer selects from predefined options and the product is assembled or produced using an established structure.
    • Engineer-to-order (ETO): the customer requirement triggers additional engineering, design work or approval beyond the standard model.
    • Make-to-order (MTO): production begins in response to an order, often using a standard or configured product.
    • Assemble-to-order (ATO): standard modules are stocked or prepared and assembled after the order is received.

    A CTO catalog can usually expose a controlled set of options and generate predictable downstream data. An ETO catalog may capture requirements, calculate preliminary specifications, identify a reference design and create an engineering task rather than promise a fully automated output.

    Combining CTO and ETO logic in one catalog requires clear status indicators. Users should know whether a selection is standard, conditionally available, subject to review or entirely outside the supported model.

    The manufacturing workflow guide explains how CPQ fits into configure-to-order, engineer-to-order and sales-to-production processes.

    Data ownership and catalog governance

    Catalog quality depends on governance as much as on software configuration. Establish an owner for each major data domain and define how changes are proposed, reviewed, tested, released and retired.

    Data domain Possible owner Governance question
    Product options Product management or engineering When is an option commercially available?
    Technical constraints Engineering What evidence supports the rule?
    Prices and discounts Finance or commercial operations Which system controls effective dates?
    ERP item mappings ERP or master-data team How are revisions and inactive items handled?
    CAD templates Design engineering Which parameters are approved for automation?
    Approval thresholds Engineering and management Which configurations require review?

    Use versioning and effective dates for products, rules, prices and integrations. A quote created under an earlier product revision may need to remain reproducible even after the catalog changes. Audit trails should show who changed a rule, why it changed and which configurations were tested.

    Implementation approach

    Document the product before building the model

    Collect product family structures, option lists, engineering rules, price logic, BOM mappings, drawings, exceptions and approval paths. Workshops with sales engineering, product management, design engineering, manufacturing, finance and IT are usually necessary because no single department owns the complete product definition.

    Separate stable structure from changing business logic

    Keep the product hierarchy and technical concepts understandable while allowing prices, discounts and regional availability to change independently. Avoid embedding every commercial exception in a technical configuration rule.

    Build a representative pilot

    Select a product family with meaningful configuration complexity but manageable scope. Include common configurations, boundary cases, invalid combinations, engineering-review cases and downstream integration scenarios. A simple product may demonstrate screens but will not adequately test catalog architecture.

    Test the complete transaction

    Test more than whether the configurator accepts a selection. Verify calculated values, price, discount, quote text, BOM, ERP item mapping, revision, CAD parameters, approval status and error handling. Test both normal and exceptional configurations.

    For implementation planning, data migration, testing and governance, consult the CPQ implementation guide.

    Common product catalog design mistakes

    • Copying the ERP item master into CPQ: an item master may lack configurable relationships and engineering constraints.
    • Creating a SKU for every combination: this can produce duplication and make maintenance impractical.
    • Using free text for technical selections: free text is difficult to validate, price and integrate.
    • Hiding rules in custom code: opaque logic increases testing and ownership problems.
    • Mixing released and provisional products: users may quote products that are not approved for production.
    • Treating a visual model as engineering validation: a 3D view does not replace structural, electrical or performance checks.
    • Ignoring historical quotes: changes must not make previously issued quotes impossible to reproduce.
    • Failing to model exceptions: unusual configurations should be routed to review rather than silently accepted or rejected.

    How to evaluate catalog capability in CPQ software

    When evaluating CPQ software for manufacturing, ask vendors to demonstrate a representative product model rather than a generic quote screen. The demonstration should include multiple interacting dimensions, incompatible materials, calculated selections, configurable BOM output, price changes, revision handling and an ERP or PLM handoff where relevant.

    Important evaluation questions include:

    • Can the platform represent product families, modules, variants and reusable rules?
    • Can business users maintain options and rules without unsafe developer changes?
    • Does it support numeric constraints, formulas, units and engineering calculations?
    • How are configurable BOMs represented and transferred?
    • Can the system distinguish quote data from released manufacturing data?
    • How are product, rule, price and configuration revisions managed?
    • What APIs and integration methods are available?
    • Can it support CTO, ETO, MTO or ATO workflows appropriate to the manufacturer?
    • Does it provide CAD automation or only link to external CAD processes?
    • How are invalid configurations, exceptions and engineering approvals handled?

    Capabilities vary significantly between platforms. Some products focus on guided selling and commercial quoting, while others provide deeper product modeling, engineering automation or BOM generation. These capabilities should be verified in product documentation and a relevant proof of concept rather than assumed from the term CPQ.

    Benefits and limitations

    A well-designed catalog can reduce configuration errors, improve quote consistency, shorten sales-engineering handoffs, expose accurate option dependencies and provide structured data for ERP or engineering processes. It can also make product changes more controlled because rules and mappings are managed in a defined model.

    However, a catalog does not eliminate poor source data or unclear product ownership. It may expose contradictions between engineering documents, ERP items and price lists. Complex ETO products may still require engineering review. Integration latency, revision conflicts, plant-specific manufacturing rules and legacy data can limit automation. Catalog design is therefore an ongoing product-data discipline, not a one-time screen-building project.

    Semantic map

    The semantic relationships below summarize the main entities and flows discussed in this article.

    • Manufacturing CPQ configures configurable products.
    • Product catalogs define product families, features and options.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration evaluates technical relationships and limits.
    • Configured products generate quote data.
    • Configured products can generate or select BOM structures.
    • EBOM represents engineering product structure.
    • MBOM represents manufacturing product structure.
    • Pricing rules calculate commercial values.
    • CPQ exchanges customer and quote data with CRM.
    • CPQ exchanges item, order and BOM data with ERP.
    • PLM manages product lifecycle and revision information.
    • PDM manages CAD files and design documents.
    • CAD automation generates product-specific drawings or models when supported.
    • ETO configurations trigger engineering review.
    • Catalog governance controls rules, revisions and ownership.

    Frequently asked questions

    1. What is a product catalog in manufacturing CPQ?

    It is a structured model of products, options, attributes, rules, calculations, prices and downstream mappings used to configure and quote manufactured products.

    2. How does a manufacturing CPQ catalog differ from a sales catalog?

    A sales catalog mainly presents products and prices. A manufacturing catalog also represents technical constraints, engineering logic, BOM relationships, revisions and production handoff data.

    3. Should ERP be the system of record for the CPQ catalog?

    Not necessarily. ERP commonly owns items, inventory, orders and financial transactions, while CPQ owns configuration logic and PLM or PDM may own released engineering data. Ownership must be defined by data domain.

    4. Should every configurable combination have its own SKU?

    No. Many manufacturers use product families, configurable options and rule-driven mappings rather than creating a separate SKU for every possible combination.

    5. What information should a CPQ catalog contain?

    It may contain product structures, options, technical attributes, constraints, formulas, prices, costs, BOM mappings, approval rules, revision data and integration identifiers.

    6. What is the difference between an option and an attribute?

    An option is usually a selectable value, such as stainless-steel casing. An attribute describes a property, such as casing thickness, diameter or operating temperature.

    7. What are configuration rules?

    Configuration rules define dependencies, exclusions, ranges, calculations, defaults and approvals that determine whether a product selection is valid.

    8. Does every CPQ system generate a BOM?

    No. Some systems generate configurable BOMs, some select ERP structures, and others pass configuration data to another system. This capability must be verified for the specific platform.

    9. Is a CPQ BOM the same as an MBOM?

    Not always. A CPQ BOM may support quoting or preliminary order processing, while an MBOM includes the manufacturing structure and plant-specific information needed to build the product.

    10. Can CPQ generate CAD drawings?

    Some platforms integrate with CAD automation or engineering systems, but CAD generation is not universal. The implementation must define supported templates, parameters and review conditions.

    11. How should ETO products be represented?

    The catalog should capture known requirements, identify a reference product or design envelope, and route nonstandard selections to engineering rather than presenting them as fully automated standard products.

    12. What is the role of PLM in catalog design?

    PLM may own product lifecycle status, released revisions, engineering structures and change control. CPQ can consume approved data needed for configuration and quoting.

    13. What is the role of PDM?

    Product Data Management systems commonly manage CAD files, drawings and related design documents. CPQ may link configuration results to approved PDM records or pass parameters to CAD automation.

    14. How should prices be managed in the catalog?

    Define which system owns list prices, costs, discounts, surcharges, currencies and effective dates. Separate commercial rules from technical configuration rules where practical.

    15. How do units affect catalog design?

    Dimensions and performance values should have defined units, ranges, precision and conversion behavior. This prevents errors when users, CAD systems or ERP operate in different unit systems.

    16. How should catalog changes be tested?

    Test valid, invalid, boundary and exception configurations, then verify prices, quote text, BOMs, revisions, integrations and approval routing.

    17. Who should own the product catalog?

    Ownership is usually shared. Product management may own commercial structure, engineering owns technical rules, finance owns pricing policies, and IT or master-data teams govern integrations and identifiers.

    18. How often should a manufacturing CPQ catalog be updated?

    It should be updated whenever products, prices, engineering rules, ERP items, revisions or regulatory requirements change. Release processes should control timing and effective dates.

    19. Can one catalog support CTO and ETO?

    Yes, but the model must distinguish standard selections from review-required configurations and clearly define when automated outputs stop and engineering work begins.

    20. What is the first step in designing a CPQ catalog?

    Document the product family, configuration decisions, rules, engineering outputs, prices, BOM relationships, system owners and workflow exceptions before configuring the software.

  • Composable CPQ for Manufacturing

    Composable CPQ for manufacturing is an architecture in which configure, price, quote (CPQ) capabilities are delivered as modular services and connected to the wider manufacturing technology stack. Instead of treating CPQ as one isolated application, a composable approach separates product configuration, rules, engineering calculations, pricing, quoting, bill of materials (BOM) generation, computer-aided design (CAD) automation and integration services where appropriate.

    This matters for manufacturers because the information required to produce an accurate quote is rarely owned by one system. Product definitions may be maintained in product lifecycle management (PLM) or product data management (PDM) software, customer and opportunity information may be held in customer relationship management (CRM), costs and item masters may belong to enterprise resource planning (ERP), and drawings or models may be generated by CAD systems. A composable CPQ architecture coordinates these capabilities while preserving data ownership in the systems responsible for it.

    In practical terms, composable CPQ can help a manufacturer configure a valid pump package, calculate a suitable motor and impeller combination, price the resulting assembly, generate a configurable BOM, request a CAD drawing, and send an approved order to ERP. However, not every CPQ platform provides every one of these functions. Buyers must establish which capabilities are native, which are delivered by extensions, and which remain in ERP, PLM, CAD or engineering applications.

    For background, see the broader guide to CPQ software for manufacturing and the guide to CPQ integrations.

    What is composable CPQ?

    Composable CPQ is a modular approach to CPQ in which business capabilities are exposed through reusable applications, services, APIs and data contracts. A manufacturer can combine these components to support a specific workflow rather than adopting one monolithic application for every configuration and engineering task.

    A composable architecture may include the following components:

    • Configuration experience: the user interface used by a salesperson, dealer, engineer, customer or ecommerce buyer.
    • Product model: the representation of products, options, variants, attributes, dependencies and selectable values.
    • Rules engine: logic that validates combinations, derives selections, enforces constraints or determines required actions.
    • Engineering calculation service: formulas or external engineering applications that calculate dimensions, capacity, performance or component selection.
    • Pricing and costing service: logic for list prices, discounts, surcharges, costs, margins, currencies and commercial approvals.
    • BOM service: logic that produces a configurable, engineering or manufacturing bill of materials for the selected product.
    • CAD and visualization service: tools that generate models, drawings, images or product-specific representations when supported.
    • Quote and document service: generation of quotations, specifications, approval records and customer-facing documents.
    • Integration and orchestration layer: APIs, events, middleware and workflow services that exchange data with ERP, CRM, PLM, PDM, CAD, product information management (PIM) and manufacturing execution system (MES) applications.

    These components can be deployed in one product, several products or a mixture of packaged software and custom services. “Composable” describes the architecture and assembly model; it does not guarantee that an implementation will be simple or that every component will be interchangeable.

    Why composable CPQ is relevant to manufacturers

    Generic sales CPQ often focuses on selecting commercial options, applying discounts and producing a quote. Manufacturing CPQ must frequently go further. The configuration may determine engineering feasibility, component dimensions, material requirements, production operations, compliance documentation and the data needed to manufacture the order.

    For example, configuring an industrial air-handling unit may involve airflow, static pressure, cabinet dimensions, insulation, coil selection, fan type, motor power, electrical supply, controls and environmental conditions. A valid configuration may require engineering calculations and may produce different components, drawings and production instructions. The pricing result is only one output of the configuration.

    Composable architecture is useful where a business has already invested in specialized systems or where different product families require different levels of engineering automation. One product line may need a deep CAD automation workflow, while another may only need rules-based option validation and ERP pricing. A modular design can support both without forcing every product family into the same technical model.

    Composable CPQ architecture in the manufacturing stack

    A typical architecture has several layers. The exact boundaries vary by business and software selection, but the following model helps clarify responsibilities.

    Layer Typical responsibility Manufacturing example
    Experience Guides a user through configuration, pricing and quoting Dealer selects a pump duty, materials, motor and accessories
    Configuration Maintains product options, attributes, dependencies and validation Prevents an incompatible motor and voltage combination
    Engineering Calculates or selects technical values and design outputs Calculates pump head, flow, shaft power or heat exchanger size
    Commercial Calculates prices, costs, discounts, margins and approvals Applies material surcharges and customer-specific discount rules
    Output generation Creates BOMs, specifications, drawings and quote documents Produces an order-specific BOM and a dimensioned arrangement drawing
    Enterprise systems Owns customer, item, cost, order, revision and production data ERP receives the approved order and manufacturing item references
    Integration Moves data between services and systems API or event sends configuration, price and revision information to ERP and PLM

    Configuration and product models

    The product model describes what can be sold and how it can be combined. It may include product families, models, features, options, dimensions, materials, accessories, software selections and service levels.

    The model should not be confused with a price list. A product configuration defines a technically and commercially meaningful product instance. Pricing is a separate concern, even though the selected configuration supplies inputs to pricing.

    Manufacturers should also distinguish several types of rules:

    • Rules-based configuration: explicit logic such as “if 480 V is selected, require a compatible motor option.”
    • Constraint-based configuration: a solver or constraint model determines whether a set of values satisfies technical relationships, ranges or dependencies.
    • Guided selling: questions and recommendations help a user reach a suitable product, but guided selling alone does not prove engineering validity.

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

    Engineering and CAD services

    Some manufacturing CPQ implementations include engineering calculations, parametric design automation, 2D drawings, 3D visualization or CAD file generation. Others validate configuration and hand the selected parameters to a separate engineering system.

    For example, a configurable conveyor may use CPQ to capture length, width, belt type, elevation, motor choice and guarding. A calculation service can determine drive requirements, while a CAD system generates a layout and an engineering application creates a product-specific drawing. The CPQ layer should record the inputs, calculation version and output references so that the quote can be traced to a particular engineering result.

    CAD automation is not an automatic consequence of composable CPQ. It requires suitable parametric models, stable interfaces, engineering rules, template governance and a process for handling exceptions. See CAD and engineering automation for CPQ.

    Pricing, costing and quoting

    A pricing service may calculate a selling price from the configured product, customer segment, currency, region, delivery terms, quantity, discount authority and commercial policies. A costing service may calculate material, labor, subcontracting, freight or estimated manufacturing costs.

    These are not necessarily the same as the configuration rules. A material may be technically valid but subject to a surcharge. A custom dimension may be valid but require engineering review. A customer may receive a discount that does not change the product definition but does change the commercial offer.

    Quote documents should identify the configuration, revision, assumptions, exclusions, lead-time basis and approval status. For BOM, pricing and quote architecture, see BOM generation, pricing and quote automation.

    Data ownership in a composable CPQ architecture

    The most important architecture decision is not whether to use APIs. It is deciding which system owns each type of data and how other systems consume it.

    Data domain Possible system of record CPQ relationship
    Customer, account and opportunity CRM CPQ reads customer context and returns configuration, quote and status information
    Product lifecycle, revisions and approved product structures PLM or PDM CPQ consumes released definitions, options, revisions or engineering references
    Item master, inventory, costs, orders and financial data ERP CPQ retrieves item and cost data and sends approved order information
    Product attributes and commercial content PIM or product master CPQ uses descriptions, images, documents and channel-specific content
    Geometry, templates and drawings CAD or engineering system CPQ sends parameters and stores generated-file references
    Production execution and work-center status MES CPQ usually provides order or configuration context rather than replacing execution control
    Configuration session and quote state CPQ CPQ records selected options, rule results, calculated values and commercial outcomes

    There is no universal answer for every domain. Some organizations manage configurable BOM logic in CPQ, while others maintain it in PLM or ERP. The decision should consider revision control, engineering approval, reuse, performance, auditability and the needs of downstream production.

    How a composable CPQ workflow works

    1. Start with commercial or customer context. A salesperson opens a CRM opportunity, or a dealer starts a new configuration. Customer, location, currency and channel data are passed to CPQ.
    2. Load the relevant product model. CPQ retrieves the applicable product family, market rules, effective date and product revision.
    3. Capture requirements. The user enters technical requirements such as flow, pressure, capacity, dimensions, temperature, material, voltage or environmental conditions.
    4. Validate and derive selections. Rules prevent invalid combinations, while calculations or selection services determine compatible components.
    5. Request engineering outputs when needed. CPQ may call a calculation engine, CAD automation service or engineering workflow. If the configuration exceeds supported rules, it can create an engineering review task.
    6. Generate commercial results. Pricing and costing services calculate price, margin, lead-time assumptions and approval requirements.
    7. Generate manufacturing-related outputs. Depending on the architecture, the system creates a configurable BOM, an engineering BOM (EBOM), a manufacturing BOM (MBOM), drawings, specifications or references to these outputs.
    8. Produce and approve the quote. The customer-facing quote includes the selected configuration and relevant assumptions. Internal approvals are recorded before release.
    9. Transfer the approved result. CPQ sends an order, configured item, BOM reference, document reference or configuration payload to ERP, PLM, PDM or another downstream system.
    10. Retain traceability. The business should be able to identify which product model, rule version, price version and engineering output produced the quote.

    This workflow can support configure-to-order (CTO), assemble-to-order (ATO), make-to-order (MTO) and engineer-to-order (ETO), but the level of automation differs. CTO uses predefined configurations. ATO assembles stocked or semi-finished components. MTO produces a product after the order, often using established designs. ETO creates or modifies engineering outputs for the specific order and normally requires stronger engineering workflow integration.

    The differences between these operating models are discussed in manufacturing CPQ workflows.

    Configurable BOMs, EBOMs and MBOMs

    A BOM is a structured list of components and quantities required for a product or assembly. A configurable BOM represents possible components and selection conditions. An EBOM is an engineering bill of materials organized around design intent. An MBOM is a manufacturing bill of materials organized around how the product is assembled or produced.

    Composable CPQ may generate a configured BOM directly, select an approved BOM variant, or send configuration parameters to PLM or ERP for BOM resolution. These approaches have different governance implications.

    Approach Potential use Important question
    CPQ resolves configured components Fast CTO or ATO quoting with established options How are revisions and production changes synchronized?
    PLM resolves the EBOM Engineering-controlled products with formal lifecycle management Can CPQ consume only released and valid structures?
    ERP resolves the production BOM Organizations where ERP owns item and manufacturing structures Can the order retain the original configuration and rule version?
    CPQ sends parameters to an engineering workflow ETO or calculation-driven products How are exceptions, approvals and design changes tracked?

    A common implementation error is treating any list of selected options as a production-ready MBOM. A commercial configuration may omit phantom assemblies, operation sequences, alternate materials, scrap factors, work instructions or plant-specific manufacturing data. The receiving system must confirm whether the output is suitable for production or only for quotation and engineering review.

    Integration patterns for composable CPQ

    Synchronous APIs

    A synchronous API request returns a result during the configuration session. It is suitable for retrieving item attributes, validating a selection, calculating a price or checking a technical value when the response is expected quickly.

    For example, CPQ may send pump flow, head, fluid and temperature to a selection service and receive compatible pump models. Timeouts, error handling and fallback behavior are important because a slow or unavailable service can interrupt quoting.

    Asynchronous events and workflows

    Asynchronous integration is useful when an operation takes longer or requires human review. CAD generation, ETO engineering, supplier checks and formal approval can produce events such as “drawing generated,” “engineering review completed” or “quote approved.”

    Event-based designs require reliable message handling, correlation identifiers, retries, duplicate protection and clear ownership of status. A quote should not appear technically approved simply because an integration request was sent.

    Batch and scheduled synchronization

    Some data does not need real-time exchange. Product descriptions, price books, released items, costs and document metadata may be synchronized on a schedule. Batch synchronization can reduce integration complexity but introduces timing and effective-date risks.

    Headless configuration services

    A headless configuration service separates configuration logic from the user interface. The same product model can support a salesperson application, dealer portal, ecommerce front end or internal engineering tool. This approach is useful when several channels need consistent rules, but it requires a stable API and careful control of channel-specific behavior.

    Benefits and limitations

    Potential benefits

    • Reuse of existing systems: the business can retain specialized ERP, PLM, CAD or engineering applications rather than replacing every system.
    • Channel consistency: shared configuration services can apply the same product rules across sales, dealers and digital channels.
    • Incremental delivery: a manufacturer can begin with configuration and pricing, then add BOM, engineering or CAD services where the business case is clear.
    • Clearer ownership: explicit boundaries can reduce duplicate product, cost and revision data.
    • Product-family flexibility: different product lines can use different engineering depth while sharing commercial and integration services.
    • Better traceability: versioned services and data references can make it easier to understand how a quote was produced.

    Limitations and risks

    • Integration becomes a product of its own: multiple services require monitoring, version management, security, testing and operational support.
    • Data semantics may conflict: an “option,” “variant,” “item,” “assembly” or “revision” may mean different things in CPQ, ERP and PLM.
    • Distributed failures are harder to diagnose: a quote may depend on several services with different availability and response times.
    • Rule duplication can grow: copying the same compatibility logic into CPQ, ERP, PLM and CAD creates inconsistent behavior.
    • Transaction boundaries are complex: a quote, drawing and order may not be committed at the same time.
    • Composable does not mean low-code: sophisticated configuration and engineering models still require domain expertise, testing and governance.
    • Vendor boundaries may be unclear: a platform may advertise extensibility or APIs without providing the manufacturing capabilities needed for BOM, CAD or engineering automation.

    Implementation considerations

    Define the target workflow before selecting components

    Start with a specific product family and workflow. Document the inputs, rules, calculations, outputs, approvals and systems involved. A pump manufacturer might map the flow from duty-point entry through pump selection, motor validation, material selection, costing, drawing generation and ERP order creation.

    Assign ownership for every important data object

    Create a data ownership matrix for product options, rules, revisions, item numbers, costs, prices, BOM structures, CAD templates, documents and customer data. Identify who can change each object, how changes are approved and how effective dates are applied.

    Separate rules by purpose

    Keep commercial rules, technical constraints, engineering formulas and manufacturing transformations distinguishable. A rule that blocks a combination is not the same as a formula that calculates a dimension, and neither is the same as a discount condition.

    Version models and outputs

    Configuration results should identify the product model version, rule version, price book, calculation version and relevant engineering revision. Without this information, reproducing an old quote or explaining a changed result becomes difficult.

    Design for exceptions

    Not every product can be fully automated. The architecture should support engineering review, manual adjustments, substitutions, customer-specific requirements and incomplete data without silently creating an invalid result. An ETO request should have a visible status and a defined handoff rather than appearing as a normal CTO configuration.

    Test the complete chain

    Testing must cover more than the CPQ user interface. Use representative combinations and test configuration validation, calculations, prices, BOM resolution, CAD outputs, document generation, API failures, revisions, permissions and downstream order creation. Regression tests are particularly important when a shared product model supports several channels.

    Implementation planning, governance and testing are covered in the CPQ implementation guide.

    How to evaluate composable CPQ software

    Manufacturers should evaluate the architecture against actual product and workflow requirements rather than counting generic features. Important questions include:

    • Can the platform represent product families, variants, dimensions, ranges, dependencies and conditional options?
    • Does it support rules-based configuration, constraint solving, guided selling, or only simple option selection?
    • Can rules and product models be versioned, tested and maintained by appropriate business or engineering users?
    • Can it expose configuration, validation, pricing and quote functions through documented APIs?
    • Does it generate a BOM, select a BOM, or pass parameters to another BOM-owning system?
    • Can it distinguish commercial configuration from EBOM and MBOM requirements?
    • Does it support engineering calculations, CAD automation or 3D visualization natively, through extensions, or not at all?
    • How are ERP, CRM, PLM, PDM, CAD, PIM and MES integrations implemented and monitored?
    • Can it support dealer, distributor, ecommerce and internal engineering channels with consistent logic?
    • How are ETO exceptions, approvals, manual engineering work and document revisions handled?
    • What happens when an external system is unavailable during configuration or order submission?
    • Can the organization export its product model, rules, configuration history and outputs if the architecture changes?

    Vendor claims should be verified through documentation, demonstrations using the manufacturer’s own product examples, API specifications, implementation references where available and a proof of concept. Do not assume that an API or modular architecture includes manufacturing-grade configuration, BOM, CAD or engineering behavior.

    Semantic map

    The following relationships summarize the main entities and how they interact in a composable manufacturing CPQ architecture.

    • CPQ connects product configuration with pricing, quoting and downstream manufacturing data.
    • Product models define selectable features, options, attributes and variants.
    • Configuration rules prevent invalid product combinations.
    • Constraint-based configuration evaluates technical relationships and limits.
    • Engineering calculations transform customer requirements into technical selections or values.
    • Configured products provide inputs to pricing and costing services.
    • Configured products can generate or select configurable BOM structures.
    • EBOM represents engineering design intent.
    • MBOM represents manufacturing assembly and production structure.
    • CAD automation generates product-specific models or drawings when supported.
    • CRM provides customer and opportunity context to CPQ.
    • ERP owns or consumes item, cost, order and financial data.
    • PLM or PDM governs product revisions and released engineering data.
    • MES executes or monitors production activities after order release.
    • APIs and events exchange configuration and engineering data between systems.
    • ETO workflows route unsupported configurations to engineering review.

    Frequently asked questions

    What is composable CPQ for manufacturing?

    It is a modular CPQ architecture that combines configuration, rules, engineering, pricing, quoting and manufacturing data services with systems such as ERP, PLM, CRM, CAD and MES.

    How is composable CPQ different from generic sales CPQ?

    Generic sales CPQ may focus on options, discounts and quote documents. Manufacturing composable CPQ also considers technical constraints, engineering calculations, BOMs, CAD outputs, revisions and production handoffs where those capabilities are required.

    Does composable CPQ replace ERP?

    Usually not. ERP commonly remains responsible for items, inventory, costs, orders, financial processing and manufacturing-related master data. CPQ supplies a validated commercial and technical configuration to ERP.

    Does composable CPQ replace PLM?

    Usually not. PLM often manages product lifecycle, engineering revisions and released product structures. CPQ may consume PLM data or manage a commercial configuration model linked to PLM references.

    Can composable CPQ generate a manufacturing BOM?

    It can in some implementations, but this is not universal. The BOM may instead be resolved in ERP or PLM. Buyers should verify whether the output is a configurable BOM, EBOM, MBOM or only a list of quoted options.

    What is the role of CAD in composable CPQ?

    CAD can receive configuration parameters and generate product-specific models, drawings or layouts. This requires compatible parametric models, automation interfaces and engineering governance; it is not guaranteed by a CPQ platform.

    Can composable CPQ support engineer-to-order products?

    Yes, when it includes or integrates with engineering workflow, calculation, CAD, approval and document processes. ETO should be treated as a controlled exception or design workflow rather than as simple option selection.

    Is a headless CPQ the same as composable CPQ?

    No. Headless CPQ separates the configuration service from its user interface. Composable CPQ is a broader architectural approach that may include headless services, modular applications, APIs and external engineering or enterprise systems.

    What systems commonly integrate with composable CPQ?

    Common systems include CRM, ERP, PLM, PDM, CAD, PIM, MES, ecommerce platforms, calculation services, document systems and integration middleware. The exact integration depends on the manufacturer’s workflow.

    Where should product rules be maintained?

    Rules should be maintained by the system best suited to their purpose and governance. Configuration rules may reside in CPQ, lifecycle-controlled engineering rules may reside in PLM or an engineering service, and manufacturing transformations may belong in ERP or manufacturing applications.

    How does composable CPQ handle pricing?

    It uses the configured product and commercial context as inputs to price books, cost data, discounts, surcharges, currencies, margins and approval policies. Pricing logic should remain distinguishable from technical configuration rules.

    Can one composable CPQ model serve dealers and internal engineers?

    It can when the platform provides reusable configuration services and role-specific interfaces. The dealer may see guided questions and prices, while an engineer may see calculated values, rule diagnostics and design outputs.

    What happens when an external integration fails?

    The system should provide explicit error states, retries where appropriate, monitoring and a controlled fallback or review process. It should not silently issue a technically incomplete quote or order.

    How does composable CPQ support configure-to-order?

    It validates a predefined product model, selects compatible options, calculates price and produces the required order or BOM data. The amount of downstream automation depends on ERP, PLM and production integration.

    How does composable CPQ support make-to-order?

    It captures the customer-specific requirements and creates a valid order configuration, while ERP or engineering systems determine procurement, production and delivery details.

    What is the main implementation risk?

    A major risk is unclear ownership or duplicated logic across CPQ, ERP, PLM, CAD and engineering services. This can produce conflicting rules, incorrect revisions, unreliable BOMs and difficult troubleshooting.

    How should a manufacturer start a composable CPQ project?

    Start with one representative product family and map the complete workflow from requirements through quote, engineering output and order release. Define data ownership, interfaces, exception handling and measurable acceptance criteria before expanding.

    How should composable CPQ vendors be evaluated?

    Evaluate product-model depth, rules, APIs, versioning, BOM behavior, pricing, engineering and CAD integration, ERP and PLM connectivity, exception workflows, governance, security, testing and implementation effort using real manufacturing examples.

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