CPQ Guide

Tag: PLM integration

  • How to Build a CPQ Product Model for Manufacturing

    A CPQ product model is the structured definition of a configurable product used by a Configure, Price, Quote system. In manufacturing, it describes the product hierarchy, selectable options, engineering parameters, configuration rules, calculations, prices and downstream outputs needed to produce a valid quote and, where supported, a bill of materials (BOM), CAD configuration or production order.

    Building a reliable model starts with the product and its engineering logic, not with a list of sales questions. The model should represent how the product is actually designed, priced, manufactured and supported. A pump model, for example, may need to validate flow, head, fluid properties, motor size, impeller diameter, materials, seal type, voltage and certification requirements before it can produce a price or manufacturing-ready result.

    This guide explains how to design a maintainable manufacturing CPQ product model, how to separate configuration rules from pricing, how to connect the model to BOM and CAD processes, and how to test and govern it over time.

    What is a CPQ product model?

    A CPQ product model is a machine-readable representation of a configurable product and the logic that determines which configurations are valid, what they cost and what data should be generated. It normally combines product structure, attributes, options, dependencies, constraints, calculations and outputs.

    In generic sales CPQ, a product model may mainly determine which commercial products can be selected together and how discounts are calculated. A manufacturing CPQ model usually goes further. It may also need to capture dimensions, materials, performance requirements, engineering formulas, component substitutions, manufacturing choices, assembly relationships and references to product data managed in other systems.

    Model element Purpose in manufacturing CPQ Example
    Product hierarchy Organizes the configurable assembly and its modules Conveyor system, drive unit, belt, guards and controls
    Options and attributes Captures choices or values selected by a user Belt width, frame material, motor voltage
    Rules and constraints Prevents invalid or unsafe combinations A high-temperature seal is required for a specified fluid temperature
    Engineering calculations Derives sizes, ratings or performance values Motor power calculated from load, speed and incline
    Commercial logic Calculates cost, price, discounts and surcharges Price adjusted for stainless steel and a hazardous-area motor
    Downstream outputs Provides data to quoting, engineering and production Configurable BOM, CAD parameters and ERP item references

    The model is therefore more than a product catalog. It is a controlled product knowledge base that connects commercial configuration with engineering and manufacturing processes.

    See the related guide to product configuration and configuration rules for a broader explanation of options, dependencies and validation.

    Why product-model design matters

    A poorly designed model can produce valid-looking quotes for products that cannot be built, priced profitably or supported by engineering. It may also become difficult to change when product managers add options, when suppliers change components or when engineering revises a design.

    A well-designed model provides a controlled path from customer requirements to an approved configuration. It can reduce manual interpretation by sales engineers, expose missing information early and create consistent data for later systems. However, CPQ does not automatically create accurate engineering logic. The quality of the result depends on the source product data, rule ownership, integration design and testing discipline.

    The main layers of a manufacturing CPQ product model

    1. Product structure

    Begin by representing the product as a hierarchy of assemblies, modules and components. The hierarchy should reflect how the product is configured and, where useful, how it is engineered or assembled.

    For an industrial air-handling unit, the structure might include the base unit, casing, fan section, filters, heating or cooling coil, controls, electrical package and accessories. Each module can have its own options, rules, calculations and output mappings.

    Do not assume that the sales structure, engineering structure and manufacturing structure are identical. A sales user may select one option called a heating package, while the engineering or manufacturing output may contain a coil, valves, sensors, control panels, wiring and mounting hardware. The model should make these relationships explicit rather than forcing users to select every internal component manually.

    2. Options and attributes

    Options are discrete choices, such as cast iron or stainless steel. Attributes are values that may be entered or calculated, such as length, flow rate, operating temperature or enclosure rating.

    Each attribute should have a defined data type, unit, allowed range, default behavior and ownership. A dimension should not be stored as unstructured text if it is used in calculations or CAD automation. Similarly, a material should use a controlled value connected to a material record or code rather than several free-text spellings.

    Data type Manufacturing example Design consideration
    Enumeration Motor type: standard, brake, inverter-duty Use controlled values with stable identifiers
    Numeric value Tank volume: 500 litres Store units, precision and valid range
    Boolean Include access platform: yes or no Define default and downstream effect
    Text Customer marking or project reference Keep free text out of engineering logic where possible
    Calculated value Required shaft diameter Document formula, inputs and rounding rules

    3. Dependencies

    Dependencies describe relationships between selections. If a customer selects a diesel engine, the model may show compatible exhaust, cooling and fuel-system options. If a product includes a hygienic stainless-steel frame, certain surface finishes and fasteners may become available while painted-steel options become unavailable.

    Dependencies should be expressed in terms of stable product data rather than interface labels. The rule should refer to an option identifier or attribute value that remains consistent if the wording shown to users changes.

    4. Constraints

    Constraints define what is permitted, required, excluded or conditionally available. Common types include:

    • Compatibility constraints: two components cannot be used together.
    • Requirement constraints: selecting one option requires another option.
    • Range constraints: a value must remain within a technically valid range.
    • Capacity constraints: a selected motor, frame or power supply must support the calculated load.
    • Process constraints: a configuration must follow manufacturing or installation limitations.
    • Regulatory constraints: materials, safety devices or certifications are required for a market or application.

    For example, a valve model may permit a 250-millimetre diameter only when the pressure class and body material support it. A pump model may reject an impeller diameter if the requested duty point falls outside the operating envelope. A mobile machine may require a specific braking package when gross vehicle weight exceeds a threshold.

    5. Calculations

    Engineering calculations transform requirements into derived values. They can size a component, determine a performance rating, select a standard part or calculate a surcharge. Examples include pressure drop, heat-transfer area, belt length, battery capacity, structural load, motor power and cable size.

    Calculation inputs should be clearly identified and validated before the calculation runs. The model should also record units, assumptions, rounding and the source of the formula. A formula copied from a spreadsheet without documenting its variables and limits is difficult to verify and maintain.

    Not every CPQ platform includes a full engineering calculation engine. Some systems rely on external services, CAD rules, engineering applications or custom code. The architecture should make this boundary explicit.

    6. Output mappings

    Output mappings connect configuration decisions to commercial and technical results. A selected option may map to a component number, a BOM quantity, an operation, a price condition, a CAD parameter, an ERP material code or a document section.

    One customer-facing option can produce multiple outputs. Selecting a stainless-steel pump package may change the casing material, fastener set, seal, baseplate finish, BOM components, cost, lead-time message and technical description.

    Start with a product-model scope

    Before building rules, define the product family and the business process the model must support. A first release should have a clear boundary. Trying to model every product variant, legacy exception and engineering possibility at once usually produces unclear ownership and excessive testing effort.

    Document:

    • the product family and included modules;
    • the intended users, such as sales, dealers, application engineers or customers;
    • the workflow, such as configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO) or assemble-to-order (ATO);
    • the required outputs, such as price, quote text, configurable BOM or CAD parameters;
    • the systems that own item, revision, customer and commercial data;
    • the approval points and conditions that require engineering review.

    CTO means configure-to-order: the product is assembled from predefined options and components. ETO means engineer-to-order: a customer requirement leads to additional engineering work or a new design. MTO means make-to-order: production begins after a customer order rather than from stock. ATO means assemble-to-order: standard modules are assembled into a customer-selected combination. One product family can support more than one of these patterns, but the model should identify when a configuration remains within standard rules and when it becomes an engineering case.

    Separate configuration, pricing and quoting logic

    Configuration determines whether and how a product can be built. Pricing determines its commercial value. Quoting determines how the result is presented, approved and communicated. These concerns interact but should not be confused.

    For example, a pump configuration rule may require a mechanical seal for a particular fluid. The pricing logic then adds the seal cost and applicable margin. The quote may display the seal as part of the selected package or as a technical inclusion. Combining all three concerns in one large rule makes changes risky.

    Concern Question answered Example
    Configuration Is this product definition valid? Can this impeller be used with this casing?
    Engineering What size or technical result is required? What motor rating meets the duty point?
    Costing What does the configuration cost to produce? What is the material and labor cost?
    Pricing What should the customer be charged? What price, discount and surcharge apply?
    Quoting How should the offer be presented and approved? Which descriptions, terms and documents appear?

    This separation makes it easier to change a price list without rewriting engineering rules, or to revise a component relationship without altering quote templates.

    Design rules for maintainability

    Use modular rule groups

    Organize rules by product module, function or decision type. Examples include motor compatibility, pressure rating, material selection, electrical requirements and documentation. Modular rules are easier to test than a single collection of nested conditions covering the whole product.

    Prefer declarative rules where practical

    A declarative rule states what must be true, such as a 480-volt motor requires a compatible control panel. This is generally easier for product experts to review than deeply embedded procedural code. Custom code may still be appropriate for complex calculations, external lookups or specialized engineering algorithms, but it should have an owner, test cases and version control.

    Use controlled vocabularies

    Materials, voltage classes, pressure ratings, regions, certifications and component types should use governed values. Controlled vocabularies reduce duplicate values and make integrations more reliable. They also help distinguish a commercial label from an engineering identifier.

    Make defaults explainable

    Defaults can reduce configuration time, but an incorrect default can create a hidden engineering or commercial error. Document why a default exists and whether the user may override it. For example, a standard motor may be preselected based on a typical duty, but the model should require confirmation when the calculated load exceeds the standard assumption.

    Do not encode every exception as a normal option

    Some requests are genuine ETO cases. If the model turns every historical exception into a selectable option, the product model becomes difficult to understand and test. Define an escalation path for nonstandard requirements instead of allowing invalid combinations through informal overrides.

    Build the model from authoritative product data

    A product model needs reliable source data. Typical sources include engineering specifications, product catalogs, drawings, bills of material, CAD parameters, price lists, costing sheets, ERP item masters and product lifecycle management (PLM) records.

    PLM manages product definitions, revisions and engineering lifecycle information. Product data management (PDM) commonly focuses on controlled engineering files and relationships. Enterprise resource planning (ERP) manages business transactions such as items, inventory, purchasing, production and orders. Product information management (PIM) manages product content for channels and catalogs. These systems are related but are not interchangeable sources for every model element.

    Before importing data, identify the system of record for each field. An ERP may own sellable item numbers and costs, while PLM owns engineering revisions and CAD relationships. A CPQ model may need synchronized copies of both, with explicit effective dates and revision behavior.

    Data Possible system of record CPQ use
    Engineering revision PLM or PDM Validate revision-specific options and outputs
    Sellable item and inventory status ERP Map selected components and check availability rules
    CAD family and parameters CAD or PLM Drive geometry or generate drawings where supported
    Channel description and images PIM Present product information to users
    Cost and price conditions ERP, pricing service or CPQ Calculate cost, price and margin

    Connect the model to BOM, CAD and manufacturing outputs

    Configurable BOMs

    A configurable BOM is a bill of materials whose components or quantities depend on the selected configuration. The output may be a structured BOM for review, an ERP order structure, a manufacturing BOM (MBOM) or an engineering BOM (EBOM).

    An EBOM represents the product from an engineering design perspective. An MBOM represents how the product is built, including manufacturing assemblies, consumables or process-specific items. They may not have the same structure. A CPQ system should not automatically treat a sales configuration output as a complete production BOM unless the mapping and approval process support that use.

    For example, an air-handling unit may have one commercial heating option, an engineering assembly containing a coil and control valve, and an MBOM containing installation hardware and production operations. The product model should identify which output is being generated and which system is responsible for final validation.

    CAD and engineering automation

    Some manufacturing CPQ platforms connect configuration values to parametric CAD, drawing templates or engineering calculation tools. A selected tank diameter might drive a CAD parameter, while a calculated nozzle position might be passed to a design automation service.

    CAD automation should be treated as a separate capability from basic CPQ. A system may support product rules and quoting without generating geometry. If CAD output is required, verify parameter mapping, revision control, regeneration behavior, drawing approvals and failure handling. More information is available in the guide to CAD and engineering automation in CPQ.

    ERP and order handoff

    ERP integration may transfer customer information, configured items, prices, BOMs, delivery information or order lines. The CPQ model must define which identifiers and revisions are sent, how errors are handled and whether ERP validates the result again.

    CPQ should not be treated as a replacement for ERP, PLM, CAD or manufacturing execution system (MES) functionality. It is an orchestration and decision layer that may exchange data with these systems. The exact boundary depends on the platform and implementation.

    Rules-based, constraint-based and guided configuration

    These approaches overlap but are not identical.

    • Rules-based configuration uses explicit conditions such as if-then relationships, requirements, exclusions and calculations.
    • Constraint-based configuration describes valid combinations through constraints that a solver or rules engine evaluates, often across many variables.
    • Guided selling asks business or application questions and recommends suitable products or options. It may guide a user without representing the full engineering constraint system.

    A guided selling flow might ask for required flow and pressure, then recommend a pump family. A constraint-based model may validate the resulting pump, motor, seal and materials across many interacting values. Guided selling can be a useful front end, but it does not by itself guarantee manufacturing validity.

    Modeling a pump example

    Consider a centrifugal pump sold for industrial water service. The model might contain the following inputs:

    • required flow and head;
    • fluid type, temperature and density;
    • casing and impeller material;
    • seal arrangement;
    • motor power, voltage and frequency;
    • connection size and pressure class;
    • baseplate and coupling requirements;
    • area classification or certification requirement.

    The model could apply rules such as:

    • the selected impeller must meet the duty point within the approved operating range;
    • fluid temperature above a defined limit requires a suitable seal and gasket package;
    • the motor must meet the calculated power requirement with the required service factor;
    • the connection size must be compatible with the casing;
    • an area classification requires an approved motor and electrical package;
    • material and certification selections may trigger additional documentation and lead-time conditions.

    The outputs might include a configuration summary, a price, a quote description, a component list, an engineering review flag and parameters for a pump datasheet. If the product falls outside the standard hydraulic range, the model should route it to application engineering rather than silently producing a standard quote.

    Validation, testing and governance

    Testing should cover more than individual rules. A model can pass isolated tests and still fail when several options interact. Create test cases from real product knowledge, historical quote errors, boundary conditions and known exceptions.

    Test type Purpose Example
    Positive test Confirms a valid configuration is accepted Standard pump with approved motor and seal
    Negative test Confirms an invalid configuration is rejected Pressure class below the required operating pressure
    Boundary test Checks limits and unit handling Maximum allowable temperature or flow
    Interaction test Checks combined rules High temperature plus hazardous-area motor plus special material
    Regression test Ensures a change does not break existing behavior New motor option does not alter existing BOM mappings
    Output test Confirms downstream data is correct Configured components map to the correct ERP identifiers

    Assign ownership for rules, calculations, prices, product descriptions, integrations and approvals. A product manager may own commercial options, engineering may own technical constraints, manufacturing may own MBOM mappings and finance may govern pricing policy. Shared governance is necessary because no single department owns the entire product model.

    Use versioning and effective dates. A quote created under one product revision should remain traceable even after a new motor, material or price is introduced. Releases should include impact analysis, test evidence and a rollback or correction procedure.

    Common product-modeling mistakes

    • Starting with the user interface: screens are designed before the product logic and data ownership are understood.
    • Using free text for structured engineering data: values cannot be validated or integrated reliably.
    • Mixing price and validity rules: discounts or surcharges accidentally make invalid products appear acceptable.
    • Copying spreadsheets without verification: hidden assumptions, obsolete formulas and manual overrides become embedded in the model.
    • Modeling only the happy path: edge cases, regional requirements and engineering review conditions are ignored.
    • Ignoring revisions: old quotes and new product definitions cannot be distinguished.
    • Assuming the CPQ BOM is production-ready: EBOM, MBOM and sales structures may require different mappings.
    • Allowing uncontrolled overrides: users bypass rules without recording who approved the exception.
    • Building one giant model: unrelated product families become difficult to test and govern.

    Implementation sequence

    1. Select a representative product family. Choose a product with meaningful configuration complexity and measurable business value.
    2. Map the current process. Document how sales, application engineering, costing, design and production handle a quote today.
    3. Inventory product data. Identify options, attributes, rules, formulas, components, revisions, prices and documents.
    4. Define ownership. Assign responsibility for technical, commercial and downstream data.
    5. Design the product hierarchy. Separate modules, standard options, calculated values and exceptions.
    6. Implement core validity rules first. Prevent unsafe or impossible configurations before adding advanced presentation features.
    7. Add calculations and outputs. Introduce sizing, pricing, quote content, BOM mappings and CAD or engineering interfaces as required.
    8. Test with real scenarios. Include valid, invalid, boundary and historical cases.
    9. Pilot with users and engineering. Confirm that questions are understandable and that outputs are useful downstream.
    10. Release under governance. Version the model, document changes and monitor exceptions after deployment.

    The detailed planning, migration, testing and governance topics are covered in the CPQ implementation guide.

    How to measure product-model quality

    Useful measures should reflect manufacturing outcomes rather than only interface activity. Possible measures include quote cycle time, percentage of configurations requiring rework, engineering review rate, invalid configuration rate, BOM correction rate, margin variance, quote-to-order conversion and the time required to implement a product change.

    Interpret these measures carefully. A lower engineering review rate may mean the model handles standard products better, or it may mean users are bypassing review. A faster quote may still be poor if the price or BOM is inaccurate. Pair speed measures with quality, margin and downstream correction measures.

    When a CPQ product model should stop

    A product model should represent repeatable, governable product logic. It should not attempt to automate every engineering decision or replace professional approval for novel designs. Establish clear boundaries for standard configuration, configurable engineering and full ETO work.

    For standard CTO products, the model may generate a validated BOM and pass parameters to ERP or CAD. For ETO products, it may capture requirements, calculate preliminary values, estimate price and create an engineering work request without claiming that the final design is complete. This distinction protects both the customer and the manufacturer.

    Semantic map

    The article connects the following manufacturing CPQ entities and relationships:

    • CPQ product model → represents → configurable product structure
    • Product options → define → customer-selectable choices
    • Configuration rules → prevent → invalid combinations
    • Engineering calculations → derive → technical product values
    • Configured product → produces → quote data
    • Configured product → can generate → configurable BOM
    • EBOM → represents → engineering product structure
    • MBOM → represents → manufacturing assembly structure
    • CAD automation → uses → configuration parameters
    • CPQ → exchanges data with → ERP
    • CPQ → may exchange revisions with → PLM or PDM
    • Pricing logic → calculates → customer price and margin
    • Manufacturing constraints → limit → valid product configurations
    • CTO workflow → uses → predefined product options
    • ETO workflow → escalates → nonstandard engineering requirements

    Frequently asked questions

    What is a CPQ product model?

    A CPQ product model is the structured definition of a configurable product, including its hierarchy, options, attributes, rules, calculations, prices and downstream outputs.

    How is a manufacturing CPQ model different from a sales CPQ catalog?

    A manufacturing model may validate engineering constraints, calculate technical values and produce BOM, CAD or ERP data. A sales catalog usually focuses on selectable products, pricing and quote presentation.

    What should be modeled first?

    Start with the product structure, critical technical inputs and rules that distinguish valid from invalid configurations. Add pricing, documents and advanced outputs after the core product logic is understood.

    Should every component appear as a customer-facing option?

    No. Internal components should normally be derived from higher-level selections. Exposing every component increases user effort and creates more opportunities for invalid combinations.

    What is the difference between an option and an attribute?

    An option is usually a discrete choice, such as stainless steel or painted steel. An attribute is a value, such as length, flow, temperature or voltage.

    How should engineering rules be represented?

    Use explicit, modular rules with defined inputs, outputs, units, ownership and test cases. Declarative rules are often easier to maintain, while custom code may be needed for specialized calculations.

    Can a CPQ product model calculate equipment size?

    Some CPQ platforms support engineering calculations or connect to external calculation services. The capability must be verified for the required formulas, units, ranges, approvals and auditability.

    Does every CPQ system generate a BOM?

    No. BOM generation varies by platform and implementation. Confirm whether the system supports configurable BOMs and whether the output is a sales structure, EBOM, MBOM or ERP order structure.

    Can a CPQ model generate CAD drawings?

    Only when the platform or its integrations support CAD or design automation. Verify parameter mapping, geometry generation, revision control, drawing approval and failure handling.

    What is the difference between EBOM and MBOM?

    An EBOM describes the product from an engineering perspective. An MBOM describes how it is manufactured and may include production-specific assemblies, consumables or operations.

    How does pricing relate to configuration rules?

    Configuration rules determine whether a product is valid. Pricing logic calculates cost, price, discounts and surcharges for a valid configuration. Keeping these concerns separate improves maintainability.

    How should ETO requirements be handled?

    The model should capture requirements, identify what is outside the standard envelope and route the case to engineering. It should not present an unapproved design as a standard configuration.

    Which systems provide data to a product model?

    Possible sources include PLM or PDM for engineering definitions, ERP for items and costs, CAD for design parameters, PIM for channel content and pricing services for commercial conditions.

    Who should own the product model?

    Ownership is usually shared. Product management may own commercial structure, engineering technical rules, manufacturing BOM mappings and finance pricing policies. A governance process coordinates these owners.

    How do you test a CPQ product model?

    Test valid and invalid configurations, boundary values, interacting rules, calculations, revisions, pricing and downstream outputs. Use regression tests whenever a rule or product definition changes.

    How often should a product model be updated?

    Update it whenever product options, engineering rules, component revisions, prices, regulations or downstream mappings change. Releases should be versioned and tested rather than changed informally.

    What is the biggest product-modeling mistake?

    A common mistake is treating the model as a sales questionnaire instead of a controlled representation of product and manufacturing logic. This creates quotes that look complete but require engineering correction.

    Can one CPQ model support CTO and ETO?

    Yes, but the model must distinguish standard configurable paths from nonstandard engineering work. CTO may produce validated outputs directly, while ETO may generate an engineering request and preliminary commercial result.

    How can manufacturers keep a product model maintainable?

    Use modular rules, controlled data, clear ownership, documented calculations, versioning, automated regression tests and a defined process for exceptions and product changes.

  • How Engineering Changes Propagate into CPQ Models

    Engineering changes propagate into a manufacturing CPQ model through a controlled chain of product data, configuration rules, calculations, bills of materials, pricing logic, CAD automation and enterprise-system integrations. A change to a motor, material, dimension, pressure rating or product option can affect much more than the visible selection screen. It may change valid combinations, engineering calculations, component quantities, labor, cost, selling price, drawings and the order data sent to production.

    The practical objective is not simply to copy an engineering revision into CPQ. It is to determine which parts of the product model are affected, update them under controlled ownership, test the resulting configurations and preserve the validity of existing quotes and orders. This is one of the central differences between manufacturing CPQ and generic sales quoting software.

    This guide explains how engineering changes move through a CPQ architecture, how to identify dependencies, and how manufacturers can maintain product models without creating configuration errors or stale commercial data. For a broader introduction, see the guide to manufacturing CPQ and the detailed overview of product configuration and rules engines.

    What does it mean for an engineering change to propagate into CPQ?

    An engineering change has propagated into CPQ when the relevant commercial and operational representations of a product have been updated consistently. These representations can include selectable options, constraints, formulas, configurable bills of materials, costs, prices, technical documents, CAD outputs and integration mappings.

    For example, an engineering team may replace a 15 kW motor with a new motor family. The CPQ impact could include:

    • removing the discontinued motor from new configurations;
    • adding a new motor option with different voltage, frame size and lead time values;
    • changing compatibility rules for the pump, coupling and baseplate;
    • updating power, flow, torque or efficiency calculations;
    • changing the configured BOM and purchased component identifiers;
    • recalculating material cost, labor and selling price;
    • updating CAD parameters and drawing templates;
    • preserving the original motor on quotes and orders created before the effective date.

    Propagation therefore involves both data and logic. A product model contains the structure of the product, while rules describe what is allowed, required, recommended or calculated. A change is complete only when the model produces correct results for the intended product versions and effective dates.

    The product model is the central change-propagation layer

    A CPQ product model is a structured representation of a configurable product. It normally contains product families, features, options, attributes, dependencies, constraints, formulas, component relationships and commercial values. In manufacturing, the model may also contain engineering parameters such as dimensions, loads, capacities, materials, ratings and operating conditions.

    The model connects the customer-facing configuration experience with downstream outputs. It is not necessarily the master record for every type of data. Product lifecycle management (PLM) or product data management (PDM) may own engineering revisions, enterprise resource planning (ERP) may own inventory and manufacturing item numbers, and a computer-aided design (CAD) system may own geometry. CPQ must either reference these systems or maintain synchronized representations.

    Model element Typical engineering change Possible CPQ impact
    Option A valve, motor or material is replaced New selection, retirement date and alternative logic
    Attribute Pressure rating or length range changes New limits, units, validation and pricing bands
    Constraint A component becomes incompatible with a frame Invalid combination blocked or automatically corrected
    Formula A sizing or capacity calculation is revised New engineering result, price and component selection
    BOM relationship A bracket or fastener is redesigned Updated configurable BOM, quantity or substitute
    CAD mapping Hole spacing or enclosure dimensions change Changed geometry, drawing or manufacturing output
    Commercial value Supplier cost or standard price changes Updated cost, margin, discount and quote value

    How an engineering change moves through the CPQ architecture

    1. Change identification and impact analysis

    The process starts with an engineering change notice, engineering change order or another controlled change record. The record should identify the affected part, assembly, product family, revision, reason, effective date and responsible approvers.

    Before changing the CPQ model, the organization should perform impact analysis. This means tracing where the affected item or attribute is used. A part number may appear in a product option, a compatibility rule, a BOM mapping, a price table, a CAD template, an ERP integration and an existing quote workflow.

    Impact analysis is difficult when models contain duplicated logic or undocumented formulas. A maintainable model makes dependencies visible through identifiers, ownership metadata, version history and automated usage reports.

    2. Product structure and option updates

    The next step is updating the product structure. An engineering revision might introduce a new option, retire an option, split one option into several variants or change a standard assembly into a configurable subassembly.

    Retirement requires particular care. Removing an option from the user interface may be correct for new quotes but incorrect for historical quotes, service replacements or open orders. A CPQ system should distinguish between available for new configuration, valid for existing transactions and completely obsolete.

    Where possible, use stable internal identifiers rather than relying only on descriptions. A description such as stainless steel pump housing can change without representing a new item, while a new ERP item number may represent a genuine replacement. The model needs a clear relationship between engineering revision, commercial option, inventory item and effective date.

    3. Rules and constraints

    Rules determine how selections interact. A rule may require a component, exclude an incompatible option, restrict a dimension, calculate a value or recommend a standard configuration. Constraint-based configuration focuses on maintaining valid relationships among variables, while guided selling generally leads users through a sequence of questions or recommendations. A manufacturing CPQ model may use both.

    Suppose a pump change increases the allowable operating temperature but requires a new seal material above a defined threshold. The model may need rules such as:

    • if temperature exceeds 120 degrees Celsius, require the high-temperature seal;
    • if the high-temperature seal is selected, exclude the standard elastomer;
    • if the selected fluid is corrosive, restrict available housing materials;
    • if the pump speed exceeds a limit, require a compatible motor and coupling;
    • if a particular motor frame is selected, change the baseplate and guard.

    Rules should be expressed in a form that product and engineering specialists can review. A technically correct rule that no one can maintain becomes a long-term risk. See the product configuration guide for more on features, dependencies, constraints and validation.

    4. Engineering calculations and derived values

    Many industrial products require calculations rather than simple option selection. Examples include heat exchanger sizing, pump duty selection, structural load checks, cable sizing, airflow calculations and vehicle axle-load analysis.

    An engineering change can alter a formula, an input range, a safety factor or the lookup table used by the calculation. The CPQ result may then affect the selected component, manufacturing operation, price and expected performance. Calculation logic should have named inputs, units, acceptable ranges, test cases and a clear owner.

    Manufacturers should not assume that a CPQ platform provides certified engineering calculations merely because it supports formulas. Critical calculations may need validation by engineering, comparison against an approved calculation tool and formal release control. More information on CAD and engineering automation is available in the CAD and engineering automation guide.

    5. BOM generation and manufacturing outputs

    A configured bill of materials (BOM) lists the components required for a specific configuration. An engineering BOM (EBOM) describes the product from a design perspective. A manufacturing BOM (MBOM) describes how the product is assembled or produced. These are related but not interchangeable.

    CPQ may generate an EBOM-like structure, an MBOM, a sales BOM, or a mapping that allows another system to create the final manufacturing structure. A configurable BOM typically contains rules that include, exclude or quantity-adjust components based on selected options and calculated values.

    For example, selecting a longer conveyor may add frame sections, supports, guards, fasteners and an additional drive component. A change to the frame profile could affect all of those relationships. The CPQ output must use approved item numbers, quantities, units of measure and revision references. See BOM, pricing and quote automation for the relationship between configuration and downstream commercial outputs.

    6. Costing and pricing

    Engineering changes often have commercial consequences. A new material may increase purchased cost, a redesigned assembly may reduce labor, or a component substitution may change lead time and freight assumptions.

    Costing estimates the internal economic impact of a configuration. Pricing determines what the customer is charged. These should be treated as distinct layers. A price rule may use cost, margin, list price, customer agreement, quantity or market segment, but it should not hide engineering logic that belongs in the product model.

    When a component revision changes cost, the organization must decide whether the new value applies immediately, from a future effective date, or only to new quotes. Existing approved quotes may need price protection. A CPQ system that recalculates historical transactions using current values can create audit and commercial disputes.

    7. CAD automation, drawings and documentation

    Some manufacturing CPQ implementations connect configuration results to CAD automation. A selected length, mounting arrangement or enclosure size may drive a parametric CAD model, 2D drawing, 3D visualization or technical document.

    Engineering changes must therefore update both the CPQ-to-CAD mapping and the CAD template or geometry rules. A new motor may require revised mounting holes, a different guard, or a changed baseplate. Updating only the option label leaves the generated drawing incorrect.

    CAD automation is not a universal CPQ capability. Where it exists, it requires controlled templates, parameter mappings, version compatibility and testing of geometric edge cases. Where it does not exist, CPQ may pass configuration data to engineering for manual design work. The CAD engineering guide explains these alternatives.

    Example: propagating a change in an industrial pump model

    Consider a centrifugal pump configured by flow rate, head, fluid, temperature, housing material, impeller diameter, seal type, motor power and voltage.

    Engineering introduces a revised impeller family. The new impeller supports a different operating range and requires a revised wear-ring clearance. The change propagation sequence could be:

    1. PLM records the revised impeller and approved effectivity date.
    2. Product management updates the CPQ option and the permitted flow and head ranges.
    3. Engineering updates the selection formula that maps duty conditions to impeller diameter.
    4. The rules engine requires the revised wear ring for the new impeller family.
    5. The configurable BOM replaces the old impeller and adds the new wear-ring item.
    6. The costing model uses the new component costs and any changed labor standard.
    7. The pricing model applies the approved commercial price or margin policy.
    8. The CAD mapping updates impeller and casing parameters if drawings are automated.
    9. The ERP integration sends the correct item and revision information for new orders.
    10. Regression tests confirm that existing standard pump configurations still produce valid results.

    The change should not automatically rewrite an already approved customer order. Historical transactions normally require their original configuration, revision and commercial values, subject to the manufacturer's change-control policy.

    Versioning, effectivity and historical accuracy

    Versioning determines which model, rule set, price and component revision applies at a particular time. Effectivity can be based on date, serial number, plant, market, customer contract or production phase.

    Useful distinctions include:

    • Model revision: a released version of the CPQ product logic.
    • Option effectivity: when an option becomes available or unavailable.
    • Part revision: an engineering revision of a component or assembly.
    • Commercial effectivity: when a cost or price becomes active.
    • Transaction snapshot: the configuration, rules and values used for a quote or order.

    A robust implementation stores enough information to reproduce the result of an historical quote. This may include selected options, calculated values, component revisions, prices, rule-set version, generated documents and integration messages.

    Ownership and governance of CPQ model changes

    Engineering should own technical definitions and constraints, but engineering is not always the only model owner. Product management may own marketable options, sales operations may own discount policies, manufacturing may own routing implications, and IT may own integrations and deployment controls.

    A practical governance model assigns ownership for each type of change:

    Change area Likely owner Required review
    Technical compatibility Product or application engineering Manufacturing and quality
    Engineering formula Engineering Technical authority and test owner
    Configurable BOM Manufacturing engineering ERP or production control
    Cost Cost accounting or procurement Finance and product management
    Selling price Commercial or product management Finance and sales operations
    CAD mapping Design automation or engineering IT CAD administration
    Integration mapping Enterprise IT ERP, PLM or CRM owners

    Governance should define who can propose, approve, test, release and roll back a model change. It should also define how emergency corrections are handled and how changes are communicated to sales engineers, dealers and customer service teams.

    Testing engineering changes in CPQ

    Testing should cover more than whether the new option appears on the screen. A useful test strategy includes:

    • Unit tests: verify individual rules, formulas, mappings and validation messages.
    • Combination tests: confirm valid and invalid combinations across important product families.
    • Boundary tests: test minimum, maximum and just-outside-limit values.
    • Regression tests: confirm that unaffected configurations still produce the same intended results.
    • BOM tests: compare component numbers, revisions, quantities and units of measure.
    • Commercial tests: verify cost, price, discount and margin outcomes.
    • CAD tests: inspect generated geometry, drawings and dimension changes where applicable.
    • Integration tests: verify messages to ERP, CRM, PLM, PDM or manufacturing systems.
    • Historical tests: confirm that prior quotes and orders remain reproducible.

    Test cases should be based on real product configurations, including unusual but valid combinations. A model can pass simple tests while failing when several options interact, such as a high-temperature material combined with a large frame, a special voltage and a nonstandard mounting arrangement.

    Common failure modes

    Changing labels without changing logic

    Renaming an option does not update its underlying item number, compatibility rule or CAD mapping. Every visible change should be traced to its data and logic dependencies.

    Duplicating engineering logic in several systems

    If a sizing formula exists independently in CPQ, a spreadsheet and an engineering application, the systems can disagree. Decide which system is authoritative and define how results are exchanged.

    Deleting obsolete options

    Deletion can make historical quotes impossible to reproduce. Use status and effectivity controls where the platform supports them.

    Ignoring manufacturing consequences

    An engineering change may appear technically valid but require new tooling, routing, inspection criteria or supplier data. Manufacturing engineering must review changes that affect the MBOM or production process.

    Releasing rules without traceability

    Without version history, approval records and deployment identifiers, it becomes difficult to determine why a quote or BOM was generated.

    Implementation practices for maintainable CPQ models

    1. Define the system of record. Document whether PLM, ERP, PDM, CPQ or another system owns each data category.
    2. Use a dependency inventory. Record where options, attributes, parts, formulas and prices are referenced.
    3. Separate model layers. Keep product structure, constraints, engineering calculations, costing and pricing logically distinct.
    4. Use meaningful identifiers. Link commercial options to approved engineering and ERP identifiers.
    5. Control units and precision. Explicitly define units for dimensions, pressure, temperature, torque, currency and quantities.
    6. Automate regression testing. Run representative configurations whenever rules or master data change.
    7. Design for effectivity. Support future releases and historical transaction snapshots.
    8. Document ownership. Assign responsibility for rules, formulas, BOMs, prices, CAD mappings and integrations.
    9. Monitor outcomes. Review configuration errors, manual overrides, engineering escalations and order corrections.
    10. Release in controlled stages. Use development, test and production environments with formal approval gates.

    These practices belong within a wider CPQ implementation program covering data migration, architecture, testing, deployment and governance. See the CPQ implementation guide for related planning topics.

    Where engineering change propagation fits in the enterprise architecture

    CPQ is usually one participant in a larger product and order data flow. Product lifecycle management (PLM) may manage engineering structures and revisions. Product data management (PDM) may manage CAD files and design documents. ERP may manage item masters, inventory, purchasing, manufacturing and financial transactions. Customer relationship management (CRM) may provide the opportunity or account context. A manufacturing execution system (MES) may receive production instructions or execution data.

    These systems are not interchangeable. A CPQ integration should specify which data is mastered where, which system performs each calculation, how identifiers are mapped and how revisions are synchronized. Some implementations use APIs, event messages, scheduled data exchange or middleware. The technology choice matters less than clear ownership and reliable error handling. See CPQ integration architecture for a system-by-system view.

    Key benefits and limitations

    Well-managed propagation provides several manufacturing benefits:

    • sales engineers configure from current approved product logic;
    • invalid combinations are blocked before quotation or order entry;
    • engineering receives more complete and consistent requirements;
    • configured BOMs and drawings can be generated with less manual rework;
    • cost and price changes can be released with the relevant product revision;
    • historical quotes and orders remain auditable;
    • product changes can be tested before reaching customers or production.

    There are also limitations. CPQ does not automatically become the authoritative engineering system. It cannot compensate for ambiguous product definitions, missing item-master data or uncontrolled spreadsheets. Complex ETO, or engineer-to-order, products may still require engineering review after configuration. CAD automation and manufacturing BOM generation may require specialized tools or custom development. Integration latency can also mean that a newly released component is not immediately available in every system.

    Conclusion

    Engineering changes propagate into CPQ through a chain of related model elements: product structure, options, constraints, calculations, BOM relationships, costs, prices, CAD mappings and integrations. The change must be assessed for dependencies, released with the correct effectivity, tested against representative configurations and governed by clearly assigned owners.

    The most reliable manufacturers treat CPQ as a controlled operational representation of the product, not as a collection of sales screens. When CPQ, engineering, PLM, ERP, CAD and manufacturing teams agree on data ownership and revision behavior, product changes can reach sales and production without silently creating invalid configurations or inaccurate quotes.

    Semantic map

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

    • Engineering change → updates → product model
    • Product model → contains → options and attributes
    • Configuration rules → prevent → invalid combinations
    • Engineering calculations → determine → derived product values
    • Configured product → generates → configurable BOM
    • Engineering BOM → represents → design structure
    • Manufacturing BOM → represents → production structure
    • CPQ → calculates → cost and selling price
    • CAD automation → generates → product-specific drawings
    • CPQ → exchanges data with → ERP
    • PLM → manages → engineering revisions
    • PDM → manages → CAD files and design documents
    • Effectivity rules → control → when revisions apply
    • Regression testing → verifies → model behavior after changes
    • Transaction snapshot → preserves → historical quote configuration
    • Engineering governance → assigns → change ownership

    Frequently asked questions

    1. What is engineering change propagation in CPQ?

    It is the controlled process of updating CPQ product models, rules, calculations, BOMs, prices, CAD outputs and integrations after an engineering change.

    2. Why do engineering changes affect CPQ pricing?

    A changed material, component, labor requirement or supplier item can change cost. Pricing logic may then apply a new margin, list price or customer-specific commercial rule.

    3. Does every engineering change require a CPQ model change?

    No. A change may be internal to engineering or manufacturing. However, it requires CPQ review if it affects selectable options, constraints, calculations, BOMs, prices, documents or downstream integration data.

    4. How should obsolete components be handled in CPQ?

    They should normally be retired using status and effectivity controls rather than deleted, so historical quotes, orders and service configurations remain reproducible.

    5. What is the difference between a CPQ rule and an engineering calculation?

    A rule controls relationships or validity, such as requiring a specific seal. A calculation derives a value, such as impeller diameter or cable size, from engineering inputs.

    6. Can CPQ replace PLM for engineering change management?

    Usually not. PLM commonly manages engineering revisions and change processes, while CPQ uses approved product information to configure and quote products.

    7. How are BOM changes propagated into CPQ?

    The affected component relationships, quantities, revisions and inclusion conditions are updated in the configurable BOM or synchronized from an authoritative product system.

    8. What is the difference between EBOM and MBOM in this context?

    An EBOM describes the product from a design perspective. An MBOM describes how it is assembled or produced. CPQ may generate or map to either, depending on the implementation.

    9. How does effectivity protect historical quotes?

    Effectivity specifies when a revision, option, cost or price applies. Historical transactions can retain the model and values that were valid when the quote or order was created.

    10. What happens when a product change affects CAD automation?

    The CPQ-to-CAD parameter mapping, CAD template, geometry logic or drawing output may need to change and must be tested with representative configurations.

    11. Should engineering or product management own CPQ rules?

    Ownership depends on the rule. Engineering should generally own technical constraints and calculations, while product management may own marketable options and commercial availability. Shared governance is important.

    12. How can manufacturers find all CPQ dependencies for a part?

    Use model metadata, usage reports, identifier searches, integration mappings and a documented dependency inventory covering rules, BOMs, prices, CAD and enterprise systems.

    13. What tests are most important after an engineering change?

    Test valid and invalid combinations, boundary values, calculations, BOM content, prices, CAD outputs, integrations and historical transaction behavior.

    14. Can a CPQ model support both CTO and ETO products?

    Configure-to-order (CTO) products can often be represented with predefined options and rules. Engineer-to-order (ETO) products may require CPQ to capture requirements and initiate additional engineering work rather than fully determine the design.

    15. How does CPQ handle a component replacement?

    The model can retire the old option for new configurations, introduce the replacement, update compatibility and BOM mappings, revise costs and preserve the old component for historical or service transactions.

    16. What is the role of ERP in engineering change propagation?

    ERP may provide item masters, costs, inventory, purchasing and manufacturing data. CPQ must map the configured result to the correct ERP items and revisions without assuming ERP owns all engineering logic.

    17. Why should pricing and configuration logic be separated?

    Configuration logic determines what can be built and how it is engineered. Pricing logic determines what it costs or sells for. Separating them makes both areas easier to govern, test and change.

    18. What are common signs that CPQ change propagation is failing?

    Warning signs include frequent manual overrides, invalid orders, mismatched BOMs, stale prices, drawings that do not match configurations, repeated engineering clarification and unexplained historical quote differences.

  • Manufacturing CPQ Use Cases: 25 Real-World Scenarios

    Manufacturing CPQ, meaning Configure, Price, Quote software for complex products, is used to turn customer requirements into valid product configurations, accurate prices, engineering data and production-ready outputs. The most valuable use cases extend beyond generating a sales proposal. A manufacturing CPQ system may connect product rules, engineering calculations, configurable bills of material, computer-aided design outputs, costing, approvals and enterprise systems.

    The 25 scenarios below show where manufacturing CPQ fits in real industrial workflows. They cover configurable machinery, pumps, valves, HVAC equipment, electrical assemblies, vehicles, medical equipment and other products that vary by dimensions, materials, components, performance requirements or manufacturing method.

    Capabilities differ significantly between platforms. Some systems focus on guided selling and pricing. Others support constraint-based configuration, engineering calculations, BOM generation, CAD automation or integration with product lifecycle management systems. These use cases should therefore be treated as functional patterns to evaluate, not as a claim that every CPQ product provides every capability.

    What manufacturing CPQ is used for

    Manufacturing CPQ is commonly used to control the path from customer requirements to an executable order. A product model defines options, dimensions, dependencies and constraints. Pricing logic calculates commercial values. Engineering logic can validate performance or select components. The resulting configuration may produce a quote, a configurable BOM, an engineering BOM, a manufacturing BOM, CAD files or an order payload for an enterprise resource planning system.

    This differs from generic sales CPQ, which may primarily manage products, discounts, subscriptions and proposal documents. Manufacturing CPQ must often answer additional questions: Is the selected motor compatible with the pump? Does the chosen enclosure meet the environmental rating? Which components are required for this voltage? Can the assembly be manufactured using the selected material and process? Does the configured product require engineering review?

    For a broader introduction, see the guide to manufacturing CPQ. Product models and configuration constraints are explained in the product configuration guide.

    25 manufacturing CPQ use cases

    1. Configure-to-order industrial machinery

    A manufacturer of conveyors, packaging machines or material-handling equipment can use CPQ to assemble a valid machine from modules and options. The model may include frame length, belt width, motor size, guarding, controls, sensors and discharge direction. Rules prevent incompatible combinations, such as selecting a motor that cannot handle the calculated load.

    The output can include a priced quote, a configured BOM and an order specification. This is a typical configure-to-order, or CTO, workflow: the product is assembled from predefined modules without designing every component from scratch.

    2. Pump selection and hydraulic sizing

    A pump manufacturer can capture flow rate, head, fluid type, temperature, viscosity and operating environment. Engineering calculations can help select an impeller, motor, seal, casing material and drive arrangement. The system can reject selections outside the operating envelope or route unusual requirements to an application engineer.

    Pricing may depend on pump size, materials, motor efficiency, coatings, accessories and testing requirements. The configuration can produce a product specification and a component structure for downstream systems.

    3. Valve configuration for process applications

    Valve configuration may involve valve type, nominal size, pressure class, body material, trim, actuator, end connection, seals and certification. Rules can link the selected process medium and temperature to suitable materials and seal types.

    CPQ can distinguish standard catalog configurations from cases requiring engineering review. It can also calculate the commercial effect of hazardous-area certification, special testing, surface treatment or documentation.

    4. HVAC equipment selection

    Heating, ventilation and air-conditioning equipment often requires selection based on airflow, capacity, ambient conditions, refrigerant, noise limits, filtration and installation constraints. A CPQ model can guide sales engineers through these inputs and identify suitable fans, coils, compressors, dampers and controls.

    Where supported, engineering calculations can validate thermal performance. The output may include a selection report, equipment schedule, price, BOM and technical submittal rather than only a commercial quote.

    5. Electrical control panel configuration

    Electrical equipment manufacturers can configure enclosures, breakers, contactors, relays, power supplies, drives, terminals and wiring accessories. Rules can enforce voltage compatibility, enclosure ratings, available space and short-circuit requirements.

    A validated configuration can generate a component list for procurement or assembly. Some implementations also automate schematic, panel layout or label outputs through CAD and electrical design tools, although this depends on the selected architecture.

    6. Engineered machine frames and dimensional products

    Manufacturers of tanks, platforms, machine frames and skids often sell products whose dimensions vary for every order. CPQ can capture length, width, height, load, access requirements and material choice, then apply dimensional rules and minimum or maximum limits.

    When connected to parametric CAD, the system may pass approved dimensions into a design template and return a product-specific model or drawing. The CPQ system is not necessarily replacing CAD; it is controlling the approved inputs and automating repetitive design work.

    7. Configurable vehicles and specialty bodies

    Specialty vehicle manufacturers can configure chassis, wheelbase, body length, storage modules, axles, suspension, power systems, doors, interiors and customer equipment. Dependencies may determine which options are available for a particular chassis or payload.

    CPQ can help maintain a consistent relationship between the sales description, commercial price, component structure and build specification. Complex or non-standard vehicle requests can be routed to engineering rather than accepted as invalid orders.

    8. Modular skids and packaged systems

    Manufacturers of process skids, compressed-air packages, pumping stations and packaged utility systems often combine standard modules with project-specific accessories. CPQ can manage the standard architecture while identifying where an engineer must define piping, instrumentation, supports or site interfaces.

    This supports a mixed CTO and engineer-to-order, or ETO, process. The standard modules are configured from known rules, while genuinely new engineering work is created as a controlled exception.

    9. Configurable BOM generation

    A configured bill of material, or BOM, lists the components required for a selected product. CPQ can use option selections and rules to include, exclude or substitute components. For example, selecting a stainless-steel pump casing may change fasteners, seals, machining operations and purchased parts.

    Manufacturers should distinguish an engineering BOM, or EBOM, from a manufacturing BOM, or MBOM. An EBOM represents the product from an engineering perspective. An MBOM represents how production plans to assemble or manufacture it. CPQ may generate one, both, or an intermediate structure that is transformed by ERP or PLM.

    10. Automated CAD and drawing creation

    In a CAD automation use case, CPQ passes validated dimensions, options and materials to a parametric design system. The design system can update a model, drawing or neutral file. This is useful for standard frames, enclosures, ductwork, guards, brackets and other products built from repeatable design templates.

    Automation is most reliable when templates, naming conventions, units, revision rules and error handling are mature. The CAD and engineering automation guide explains how these workflows fit together.

    11. Engineering calculations during configuration

    Some products require calculations before they can be quoted. Examples include motor sizing, pressure drop, heat transfer, structural loading, torque, electrical capacity and lifting capacity. A CPQ system may contain calculation logic or call an external engineering service.

    The calculation result can determine valid components, price adjustments, lead-time assumptions or whether an engineer must review the quote. Calculation governance is important because an uncontrolled formula can create both commercial and safety risks.

    12. Cost-based pricing for engineered products

    Manufacturers can use CPQ to calculate price from material cost, purchased components, labor, machine time, overhead, subcontracting, freight and margin rules. This is particularly useful when a product cannot be represented by one static price.

    Costing and pricing should remain conceptually separate. Costing estimates what the manufacturer spends. Pricing determines what the customer is charged. A pricing engine may apply customer terms, channel discounts, project adjustments, minimum margins or approval thresholds after cost is calculated.

    13. Quote generation for technical sales

    CPQ can assemble a quote from the selected configuration, commercial terms, delivery assumptions, exclusions, technical description and supporting documents. For an industrial machine, the proposal may include performance data, utilities, installation requirements and a line-item breakdown.

    Automated documents are only as reliable as their source data. Product descriptions, units, revision status and translated text need ownership and change control.

    14. Dealer and distributor configuration

    Manufacturers selling through dealers or distributors can expose a controlled configuration experience without exposing every internal engineering rule. The channel user may select application parameters and options while the manufacturer retains control over product validity, pricing boundaries and approval rules.

    Different channels may require different price books, currencies, discounts, territories and authorization levels. The system should also define whether a dealer can submit an unusual configuration or must request manufacturer review.

    15. Web or self-service configuration for standard products

    A manufacturer can provide online configuration for products with stable rules and clear application limits, such as standard enclosures, pumps, actuators or modular equipment. The customer may receive an indicative price, technical summary or request-for-quote package.

    Self-service is less suitable when requirements are ambiguous, site conditions are unknown or safety-critical engineering decisions cannot be automated. A useful design combines guided questions with escalation to a sales engineer.

    16. Guided selling for non-technical users

    Guided selling asks questions in business or application language rather than exposing the entire product catalog. For example, a customer may specify required lifting height, load and operating environment instead of selecting a motor and gearbox directly.

    Guided selling is not the same as a complete constraint solver. It may recommend suitable products, while a deeper configuration engine validates the final combination. Manufacturers should evaluate whether recommendations are explainable and whether users can see the assumptions behind them.

    17. Engineer-to-order intake and triage

    ETO products require new or substantially modified engineering for each order. CPQ can collect a structured requirements package before work reaches engineering. Inputs may include dimensions, duty cycle, materials, standards, site conditions, interfaces and required documentation.

    The system can classify the request as standard, configurable, configurable with review or fully engineered. This reduces incomplete handoffs and helps engineering estimate effort, risk and lead time.

    18. Make-to-order and assemble-to-order workflows

    Make-to-order, or MTO, products are manufactured after an order is received, while assemble-to-order, or ATO, products are assembled from stocked or planned modules. CPQ can identify the selected modules, communicate demand to ERP and create an order with the correct options.

    For ATO, the key requirement is usually a reliable modular product structure. For MTO, the process may require additional manufacturing instructions, procurement decisions or engineering review.

    19. ERP order creation

    An enterprise resource planning system, or ERP, manages business processes such as orders, inventory, purchasing, production and financial transactions. CPQ can send an approved configuration, customer data, price, delivery information and BOM-related data to ERP.

    Integration design must define the system of record for products, customers, prices, revisions, units and order status. Sending a PDF quote is not equivalent to creating a reliable executable order.

    20. PLM and PDM-controlled product data

    Product lifecycle management, or PLM, governs product definitions, revisions, workflows and lifecycle status. Product data management, or PDM, commonly manages design files and related engineering metadata. CPQ can consume released product rules and structures from these systems or publish approved configuration outcomes back to them.

    Manufacturers should clarify whether CPQ owns commercial option logic, whether PLM owns engineering structures and how revisions are synchronized. Without clear ownership, a product change can produce conflicting configuration results.

    21. CRM-to-engineering handoff

    Customer relationship management, or CRM, records customer, opportunity and activity information. A manufacturing CPQ application may run inside or alongside CRM, but CRM does not automatically provide the engineering logic required for complex products.

    A structured handoff can include the configuration ID, selected options, calculated values, assumptions, attachments, approval history and engineering questions. This is more useful than sending an unstructured email or manually rekeying a quote.

    22. Compliance, certification and documentation packages

    Industrial products may require certificates, inspection plans, test reports, declarations, manuals or customer-specific documentation. CPQ rules can associate these documents with materials, pressure classes, hazardous-area options, markets or regulatory requirements.

    The document system should distinguish automatically generated content from documents requiring technical approval. Compliance logic must be maintained as standards, markets and product designs change.

    23. Configuration-based lead-time estimation

    Lead time can depend on purchased components, manufacturing capacity, special materials, testing, engineering workload and external suppliers. CPQ can identify configuration attributes that affect delivery and pass the result to planning or ERP.

    This is an estimate, not a guarantee, unless it is connected to current capacity, inventory and supplier information. A static lead-time table may be useful for early quoting but should not be presented as real-time production availability.

    24. Quote approvals and commercial governance

    CPQ can route quotes for approval when margins fall below a threshold, unusual terms are requested, non-standard components are selected or engineering risk exceeds a defined level. Approval rules can consider product family, customer segment, sales channel, currency and contract terms.

    Approval workflows should avoid becoming a substitute for product governance. If users regularly request approval for the same valid combination, the product model or price rules may need improvement.

    25. Product and configuration analytics

    Configuration data can reveal which options are frequently selected, which combinations cause errors, where quotes are abandoned and which products generate engineering effort. Manufacturers can use this information to rationalize options, improve standard modules, revise pricing or identify candidates for automation.

    Analytics require consistent identifiers, versioned configurations and clear definitions of events such as quote creation, approval, order conversion and engineering release. Otherwise, dashboards may describe process noise rather than product behavior.

    How these use cases fit into the manufacturing architecture

    A typical manufacturing CPQ architecture contains several related layers:

    • Product model: products, variants, options, dimensions, materials, components and valid values.
    • Rules and constraints: dependencies, exclusions, required selections, formulas, limits and approval conditions.
    • Engineering logic: sizing calculations, performance checks, component selection and exception classification.
    • Commercial logic: costs, prices, discounts, currencies, margins, taxes and terms.
    • Output generation: quotes, specifications, BOMs, CAD parameters, drawings, submittals and order payloads.
    • Integration services: connections to CRM, ERP, PLM, PDM, CAD, product information management, or PIM, and manufacturing execution systems, or MES.

    These systems are not interchangeable. CRM manages customer and opportunity information. ERP manages transactional and operational business processes. PLM governs product lifecycle data. PDM manages engineering files and metadata. CAD creates design geometry and drawings. PIM manages product information for publication across channels. MES manages execution and tracking on the shop floor.

    For integration patterns and ownership questions, see the CPQ integration guide. For BOM, costing and quote outputs, see BOM, pricing and quoting in manufacturing CPQ.

    Rules-based configuration, constraint solving and guided selling

    Approach How it works Manufacturing example Typical limitation
    Rules-based configuration Explicit if-then rules include, exclude or require options. If the enclosure is outdoor-rated, require a suitable gasket and coating. Large rule sets can become difficult to maintain if poorly structured.
    Constraint-based configuration The system evaluates relationships, limits and compatibility conditions across many variables. Select a motor and gearbox that satisfy torque, speed, voltage and duty requirements. Requires accurate constraints and careful testing of edge cases.
    Guided selling Questions lead a user toward suitable products or configurations. Recommend a pump family from flow, head and fluid requirements. Guidance alone may not validate every engineering consequence.

    A mature implementation may use all three. Guided selling collects requirements, constraint logic validates feasibility and rules-based logic controls specific option dependencies.

    Benefits and limitations

    Potential benefits

    • Fewer invalid configurations reaching engineering or production.
    • More consistent pricing for products with variable materials, components and labor.
    • Shorter handoffs between sales, application engineering and manufacturing.
    • Reusable product knowledge instead of rules stored only in individual spreadsheets or employee expertise.
    • More complete order data for ERP, PLM, procurement and production.
    • Better visibility into option popularity, exceptions and recurring engineering work.

    Important limitations

    • CPQ does not correct inaccurate product data or undocumented engineering knowledge by itself.
    • Complex ETO work may still require engineering judgment and design review.
    • CAD automation depends on stable templates, APIs, naming standards and revision control.
    • BOM generation requires agreement about structure, effectivity, alternates and EBOM-to-MBOM ownership.
    • Real-time pricing and lead time require current source data and reliable integrations.
    • Rules become a maintenance burden if ownership, testing and release governance are missing.

    Implementation considerations for manufacturers

    Begin with a product family where configuration errors, engineering effort or quote delay are significant and measurable. Document the current workflow from customer requirement through quote, approval, engineering release, order entry and production. Identify where information is re-entered and which decisions depend on informal expertise.

    Define the product model before selecting an interface. List options, variables, dependencies, constraints, calculations, component effects, revision rules and exception paths. Decide which data belongs in CPQ and which remains authoritative in ERP, PLM, PDM, CAD or another system.

    Test more than common configurations. Include incompatible combinations, minimum and maximum dimensions, unit conversions, obsolete parts, regional variations, pricing thresholds, revision changes and incomplete requirements. Manufacturing acceptance testing should include sales engineering, product management, engineering, operations, finance and IT.

    Plan for ongoing governance. Assign owners for product rules, pricing, engineering formulas, document templates, integrations and release approvals. Measure configuration validity, quote cycle time, engineering touches, approval frequency, order corrections and the percentage of quotes that convert without manual rework.

    The manufacturing CPQ implementation guide covers requirements, data migration, testing, deployment, governance and maintenance. Manufacturing workflow patterns are described in the configure-to-order and engineer-to-order guide.

    How to prioritize CPQ use cases

    Priority question Why it matters
    Does the product have repeatable configuration logic? Repeatability makes automation more practical than fully bespoke engineering.
    Is the current error or delay measurable? A baseline helps justify scope and evaluate results.
    Are product data and rules available? CPQ implementation cannot reliably automate undocumented decisions.
    Which output has the highest operational value? A valid quote, BOM, CAD file or ERP order may require different capabilities.
    Who owns changes after launch? Product models require maintenance as designs, suppliers and regulations change.

    A practical first release might configure one product family, calculate price, produce a technical quote and create a structured handoff to engineering. BOM, CAD and ERP automation can then be added when the underlying product model and governance are stable.

    Semantic map

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

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraint logic validates engineering relationships.
    • Guided selling collects customer requirements.
    • Engineering calculations determine feasible selections.
    • A configured product generates a BOM.
    • An EBOM represents an engineering product structure.
    • An MBOM represents a manufacturing product structure.
    • CAD automation generates product-specific drawings.
    • CPQ calculates prices from costs and commercial rules.
    • CPQ generates technical quotes.
    • CPQ exchanges customer and opportunity data with CRM.
    • CPQ exchanges orders and operational data with ERP.
    • PLM governs released product definitions.
    • PDM manages engineering files and metadata.
    • CPQ supports CTO workflows.
    • ETO workflows require engineering review for non-standard designs.
    • Configuration analytics identifies recurring product choices and exceptions.

    Frequently asked questions

    What is a manufacturing CPQ use case?

    A manufacturing CPQ use case is a practical application in which configuration, pricing and quoting software supports an industrial product workflow. It may include product validation, engineering calculations, BOM generation, CAD automation or integration with ERP and PLM.

    How is manufacturing CPQ different from sales CPQ?

    Sales CPQ commonly focuses on products, prices, discounts and proposals. Manufacturing CPQ also handles technical options, dimensions, material compatibility, engineering constraints, BOMs, CAD outputs and production handoffs where those capabilities are supported.

    Can CPQ generate a bill of material?

    Some manufacturing CPQ platforms can generate configurable BOMs or pass configuration data to a system that creates the BOM. Buyers should verify whether the platform supports EBOM, MBOM, revisions, alternates, effectivity and the required ERP or PLM integration.

    Can CPQ automate CAD drawings?

    Some platforms integrate with parametric CAD or design automation tools to update models and drawings from approved configuration values. This requires compatible CAD templates, stable interfaces, naming standards and revision control.

    Does every CPQ system support engineer-to-order products?

    No. ETO support may range from structured requirements intake and engineering triage to deep design automation. Fully bespoke engineering normally still requires specialist review and design work.

    What products are good candidates for manufacturing CPQ?

    Good candidates have repeatable options, known constraints and meaningful variation in price or engineering output. Examples include pumps, valves, HVAC units, industrial machinery, control panels, modular skids and specialty vehicles.

    Can CPQ replace an ERP system?

    No. CPQ manages configuration and commercial or technical quote processes, while ERP manages broader transactions such as orders, inventory, purchasing, production planning and financial processes.

    What is the role of PLM in a CPQ architecture?

    PLM can govern product definitions, revisions, approvals and lifecycle status. CPQ may consume released product information from PLM and return configuration results or requirements, depending on the architecture.

    Should pricing be stored in CPQ or ERP?

    There is no universal answer. CPQ often performs complex configuration pricing and quote calculations, while ERP may remain authoritative for financial transactions, customer pricing agreements or order validation. Ownership and synchronization must be defined explicitly.

    What is a configurable BOM?

    A configurable BOM is a product structure that changes according to selected options, dimensions, materials or rules. For example, selecting a different pump seal or motor may add, remove or substitute several components.

    What is the difference between CTO and ETO?

    Configure-to-order uses predefined modules and rules to create a valid product. Engineer-to-order requires new or substantially modified engineering for a particular order. A CPQ process may support both by separating standard configuration from engineering exceptions.

    Can CPQ calculate manufacturing cost?

    Some systems calculate cost using material, labor, machine time, purchased parts and overhead inputs. Others receive cost data from ERP or costing applications. The required depth should be verified for the manufacturer’s costing model.

    How does CPQ reduce sales-to-engineering rework?

    It can capture structured requirements, validate selections and transmit the configuration, calculations, assumptions and attachments as a controlled handoff. It does not remove rework caused by incomplete product rules or ambiguous customer requirements.

    Can dealers use manufacturing CPQ?

    Yes. A dealer portal can expose approved product options, channel pricing and application questions while limiting access to internal engineering data. The manufacturer should define authorization, exception handling and quote ownership.

    What should be tested before launching manufacturing CPQ?

    Test valid and invalid combinations, boundary dimensions, units, pricing, revisions, obsolete parts, approvals, document outputs, integrations, BOM structures and engineering exceptions. Users from sales, engineering, operations, finance and IT should participate.

    How should a manufacturer choose its first CPQ use case?

    Choose a product family with repeatable configuration logic, measurable errors or delays, available product data and engaged business owners. Start with a focused workflow and expand after rules, integrations and governance have been proven.

  • Common Manufacturing CPQ Challenges and How They Are Solved

    Manufacturing Configure, Price, Quote (CPQ) projects are difficult because they must connect a customer’s requirements with valid product designs, engineering calculations, accurate pricing and production-ready data. A sales-only quoting tool may select options and calculate a price, but manufacturing CPQ often must also validate dimensions, materials, capacities, electrical characteristics, component compatibility, lead times and downstream manufacturing requirements.

    The most common challenges are poor product data, incomplete configuration rules, excessive product complexity, disagreement about ownership, unreliable pricing, weak engineering integration, incorrect bills of materials (BOMs), difficult enterprise integrations and inadequate testing. These challenges are solved by treating CPQ as a governed product and engineering model rather than simply as a quote-generation application.

    This guide explains where manufacturing CPQ projects typically fail, how the problems appear in daily operations and what implementation practices reduce the risk. For a broader introduction, see the guide to manufacturing CPQ.

    What makes manufacturing CPQ different?

    Manufacturing CPQ supports the process of selecting or designing a valid product, calculating its commercial result and communicating the result to engineering, production and business systems. The exact scope varies by platform. Some products focus mainly on configuration and quoting; others also support engineering calculations, computer-aided design (CAD) automation, BOM generation or production workflows. These capabilities should be verified rather than assumed.

    Manufacturing CPQ may serve several production models:

    • Configure-to-order (CTO): the customer selects from a defined product model and the configured result is manufactured or assembled.
    • Make-to-order (MTO): production starts after the order, usually from a known product and manufacturing definition.
    • Assemble-to-order (ATO): standard modules or components are assembled in a customer-selected combination.
    • Engineer-to-order (ETO): the order requires additional engineering work, calculations, design changes or approval before production.

    A useful CPQ architecture therefore separates the product model, rules, engineering logic, pricing, quoting and integrations, while allowing them to exchange consistent configuration data. The product configuration guide explains the related concepts of options, features, dependencies, constraints and validation.

    1. Poor, fragmented or contradictory product data

    Many CPQ projects begin with product information spread across enterprise resource planning (ERP) records, product lifecycle management (PLM) systems, product data management (PDM) repositories, CAD files, spreadsheets, price lists, engineering documents and the knowledge of experienced application engineers. Names, units, part numbers and revision conventions may differ between sources.

    This creates a basic modeling problem. A pump may be described by flow rate in one system, nominal capacity in another and a family-specific performance code in a third. A motor option may have different voltage labels in the sales catalogue and the ERP. If the CPQ model copies these inconsistencies, users may receive invalid selections or prices that cannot be fulfilled.

    How to solve it

    1. Inventory the source data before modeling the product.
    2. Define a canonical vocabulary for options, attributes, units, materials, components and revisions.
    3. Identify which system owns each data element.
    4. Separate reusable product attributes from sales descriptions and document translations between them.
    5. Clean duplicates and obsolete parts before migration.
    6. Define revision and effective-date behavior for products, rules and prices.

    Do not attempt to reproduce every historical spreadsheet in CPQ. The goal is a controlled product model that represents currently sellable and manufacturable configurations. Data ownership and migration are central topics in the manufacturing CPQ implementation guide.

    2. Modeling complex products without creating an unmaintainable rule set

    Industrial products often contain hundreds or thousands of possible combinations. A machine may include frame size, process capacity, drive type, motor rating, control voltage, enclosure, environmental rating, materials, safety options and accessories. A valve may depend on size, pressure class, body material, trim, actuator, seal material and operating temperature.

    The challenge is not merely storing options. CPQ must express relationships between them. A selected material may restrict temperature range. A motor may require a particular starter or variable frequency drive. A dimension may determine the available frame, shaft, guard and shipping configuration. Some rules are simple exclusions, while others require calculations or external engineering data.

    How to solve it

    Start with a product architecture that reflects how the manufacturer designs and builds the product. Model product families, modules, features, attributes and component selections separately. Use clear rule categories:

    • Compatibility rules prevent combinations that cannot work together.
    • Dependency rules require or recommend related options.
    • Range rules constrain numeric values such as length, capacity or pressure.
    • Calculation rules derive values such as power, weight, flow, heat load or cable size.
    • Commercial rules control price, discount, currency, market and validity dates.
    • Manufacturing rules determine components, operations, routings or production attributes.

    Use modular rules and reusable functions rather than a long sequence of special-case conditions. A rule should explain its purpose, owner, inputs, outputs, effective date and test cases. Where possible, distinguish hard constraints from warnings and recommendations. The product configuration resource provides more detail on rules engines and constraint-based configuration.

    3. Confusing guided selling with engineering configuration

    Guided selling helps a user select a suitable product by asking business-oriented questions such as required capacity, application, environment and budget. Product configuration determines whether the selected options form a technically valid product. These functions overlap but are not identical.

    For example, a distributor may ask which water flow and pressure are required. Guided selling can recommend a pump family. The configuration model must then validate impeller diameter, motor power, seal material, temperature limits and connection standards. A recommendation is not proof that the final product is engineered or manufacturable.

    How to solve it

    Use separate layers for customer questions, recommendations, technical constraints and engineering calculations. Make the transition visible to users. A sales representative should be able to understand whether the system has recommended an option, automatically selected a required component or rejected an invalid combination.

    For higher-risk products, require an engineering review when inputs fall outside a validated CTO model. This prevents a guided-selling interface from presenting an apparently complete quote for an ETO design that still requires engineering.

    4. Handling engineer-to-order requirements

    Not every industrial product can be fully represented by a fixed option matrix. ETO orders may require custom dimensions, new interfaces, nonstandard materials, special loads, application calculations or a new CAD design. Treating every ETO case as a normal configuration can create false confidence and inaccurate delivery dates.

    How to solve it

    Define clear boundaries between CTO and ETO. CPQ can collect requirements, perform preliminary calculations, identify a product family, create a preliminary BOM and route the request for engineering review. Engineering can then complete the design in CAD or PLM, approve the result and return the final part numbers, BOM and documents.

    The quote should show its status, such as preliminary, subject to engineering approval or technically approved. The workflow should record assumptions, unresolved questions, responsible reviewers and required approval dates. More information about this handoff is available in the manufacturing workflows guide.

    5. Inaccurate engineering calculations

    Industrial CPQ frequently needs calculations that influence both feasibility and price. Examples include pump duty and motor sizing, heat exchanger capacity, structural loads, conveyor length, tank volume, cable sizing, airflow, pressure drop, weight and shipping dimensions.

    A calculation can be wrong because of an incorrect formula, unit conversion, boundary condition, material property, rounding convention or outdated engineering constant. It can also be technically correct but used outside its validated range.

    How to solve it

    • Document each calculation, its inputs, units, formula, assumptions and valid operating range.
    • Use standard units internally and convert only at user or document boundaries.
    • Version formulas and engineering constants.
    • Compare CPQ results with approved engineering tools or manually verified examples.
    • Flag values outside the model’s validated range for engineering review.
    • Store calculation results with the configuration so the quote and downstream records can be audited.

    Some CPQ platforms include engineering calculation capabilities, while others require an external calculation service or integration. CAD and engineering automation are discussed in the CAD and engineering guide.

    6. Generating the wrong BOM

    A bill of materials is a structured list of parts, assemblies, quantities and relationships. A configured product may need more than one BOM representation. An engineering BOM (EBOM) describes the design structure, while a manufacturing BOM (MBOM) describes how the product is assembled or produced. A configurable BOM may contain rules or placeholders that resolve only after customer selections are made.

    Common problems include missing accessories, duplicate components, incorrect quantities, obsolete part numbers, wrong revisions and confusion between purchased, manufactured and phantom assemblies. A sales quote may also need a commercial item list that does not match the exact structure required by production.

    How to solve it

    Define the purpose and owner of each BOM. Decide whether CPQ generates a sales BOM, a preliminary EBOM, a production-ready MBOM or only a set of component selections for ERP or PLM to resolve. Do not describe a BOM as production-ready unless the data, revisions, routings and approvals support that claim.

    Test quantity formulas, optional and mandatory components, substitutes, kits, consumables and effectivity dates. Reconcile CPQ output against approved product structures. The BOM, pricing and quoting guide covers EBOM, MBOM, configurable BOMs and quote generation.

    7. CAD automation that does not match the configuration

    Some manufacturers expect CPQ to generate a product-specific 3D model, drawing, DXF file, layout or engineering document. This can reduce repetitive design work, but it introduces a dependency between the configuration model and CAD templates, parameters, constraints and file-generation processes.

    Failures occur when a CPQ option has no CAD mapping, a CAD parameter accepts a value outside its range, a template revision differs from the product rule revision or the generated drawing does not reflect the selected BOM.

    How to solve it

    1. Map each CAD-driving attribute to a controlled parameter.
    2. Define which configurations can be generated automatically and which require manual design.
    3. Validate geometry, interference, manufacturing limits and drawing completeness.
    4. Use revision-controlled templates and link generated outputs to the configuration identifier.
    5. Ensure that CAD output, BOM output and quote descriptions use the same approved configuration state.

    CAD automation is an advanced capability, not a standard feature of every CPQ product. Buyers should verify supported CAD systems, template methods, file formats, server requirements and review workflows.

    8. Pricing and costing do not reflect the configured product

    Manufacturing prices may depend on material, dimensions, purchased components, labor, machine time, setup, freight, region, currency, warranty, service scope, engineering effort and quantity. A simple option surcharge is often insufficient.

    Cost and price are also different concepts. Cost estimates the manufacturer’s economic input. Price is the commercial amount offered to the customer and may include margin, discount, risk, channel terms and negotiated adjustments.

    How to solve it

    Define a pricing architecture that identifies cost sources, price rules, discount authority and approval thresholds. Use effective dates and revision control for price lists, exchange rates, labor rates and material costs. Make the calculation traceable so users can see the basis of a price without exposing information that should remain internal.

    When the configuration changes, recalculate affected costs, lead times and prices. Do not allow a quote to retain a price based on an earlier motor, material or dimension selection. Pricing logic should be tested with boundary cases, currencies, quantities, discounts and manual overrides.

    9. Weak integration with ERP, CRM, PLM, PDM, MES and CAD

    Enterprise systems have different responsibilities. Customer relationship management (CRM) manages accounts, opportunities and commercial activities. ERP manages transactions such as orders, inventory, purchasing, production planning and financial data. PLM manages product definitions, revisions and lifecycle processes. PDM manages engineering files and product data. Manufacturing execution systems (MES) support execution and shop-floor information. CAD creates engineering designs. Product information management (PIM) commonly manages product content for channels.

    Integration fails when systems exchange ambiguous identifiers, incomplete revisions or inconsistent status values. A quote may refer to a description that ERP cannot order, or CPQ may use a product revision that PLM has superseded.

    How to solve it

    • Document the system of record for each entity and attribute.
    • Use stable identifiers for products, options, parts, configurations and documents.
    • Define synchronous and asynchronous integration requirements.
    • Specify error handling, retries, reconciliation and ownership of failed transactions.
    • Exchange revision, effectivity, unit and status information rather than only descriptions.
    • Use APIs or integration middleware where appropriate, but do not let the technology replace data governance.

    The CPQ integration guide explains common relationships between CPQ and ERP, CRM, PLM, PDM, CAD, PIM and MES.

    10. Slow or unreliable configuration performance

    Large product models can become slow when every selection triggers extensive rule evaluation, external calls, calculations, image rendering or CAD generation. Poor performance encourages users to bypass the system or create incomplete configurations offline.

    How to solve it

    Profile the model using realistic product families and worst-case combinations. Separate immediate validation from expensive background work. Cache stable reference data, avoid unnecessary repeated calculations and load product modules progressively. Keep CAD generation and document rendering asynchronous when they do not need to block configuration.

    Performance testing should include concurrent users, dealer access, peak quoting periods, large configurations and integration failures. A fast interface is useful only if it remains reliable when downstream systems are unavailable.

    11. Poor user experience for sales, dealers and engineers

    Users need different levels of detail. A sales representative may need application questions and visible warnings. An application engineer may need dimensions, formulas, component substitutions and calculation results. A dealer may need a constrained catalogue and channel pricing. An internal administrator needs rule diagnostics and audit history.

    A single interface that exposes every engineering attribute can be overwhelming. Conversely, hiding important assumptions can make a quote impossible to review.

    How to solve it

    Design role-specific views while retaining one governed configuration model. Use progressive disclosure, meaningful units, contextual help, validation near the relevant input and clear explanations for rejected choices. Show which values were entered, calculated, recommended or inherited. Preserve an audit trail when a user changes a default or requests an exception.

    12. Rules become difficult to own and maintain

    After implementation, product rules change because of new components, supplier substitutions, regulations, engineering revisions, market requirements and pricing updates. If only the original implementation team understands the model, even a small change becomes expensive and risky.

    How to solve it

    Establish governance before go-live. Assign owners for product structure, technical rules, calculations, pricing, documents and integrations. Use naming conventions, version control, approval workflows and release calendars. Store rules in maintainable forms and document dependencies between product families.

    Regularly remove obsolete options and review rules that are never used. Administrators should be able to test changes in a non-production environment and compare results before release.

    13. Insufficient testing and exception handling

    Testing only a few normal configurations is not enough. Manufacturing CPQ must be tested against valid, invalid, borderline, obsolete and intentionally incomplete inputs. It must also be tested when ERP, PLM, CAD or pricing services return errors.

    How to solve it

    Create a test catalogue that includes representative products, high-volume configurations, boundary values, incompatible options, revision transitions, currency changes, discounts, dealer permissions, engineering approvals and BOM comparisons. Automate regression tests for rules and calculations where possible.

    Test the complete flow from configuration to quote, approval, order, BOM, CAD output and production handoff. Define what happens when an integration fails: queue the transaction, block the quote, allow a draft or route it to a support team. An error message should explain the action required rather than expose a technical stack trace.

    14. Scope expands beyond what the organization can govern

    A CPQ initiative can quickly become a replacement for product master data, CAD, PLM, ERP, pricing management, document management and order entry. Expanding scope increases dependencies and delays the point at which users see value.

    How to solve it

    Define a staged target architecture. A first release might cover one product family, a validated configuration model, pricing, a quote document and a controlled handoff to ERP. Later releases can add BOM resolution, CAD automation, dealer access or ETO workflows after the core model is stable.

    Document capabilities that remain in other systems. A CPQ platform should complement rather than duplicate PLM, ERP or CAD unless there is a deliberate architectural reason to move that responsibility.

    15. Measuring benefits without reliable baseline data

    Manufacturers often want faster quotes, fewer errors and less engineering effort, but they may not have consistent baseline measurements. Quote turnaround time may vary by product family, and configuration errors may be discovered only after order entry or production release.

    How to solve it

    Define measurable indicators before implementation. Useful measures may include quote cycle time, percentage of configurations requiring engineering review, rejected or reworked orders, manual data-entry steps, pricing overrides, rule defects, BOM corrections, quote-to-order conversion and time spent maintaining product models.

    Interpret metrics in context. A reduction in engineering reviews may indicate better configuration, but it could also indicate that users are bypassing review. Pair operational metrics with quality checks and user feedback.

    A practical problem-solving framework

    Manufacturers can evaluate a CPQ challenge using five questions:

    1. What decision is being made? For example, selecting a motor, determining a frame size or approving a discount.
    2. What data is required? Identify attributes, units, revisions, customer requirements and reference data.
    3. What rule or calculation governs the decision? Record constraints, formulas, assumptions and valid ranges.
    4. Which system owns the result? Decide whether CPQ, ERP, PLM, CAD or another service is authoritative.
    5. How will the result be tested and maintained? Define test cases, approvals, release behavior and an owner.

    This framework keeps implementation discussions concrete. It also separates product configuration from price calculation, quote presentation, engineering design and order execution.

    Recommended manufacturing CPQ architecture

    A typical architecture may contain the following logical layers:

    Layer Purpose Typical data
    Product model Defines families, modules, features and attributes Sizes, materials, options, components
    Rules and constraints Validates combinations and dependencies Compatibility, range, required and excluded options
    Engineering logic Calculates or derives technical values Capacity, weight, power, dimensions, performance
    Configuration output Creates a resolved product definition Configuration identifier, selected values, component selections
    Pricing and costing Calculates commercial results Material cost, labor, margin, discount and currency
    Documents Communicates the result Quote, specification, approval record and drawings
    Integration layer Exchanges controlled data with enterprise systems Customer, item, BOM, revision, order and document identifiers

    This architecture does not imply that one software product supplies every layer. It describes the responsibilities that must be designed and governed across the complete workflow.

    Implementation checklist

    • Select a representative product family rather than the easiest catalogue item.
    • Document the current quote-to-order and order-to-production process.
    • Identify configuration decisions that cause engineering rework or order errors.
    • Clean and classify product, component, price and revision data.
    • Define CTO, ATO, MTO and ETO boundaries.
    • Assign ownership for rules, calculations, pricing, BOMs, CAD outputs and integrations.
    • Build a testable minimum product model with clear validation messages.
    • Validate outputs against approved engineering and production examples.
    • Design error handling and manual review paths before connecting production systems.
    • Train administrators as well as sales and engineering users.
    • Release changes through controlled governance and regression testing.

    Manufacturers evaluating platforms should compare configuration depth, constraint handling, product model maintainability, BOM behavior, CAD and engineering support, costing, pricing, quote generation, workflow, APIs, ERP and PLM integration, dealer access, scalability and implementation effort. The manufacturing CPQ comparison resources can support this evaluation.

    Benefits and limitations

    When implemented well, manufacturing CPQ can reduce manual configuration work, identify invalid combinations earlier, improve pricing consistency, shorten the handoff from sales to engineering and provide more reliable product data for ordering and production. It can also make product knowledge more accessible to dealers and less dependent on individual experts.

    CPQ does not automatically repair inaccurate product data, replace engineering judgment or eliminate all ETO work. A platform cannot make an undefined product strategy precise. It may also expose organizational disagreements about part ownership, revision control, pricing authority and production responsibility. These are governance problems that software can support but not solve by itself.

    Frequently asked questions

    What is the most common manufacturing CPQ challenge?

    The most common challenge is converting fragmented product and engineering knowledge into a governed, testable product model with clear rules and ownership.

    How is manufacturing CPQ different from sales CPQ?

    Sales CPQ may focus on selecting offers, calculating prices and producing quotes. Manufacturing CPQ may also validate technical constraints, calculate engineering values, generate BOM data, automate CAD outputs and connect the result to production systems.

    Does every CPQ system generate a BOM?

    No. Some systems generate configurable or resolved BOMs, while others pass selections to ERP or PLM for BOM resolution. The supported BOM type and level of production readiness must be verified.

    Can CPQ replace an ERP system?

    Normally no. ERP manages business transactions such as inventory, purchasing, production planning and financial records. CPQ typically prepares a validated commercial and product definition for ERP.

    Can CPQ replace PLM or PDM?

    Not automatically. PLM manages product lifecycle processes and PDM commonly manages engineering files and structures. CPQ may consume approved data from these systems or exchange configuration results with them.

    What is the difference between an EBOM and an MBOM?

    An EBOM describes the engineering design structure. An MBOM describes how the product is assembled or manufactured. A CPQ project must define which structure it creates or passes to another system.

    How should a manufacturer handle ETO products in CPQ?

    Use CPQ to capture requirements, validate known constraints, perform preliminary calculations and route the case for engineering review. Do not represent an unapproved custom design as a fully production-ready configuration.

    What types of rules are needed for industrial products?

    Common rules include compatibility, dependency, range, calculation, material, manufacturing, pricing and approval rules. Their exact use depends on the product and system scope.

    Should CPQ rules contain all engineering knowledge?

    No. CPQ should contain the validated logic needed for its intended decisions. Complex or high-risk engineering may remain in specialist calculation tools, CAD, PLM or an engineering review process.

    How do configuration errors affect manufacturing?

    They can cause incorrect quotes, unavailable components, wrong BOMs, production rework, delayed engineering reviews, unplanned purchasing and customer dissatisfaction.

    How can pricing stay synchronized with configuration?

    Pricing should consume the resolved configuration and recalculate when relevant attributes change. Price lists, costs, rates, currencies and discounts need effective dates and controlled ownership.

    What should be tested in a manufacturing CPQ project?

    Test valid and invalid combinations, boundary values, calculations, revisions, prices, BOM quantities, approvals, document output, integrations, permissions and failure scenarios.

    How can CPQ support dealers and distributors?

    It can provide a controlled product model, role-specific questions, channel pricing, quote permissions and a validated handoff to the manufacturer. Dealer access should not expose data or options outside the channel policy.

    What is the role of CAD automation in CPQ?

    CAD automation can generate product-specific models, drawings or layouts from approved configuration parameters. It requires controlled templates, parameter mappings, validation and supported CAD workflows.

    How should CPQ handle obsolete components?

    Use revision and effectivity controls to prevent obsolete components from appearing in new configurations while preserving historical quote and order records.

    What is a good first CPQ implementation scope?

    A good first scope usually covers one representative product family, a governed product model, core rules, pricing, quote output and a controlled downstream handoff. Additional automation can follow after the model is proven.

    How do manufacturers measure CPQ success?

    Useful measures include quote cycle time, configuration defects, engineering review rates, BOM corrections, pricing overrides, manual data entry, rework and product-model maintenance effort.

    Semantic map

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

    • Manufacturing CPQ connects customer requirements, product rules, engineering logic, pricing, quoting and production data.
    • Product configuration resolves options and attributes into a technically valid product definition.
    • Rules and constraints control which product combinations are permitted.
    • Engineering calculations derive technical values such as capacity, weight, power and dimensions.
    • A resolved configuration can contribute to a configurable BOM, EBOM or MBOM depending on system scope.
    • Pricing uses the configured product, cost data and commercial policies to calculate an offer.
    • CAD automation can use approved configuration parameters to generate product-specific engineering outputs.
    • ERP manages downstream business and production transactions, while PLM and PDM manage product and engineering information.
    • ETO workflows route unresolved or nonstandard requirements to engineering review.
    • Governance maintains rules, revisions, ownership, testing and release quality over time.

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

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

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

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

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

    What is CRM in manufacturing?

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

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

    Typical CRM responsibilities

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

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

    What is CPQ in manufacturing?

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

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

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

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

    Typical manufacturing CPQ responsibilities

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

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

    CPQ vs CRM: the core difference

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

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

    How CRM and CPQ work together

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

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

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

    Data boundaries between CPQ and CRM

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

    Data usually owned by CRM

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

    Data usually owned by CPQ

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

    Data that may be mastered elsewhere

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

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

    Product configuration is not the same as quoting

    Configuration, pricing and quoting are related but separate functions.

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

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

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

    Manufacturing example: configurable industrial pump

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

    CPQ may then:

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

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

    CRM, CPQ and BOM ownership

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

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

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

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

    CRM, CPQ and engineering automation

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

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

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

    Where the boundary becomes difficult

    Shared product and price data

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

    Quote records

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

    Customer-specific pricing

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

    ETO work

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

    Benefits of integrating CPQ and CRM

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

    Limitations and implementation risks

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

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

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

    How to decide whether you need CPQ or CRM capabilities

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

    Recommended architecture and governance

    A practical architecture normally assigns responsibilities explicitly:

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

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

    CPQ vs CRM in CTO, MTO and ETO workflows

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

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

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

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

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

    Semantic map

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

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

    Frequently asked questions

    1. Is CPQ part of CRM?

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

    2. Can CRM replace manufacturing CPQ?

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

    3. Does CPQ store customer information?

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

    4. Does CPQ generate a BOM?

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

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

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

    6. Can CPQ calculate manufacturing cost?

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

    7. What does CRM send to CPQ?

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

    8. What does CPQ send back to CRM?

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

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

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

    10. Can CPQ automate CAD?

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

    11. Does CPQ replace PLM?

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

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

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

    13. Should CRM own pricing?

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

    14. How are discounts handled between CRM and CPQ?

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

    15. Can CPQ work without CRM?

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

    16. Can CRM work without CPQ?

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

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

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

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

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

    Related manufacturing CPQ guides

  • Cloud vs On-Premise CPQ for Manufacturers

    For manufacturers, the choice between cloud and on-premise CPQ depends less on where the software is hosted than on how deeply it must connect product configuration with engineering, pricing, quoting and production systems. Cloud CPQ is usually easier to deploy, access and update, while on-premise CPQ can provide greater control over infrastructure, data location and tightly coupled internal integrations. Neither option is automatically better for complex products.

    A manufacturing CPQ system should be evaluated as more than a sales quoting tool. CPQ means Configure, Price, Quote. In an industrial environment, configuration may select dimensions, materials, motors, pumps, valves, electrical components and safety options; validate engineering constraints; calculate price and cost; generate a configurable bill of materials (BOM); create engineering outputs; and transfer order data to enterprise systems. A deployment decision must therefore account for the complete data flow, not only the quote screen.

    In general, cloud CPQ is often the better starting point when a manufacturer needs rapid deployment, access for distributed sales channels, managed infrastructure and easier software updates. On-premise CPQ may be more appropriate when strict data-residency rules, isolated networks, legacy system dependencies, highly customized integrations or internal infrastructure control are decisive. A hybrid architecture can be appropriate when configuration and quoting are cloud-based but engineering, CAD, PLM or production systems remain inside the company network.

    For background, see the guide to manufacturing CPQ and the detailed explanation of product configuration and rules engines.

    What is cloud CPQ?

    Cloud CPQ is CPQ software operated in a cloud environment rather than installed entirely on the manufacturer’s own servers. The vendor or a hosting provider normally manages some or all of the infrastructure, application runtime, storage, monitoring and software deployment. Users typically access the system through a web interface or application programming interface (API).

    Cloud deployment does not mean that every system has the same architecture. A vendor may offer a multi-tenant application shared by many customers, a logically isolated hosted environment, or a dedicated private cloud instance. Buyers should verify the actual tenancy model, release process, data location, backup policy, integration methods and customization limits.

    In manufacturing, cloud CPQ may contain the product model, configuration rules, pricing logic, quote documents and user permissions. It may also connect through APIs or integration middleware to customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM), computer-aided design (CAD), product information management (PIM) and manufacturing execution systems (MES). The presence of an integration option should not be confused with a complete, tested integration for a particular manufacturer.

    What is on-premise CPQ?

    On-premise CPQ is installed and operated on infrastructure controlled by the manufacturer or by a hosting partner under a more traditional dedicated operating model. The company usually controls the servers, network access, operating system, database, backup arrangements, security controls and timing of application upgrades.

    On-premise does not necessarily mean that every component is physically located in the company’s main factory. It can include software hosted in a private data center or a dedicated managed environment. The important distinction is that the manufacturer retains a higher degree of responsibility and control for the application environment and its operation.

    This model can be useful where CPQ must communicate with internal systems over private networks, where production data cannot leave a controlled environment, or where the organization has established processes for infrastructure, identity management, disaster recovery and application support. It also creates more operational work. The manufacturer may be responsible for patching, capacity planning, monitoring, backup testing, high availability and compatibility with connected systems.

    Cloud vs on-premise CPQ: the main differences

    Criterion Cloud CPQ On-premise CPQ Manufacturing question
    Infrastructure Usually operated by the vendor or hosting provider Operated by the manufacturer or its designated infrastructure partner Who is accountable when the configuration service is unavailable during quoting or order entry?
    Deployment speed Often faster because servers and base environments already exist May require infrastructure, network, security and installation preparation Does the implementation schedule include firewall, identity and production-system work?
    Updates Usually delivered by the vendor according to a defined release process Scheduled and tested by the manufacturer or implementation team Can product rules, custom integrations and CAD automation survive an upgrade?
    Data control Depends on the provider’s regions, controls, contracts and architecture Greater direct control over storage location and network boundaries What customer, design, pricing and production data must remain in a controlled environment?
    External access Generally suited to dealers, distributors, remote sales teams and supplier users May require VPN, secure gateways or additional access architecture How will dealers configure products without exposing internal systems?
    Integration Often uses APIs, webhooks, middleware or secure connectors Can use internal network access and existing enterprise integration patterns Can CPQ exchange current items, prices, inventory and orders with ERP and engineering data with PLM?
    Customization May be constrained by the vendor’s extension model and shared release cycle May permit deeper environment-level customization, but increases maintenance Are custom calculations and rules genuinely differentiating, or are they creating technical debt?
    Operational responsibility Shared with the provider, subject to the contract and service boundaries Primarily the manufacturer’s responsibility Does the IT team have the skills and capacity to operate a mission-critical configuration service?
    Cost structure Often includes recurring software, hosting or service charges Includes licenses or subscriptions plus infrastructure, support and upgrade costs What is the total cost over the expected life of the product model?

    Why manufacturing CPQ makes the decision more complex

    Generic sales CPQ may focus on selecting products, applying discounts and producing a proposal. Manufacturing CPQ can include all of those activities, but it may also act as a controlled product-model and engineering decision system.

    Consider a configurable industrial pump. The user may select flow rate, pressure, fluid, temperature, casing material, impeller diameter, motor power, seal type, connection standard, enclosure rating and control panel. Rules must prevent incompatible combinations. Engineering calculations may determine a suitable motor or impeller. Pricing may depend on material, performance and supplier costs. The resulting BOM may need separate engineering and manufacturing representations. A CAD system may generate a drawing, while ERP needs item numbers, routings or order data.

    Some CPQ products support only a portion of this flow. A platform may provide guided selling and pricing but require a separate configurator, rules engine, CAD automation service or BOM application. Buyers should therefore compare the deployment architecture of the complete solution, not assume that cloud or on-premise describes every capability.

    How cloud and on-premise CPQ fit into the manufacturing architecture

    A typical manufacturing CPQ architecture contains several logical layers:

    1. User and channel layer: sales engineers, application engineers, dealers, distributors, ecommerce users or customers interact with a configuration experience.
    2. Configuration layer: a product model represents families, options, attributes, dependencies and constraints. Rules validate choices and may calculate derived values.
    3. Commercial layer: costing, price lists, discounts, margins, currencies, approvals and quote documents are applied.
    4. Engineering layer: calculations, CAD automation, drawings, specifications and engineering review may be triggered.
    5. Manufacturing data layer: the system may generate or select a configurable BOM, engineering BOM (EBOM) or manufacturing BOM (MBOM), depending on the process.
    6. Enterprise integration layer: ERP, CRM, PLM, PDM, MES and other systems exchange master data, transactions and status information.

    Cloud and on-premise deployment affect the communication paths between these layers. In a cloud design, an internal ERP or PLM system may need an outbound connector, an API gateway, a message broker or a secure integration service. In an on-premise design, CPQ may access internal databases and services more directly, although direct database access can create governance and upgrade problems.

    PLM manages product lifecycle information and revisions, while PDM commonly manages engineering files and design data. ERP manages business transactions such as items, customers, orders, purchasing and financial information. MES supports execution and visibility on the shop floor. CRM manages customer and opportunity information. These systems are related but not interchangeable. A CPQ deployment should specify which system owns each data object and how revisions are synchronized.

    Read more about CPQ integrations with ERP, CRM, PLM, PDM, CAD and MES.

    Cloud CPQ for manufacturers

    Potential advantages

    • Faster initial access: infrastructure provisioning and standard environments may be available without a new internal server project.
    • Distributed channel support: sales offices, dealers and distributors can use a browser-based application without extending the factory network to every user.
    • Centralized product-model access: approved configuration rules, pricing logic and quote templates can be maintained in one managed service.
    • Managed technical operations: the provider may handle infrastructure monitoring, backups, availability and platform maintenance within agreed service boundaries.
    • Scalable integration options: APIs and asynchronous messaging can connect cloud CPQ to multiple ERP, CRM or ecommerce environments.
    • Reduced local deployment dependency: new sales teams may not require a locally installed application.

    Limitations and risks

    • Connectivity dependence: a remote plant or dealer with unreliable connectivity may need offline processes or local fallback procedures.
    • Integration across network boundaries: sending configuration results to an internal CAD, PLM or ERP system requires carefully designed security, identity and error handling.
    • Release constraints: the vendor’s upgrade schedule may affect custom rules, integrations and extensions.
    • Data residency and confidentiality: product designs, customer information, prices and engineering calculations may be subject to contractual or regulatory restrictions.
    • Shared service dependencies: availability, performance and support depend partly on the provider’s architecture and service agreement.
    • Subscription and exit considerations: a manufacturer should understand data export, model portability, API access and assistance if the relationship ends.

    Cloud is not automatically simpler for a manufacturer with complex engineering. A large product model still requires ownership, testing, version control and a disciplined release process. Moving hosting to a provider does not remove the need to maintain rules for materials, dimensions, options, revisions and manufacturing outputs.

    On-premise CPQ for manufacturers

    Potential advantages

    • Control over the environment: the manufacturer can define network zones, storage locations, access policies and infrastructure standards.
    • Proximity to internal systems: CPQ can be placed near ERP, PLM, PDM, CAD services and file repositories where low-latency or private communication is important.
    • Release control: upgrades can be scheduled around engineering releases, factory shutdowns and peak quoting periods.
    • Support for isolated operations: plants or business units with restricted networks may prefer a system that does not require continuous external access.
    • Deeper environment customization: an organization with strong development and operations capabilities may have more control over custom services and integration components.

    Limitations and risks

    • Infrastructure responsibility: servers, databases, backups, monitoring, patching, disaster recovery and capacity planning must be assigned and funded.
    • Slower channel expansion: secure access for dealers and external sales teams can require additional identity and network architecture.
    • Upgrade burden: heavily customized deployments may be difficult to update, leaving old product rules or security components in place.
    • Higher dependence on internal specialists: the company may need people who understand the CPQ application, integration layer, databases and infrastructure.
    • Business continuity exposure: a local outage, failed integration server or unavailable data center can interrupt quoting and order preparation.

    On-premise deployment is not a substitute for governance. An internally hosted product model can still contain duplicate rules, obsolete prices, undocumented calculations and uncontrolled changes. The manufacturer remains responsible for deciding who owns the model and how changes are tested.

    Product configuration, engineering and BOM considerations

    The most important deployment question is often whether the product model is merely a sales catalog or a source of manufacturing-relevant decisions.

    Rules-based configuration uses explicit logic such as “if option A is selected, option B is required” or “this valve material is unavailable with that fluid.” Constraint-based configuration evaluates allowed combinations against technical constraints, ranges and relationships, such as pressure, temperature, load, capacity or dimensional limits. Guided selling asks users business-oriented questions and recommends products or options; it may use rules, but it does not necessarily perform full engineering validation.

    Cloud and on-premise systems can support any of these approaches only if the specific product provides the required functionality. Buyers should test realistic models, not a small demonstration product. A useful proof of concept might include a pump with material compatibility, motor sizing, regional electrical standards, price breaks, replacement components and a manufacturing output.

    A BOM is a structured list of components and quantities. An EBOM describes the engineering view of a product, while an MBOM describes how it is manufactured and may include production-specific assemblies, consumables, work instructions or shop-floor requirements. A configurable BOM represents alternatives, conditions or rules rather than one fixed structure.

    Some CPQ systems generate a BOM directly; others select existing ERP or PLM structures, call a separate configuration service, or pass option selections to downstream applications. The deployment model must support the chosen ownership pattern. For example, a cloud CPQ application may create a configuration result that an on-premise PLM system converts into an EBOM. Alternatively, CPQ may send a sales configuration to ERP while engineering creates the final MBOM later.

    CAD automation is similarly variable. A CPQ platform may integrate with parametric CAD, invoke a design automation service, generate drawings or only display a 2D or 3D representation. Verify whether CAD files are created synchronously, asynchronously or by a separate engineering system, and how revisions, failures and approvals are handled. See the guide to CAD and engineering automation and the guide to BOM generation, costing, pricing and quote automation.

    Security, availability and data governance

    Security should be evaluated as an architecture and operating responsibility, not as a simple cloud-versus-on-premise label. Cloud providers may offer strong physical security, encryption, identity controls, logging and backup capabilities, while an individual manufacturer may have weaker controls in its own data center. Conversely, some manufacturers require physical or network isolation that a standard cloud service cannot provide.

    Ask both deployment models the same questions:

    • Where are customer, pricing, product and engineering data stored?
    • How are users, dealers, service accounts and APIs authenticated?
    • Is data encrypted in transit and at rest?
    • How are configuration changes and price changes logged?
    • What are the recovery objectives for an outage?
    • How are backups isolated, retained and tested?
    • How are vulnerabilities and patches handled?
    • Can access be limited by role, business unit, product family or region?
    • How are data exports and deletion handled at contract termination?

    Availability must also be considered in operational terms. A sales team may tolerate a temporary delay in a proposal system, while an order-entry process that creates production data may require a defined recovery process. If the CPQ service cannot reach ERP, PLM or CAD, the organization needs clear behavior: queue the transaction, block submission, allow a controlled draft, or route the configuration for manual review.

    Integration patterns to evaluate

    Manufacturers should document the direction, ownership and timing of every important data exchange. Typical examples include:

    Data or event Possible source Possible CPQ use Important design issue
    Customer and opportunity CRM Start a configuration and associate it with an account Identity matching and authorization
    Item, cost and price data ERP or PIM Calculate a current quote Effective dates, currencies and synchronization failures
    Product revision and engineering attributes PLM or PDM Apply approved options and design rules Revision control and lifecycle status
    Configuration result CPQ Create an order, request engineering review or generate a BOM Idempotency, validation and audit history
    CAD request CPQ or engineering workflow Generate a model, drawing or specification Long-running jobs, errors and file ownership
    Production status ERP or MES Show order progress or confirm release Do not confuse quote status with manufacturing status

    Cloud systems commonly use REST or other APIs, webhooks, message queues and managed integration platforms. On-premise systems may use internal APIs, service buses, file exchange or direct network connections. Direct database integration can appear fast but often bypasses business rules and creates upgrade risk. In either architecture, transactions should be traceable, retriable and protected against duplicate orders.

    CTO, ETO, MTO and ATO implications

    Deployment choice should reflect the manufacturer’s operating model.

    • Configure-to-order (CTO): customers select from a controlled set of options, and the configured product can usually be assembled or produced using established structures. Fast, reliable configuration and BOM transfer are priorities.
    • Engineer-to-order (ETO): the customer’s requirements trigger new engineering work. CPQ may capture requirements, perform preliminary calculations, create a project or send a controlled request to engineering rather than produce a final manufacturing BOM immediately.
    • Make-to-order (MTO): production begins after a specific order, even if the product is based on an established design. Accurate options, cost, lead time and order data are important.
    • Assemble-to-order (ATO): standard modules are assembled after the order. The configuration and inventory model must agree on compatible modules and availability.

    A cloud architecture may work well for dealer-led CTO and ATO processes, while an on-premise or hybrid architecture may be preferred when ETO depends on restricted CAD, simulation or PLM environments. This is not a rule. The correct choice depends on the actual interfaces, data classifications and workflow controls.

    See manufacturing CPQ workflows for more detail on CTO, ETO, MTO, ATO and the sales-to-engineering handoff.

    How to choose between cloud and on-premise CPQ

    Use a weighted evaluation rather than a general preference for cloud or on-premise software. The following sequence is practical for a manufacturing selection project:

    1. Map the end-to-end workflow. Document how a requirement becomes a configuration, price, quote, engineering review, BOM, order and production release.
    2. Classify the data. Identify customer data, product designs, prices, costs, formulas, CAD files, supplier information and production data. Record residency and access requirements.
    3. Define system ownership. Decide which system owns products, options, rules, revisions, costs, prices, customers, BOMs and order status.
    4. Measure integration complexity. List ERP, CRM, PLM, PDM, CAD, PIM and MES interfaces, including legacy systems and plants with different architectures.
    5. Test representative products. Use a real product family with dependencies, incompatible options, calculations, revisions and downstream outputs.
    6. Evaluate operating capability. Compare the manufacturer’s ability to run infrastructure, manage releases, monitor integrations and support users.
    7. Model lifecycle cost. Include implementation, data cleanup, integration, licenses, hosting, internal support, upgrades, testing, training and eventual replacement.
    8. Plan governance. Assign owners for product models, rules, prices, engineering calculations, templates and integrations.
    9. Confirm exit and continuity plans. Verify backups, exports, disaster recovery, manual fallback processes and the ability to continue quoting if a connected system is unavailable.

    A proof of concept should include failure cases. Try an invalid material combination, an expired price, a missing ERP item, a CAD job that fails, a product revision that is not released and a configuration that requires engineering approval. These tests reveal more than a demonstration of a successful quote.

    The CPQ implementation guide covers requirements, migration, testing, deployment, governance and maintenance. Vendor selection criteria are also discussed in the manufacturing CPQ comparisons and selection guides.

    When a hybrid CPQ architecture makes sense

    Hybrid deployment places different functions in cloud and internal environments. For example, a manufacturer may expose cloud CPQ to dealers and sales teams, while keeping PLM, PDM, CAD automation, detailed cost data or production release services inside the corporate network.

    A hybrid design can balance external accessibility with internal control, but it introduces a boundary that must be designed carefully. The project should specify:

    • which data is copied to the cloud and which remains internal;
    • how identities and permissions cross the boundary;
    • how configuration revisions are synchronized;
    • how long-running CAD or engineering jobs report status;
    • what happens when the internal service is unavailable;
    • how errors, retries and duplicate requests are handled;
    • which system is the audit authority for the final configuration and order.

    Hybrid is not automatically a compromise-free option. It can increase integration and monitoring requirements. It is most useful when the business has a clear reason to separate user access from sensitive engineering or production services.

    Common mistakes in the deployment decision

    • Choosing based only on hosting cost: integration, model maintenance, data migration and testing often dominate the real implementation effort.
    • Assuming cloud means no IT involvement: cloud CPQ still requires identity, integration, data governance, release management and support.
    • Assuming on-premise means full control without cost: internal control requires people, processes, infrastructure and investment.
    • Evaluating a simple catalog: a few products and prices do not test engineering constraints or manufacturing outputs.
    • Confusing a quote with an order-ready configuration: a priced proposal may not contain an approved BOM, CAD output or ERP-valid item structure.
    • Ignoring model ownership: unclear responsibility for rules and revisions creates inconsistent quotes regardless of deployment model.
    • Underestimating connected-system failures: CPQ must define behavior when prices, inventory, item masters or engineering services cannot be reached.
    • Over-customizing early: custom code can make either deployment model harder to test, upgrade and govern.

    Conclusion

    Cloud and on-premise CPQ are deployment choices, not substitutes for a sound manufacturing product model. Cloud CPQ can simplify access, support distributed channels and reduce infrastructure administration. On-premise CPQ can provide tighter control over networks, data and release timing. Hybrid architecture can separate dealer-facing configuration from internal engineering and production services.

    The decisive questions are whether the system can represent the product accurately, enforce technical and commercial rules, produce the required engineering or manufacturing data, integrate with the existing enterprise landscape and remain maintainable as products change. Evaluate the complete workflow from customer requirement to production-ready information, then select the deployment model that the manufacturer can operate securely and govern over the product’s full lifecycle.

    Semantic map

    The article connects deployment architecture with the manufacturing CPQ entities and workflows below:

    • Manufacturing CPQ connects product configuration, engineering validation, pricing, quoting, BOM generation and enterprise integration.
    • Cloud CPQ connects distributed users and channels to centrally managed configuration services.
    • On-premise CPQ connects internally controlled infrastructure to ERP, PLM, PDM, CAD and production systems.
    • Hybrid CPQ connects cloud user access with internal engineering and manufacturing services.
    • Configuration rules connect customer choices to valid product structures and technical constraints.
    • Product revisions connect PLM or PDM data to approved configuration models.
    • Configured products connect pricing decisions to EBOM, MBOM or order data.
    • CAD automation connects configuration results to product-specific models and drawings.
    • ERP connects CPQ with items, costs, customers, orders and commercial transactions.
    • Manufacturing workflows connect CTO, ETO, MTO and ATO processes to downstream production.

    Frequently asked questions

    1. Is cloud CPQ better than on-premise CPQ for manufacturers?

    Not universally. Cloud CPQ may suit distributed sales and dealer access, while on-premise CPQ may suit strict network control or deeply integrated internal environments. The product model and integration requirements should determine the choice.

    2. What is the main advantage of cloud CPQ?

    The main potential advantage is managed access to a CPQ application without the manufacturer operating all underlying infrastructure. It can also simplify access for remote sales teams and distributors.

    3. What is the main advantage of on-premise CPQ?

    On-premise CPQ gives the manufacturer greater direct control over infrastructure, network boundaries, data location and upgrade timing. That control comes with additional operating responsibility.

    4. Can cloud CPQ connect to an on-premise ERP system?

    Yes, if the CPQ and ERP provide suitable APIs, connectors or integration services. The design must address authentication, firewall access, synchronization, errors, retries and duplicate transactions.

    5. Can on-premise CPQ support dealers and distributors?

    Yes, but external access may require secure gateways, identity federation, a virtual private network or a separate channel architecture. The security and support implications should be tested.

    6. Does cloud CPQ automatically generate a manufacturing BOM?

    No. BOM generation is a capability of the specific CPQ product or connected solution. Some systems generate BOMs, some select existing structures, and others pass configuration results to ERP, PLM or a separate configurator.

    7. Does on-premise CPQ provide better engineering automation?

    Not automatically. CAD automation and engineering calculations depend on the software, integration design and product model. On-premise deployment may simplify access to internal CAD or PLM services, but capability still must be verified.

    8. Is cloud CPQ suitable for engineer-to-order products?

    It can be suitable for capturing requirements, performing preliminary calculations, pricing work and initiating engineering review. Whether it can produce final engineering outputs depends on the specific system and workflow.

    9. What data does a manufacturing CPQ system need?

    It may need product families, options, attributes, rules, constraints, dimensions, materials, costs, prices, currencies, customer data, revisions and output mappings. The exact data depends on the intended workflow.

    10. Which system should own product configuration rules?

    There is no universal answer. Rules may be maintained in CPQ, a dedicated configurator, PLM or another product-model service. Ownership should be explicit, versioned, tested and aligned with the approved engineering process.

    11. How does cloud deployment affect CAD automation?

    Cloud CPQ may call a cloud CAD service, a secure internal CAD service or an asynchronous engineering workflow. The architecture must handle file transfer, permissions, processing time, revisions and failed jobs.

    12. Is on-premise CPQ more secure than cloud CPQ?

    Security depends on controls, architecture and operations rather than location alone. Compare encryption, identity management, logging, patching, backup, monitoring, network isolation and incident response for both options.

    13. What is hybrid CPQ?

    Hybrid CPQ places some services in the cloud and others inside the manufacturer’s network. A common pattern is cloud access for sales and dealers with internal ERP, PLM, PDM or CAD services retained behind corporate controls.

    14. How should manufacturers compare CPQ implementation costs?

    Include product modeling, data cleanup, integration, migration, testing, training, infrastructure, support, upgrades, security, governance and ongoing rule maintenance. Comparing only license or hosting charges is incomplete.

    15. Can a manufacturer migrate from on-premise CPQ to cloud CPQ?

    Migration may be possible, but it requires assessment of product models, custom code, integrations, historical quotes, files, user identities and data-export formats. A pilot product family can reveal portability issues.

    16. Can a manufacturer migrate from cloud CPQ to on-premise CPQ?

    That depends on the vendor’s licensing, export facilities and whether the target system represents the same rules, calculations, documents and integrations. Contractual and technical exit requirements should be reviewed before selection.

    17. Does deployment choice affect quote accuracy?

    Deployment location does not directly determine accuracy. Accuracy depends on product data, rules, calculations, price governance, integration quality, testing and user processes. Poorly maintained models produce errors in any hosting model.

    18. What should a CPQ proof of concept include?

    Use a representative configurable product with dependencies, technical constraints, pricing logic, revisions, engineering approval and a downstream output such as an order structure or BOM. Include invalid combinations and integration failure tests.

    19. Should ERP or PLM replace manufacturing CPQ?

    ERP and PLM serve different primary purposes. ERP manages business and production transactions, while PLM manages product lifecycle and engineering information. CPQ can coordinate customer-facing configuration, commercial logic and selected downstream outputs.

    20. How often must manufacturing CPQ rules be maintained?

    Rules should change whenever products, engineering constraints, prices, suppliers, regulations or manufacturing processes change. A governed release process should include ownership, testing, approval and version history.

  • No-Code vs Low-Code vs Custom CPQ for Manufacturing

    For most manufacturers, low-code CPQ provides the best balance between configuration depth, implementation speed and long-term control. No-code CPQ can work well when products have relatively stable options, straightforward rules and limited engineering automation. Custom CPQ is justified when the business has unusual calculation, configuration, CAD or production requirements that packaged platforms cannot support without excessive compromise.

    The important distinction is that manufacturing CPQ is more than a tool for creating sales quotes. A manufacturing CPQ system may need to validate product configurations, apply engineering constraints, calculate dimensions or capacity, generate a configurable bill of materials (BOM), create product-specific drawings, calculate costs and prices, and pass order-ready data to enterprise systems. The right delivery model depends on which of these capabilities are required and who must maintain them.

    This guide compares no-code CPQ, low-code CPQ and custom CPQ using manufacturing criteria rather than generic sales automation features.

    What are no-code, low-code and custom CPQ?

    CPQ means configure, price, quote. In manufacturing, CPQ software represents products and their valid combinations, applies rules and calculations, determines pricing and costs, and produces a quote or downstream order data. The product model may include options, dimensions, materials, accessories, capacity ranges, dependencies, exclusions, engineering formulas and manufacturing components.

    No-code CPQ uses visual administration tools rather than conventional programming. Product managers or business administrators typically create options, rules, pricing tables and quote templates through forms, spreadsheets, decision tables or graphical interfaces.

    Low-code CPQ combines visual configuration with extension points such as scripting, APIs, custom functions, data models, workflow tools or developer-managed components. Business users can maintain routine product data while technical specialists implement complex logic and integrations.

    Custom CPQ is built or extensively developed specifically for one manufacturer. It may use a general application framework, custom web software, an enterprise platform or a bespoke product configurator. The manufacturer controls the architecture and behavior but also owns more of the implementation, testing, security and maintenance burden.

    Approach Primary configuration method Best fit Main limitation
    No-code Visual rules, tables and administration screens Stable products with manageable rules and limited engineering automation May become restrictive when calculations, integrations or exceptions become complex
    Low-code Visual model plus scripts, APIs and extension components Manufacturers needing substantial configuration and integration flexibility Requires technical governance and specialist skills
    Custom Purpose-built application logic and data architecture Highly specialized products, workflows or engineering processes Higher cost, longer delivery and greater maintenance responsibility

    Why the choice matters in manufacturing

    A generic sales CPQ implementation may only need a catalog, discount rules, a quote template and an approval workflow. A manufacturing implementation often has a deeper chain of dependencies:

    • A customer selects a pump duty, fluid, temperature and materials.
    • The configuration engine checks whether the selected pump, impeller and motor are compatible.
    • An engineering calculation determines the required performance or dimensions.
    • The system selects valid components and creates a configurable BOM.
    • Costing and pricing logic calculate material, labor, purchased components, freight and margin.
    • CAD or design automation may generate a model, drawing or manufacturing document.
    • ERP, product lifecycle management (PLM), product data management (PDM) or manufacturing execution system (MES) receives approved information.

    No-code, low-code and custom approaches can all support parts of this chain, but they do not provide the same level of control. A buyer should evaluate the complete flow from product selection to production data instead of comparing only quote templates or user interface features.

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

    No-code CPQ for manufacturing

    How no-code CPQ works

    No-code CPQ generally represents a product through configurable attributes, option groups, conditions, pricing rules and document templates. An administrator might create a rule stating that a stainless-steel pump body requires a compatible seal material, or that a particular motor cannot be selected below a specified flow range.

    Rules may be expressed as dependencies, exclusions, required selections, min/max values, compatibility tables or guided questions. Guided selling asks users questions and narrows the available choices. It is useful, but it is not identical to a full constraint-based configuration engine. Guided selling helps a user reach an appropriate choice; constraint logic validates relationships that may involve several components or engineering variables.

    Where no-code works well

    No-code is often appropriate for manufacturers with products such as standard machine packages, modular conveyor sections, electrical enclosures, standard HVAC units or catalog-based assemblies. It is particularly useful when:

    • the option structure is well understood;
    • product rules can be expressed in tables or simple conditions;
    • pricing is based on price lists, markups, quantities and discounts;
    • the BOM is a selection of predefined components;
    • engineering calculations are limited or performed outside CPQ;
    • sales, dealers or product managers need to maintain routine changes;
    • integration requirements are limited to standard CRM or ERP transactions.

    For example, a manufacturer of modular air-handling units might use no-code rules to restrict coil types by airflow range, require a compatible control package and calculate price from cabinet size and selected options. If the final unit is assembled from established components, a configurable BOM may be sufficient without custom CAD generation.

    Limitations of no-code CPQ

    No-code does not mean no complexity. A visual interface can hide complexity rather than remove it. Large numbers of interdependent rules may become difficult to understand, test and govern. Administrators may also create duplicate or contradictory logic when ownership is unclear.

    No-code platforms may be limited when a manufacturer needs:

    • iterative engineering calculations;
    • advanced constraint propagation across many variables;
    • custom algorithms for sizing, selection or optimization;
    • dynamic CAD geometry and product-specific drawings;
    • complex engineering-to-order (ETO) workflows;
    • unusual BOM transformations between engineering and manufacturing structures;
    • specialized integrations or event-driven data exchanges.

    These limitations vary by product. A platform marketed as no-code may still offer APIs or extensions, while another may restrict both logic and integration. Capability must be verified against a real product model and representative configuration scenarios.

    Low-code CPQ for manufacturing

    How low-code CPQ works

    Low-code CPQ provides a visual foundation for product data, rules, pricing, workflows and documents, while allowing developers or technical administrators to add custom behavior. Extensions may include scripts, reusable functions, custom objects, API calls, database services, web components or integration middleware.

    This model separates routine product maintenance from exceptional logic. A product manager may maintain motor options and standard prices. A CPQ developer may implement a pump-selection calculation, connect a CAD service or transform a configurable BOM into an ERP-specific structure.

    Why low-code is often suitable for complex products

    Manufacturers commonly need both business agility and engineering depth. Product teams need to change options, costs and rules without waiting for a software release. At the same time, the company may need specialist logic for dimensional constraints, performance calculations, component selection and downstream data generation.

    Low-code can support this division of responsibility. It can also provide a more controlled path for gradual expansion:

    1. Start with product options, configuration validation and quote generation.
    2. Add pricing, costing and approval rules.
    3. Generate configurable BOMs and map them to ERP items.
    4. Connect to PLM or PDM for released product data.
    5. Add engineering calculations, CAD automation or ETO workflows where justified.

    For example, a material-handling manufacturer may configure conveyor length, belt type, frame material, drive power, guarding and discharge arrangement. Visual rules can manage standard compatibility. A custom calculation can determine motor sizing or belt requirements. An integration service can retrieve current costs from ERP and send an approved BOM and order configuration back to production systems.

    Risks and governance requirements

    Low-code can become uncontrolled custom development if every exception is implemented as a script. It requires architectural standards, code review, version control, testing and clear ownership. The organization should document which logic belongs in the product model, which belongs in an engineering service, and which belongs in ERP, PLM or CAD.

    Low-code also does not guarantee manufacturing capability. Buyers must verify whether the platform supports the required BOM structures, CAD connections, calculations, APIs and workflows rather than assuming that an extension point can solve every problem economically.

    Custom CPQ for manufacturing

    When custom development is justified

    Custom CPQ may be appropriate when the manufacturer has a highly differentiated configuration process or when packaged platforms cannot represent the required product and production logic. Potential examples include specialized vehicles, complex electrical systems, engineered process equipment, products governed by proprietary calculations, or businesses with unusual dealer and factory workflows.

    Custom development can provide direct control over:

    • the product and configuration data model;
    • constraint-solving and calculation algorithms;
    • CAD and engineering service orchestration;
    • custom user experiences for sales, dealers or engineers;
    • EBOM and MBOM transformation;
    • integration patterns with ERP, PLM, PDM, MES and other systems;
    • security, deployment and performance architecture.

    An EBOM, or engineering bill of materials, describes the product from an engineering perspective. An MBOM, or manufacturing bill of materials, organizes components and operations for production. A custom CPQ application may be designed to create or transform both structures, but that requires explicit rules and ownership. It should not be assumed that a quote configurator automatically creates a production-ready MBOM.

    Costs and risks of custom CPQ

    The main risk is not only initial development cost. Custom software requires continuing investment in security, infrastructure, integrations, regression testing, product-model maintenance, user support and technical skills. The manufacturer must also maintain the knowledge needed to understand why a configuration rule exists and what downstream systems depend on it.

    Custom systems can reproduce poor product data practices at scale. If option definitions, part numbers, engineering formulas and revision rules are not governed, a bespoke interface will not create reliable manufacturing data. Custom CPQ should therefore follow a clearly defined product model and release process rather than becoming a collection of sales-specific exceptions.

    Comparison by manufacturing capability

    Evaluation area No-code Low-code Custom
    Basic option and dependency rules Strong for manageable models Strong Strong, but potentially unnecessary
    Complex constraints Depends on platform limits Usually more extensible Maximum control
    Guided selling Usually suitable Usually suitable Can be tailored fully
    Engineering calculations May be limited Can use custom functions or services Can implement specialized algorithms
    Configurable BOM generation Suitable for predefined structures if supported Can transform data for downstream systems Can be designed around factory requirements
    CAD automation Often limited or connector-dependent Can orchestrate CAD services where supported Maximum integration control
    ERP, PLM and MES integration Usually relies on standard connectors or APIs Supports more tailored integration Designed specifically for the enterprise architecture
    Business-user maintenance Usually highest Shared between business and technical teams Often depends on custom administration tools
    Implementation speed Usually fastest for defined scope Moderate Usually slowest
    Long-term technical ownership Lower internal code ownership, but vendor dependency may be higher Shared ownership Highest internal responsibility

    How to choose the right approach

    Assess product complexity, not just option count

    A product with 500 options is not necessarily more difficult than one with 30 options. The important questions are how those options interact, whether values are continuous or discrete, whether calculations are iterative, and whether the result must drive engineering and production.

    Document representative products and identify:

    • dimensions, materials, ratings and performance parameters;
    • required, optional and mutually exclusive features;
    • compatibility rules between assemblies;
    • engineering formulas and external calculation services;
    • part-number and revision logic;
    • configurable BOM, EBOM and MBOM requirements;
    • CAD models, drawings and document outputs;
    • cost, price, margin, currency and approval rules.

    Assess the manufacturing workflow

    Clarify whether the business sells configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO) or assemble-to-order (ATO) products. In CTO, customers select from a defined product model and the system can usually produce a predictable configuration and BOM. ETO introduces customer-specific engineering work. MTO focuses on production triggered by an order, while ATO assembles predefined modules after demand is known.

    A no-code model may be adequate for standard CTO or ATO products. Low-code may be more appropriate when CTO products require calculations, integrations and controlled exceptions. Custom development may be warranted for ETO processes, but many ETO organizations should first determine which portions can be standardized before building specialized software.

    Read the guide to manufacturing CPQ workflows for a deeper comparison of CTO, ETO, MTO and ATO.

    Assess data and system boundaries

    CPQ should not become the uncontrolled master of every manufacturing record. A customer relationship management (CRM) system may own the opportunity. ERP may own inventory, orders, costs or production transactions. PLM may own released product structures and revisions. PDM may manage CAD files and engineering documents. A product information management (PIM) system may manage commercial product content. MES may manage shop-floor execution. CAD creates or updates design geometry.

    Define which system owns each data object and how CPQ exchanges it. The CPQ integrations guide covers these boundaries in more detail.

    Implementation practices for any CPQ approach

    Build a governed product model

    Separate product features from prices, components, engineering parameters and presentation content. Give each rule an owner, purpose, source and effective date. Avoid embedding undocumented knowledge in formulas or scripts.

    Start with a representative product family

    Do not select a simple catalog item if the long-term requirement is a highly engineered machine. Conversely, do not begin with the most exceptional ETO product if the organization has not established basic data ownership. Select a product family that exposes important rules, BOM needs and integration dependencies without making the first release unmanageable.

    Test configurations and downstream outputs

    Testing must include valid and invalid combinations, boundary values, changed revisions, discontinued components, price changes and incomplete data. It should also verify that the resulting quote, BOM, CAD output and ERP transaction remain consistent. A configuration that appears valid to sales but produces an incomplete manufacturing structure is not a successful result.

    Plan for change management

    Product rules change when components are discontinued, suppliers change, regulations evolve, prices move or engineering releases a new design. Define how changes are approved, tested, versioned and rolled back. Business administrators need training, while technical teams need documentation and monitoring.

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

    Questions to ask CPQ vendors and implementation teams

    • Can the system represent dimensions, ranges, formulas and cross-component constraints?
    • Which rules can business users maintain, and which require code?
    • Can it create a configurable BOM, and can it distinguish engineering and manufacturing structures?
    • How are part numbers, revisions, substitutions and effectivity dates managed?
    • What CAD, PLM, PDM and ERP integration methods are available?
    • Can calculations run synchronously during configuration, or must they use an external service?
    • How are failed integrations, incomplete data and rejected configurations handled?
    • Can the system support both standard CTO products and controlled ETO exceptions?
    • How are rules tested before release?
    • Can the organization export its product model and configuration data if the platform changes?
    • What audit history is available for rule, price and product-data changes?
    • What skills are required to maintain custom extensions after implementation?

    Use the manufacturing CPQ comparison and selection resources when preparing an evaluation or request for proposal. Software profiles are available in the manufacturing CPQ software directory.

    Best no-code CPQ software: what buyers should verify

    The phrase “best no-code CPQ software” can be misleading in manufacturing. The best platform is not necessarily the one with the simplest administration interface. It is the one that can represent the required product logic, produce reliable outputs and remain maintainable as products change.

    Before choosing a no-code product, test a real configuration with multiple assemblies, incompatible options, dimensional limits, price conditions and a representative BOM. Ask whether the platform can handle the next level of complexity without forcing a complete rebuild or undocumented workarounds. If engineering calculations, CAD generation or production-specific BOM transformation are central requirements, compare low-code and custom alternatives as well.

    Semantic map

    The following relationships summarize the main manufacturing entities and how they connect:

    • CPQ configures configurable products.
    • Product models represent options, attributes and product structures.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration validates relationships between product variables.
    • Guided selling narrows customer choices.
    • Engineering calculations determine product-specific values.
    • A configured product generates a configurable BOM.
    • An EBOM represents an engineering product structure.
    • An MBOM represents a manufacturing product structure.
    • CAD automation generates product-specific drawings or models.
    • Pricing rules calculate commercial prices and margins.
    • Costing rules estimate material, labor and purchased-component costs.
    • CPQ exchanges customer and order data with CRM.
    • CPQ exchanges item, cost and order data with ERP.
    • PLM and PDM provide controlled product and design information.
    • MES receives manufacturing execution data.
    • Low-code extensions add custom calculations and integrations.
    • Custom CPQ provides maximum control over specialized workflows.

    Frequently asked questions

    1. Is no-code CPQ suitable for manufacturing?

    Yes, when products use manageable options, clear dependencies, standard components and relatively simple pricing or BOM logic. It may be insufficient for advanced engineering calculations, complex CAD automation or highly specialized ETO workflows.

    2. Is low-code CPQ better than no-code CPQ?

    Not automatically. Low-code is generally more flexible, but it requires stronger technical governance. No-code may be the better choice for a stable product family that business users can maintain without custom development.

    3. When should a manufacturer build custom CPQ?

    Custom CPQ is most defensible when specialized configuration, engineering, CAD, production or integration requirements cannot be supported economically by packaged software. The decision should include long-term maintenance and ownership costs.

    4. Can no-code CPQ generate a BOM?

    Some no-code CPQ systems can generate BOMs from predefined component rules. Buyers must verify whether the output is a sales BOM, configurable BOM, EBOM or MBOM and whether it contains the data required by ERP or production.

    5. Does CPQ replace ERP?

    No. CPQ typically manages configuration, pricing, quoting and related order data. ERP usually manages orders, inventory, purchasing, financial transactions and other operational records, although system boundaries differ by architecture.

    6. Does CPQ replace PLM or PDM?

    No. Product lifecycle management and product data management systems typically govern released product structures, revisions, CAD files and engineering documents. CPQ may consume approved data and return configuration results.

    7. Can low-code CPQ support CAD automation?

    It can if the platform provides suitable APIs, integration mechanisms or engineering-service extensions. The capability depends on the CPQ platform, CAD system and implementation architecture; it should not be assumed from the term low-code alone.

    8. Is guided selling the same as product configuration?

    No. Guided selling helps users select suitable products by asking questions. Product configuration validates the complete combination of features, parameters and components, often using rules or constraints.

    9. What is the difference between rules-based and constraint-based configuration?

    Rules-based configuration commonly applies explicit conditions such as “if option A is selected, require option B.” Constraint-based configuration evaluates relationships and allowable values across multiple variables, which can be more suitable for complex engineering products.

    10. Can no-code CPQ support engineer-to-order products?

    It may support the commercial intake and initial qualification of ETO products, but ETO often requires engineering review, custom calculations, CAD work and project-specific production data. Those requirements may need low-code extensions, specialist tools or custom development.

    11. What is the difference between CTO and ETO in CPQ?

    Configure-to-order uses a predefined product model and approved combinations. Engineer-to-order includes customer-specific engineering after or during the quote process, so CPQ must coordinate with engineering rather than fully determine every output.

    12. Which CPQ approach is easiest for product managers to maintain?

    No-code is usually easiest for routine maintenance because users work through visual administration tools. Low-code can also support business maintenance, but technical extensions need controlled ownership and release processes.

    13. Does custom CPQ always provide better performance?

    No. Performance depends on architecture, data volume, calculations, integrations and implementation quality. Custom software provides control over performance design but does not guarantee a faster result.

    14. How should manufacturers test a CPQ platform?

    Use representative products and test valid and invalid configurations, dimensional boundaries, price changes, revisions, substitutions, BOM output, CAD documents and ERP transactions. Testing only the user interface is insufficient.

    15. What data is needed before implementing CPQ?

    Typical inputs include product options, attributes, dependencies, constraints, part numbers, revisions, costs, prices, engineering formulas, BOM structures, document templates and integration ownership. Data quality often determines project success.

    16. Can a manufacturer start with no-code and move to low-code?

    Often yes, if the platform supports extensions and the initial product model is governed properly. The migration path should be confirmed before implementation, especially when future CAD, engineering and ERP requirements are known.

    17. What is the main risk of low-code CPQ?

    The main risk is uncontrolled customization. If every exception becomes a script or one-off integration, the model becomes difficult to test and maintain. Clear boundaries, code review and ownership are essential.

    18. What is the main risk of custom CPQ?

    The main risk is creating a long-term software product that the manufacturer must fund and maintain without sufficient internal expertise. Custom CPQ also takes longer to deliver and can duplicate capabilities already available in packaged platforms.

  • Manufacturing CPQ Process Flow from Customer Need to Quote

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

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

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

    What is the manufacturing CPQ process flow?

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

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

    Stage 1: Capture the customer need

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

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

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

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

    Important requirement data

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

    Stage 2: Select the product family and configure the product

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

    Configuration can use several approaches:

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

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

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

    Stage 3: Validate technical constraints

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

    Typical rules include:

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

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

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

    Stage 4: Perform engineering calculations and design automation

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

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

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

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

    Stage 5: Generate the bill of materials and manufacturing data

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

    Several BOM concepts should be distinguished:

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

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

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

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

    Stage 6: Calculate cost, price and lead time

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

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

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

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

    Stage 7: Generate the quote and manage approvals

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

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

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

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

    Stage 8: Handoff from quote to order and production

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

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

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

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

    How the process differs by manufacturing environment

    Configure-to-order

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

    Engineer-to-order

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

    Dealer and distributor sales

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

    Self-service and ecommerce

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

    Systems and data architecture

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

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

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

    Benefits of a controlled manufacturing CPQ flow

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

    Limitations and common failure points

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

    Common failure points include:

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

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

    Implementation considerations

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

    Before building the model, document:

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

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

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

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

    How to measure the process

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

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

    Conclusion

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

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

    Semantic map

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

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

    Frequently asked questions

    1. What is a CPQ process flow in manufacturing?

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

    2. What does CPQ stand for?

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

    3. How does manufacturing CPQ differ from sales CPQ?

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

    4. What happens first in the CPQ process?

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

    5. What is the role of configuration rules?

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

    6. Is guided selling the same as product configuration?

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

    7. Can CPQ generate a bill of materials?

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

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

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

    9. Does every CPQ system include CAD automation?

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

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

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

    11. How does CPQ calculate manufacturing prices?

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

    12. Which systems commonly integrate with manufacturing CPQ?

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

    13. What information should appear in a manufacturing quote?

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

    14. Why are manufacturing CPQ implementations difficult?

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

    15. Should every configuration be fully automated?

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

    16. What is the difference between CTO and ETO?

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

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

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

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

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

    19. Who should own manufacturing CPQ rules?

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

    20. What is the main objective of manufacturing CPQ?

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

  • CPQ vs Quote-to-Cash: Where Manufacturing CPQ Fits

    Manufacturing CPQ is the configuration, engineering, pricing and quoting part of the broader quote-to-cash process. Quote-to-cash describes the complete commercial lifecycle from identifying a customer requirement and preparing a quote through contract acceptance, order processing, delivery, invoicing and payment. Configure, Price, Quote (CPQ) focuses primarily on turning a customer requirement into a valid product configuration and an accurate commercial offer.

    For a manufacturer selling configurable pumps, industrial machinery, electrical assemblies or specialty vehicles, CPQ may do much more than select options and calculate a price. It can apply product rules, perform engineering calculations, validate dimensions and materials, create a configurable bill of materials (BOM), trigger computer-aided design (CAD) automation and pass order-ready data to enterprise systems. However, not every CPQ platform provides all of these capabilities.

    The practical distinction is this: CPQ helps determine what can be sold and under what commercial and technical conditions; quote-to-cash manages what happens across the wider business after and around that quote. Manufacturing CPQ normally sits between customer and product requirements on one side and customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM) and production processes on the other.

    What is quote-to-cash?

    Quote-to-cash is an end-to-end business process that begins with a sales opportunity or customer request and ends when the manufacturer receives payment. It is a process scope rather than one specific software category. Different companies implement it using several connected systems.

    A typical quote-to-cash flow includes:

    1. Identifying an opportunity, customer requirement or request for quotation.
    2. Determining whether the product and commercial terms are suitable.
    3. Configuring the product and calculating cost and selling price.
    4. Generating and approving a quotation.
    5. Negotiating terms and accepting a contract or purchase order.
    6. Creating a sales order and releasing the order for fulfillment.
    7. Planning procurement and production, followed by shipment or installation.
    8. Creating an invoice, collecting payment and managing financial records.

    The exact boundaries vary. Some organizations include lead management and opportunity management. Others begin with quotation and end with payment. The important point is that quote-to-cash crosses departmental and system boundaries. Sales, application engineering, finance, operations, manufacturing, logistics and customer service may all participate.

    What is manufacturing CPQ?

    Manufacturing CPQ is software and product-modeling capability used to configure complex products, calculate prices and costs, and generate accurate quotations. In manufacturing environments, it may also connect the selected configuration to engineering and production data.

    A manufacturing CPQ product model can contain:

    • Product families, modules, options and variants.
    • Dependencies between features, such as a motor that requires a specific controller.
    • Exclusions, such as materials or voltage ranges that cannot be combined.
    • Dimensional limits, load ratings, pressure ranges and performance constraints.
    • Calculations for capacity, flow, torque, power, heat transfer or structural requirements.
    • Pricing, discount, surcharge, currency and margin rules.
    • Component and operation relationships used to create a configurable BOM.
    • Rules for when an application engineer must review or complete an engineer-to-order request.

    These capabilities are not universal. A lightweight sales CPQ application may manage guided selling, product selections, discounts and proposal documents without generating a manufacturing BOM or CAD model. Buyers should verify each capability rather than assuming that the label CPQ describes a complete engineering system.

    Read the broader guide to manufacturing CPQ for an overview of product models, engineering automation, pricing and downstream manufacturing integration.

    CPQ versus quote-to-cash: the central difference

    Area Manufacturing CPQ Quote-to-cash
    Primary purpose Determine a valid product configuration, price and quote. Manage the complete commercial process through order, delivery, invoicing and payment.
    Typical starting point Customer requirements, product selection or an opportunity. Lead, opportunity, request for quotation or customer order.
    Product focus Options, constraints, dimensions, engineering rules and product structure. Product, contract, order, fulfillment, billing and financial records.
    Key users Sales engineers, application engineers, product managers and technical sales teams. Sales, finance, order management, operations, manufacturing, logistics and customer service.
    Typical outputs Validated configuration, price, quote, BOM, calculation results or CAD outputs where supported. Accepted order, fulfillment transactions, invoice, payment and revenue records.
    Common systems CPQ, rules engine, CAD and engineering tools. CRM, CPQ, contract management, ERP, order management, billing and payment systems.
    Manufacturing dependency Must represent product and engineering logic accurately. Must coordinate commercial, operational and financial execution.

    CPQ is therefore not automatically an alternative to quote-to-cash. It is usually a specialized capability within the quote-to-cash architecture. A company can have quote-to-cash processes without a dedicated CPQ platform, but complex manufacturers often need more than manual spreadsheets, generic CRM product lists or basic quoting tools.

    Where manufacturing CPQ fits in the quote-to-cash architecture

    Manufacturing CPQ commonly occupies the decision point where a customer requirement becomes a defined, priced and quotable product. Its upstream and downstream relationships are important.

    Upstream systems and inputs

    A CRM system stores accounts, contacts, opportunities and sales activities. It may initiate the CPQ session or receive the resulting quote. Product information management (PIM) systems may provide descriptions, images and commercial attributes. Product lifecycle management (PLM) or product data management (PDM) systems may provide approved product structures, revisions and engineering metadata.

    These systems are not interchangeable. CRM manages customer and sales relationships. PLM manages product lifecycle information and engineering change processes. PDM usually focuses on engineering files and product data control. PIM commonly manages product content for channels. CPQ consumes or references selected data to support configuration and quoting.

    The CPQ decision layer

    Within CPQ, the user or customer selects options, enters requirements and receives feedback. The system may use several types of logic:

    • Rules-based configuration: explicit if-then logic, such as requiring a stainless-steel wetted part for a specified chemical service.
    • Constraint-based configuration: a solver evaluates permitted combinations, ranges and relationships, such as pressure, temperature, flow and material limits.
    • Guided selling: questions lead a user toward suitable products or options, often without exposing the full engineering model.

    A mature model may use all three approaches. Guided selling helps a distributor or salesperson gather requirements. Rules and constraints validate the technical result. The model may then calculate price, create a BOM or route an exception to engineering.

    Downstream systems and outputs

    After a quote is accepted, the configured result may be sent to ERP for customer, order, inventory, procurement, costing or financial processing. A PLM or PDM system may remain the authority for released engineering structures and revisions. CAD integration may create or update a product-specific model and drawings. A manufacturing execution system (MES) may receive production instructions or order data, usually through ERP or another controlled integration.

    Integration design determines whether the CPQ result is merely a sales record or a reliable manufacturing input. See the guide to CPQ integrations with ERP, CRM, PLM, PDM, CAD and MES.

    How CPQ supports a manufacturing quote-to-cash process

    1. Capture requirements

    The process begins with requirements such as flow rate, lifting capacity, voltage, ambient temperature, dimensions, material, duty cycle or regulatory classification. A CPQ interface can expose these as structured inputs instead of relying on free-text notes.

    For example, a pump configuration may require flow, head, fluid type, temperature, motor voltage, seal material and area classification. The product model can identify whether the selected pump, impeller, motor and seal combination is technically valid.

    2. Validate the product

    Validation prevents invalid combinations before they reach engineering or order entry. A rule might prohibit an aluminum housing at a specified pressure, require a larger frame size above a torque threshold or restrict a motor to compatible electrical controls.

    Validation does not eliminate engineering responsibility. It is only as reliable as the product data, rules and assumptions behind it. New products, supplier substitutions, regulatory changes and undocumented exceptions can make a model incomplete.

    3. Perform calculations

    Some manufacturing CPQ systems perform calculations directly; others call external engineering services or use precomputed selection tables. Examples include heat exchanger sizing, motor selection, conveyor capacity, valve sizing, cable selection and vehicle payload calculations.

    Calculation results should be traceable. A quote may need to show the selected duty point, design margin, assumptions and any engineering approval requirement. A simple option list is not equivalent to an engineering calculation engine.

    4. Generate cost and price

    CPQ pricing can combine list prices, component costs, labor, freight assumptions, currency conversion, customer-specific agreements, volume breaks, discounts, surcharges and margin controls. Costing and pricing are related but distinct. Cost estimates describe expected internal or supplier cost; selling price describes the commercial amount offered to the customer.

    Some manufacturers calculate costs in ERP or a specialized costing system and use CPQ to retrieve them. Others maintain selected cost and pricing logic in CPQ. The authoritative source, update process and timing should be defined during implementation.

    5. Create a quote

    CPQ can generate a quote containing line items, descriptions, quantities, prices, terms, lead-time assumptions, exclusions and approval information. For engineered products, the document may also need performance data, outline drawings, compliance information or a preliminary specification.

    A polished proposal is not proof that the product is manufacturable. The technical validity of the configuration and the completeness of downstream data matter more than document formatting.

    6. Create manufacturing information

    Where supported, CPQ can generate a configurable BOM or pass configuration data to a system that creates one. A BOM is a structured list of components and quantities. An engineering BOM (EBOM) represents the product from an engineering perspective, while a manufacturing BOM (MBOM) represents how it is assembled or produced. They may contain different structures, items and operations.

    A configurable BOM may contain selectable components, quantities driven by dimensions and rules for alternative materials. It should not automatically be treated as a released EBOM or MBOM. Engineering and manufacturing governance may require review, revision control, effectivity and approval before production.

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

    7. Handoff to order and production

    After acceptance, the system must preserve the exact configuration that was quoted. A change in motor, material, dimensions or commercial terms can affect cost, BOM, lead time and drawings. A robust handoff carries a configuration identifier, revision, selected options, calculated values, documents and approval status into order processing.

    The resulting workflow may be configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO) or assemble-to-order (ATO):

    • CTO: the customer selects from predefined valid options and the product is configured from an established model.
    • ETO: the order requires significant engineering design or modification after the commercial decision.
    • MTO: production begins after an order, often using a known design or product specification.
    • ATO: standard modules or components are stocked or prepared and assembled after the order.

    These categories can overlap. A configurable machine may be CTO at the product-model level while still requiring limited ETO work for a site-specific foundation or interface.

    See manufacturing workflows for CTO, ETO, MTO and ATO for a more detailed comparison.

    Manufacturing CPQ versus generic sales CPQ

    Generic sales CPQ typically emphasizes product selection, discount controls, approvals, quote documents and CRM workflow. Those capabilities can be useful in manufacturing, especially for standard products and dealer sales.

    Manufacturing CPQ must be evaluated more deeply when products contain engineering dependencies. Relevant questions include:

    • Can the system model dimensions, ranges, formulas and conditional dependencies?
    • Can product rules be maintained by product managers and engineers without creating uncontrolled custom code?
    • Can it produce a configurable BOM, and is that BOM an input to ERP, PLM or manufacturing engineering?
    • Can it integrate with CAD or generate drawings, and under what conditions?
    • Can it distinguish standard CTO options from ETO exceptions?
    • Can it support dealer, distributor, internal sales and direct customer workflows?
    • Can it preserve product revisions and quote configuration snapshots?
    • Can administrators test rule changes against representative product scenarios?

    A platform may be strong at sales quoting but unsuitable for engineering-driven configuration. Conversely, an engineering configurator may model products well but require additional systems for commercial approvals, customer records or financial processing.

    What quote-to-cash does not mean

    Quote-to-cash is not necessarily a single application, and it is not synonymous with CPQ. It does not automatically provide a product rules engine, CAD automation, BOM generation or manufacturing planning. These functions may be distributed across CPQ, ERP, PLM, PDM, CAD, MES and specialized applications.

    Likewise, CPQ does not automatically cover contract execution, delivery scheduling, invoicing or payment collection. Some vendors position CPQ inside a broader revenue or quote-to-cash suite, but the actual manufacturing capabilities must be verified separately.

    Benefits of placing CPQ correctly

    • Fewer configuration errors: rules identify incompatible options before quotation or order entry.
    • Faster engineering response: repeatable selections and calculations reduce manual application work for standard cases.
    • More accurate commercial decisions: cost, price, margin and lead-time assumptions can reflect the actual configuration.
    • Better sales-to-engineering handoff: structured requirements replace ambiguous notes and email attachments.
    • More reliable downstream data: selected options can feed BOM, CAD, ERP or PLM processes where integrations support it.
    • Improved governance: product rules, prices and approval logic can be versioned, tested and assigned to owners.

    Limitations and risks

    CPQ cannot compensate for poor product data. If engineering structures are incomplete, prices are outdated or exceptions exist only in an experienced salesperson’s knowledge, the system may produce consistent but incorrect results.

    Common risks include:

    • Trying to model every engineering possibility before deciding which products should be standardized.
    • Duplicating uncontrolled product and price data across CPQ, ERP and PLM.
    • Using free-text exceptions that bypass configuration validation.
    • Confusing a quote BOM with a released manufacturing BOM.
    • Sending a configuration to ERP without a clear revision or change process.
    • Assuming CAD automation is included because a platform supports product configuration.
    • Failing to test rules after product, supplier, regulatory or pricing changes.
    • Designing for sales users without involving engineering, manufacturing and finance.

    For implementation guidance, see CPQ implementation planning, testing, governance and maintenance.

    How to decide whether CPQ belongs in your quote-to-cash program

    A dedicated or expanded manufacturing CPQ capability is most valuable when product complexity creates recurring commercial and engineering risk. Indicators include long quote cycles, frequent clarification emails, repeated engineering effort for standard configurations, pricing errors, inconsistent dealer quotes, manual BOM preparation and orders that require re-entry into multiple systems.

    Start with a bounded product family rather than attempting to model the entire catalog. Select a product with measurable configuration problems, stable enough rules and a clear downstream owner. Document:

    1. Customer inputs and required technical constraints.
    2. Product options, dependencies and exclusions.
    3. Engineering formulas and selection tables.
    4. Cost and price sources, including approval thresholds.
    5. Quote content and revision requirements.
    6. BOM, CAD and document outputs.
    7. ERP, CRM, PLM, PDM and MES responsibilities.
    8. Exceptions that require human engineering review.
    9. Test cases covering valid, invalid, boundary and changed configurations.

    Then define whether CPQ is the system of record, a decision layer, or an orchestration layer. In many architectures, PLM remains authoritative for released engineering data, ERP remains authoritative for orders and financial transactions, CRM remains authoritative for customer and opportunity data, and CPQ coordinates configuration and commercial decision-making.

    How to evaluate CPQ and quote-to-cash architecture

    Evaluation question Why it matters
    Where are product rules owned? Prevents contradictory logic and clarifies who approves changes.
    Where are costs and prices maintained? Determines whether margins and commercial terms are trustworthy.
    What is the exact output of configuration? Separates a quote line from a BOM, CAD model, specification or order-ready structure.
    How are revisions represented? Protects the relationship between the quoted, ordered and manufactured product.
    Which exceptions require engineering? Prevents CPQ from falsely promising full automation.
    How are integrations monitored? Makes failures, stale data and duplicate transactions visible.
    How are rule and price changes tested? Reduces the risk that a release creates invalid configurations or incorrect quotes.

    Semantic map

    The following relationships summarize where manufacturing CPQ fits within quote-to-cash and production-oriented architecture:

    • CPQ configures configurable products.
    • Configuration rules prevent invalid combinations.
    • Constraint-based configuration evaluates technical limits.
    • Guided selling collects customer requirements.
    • Engineering calculations determine product suitability.
    • A configured product can generate a configurable BOM.
    • An EBOM represents an engineering product structure.
    • An MBOM represents a manufacturing product structure.
    • CAD automation can generate product-specific drawings.
    • CPQ calculates cost and selling price.
    • CPQ generates a quotation.
    • CRM provides opportunity and customer context.
    • ERP processes orders, inventory and financial transactions.
    • PLM governs product lifecycle and engineering revisions.
    • MES supports production execution.
    • Quote-to-cash includes CPQ, order processing, fulfillment, invoicing and payment.

    Frequently asked questions

    1. Is CPQ the same as quote-to-cash?

    No. CPQ is a capability focused on configuring products, calculating prices and producing quotes. Quote-to-cash is the broader process from opportunity or quotation through order, fulfillment, invoicing and payment.

    2. Where does CPQ fit in quote-to-cash?

    CPQ usually fits between customer requirements or a sales opportunity and the accepted order. It creates a validated commercial and, where supported, technical definition of the product before order processing.

    3. Does quote-to-cash include manufacturing?

    It can include manufacturing-related order fulfillment, but the term itself does not guarantee product configuration, BOM generation or production planning. Those capabilities usually depend on CPQ, ERP, PLM, MES and other systems.

    4. Can a CRM system replace manufacturing CPQ?

    A CRM system may support simple product selection and quoting, but it may not model engineering constraints, dimensional calculations, configurable BOMs or CAD outputs. The required product complexity should determine whether CRM-only quoting is sufficient.

    5. Does every CPQ system generate a BOM?

    No. Some CPQ systems generate only quote lines or product selections. Others can create configurable BOMs or pass structured configuration data to ERP, PLM or another engineering system. This capability must be verified for the specific platform and product model.

    6. Is a CPQ-generated BOM the same as an MBOM?

    Not necessarily. A CPQ output may be a sales or configurable BOM. An MBOM is structured for manufacturing and may include assembly sequence, operations, work centers and manufacturing-specific items.

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

    It can support ETO by collecting requirements, identifying standard content, calculating preliminary prices and routing exceptions to engineering. It does not eliminate the engineering design work required for genuinely new products.

    8. What is the difference between CTO and ETO in CPQ?

    Configure-to-order uses predefined valid options and product rules. Engineer-to-order requires additional design or engineering work after the requirement is understood. A CPQ implementation may support both, but the workflows and outputs differ.

    9. Does CPQ replace ERP?

    No. CPQ generally handles configuration and quoting, while ERP manages areas such as orders, inventory, procurement, production planning, costing, invoicing and financial records. Integration responsibilities must be clearly defined.

    10. Does CPQ replace PLM?

    No. PLM manages product lifecycle information, engineering changes, approvals and released product data. CPQ may use PLM data and return configuration or order information, but the systems serve different purposes.

    11. Does manufacturing CPQ require CAD integration?

    No. CAD integration is valuable when quotes require product-specific models, drawings or design automation, but many CPQ deployments do not include it. CAD capability should be evaluated separately from configuration and pricing.

    12. Can CPQ calculate engineering requirements?

    Some systems provide formulas, selection logic or integrations with calculation services. Others rely on external engineering tools or lookup tables. Buyers should verify supported calculation types, traceability and approval requirements.

    13. What data does manufacturing CPQ need?

    Typical data includes product families, options, dependencies, constraints, dimensions, formulas, components, costs, prices, lead-time assumptions, documents, revisions and integration identifiers. The exact data model depends on the product and workflow.

    14. Who should own CPQ product rules?

    Ownership is usually shared. Product management may own commercial options, engineering may own technical constraints, manufacturing may own production implications, and finance may govern pricing controls. A formal governance model prevents conflicting changes.

    15. How does CPQ improve the sales-to-engineering handoff?

    It captures requirements and selected options in structured data, applies repeatable validation and preserves the configuration used for the quote. This reduces dependence on free-text notes and manual re-entry, although exceptions may still require engineering review.

    16. Can CPQ support dealer and distributor sales?

    Yes, some platforms provide role-specific interfaces, guided selling, price lists, approvals and self-service workflows for dealers. The manufacturer must verify channel pricing, authorization, product visibility and technical configuration capabilities.

    17. Is quote-to-cash only relevant to software companies?

    No. The concept is also relevant to manufacturers. In manufacturing, the quote-to-cash flow may include technical configuration, application engineering, BOM preparation, production, shipment, invoicing and payment rather than subscription billing.

    18. What is the biggest implementation risk?

    A major risk is treating CPQ as a quoting interface while ignoring product data, rule ownership, engineering exceptions and downstream system responsibilities. A successful implementation defines the product model and process architecture together.

    19. Should CPQ or ERP be implemented first?

    There is no universal sequence. The decision depends on product complexity, existing systems, data quality and the business objective. A focused CPQ implementation can expose product-model issues, while ERP readiness may be necessary for reliable costing and order handoff.

    20. How should manufacturers measure CPQ success?

    Useful measures include quote turnaround time, configuration error rates, engineering hours per quote, quote-to-order conversion, margin variance, manual re-entry, exception rates and the completeness of order-ready product data. Metrics should reflect the targeted product family and process.

  • Tacton CPQ for Manufacturing: Features, Strengths, and Fit

    Tacton CPQ is a manufacturing-focused configure, price, quote platform for companies that sell complex, configurable or engineered products. Its relevance is strongest where quoting depends on product rules, engineering constraints, calculations, product variants, technical documentation or downstream manufacturing data rather than only on selecting items from a price list.

    Tacton is commonly associated with rules-based product configuration, guided selling, engineering automation, visual configuration, CAD-related automation and integration with enterprise systems. Its potential fit includes industrial machinery, equipment, pumps, valves, material handling systems, electrical equipment, vehicles and other products with many valid combinations and technical dependencies.

    However, a buyer should not assume that every Tacton deployment includes every capability. Available modules, connectors, CAD systems, visualization functions, integration patterns and automation depth depend on the purchased product scope, implementation design, customer data and current product release. A serious evaluation should therefore test a representative product model rather than rely only on a feature checklist.

    What is Tacton CPQ?

    Tacton CPQ is a software platform for configuring products, calculating prices and producing quotes. In a manufacturing context, CPQ must do more than assemble a commercial proposal. It may need to determine whether a selected motor is compatible with a pump, calculate a machine configuration from capacity and dimensions, select the correct components, produce engineering outputs and transfer order data to enterprise systems.

    Tacton positions its CPQ capabilities around complex product configuration and the automation of technical sales processes. The platform is intended to represent product options, dependencies, constraints and commercial logic in a reusable product model. A sales representative, dealer or customer can then answer questions or select requirements while the system validates the configuration.

    This differs from generic sales CPQ, which may concentrate on product catalogs, discounts, approvals and proposal documents. Manufacturing CPQ connects those commercial functions with engineering and production information. The important evaluation question is not simply whether Tacton can create a quote, but whether it can reliably convert a valid configuration into the technical and commercial data needed by sales, engineering, operations and manufacturing.

    How Tacton fits into a manufacturing workflow

    A typical manufacturing CPQ workflow can begin with a customer requirement such as flow rate, pressure, lifting height, payload, enclosure rating, voltage, throughput or vehicle dimensions. The system uses a product model to translate that requirement into compatible options and calculated values.

    1. Requirement capture: A salesperson, dealer or customer enters technical and commercial requirements.
    2. Configuration: The product model proposes or validates options, dimensions, materials, accessories and operating parameters.
    3. Constraint checking: Rules prevent incompatible combinations, such as a motor that cannot meet the selected load or a material unsuitable for the specified fluid.
    4. Engineering calculation: Where implemented, formulas or external engineering services can calculate sizes, capacities, performance values or other technical results.
    5. Pricing and costing: The system applies prices, surcharges, discounts, currencies, cost inputs and commercial policies.
    6. Output generation: The quote may include technical descriptions, drawings, visual representations, bills of material or other documents, depending on the configured solution.
    7. System handoff: Approved data can be exchanged with systems such as enterprise resource planning (ERP), customer relationship management (CRM), product lifecycle management (PLM), product data management (PDM) or computer-aided design (CAD) platforms.

    The exact sequence varies. A configure-to-order (CTO) manufacturer may select from predefined modules and generate a manufacturing bill of material. An engineer-to-order (ETO) business may use CPQ to define the commercial and technical starting point, followed by engineering review and detailed design.

    Key Tacton CPQ capabilities for manufacturers

    Product configuration and rules

    Configuration is the central manufacturing use case. Tacton product models can be used to represent options, attributes, relationships and constraints for complex products. Rules can express conditions such as “if the pump handles corrosive fluid, restrict material choices to compatible alloys” or “if the conveyor length exceeds a threshold, require an additional support module.”

    These rules are different from simple guided selling. Guided selling asks questions and recommends products based on user responses. Rules-based configuration validates combinations and controls the structure of the product. Constraint-based configuration goes further by resolving relationships between technical variables, requirements and available options. Buyers should establish which of these mechanisms is used for their product models and how complex dependencies are maintained.

    Important evaluation areas include rule authoring, reusable logic, versioning, error handling, effective dates, test coverage, dependency visualization and ownership. A technically capable engine can still become difficult to maintain if product rules are scattered across code, spreadsheets, CAD files and ERP logic.

    Guided selling and user experience

    Tacton can support guided configuration experiences intended for sales users, dealers, distributors and potentially self-service channels, depending on the selected deployment and implementation. A guided interface can present technical questions in a sequence that matches how customers describe their requirements rather than how engineering stores product data.

    For example, a customer buying an industrial air-handling unit may specify airflow, temperature range, installation environment and available space. The configuration model can use those inputs to narrow valid selections and expose only relevant options. This reduces the need for a salesperson to understand every internal part number, but it does not eliminate the need for accurate product data and well-maintained rules.

    Engineering calculations and product logic

    Engineering calculations are important when a quote depends on performance or physical requirements. Examples include sizing a pump from flow and head, selecting a drive from torque and speed, determining heat-exchanger capacity, calculating structural requirements or choosing a vehicle configuration based on payload.

    Tacton is associated with engineering-oriented configuration and calculation scenarios, but the scope of calculations should be verified for each project. Buyers should determine whether calculations are native to the proposed solution, implemented through formulas, connected to an external calculation service or handled by CAD and engineering applications. They should also test units, rounding, boundary conditions, tolerances, missing inputs and exception handling.

    CAD automation and 3D visualization

    CAD means computer-aided design. CAD automation can create or update product-specific models, drawings or design parameters from a valid configuration. Three-dimensional visualization can help a customer or salesperson understand the selected product, options and spatial arrangement.

    Tacton has been associated with design automation and visual configuration capabilities for industrial products. These capabilities can be valuable for machinery and equipment manufacturers where a quote requires a configured layout, product image, drawing or design output. A useful proof of concept should test the actual CAD platform, template strategy, geometry variations, drawing rules, generation time and error recovery process.

    Visualization should not be confused with engineering automation. A 3D model that displays selected options may not be the same as a production-ready CAD model. Similarly, a sales image does not automatically constitute an approved drawing. Buyers should define whether the required output is a visual aid, a quotation drawing, a design model, a manufacturing drawing or a controlled engineering document.

    BOM generation and manufacturing data

    A bill of material (BOM) is a structured list of components required for a product. An engineering bill of material (EBOM) represents the product from a design perspective, while a manufacturing bill of material (MBOM) organizes components and operations for production. A configurable BOM contains conditional or variable components that depend on the selected configuration.

    In a manufacturing CPQ architecture, a configured product may generate a BOM directly, request one from an ERP or PLM system, or pass configuration parameters to another application that creates the final structure. Tacton deployments may support BOM-related outputs and downstream data flows, but the buyer must verify the exact ownership model.

    Key questions include whether the system creates EBOM or MBOM data, how purchased and manufactured parts are represented, how revisions are controlled, whether phantom assemblies are supported, how substitutes and alternates are handled, and whether the resulting structure is accepted by the target ERP or PLM platform. A quote-level component list is not automatically a production-ready BOM.

    Pricing, costing and quoting

    Pricing converts a valid configuration into a commercial offer. It may include base prices, option prices, material surcharges, engineering charges, freight, regional adjustments, customer-specific agreements, currencies, discounts and approval thresholds. Costing estimates internal cost or margin and should be distinguished from sales pricing.

    Tacton CPQ can be evaluated for its ability to combine technical configuration with pricing and quote generation. The practical question is whether commercial logic remains consistent with the product model. For example, an extended stainless-steel option should update both the technical configuration and the price, while a custom dimension may trigger an engineering charge or an ETO review.

    Buyers should test price validity dates, revisions, currencies, taxes, discounts, manual overrides, approval workflows and auditability. They should also identify whether authoritative prices come from CPQ, ERP, a pricing service or another system.

    Integrations and architecture

    Manufacturing CPQ normally operates as part of an enterprise application landscape rather than as an isolated quoting tool. Tacton implementations may exchange data with multiple systems, but the available integration method and depth must be confirmed for the specific environment.

    System Typical CPQ relationship Questions to verify
    CRM Opportunity, account, contact and quote context Which system owns the opportunity, quote status and customer record?
    ERP Items, prices, inventory, orders, customers and manufacturing data Does CPQ create orders, send configuration attributes or retrieve authoritative prices?
    PLM Product structures, revisions, lifecycle and engineering authority How are released versions and change processes synchronized?
    PDM CAD files, drawings, metadata and document control Can outputs be linked to controlled documents and revisions?
    CAD Parameters, models, drawings and design automation Which CAD products and templates are supported in the proposed design?
    PIM Product descriptions, media and commercial content Which system owns customer-facing product content?
    MES Production execution and shop-floor information Is CPQ expected to integrate directly, or through ERP or PLM?

    Integration architecture may use APIs, middleware, batch processes, event-driven services or vendor connectors. A buyer should request a logical data-flow diagram showing the source and destination of product rules, item masters, prices, revisions, BOMs, drawings and order information. More detail is available in this guide to CPQ integrations.

    Strengths of Tacton CPQ for manufacturing

    • Manufacturing orientation: Tacton is positioned around complex products and technical configuration rather than only subscription or sales quoting.
    • Configuration depth: Its product-model approach is relevant to equipment with dependencies, constraints, calculated values and many valid variants.
    • Engineering connection: The platform is a candidate for organizations that need configuration to influence calculations, CAD outputs or technical documentation.
    • Commercial and technical alignment: A shared model can connect selected options with price, description and downstream data.
    • Multiple sales channels: Guided configuration can potentially support direct sales, dealers, distributors and other channels, subject to implementation.
    • Suitability for complex products: It may be a better fit than lightweight CPQ when a product requires technical validation before it can be quoted.

    Limitations and risks to investigate

    Tacton should not be treated as an automatic replacement for ERP, PLM, CAD, PDM or engineering applications. It may coordinate data between these systems, but the boundaries must be designed explicitly.

    • Implementation complexity: Complex product models require analysis of engineering rules, commercial policies, data ownership and exception processes.
    • Product-model maintenance: New variants, obsolete components, engineering changes and regional pricing can create substantial governance work.
    • CAD scope: CAD automation may depend on specific CAD systems, templates, licensing, server architecture and engineering standards.
    • BOM ownership: A configured BOM may require additional transformation before it is suitable for production or order fulfillment.
    • ETO boundaries: CPQ can structure an engineered sale, but it may not replace detailed engineering review, project management or design approval.
    • Integration dependency: Data quality and integration design often determine the outcome more than the CPQ interface.
    • Commercial transparency: Pricing logic, discounts and manual overrides require clear ownership and audit controls.
    • Release variation: Features, connectors and deployment options can change, so current documentation and a solution-specific demonstration are necessary.

    These are not necessarily product defects. They are common risks in manufacturing CPQ projects. The CPQ implementation guide explains why product modeling, testing, governance and data migration should be treated as core workstreams.

    Deployment and implementation considerations

    Prospective customers should evaluate the proposed Tacton architecture, hosting model, environments, identity management, release process, APIs, monitoring, security controls and responsibilities for upgrades. The commercial label “cloud” does not by itself explain how CAD automation, integration middleware, customer data and engineering outputs will operate.

    Implementation should begin with representative products, not the entire catalog. Select a product family such as a pump, industrial cabinet or conveyor and document:

    • technical inputs and units of measure;
    • valid and invalid combinations;
    • calculation formulas and boundary conditions;
    • option and component relationships;
    • price, cost and discount sources;
    • EBOM, MBOM or configurable BOM requirements;
    • CAD, drawing and visualization outputs;
    • approval and exception paths;
    • ERP, CRM, PLM, PDM and other integration messages;
    • ownership of rules, data and future changes.

    Testing should include valid configurations, invalid combinations, changes to released products, discontinued parts, unusual dimensions, currency changes, manual overrides, integration failures and ETO exceptions. A configuration that works in a demonstration but fails at a boundary condition can still create engineering rework or production errors.

    When Tacton CPQ may be a good fit

    Tacton is worth evaluating when a manufacturer has complex configurable products, a substantial sales-engineering workload and a need to connect technical selection with pricing, documentation or downstream systems. Examples include machinery with many option dependencies, pumps selected from operating conditions, modular material-handling equipment, configurable electrical systems and specialty vehicles with dimensional or regulatory constraints.

    It may be less appropriate when the requirement is limited to simple product bundles, basic discount management or a small catalog with no technical validation. It may also be unsuitable if the organization is not prepared to establish ownership for engineering rules, product data and integration maintenance.

    Alternatives and selection criteria

    Tacton should be compared with other manufacturing CPQ, product configuration and design-automation platforms using the buyer’s product complexity and workflow. The relevant alternative may be a specialized configurator, a CPQ suite connected to PLM, an ERP product configurator, a CAD-driven design automation tool or a custom solution.

    Use the manufacturing CPQ comparison resources and CPQ software profiles to structure an evaluation. Ask each vendor to demonstrate the same product family, including constraints, calculations, pricing, BOM output, CAD requirements, approval exceptions and integration messages. Feature counts are less useful than evidence that the proposed system can maintain the product model over time.

    Conclusion

    Tacton CPQ is a serious candidate for manufacturers that need technical product configuration connected to pricing and quoting, and potentially to engineering automation, CAD, visualization and enterprise systems. Its strongest apparent fit is complex industrial products where invalid combinations, manual engineering effort and slow quote preparation create measurable business problems.

    The final decision should depend on a controlled proof of concept. Verify the current product scope, supported integrations, CAD and visualization requirements, BOM behavior, deployment architecture, implementation responsibilities and total maintenance model. Tacton may provide the configuration foundation, but reliable manufacturing outcomes still depend on accurate product data, disciplined rules governance and well-designed ERP, PLM, CAD and production workflows.

    Semantic map

    The following relationships summarize how Tacton CPQ connects manufacturing concepts:

    • Tacton CPQ → configures → complex industrial products
    • Product models → represent → options, attributes and dependencies
    • Configuration rules → prevent → invalid product combinations
    • Engineering calculations → determine → technical product parameters
    • Guided selling → collects → customer requirements
    • Configured products → determine → prices and technical descriptions
    • Configured products → can generate or request → BOM data
    • CAD automation → produces → product-specific models or drawings
    • 3D visualization → communicates → selected product variants
    • CPQ → exchanges data with → ERP systems
    • CPQ → connects commercial configuration with → CRM opportunities
    • PLM and PDM → govern → product revisions and engineering documents
    • CTO workflows → use → predefined configurable modules
    • ETO workflows → require → engineering review after configuration
    • Product governance → maintains → rules, prices and released variants

    Frequently asked questions

    1. What is Tacton CPQ?

    Tacton CPQ is a configure, price, quote platform designed for complex products. In manufacturing, it can connect technical product selection with pricing, quoting and selected engineering or enterprise workflows.

    2. Is Tacton CPQ designed for manufacturing?

    Yes. Tacton is positioned for manufacturers and businesses selling complex configurable or engineered products. Its suitability still depends on the specific product model, integrations and implementation scope.

    3. Can Tacton CPQ handle complex product configuration?

    It is intended to handle complex configuration involving options, dependencies, constraints and technical requirements. Buyers should test their own product rules, calculations and exception cases.

    4. Does Tacton CPQ generate a bill of material?

    A Tacton solution may generate or exchange BOM-related data, but the exact output and ownership model must be verified. A quotation component list is not automatically an ERP-ready MBOM.

    5. Does Tacton CPQ support CAD automation?

    Tacton is associated with CAD and design-automation scenarios. The supported CAD application, templates, outputs, licensing and generation workflow should be confirmed during evaluation.

    6. Does Tacton include 3D product configuration?

    Tacton has been associated with visual and 3D configuration capabilities. Buyers should establish whether the required function is a sales visualization, interactive model, engineering model or production drawing.

    7. Can Tacton CPQ perform engineering calculations?

    Engineering-oriented configuration and calculations can be part of a Tacton solution, but the implementation method and calculation scope must be confirmed for the product being evaluated.

    8. Can Tacton CPQ support configure-to-order manufacturing?

    It can be evaluated for configure-to-order workflows where customers select valid combinations of predefined modules and options. ERP and manufacturing systems may still own order and production execution.

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

    It can help capture requirements and define the commercial and technical starting point for an engineer-to-order product. Detailed design approval, project engineering and document control may remain in engineering or PLM systems.

    10. Does Tacton CPQ replace an ERP system?

    No. An ERP system typically remains responsible for areas such as order management, inventory, purchasing, production and financial processing. CPQ normally exchanges selected data with ERP.

    11. Does Tacton CPQ replace PLM or PDM?

    No. Product lifecycle management and product data management systems may remain authoritative for revisions, engineering structures, CAD files and controlled documents.

    12. Can Tacton CPQ integrate with CRM?

    A CPQ deployment may exchange opportunity, customer and quote information with CRM. The integration method and supported CRM environment should be confirmed for the proposed architecture.

    13. Is Tacton CPQ suitable for dealer and distributor channels?

    Guided configuration can be relevant to dealer and distributor sales channels. Access controls, channel-specific pricing, product visibility and approval rules should be demonstrated.

    14. Is Tacton CPQ suitable for simple product catalogs?

    It may be more capable than necessary when products have few dependencies and pricing is simple. A lighter quoting or catalog solution could be easier to implement in that situation.

    15. What product data does Tacton CPQ require?

    Typical requirements include product options, attributes, constraints, component relationships, prices, descriptions, units, revisions and integration identifiers. CAD, BOM and calculation data may also be required.

    16. Who should own Tacton product rules?

    Ownership should be shared through a defined governance process involving product management, engineering, sales operations, IT and manufacturing stakeholders. One team should be accountable for rule quality and release control.

    17. How should a manufacturer evaluate Tacton CPQ?

    Use a representative product family and test configuration rules, calculations, pricing, BOM outputs, CAD requirements, approval exceptions and system integrations. Avoid evaluating only through a generic demonstration.

    18. What are the main implementation risks?

    Common risks include poor product data, unclear rule ownership, uncontrolled exceptions, inaccurate pricing, weak integration design, insufficient testing and confusing sales outputs with production-ready engineering data.