Tag: BOM generation

  • CPQ Software for Manufacturing: The Complete Guide

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

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

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

    What is manufacturing CPQ software?

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

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

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

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

    How manufacturing CPQ differs from generic sales CPQ

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

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

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

    The main capabilities of manufacturing CPQ

    Product configuration and product models

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

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

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

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

    Rules, constraints and guided selling

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

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

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

    Engineering calculations

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

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

    Costing and pricing

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

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

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

    Quote and proposal generation

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

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

    Bill of material generation

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

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

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

    CAD automation and visualization

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

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

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

    Where CPQ fits in the manufacturing technology stack

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

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

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

    Manufacturing workflows supported by CPQ

    Configure-to-order

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

    Make-to-order and assemble-to-order

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

    Engineer-to-order

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

    These workflows are explained in the manufacturing CPQ workflow guide.

    Example: configuring an industrial air-handling unit

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

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

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

    Benefits of CPQ for manufacturers

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

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

    Limitations and risks

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

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

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

    How to evaluate CPQ software for manufacturing

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

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

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

    Implementation approach

    1. Define the business case and scope

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

    2. Inventory product and commercial data

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

    3. Establish ownership and governance

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

    4. Model a representative product

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

    5. Design integrations and data contracts

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

    6. Test rules and outputs

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

    7. Deploy in controlled releases

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

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

    Key questions to ask before buying

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

    Semantic map

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

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

    Frequently asked questions

    What does CPQ stand for in manufacturing?

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

    What is the main purpose of manufacturing CPQ?

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

    Is manufacturing CPQ the same as sales CPQ?

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

    Can CPQ generate a bill of material?

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

    What is the difference between an EBOM and an MBOM?

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

    Can CPQ create CAD drawings?

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

    Does CPQ replace ERP?

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

    Does CPQ replace PLM?

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

    Can CPQ support engineer-to-order products?

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

    What products benefit most from manufacturing CPQ?

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

    What is a product model in CPQ?

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

    What is the difference between configuration rules and constraints?

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

    Can manufacturers use CPQ for dealer and distributor sales?

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

    How does CPQ reduce engineering workload?

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

    How long does a manufacturing CPQ implementation take?

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

    What data is needed to implement CPQ?

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

    How should CPQ rules be maintained?

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

    What should a CPQ proof of concept include?

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

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

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

    Is 3D visualization required for manufacturing CPQ?

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

  • CPQ Configurator vs Product Configurator: What Is the Difference?

    A product configurator determines how a product can be configured. A CPQ configurator uses product configuration as one part of a broader Configure, Price, Quote process. In manufacturing, that broader process may include engineering rules, calculations, costing, pricing, quote generation, bills of material (BOMs), CAD outputs and handoffs to enterprise systems.

    The terms overlap because many modern manufacturing CPQ platforms contain a product configuration engine. However, they are not automatically interchangeable. A standalone product configurator may validate options and display a configured machine without calculating a commercial price or creating a production-ready BOM. A CPQ configurator normally connects the valid configuration to commercial and, depending on the implementation, engineering and operational outputs.

    The practical distinction is therefore one of scope:

    • Product configurator: focuses primarily on selecting and validating the product.
    • CPQ configurator: configures the product and supports pricing, quoting and related downstream processes.

    For a manufacturer selling pumps, industrial machinery, HVAC systems, electrical equipment or specialty vehicles, the right choice depends on whether the business needs only configuration guidance or needs to turn a validated configuration into an accurate, manufacturable commercial transaction.

    What is a product configurator?

    A product configurator is software that helps a user select valid features, options, dimensions, materials and components for a product. It applies product rules to prevent incompatible combinations and may calculate technical values or display the result visually.

    For example, a pump product configurator might ask for:

    • flow rate and discharge pressure;
    • pump type and impeller diameter;
    • motor voltage and power rating;
    • casing material, such as cast iron or stainless steel;
    • seal and bearing options;
    • connection size and mounting arrangement.

    The configurator can use dependencies and constraints to determine whether a chosen combination is valid. A stainless-steel casing may require a particular seal. A selected flow rate may require a larger impeller or motor. A voltage option may be unavailable for a specific motor size. If the user selects an incompatible combination, the system can block it, remove the option or explain what must change.

    A product configurator can be deployed in several places, including a sales application, dealer portal, business-to-business ecommerce site, engineering application or internal product-selection tool. It may be a standalone application or a component within a larger CPQ, product lifecycle management (PLM), customer relationship management (CRM) or ecommerce architecture.

    What is a CPQ configurator?

    A CPQ configurator is the configuration component of CPQ software. CPQ stands for Configure, Price, Quote. It combines product configuration with commercial logic so that a valid product selection can become an accurate price and customer quote.

    In a manufacturing environment, a CPQ configurator may perform the following sequence:

    1. Collect customer and application requirements.
    2. Guide the user through valid product options.
    3. Apply configuration rules and engineering constraints.
    4. Calculate dimensions, capacity, performance or other technical values.
    5. Determine the configured product structure.
    6. Calculate material, component, labor, freight or other costs where supported.
    7. Apply list prices, discounts, surcharges, regional pricing and margin rules.
    8. Generate a quotation with technical specifications and commercial terms.
    9. Create a configurable or product-specific BOM and send relevant data to ERP, PLM, CRM, CAD or manufacturing systems where integrations exist.

    Not every CPQ product performs every step. Some systems focus on guided selling, pricing and proposals. Others extend into engineering automation, CAD generation and production data. Buyers should verify the actual scope of a platform rather than assuming that the word CPQ means it creates manufacturing-ready outputs.

    CPQ configurator vs product configurator: key differences

    Dimension Product configurator CPQ configurator
    Primary purpose Select and validate a product configuration Configure a product, calculate its commercial result and generate a quote
    Main users Customers, dealers, salespeople, engineers or product selectors Sales, sales engineering, application engineering, commercial operations and sometimes customers or dealers
    Core rules Options, dependencies, exclusions and technical constraints Configuration rules plus pricing, discount, approval and quoting rules
    Output Validated configuration, product summary or visual representation Price, quote, technical specification and potentially BOM, CAD or order data
    Pricing Optional; may show no price or a simple price Central capability, including prices, discounts, surcharges and margins
    Engineering data May use technical rules and calculations May connect configuration to calculations, CAD automation and engineering workflows
    Manufacturing integration Usually optional and dependent on the product Often designed to exchange data with ERP, PLM, CRM, CAD or manufacturing systems, although depth varies
    Commercial approvals Usually outside the main scope May include discount, margin, exception and approval workflows

    The boundary is not absolute. A sophisticated product configurator can include pricing, while a CPQ platform may provide only limited engineering or manufacturing functionality. The useful question is not what label a vendor uses, but which inputs, rules and outputs the implementation supports.

    Where the two concepts overlap

    Both systems normally contain a product model. A product model describes the features, options, components, parameters and relationships that define a product family.

    Both may support:

    • feature and option selection;
    • mandatory and optional components;
    • dependencies and exclusions;
    • compatibility rules;
    • dimension and capacity limits;
    • configuration validation;
    • guided questions for nontechnical users;
    • technical specifications or a configuration summary;
    • visualization of the selected product.

    The difference is what happens after a valid configuration is found. A product configurator may stop at the validated selection. A CPQ configurator generally passes that result into pricing and quoting services and may continue into order, engineering or production processes.

    How configuration rules differ from pricing rules

    Configuration rules answer: Can this product be built or sold in this combination? Pricing rules answer: What should this valid combination cost or sell for?

    Configuration rules

    Configuration rules describe product logic. Examples include:

    • A 15 kW motor requires a larger frame than a 7.5 kW motor.
    • A high-temperature seal is required when the operating temperature exceeds a defined threshold.
    • A particular valve body material is unavailable with a selected pressure class.
    • A truck body length requires a compatible chassis wheelbase.
    • An electrical enclosure must meet a specified ingress-protection rating for an outdoor application.

    These rules protect technical validity, safety, manufacturability and serviceability. They may be implemented as simple if-then rules, compatibility matrices, calculations or constraint-solving logic.

    Pricing rules

    Pricing rules convert the valid configuration into a commercial result. Examples include:

    • adding the price of a stainless-steel casing;
    • applying a regional price list;
    • calculating a surcharge for a special coating;
    • applying a dealer discount within an approved range;
    • requiring approval when a quote falls below a target margin;
    • calculating freight based on weight, dimensions or destination.

    A product configurator can contain the first group without containing the second. A CPQ configurator is expected to connect both groups, although the sophistication of the pricing engine varies by product and implementation.

    Manufacturing example: configuring an industrial pump

    Consider a manufacturer selling centrifugal pumps for water treatment and industrial process applications.

    A basic product configurator might guide a user through pump family, flow range, pressure, impeller size, motor, material and connection options. It would reject an invalid combination, such as a motor that cannot deliver the required duty point or a pressure class that is incompatible with the selected casing.

    A CPQ configurator would use the same product logic but add commercial and operational outputs:

    1. The user enters the required flow, pressure, fluid temperature and material requirements.
    2. An engineering calculation identifies a suitable pump family and motor range.
    3. The rules engine filters incompatible impellers, seals, materials and accessories.
    4. The system selects or derives components for the configured assembly.
    5. The pricing engine calculates the equipment price, options, services and freight assumptions.
    6. The quote includes a technical description, performance information, exclusions, delivery assumptions and commercial terms.
    7. A configurable BOM or engineering BOM (EBOM) may be generated for review.
    8. After order acceptance, the configuration may be transferred to an enterprise resource planning (ERP) system or product lifecycle management (PLM) system for order processing and engineering control.

    If the pump requires a new casing design, a nonstandard seal arrangement or a customer-specific mounting interface, the transaction may become engineer-to-order (ETO). In that case, the CPQ configurator can capture requirements and create a controlled engineering request, but it may not be able to complete the design automatically.

    How a CPQ configurator fits into the manufacturing architecture

    A CPQ configurator is usually an application layer between product and commercial data and the systems that manage customers, products and operations.

    Product and engineering data

    Product data may originate in PLM or product data management (PDM) systems, engineering databases, ERP item masters, CAD models or maintained CPQ product models. PLM manages product information and lifecycle processes; PDM generally focuses more narrowly on engineering files, revisions and relationships.

    The CPQ model must represent sellable options and rules at a level that sales and engineering can maintain. It may not be a direct copy of the engineering structure. A customer-facing option such as “corrosion-resistant package” may map to several engineering components, documents and operations.

    CRM and sales channels

    Customer relationship management (CRM) systems manage accounts, opportunities and customer interactions. A CPQ configurator may be launched from CRM or embedded in a sales process. The configuration should be associated with the opportunity, customer, salesperson, dealer or project.

    ERP and production systems

    Enterprise resource planning (ERP) systems manage transactions such as orders, inventory, purchasing, manufacturing and financial records. A CPQ configurator may send a quote or order with item identifiers, quantities, prices, configuration attributes and BOM data to ERP.

    A manufacturing BOM, or MBOM, represents how a product is assembled or produced. It may differ from an EBOM, which represents the engineering design structure. A CPQ implementation must define whether it creates an EBOM, an MBOM, a configurable BOM, or only a commercial list of selected components.

    CAD and automation

    Computer-aided design (CAD) automation can use configuration parameters to generate a product-specific model, drawing or document. This is more advanced than displaying a product image. It requires stable parametric models, controlled templates, mapping between configuration attributes and CAD parameters, and a process for handling exceptions.

    Some CPQ configurators have CAD automation capabilities; others integrate with separate engineering automation tools; many do not generate CAD at all. This distinction is important when evaluating a platform for machinery or ETO products.

    Types of product configuration inside CPQ

    Rules-based configuration

    Rules-based configuration uses explicit logic such as if-then statements, option dependencies, exclusions and formulas. It works well when product logic is known and can be maintained as business rules.

    Constraint-based configuration

    Constraint-based configuration represents permitted relationships and lets a solver find or validate combinations that satisfy multiple constraints. This can be useful for products with many interacting dimensions, capacities, materials and performance requirements.

    Guided selling

    Guided selling asks questions in business or application language and recommends suitable product options. It is useful when a dealer or salesperson understands the customer problem but not every technical attribute. Guided selling should not be confused with a complete engineering configurator: recommendations still need to be checked against authoritative product rules.

    A manufacturing CPQ implementation may use all three approaches. Guided questions capture requirements, a rules engine validates the selection and calculations determine technical values. The resulting configuration then drives price and downstream outputs.

    When a product configurator may be enough

    A standalone product configurator may be appropriate when the main requirement is product selection rather than transaction automation. Examples include:

    • helping customers select a standard motor or pump variant;
    • showing compatible accessories for an existing product;
    • providing a dealer-facing technical selection tool;
    • displaying a visual configuration for a modular vehicle;
    • validating options before a salesperson enters an order elsewhere;
    • supporting engineering or service teams with product selection.

    It may also be suitable when pricing is fixed and managed in another system, or when the company wants to separate configuration logic from commercial quoting.

    When a CPQ configurator is more appropriate

    A CPQ configurator is usually more suitable when configuration and commercial decisions are tightly connected. Typical indicators include:

    • salespeople currently calculate prices manually in spreadsheets;
    • different teams use different product and discount rules;
    • quotes contain invalid options or omit required components;
    • engineering reviews a large number of routine configurations;
    • configured options affect cost, margin, delivery or freight;
    • the company needs formal quote approvals;
    • dealers need controlled pricing and configuration access;
    • the quote must include technical specifications and a consistent BOM;
    • the configuration must be transferred to CRM, ERP, PLM, CAD or manufacturing systems.

    The business case is strongest when errors or delays occur at the boundary between sales, engineering and production. A CPQ configurator can encode repeatable product logic so that routine configurations do not require the same manual intervention as genuinely novel designs.

    Important limitations and risks

    Neither term guarantees a particular technical capability. A system called a CPQ configurator may provide only basic option selection and pricing. A product configurator may support complex engineering constraints but have no quote workflow.

    Manufacturers should examine the following limitations:

    • Product model complexity: large rule sets can become difficult to understand, test and change.
    • Data ownership: product, price, cost and engineering data may be maintained in different systems with conflicting revisions.
    • Rule maintenance: rules must change when components, suppliers, standards, designs and manufacturing methods change.
    • Exception handling: unusual customer requirements may require ETO processes rather than forced configuration.
    • BOM semantics: a commercial configuration does not automatically equal an engineering or manufacturing BOM.
    • Integration boundaries: sending data to ERP or PLM requires agreed identifiers, revisions, units, statuses and error handling.
    • CAD automation effort: automated drawings and models need controlled templates and engineering governance.
    • Pricing governance: discounts, cost updates, currencies and regional price lists require ownership and release control.
    • User experience: a technically correct configurator can still fail if questions are unclear or require engineering knowledge that salespeople do not have.

    Implementation considerations for manufacturers

    Define the required output first

    Start by documenting what the configuration must produce. Possible outputs include a validated product selection, technical specification, price, quote, EBOM, MBOM, CAD model, drawing, work request, sales order or production package. Do not treat these outputs as equivalent.

    Choose the right product scope

    Begin with a product family where rules are reasonably stable and quoting effort is measurable. A focused pump, valve, enclosure or machine module may be a better starting point than the entire portfolio.

    Separate configuration, pricing and engineering logic

    These forms of logic interact but have different owners. Product management may own commercial options, engineering may own technical constraints, finance may govern margin rules and manufacturing may own assembly structures. The implementation should make these responsibilities visible rather than placing all logic in unstructured code.

    Establish source-system responsibilities

    Decide which system is authoritative for each data type:

    • product revisions and engineering documents in PLM or PDM;
    • items, inventory and order transactions in ERP;
    • customer and opportunity data in CRM;
    • pricing and discount policies in CPQ or an approved commercial system;
    • CAD templates and parameters in the engineering environment.

    In some businesses, CPQ becomes the operational source for the sellable product model while PLM remains the source for engineering-controlled data. That arrangement can work, but the synchronization and approval process must be explicit.

    Test combinations and revisions

    Testing should include valid and invalid combinations, boundary dimensions, obsolete components, regional pricing, discounts, units of measure, revision changes and integration failures. Manufacturers should also test whether an old quote remains reproducible after product or price rules change.

    Plan for CTO, MTO and ETO

    Configure-to-order (CTO) uses predefined options and standard modules. Make-to-order (MTO) produces an item after the order but may use a relatively stable design. Assemble-to-order (ATO) combines stocked modules after the order. Engineer-to-order (ETO) requires new or substantially modified engineering work.

    A CPQ configurator is often most predictable for CTO and some MTO or ATO scenarios. It can support ETO by capturing requirements, estimating commercial impact and initiating engineering work, but it should not pretend that every ETO design can be reduced to a fixed option list.

    Questions to ask when evaluating a CPQ configurator

    • Can it represent dimensions, formulas, capacities and engineering constraints?
    • Can non-developers maintain product rules safely?
    • How are configuration rules tested and versioned?
    • Can the system distinguish a sellable option from its underlying components?
    • Does it calculate cost, price, margin, freight and lead-time effects?
    • What exactly does “BOM generation” mean in the product documentation?
    • Can it produce an EBOM, MBOM, configurable BOM or only a quote line list?
    • Does it integrate with the company’s ERP, CRM, PLM, PDM and CAD systems?
    • Can it create a controlled engineering request for exceptions?
    • How are product, price and engineering revisions handled?
    • Can dealers or distributors access a restricted product model and price list?
    • Are APIs available for ecommerce, portals or custom applications?
    • Can the implementation support multiple plants, regions, currencies and units?
    • How are approvals and overrides recorded?
    • What skills are required to maintain the model after go-live?

    Conclusion

    A product configurator is primarily concerned with selecting and validating a product. A CPQ configurator includes that capability but extends it into price calculation and quote creation. In manufacturing, the distinction becomes more significant because a configured product may also need technical calculations, a BOM, CAD outputs, engineering review and integration with ERP or PLM.

    There is no universal boundary between the two categories. Some product configurators include commercial features, and some CPQ systems provide only limited manufacturing automation. The correct evaluation method is to map the required product rules, pricing logic, engineering outputs and system handoffs, then verify which capabilities are native, integrated or absent.

    For a broader explanation of manufacturing CPQ architecture and use cases, see the manufacturing CPQ guide. Related topics include product configuration and rules engines, CAD and engineering automation, BOM generation, pricing and quoting and CPQ integrations.

    Frequently asked questions

    Is a CPQ configurator the same as a product configurator?

    No. A CPQ configurator includes product configuration but also connects the result to pricing and quoting. A product configurator may stop after validating the selected product.

    Can a product configurator calculate prices?

    Some can. Pricing is an optional capability in a product configurator, while it is a central part of the CPQ model. Buyers should verify whether pricing supports discounts, surcharges, currencies, costs and margin rules.

    Does every CPQ configurator generate a BOM?

    No. BOM generation varies considerably. Some systems create a configurable BOM or quote component list, while others can produce an engineering or manufacturing BOM through an integration.

    What is the main benefit of a CPQ configurator for manufacturers?

    It connects a valid product configuration with an accurate commercial result and, where supported, structured engineering or production data. This reduces manual translation between sales, engineering and operations.

    Can a product configurator support complex machinery?

    Yes, if it supports the required rules, calculations and data structures. A simple option selector may be insufficient for machinery with interacting dimensions, performance requirements and component constraints.

    What is guided selling?

    Guided selling asks business-oriented questions and recommends suitable products or options. It can make a technical product configurator easier for salespeople and customers, but recommendations still need authoritative validation rules.

    What is the difference between configuration rules and pricing rules?

    Configuration rules determine whether a combination is technically or commercially valid. Pricing rules determine what that valid combination costs or should be sold for.

    Can a CPQ configurator replace engineering?

    Usually not. It can automate repeatable engineering decisions and route exceptions, but novel designs, safety reviews and nonstandard requirements may still require engineers.

    Is CAD automation included in every CPQ configurator?

    No. CAD automation is an advanced capability that may be native, delivered through a separate tool or unavailable. It requires parametric CAD models, templates, mappings and engineering governance.

    Can a CPQ configurator support engineer-to-order products?

    It can support parts of an ETO process, such as requirements capture, preliminary pricing and engineering-work requests. It may not automatically design every custom product.

    What systems does a CPQ configurator connect to?

    Depending on the implementation, it may connect to CRM, ERP, PLM, PDM, CAD, product information management (PIM), manufacturing execution systems (MES) and ecommerce channels. The specific integration depth must be verified.

    Should product rules be stored in ERP or CPQ?

    There is no universal answer. ERP is normally authoritative for transactions and inventory, while CPQ often manages the sellable configuration model. Responsibilities and synchronization should be defined during architecture design.

    What is an EBOM?

    An EBOM, or engineering bill of material, describes the product from an engineering design perspective. It may differ from an MBOM, which describes how the product is assembled or manufactured.

    What is a configurable BOM?

    A configurable BOM is a structure containing possible components and selection logic. A particular configuration resolves that structure into the components required for the selected product.

    When is a standalone product configurator preferable?

    It may be preferable when the main need is technical selection, compatibility validation or visualization, and pricing and order processing remain in another system.

    When should a manufacturer choose CPQ instead?

    CPQ is more appropriate when configuration directly affects price, margin, quote approvals, technical documents, BOMs, order data or the handoff from sales to engineering and production.

    Semantic map

    Entity Relationship Related entity
    CPQ configurator configures and prices configurable product
    Product configurator validates product options and combinations
    Configuration rules prevent invalid product combinations
    Pricing rules calculate price, discount and margin
    Configured product can generate configuration summary or BOM
    EBOM represents engineering product structure
    MBOM represents manufacturing assembly structure
    CPQ exchanges commercial data with ERP and CRM
    CPQ may consume engineering data from PLM, PDM and CAD
    CAD automation generates configuration-specific models and drawings
    CTO uses predefined product options and modules
    ETO requires engineering work for nonstandard requirements
    Guided selling translates customer requirements into product recommendations
  • CPQ (Configure, Price, Quote)

    CPQ (Configure, Price, Quote) is software that guides the selection of valid product options, calculates configuration-based prices and costs, and generates accurate quotations. In manufacturing, CPQ can also connect the commercial configuration to engineering and production data such as bills of materials, drawings and enterprise resource planning systems.

    What CPQ means in manufacturing

    Manufacturing CPQ is designed for products that vary by dimensions, materials, capacities, performance requirements, components or production processes. It is more than a sales quoting tool: depending on the implementation, it can contain product rules, engineering calculations, configurable bills of materials and integrations with design and production systems.

    The three parts of CPQ are closely related but distinct:

    • Configure: select options and values while applying dependencies, exclusions, constraints and engineering rules.
    • Price: calculate a price or cost from the selected configuration, quantities, customer terms, currency, freight and margin requirements.
    • Quote: present the result in a commercial quotation containing prices, specifications, delivery information, terms and sometimes technical drawings or visualizations.

    How CPQ works

    A CPQ process normally starts with a product model. The model contains features, options, attributes, components, rules and pricing data. A user may configure the product through guided questions, a rules-based interface, a constraint solver, a dealer portal or a business-to-business ecommerce channel.

    When the user selects an option, the CPQ system validates the configuration. For example, a pump model may allow a particular impeller only with certain materials and motor sizes. The system can prevent incompatible combinations, calculate required dimensions and identify information that is still missing.

    After validation, the system calculates price and cost and generates a quote. Some implementations also create a configurable bill of materials (BOM), technical specification, engineering request or order payload for downstream systems. These capabilities are not present in every CPQ product and should be verified during evaluation.

    Industrial example

    Consider a manufacturer selling packaged pumping systems. A sales engineer selects flow rate, pressure, pump material, motor voltage, control panel, pipe connections and enclosure type. Rules may restrict the available impeller and motor combinations, while an engineering calculation determines the required pump size. CPQ can then calculate material and labor costs, apply customer-specific pricing, produce a quotation and generate a configuration-specific BOM.

    If the system connects to computer-aided design (CAD), it may also request or generate a parametric model and drawing. If it connects to enterprise resource planning (ERP), the approved configuration may be transferred for order processing, inventory checks or manufacturing planning. A product lifecycle management (PLM) or product data management (PDM) system may provide approved product structures and revisions.

    CPQ and related manufacturing systems

    System or concept Typical relationship with CPQ
    CRM Provides customer, opportunity and account context; it is not normally the authoritative source for engineering product structures.
    ERP Receives orders, prices or configured items and supports inventory, planning, purchasing and financial processes.
    PLM or PDM Manages approved product data, revisions, engineering structures and lifecycle information.
    CAD May receive configuration parameters or generate product-specific models and drawings.
    MES May receive production instructions or configuration data for execution on the shop floor.

    A manufacturing CPQ implementation may support configure-to-order (CTO), where known options produce a repeatable product, or engineer-to-order (ETO), where the configuration triggers additional engineering work. Make-to-order (MTO) describes production started in response to an order, while assemble-to-order (ATO) uses stocked modules assembled after ordering. These terms describe operating models, not interchangeable CPQ features.

    Benefits and limitations

    • Reduces invalid configurations by enforcing product and engineering rules.
    • Improves pricing consistency for options, materials, services and customer-specific terms.
    • Reduces manual re-entry between sales, engineering and operations.
    • Can shorten the path from an approved quote to a manufacturing-ready order.
    • Provides a controlled way to expose complex products to dealers or customers.

    CPQ does not automatically fix poor product data or unclear ownership of rules. Implementation can require substantial work to rationalize options, map configurable BOMs, define pricing logic, migrate legacy knowledge and integrate ERP, PLM, CAD or CRM systems. Large product models also need testing, version control, performance monitoring and governance. Buyers should confirm whether a platform supports the required depth of constraints, calculations, BOM handling and engineering automation rather than assuming that every CPQ system does.

    Related manufacturing CPQ concepts

    Product configuration defines the selected product and its valid structure. A BOM describes the components required to build it. An engineering BOM (EBOM) represents an engineering view, while a manufacturing BOM (MBOM) represents how production organizes materials and operations. CPQ may generate or request one of these structures, but it is not automatically a replacement for PLM or ERP.

    For a broader overview, see the manufacturing CPQ guide. Related subjects include product configuration and rules engines, CAD and engineering automation, BOM generation, costing and quoting, configure-to-order and engineer-to-order workflows, and CPQ integrations with ERP, PLM, CRM and CAD.

    FAQ

    What does CPQ stand for?

    CPQ stands for Configure, Price, Quote.

    What is CPQ software used for?

    It is used to create valid product configurations, calculate prices and costs, and produce customer quotations.

    Is CPQ only a sales tool?

    No. Manufacturing CPQ can connect sales configuration with engineering, BOM creation, CAD automation and production systems, although the depth varies by platform.

    How is manufacturing CPQ different from generic sales CPQ?

    Manufacturing CPQ usually needs product constraints, technical calculations, configurable structures and downstream engineering or production data in addition to commercial quoting.

    What is a product model in CPQ?

    A product model is the structured definition of features, options, attributes, components, rules and pricing used to configure a product.

    What are CPQ configuration rules?

    They are conditions that allow, require, restrict or exclude options. For example, a voltage selection may limit compatible motors and control panels.

    What is guided selling?

    Guided selling asks users business or application questions and recommends suitable products or options. It may be simpler than a full engineering constraint model.

    Can CPQ generate a BOM?

    Some manufacturing CPQ systems can generate a configurable BOM or transfer configuration data for BOM creation. This capability must be verified for the required EBOM or MBOM process.

    Can CPQ replace ERP?

    No. CPQ generally handles configuration, pricing and quoting, while ERP manages broader processes such as orders, inventory, purchasing, planning and finance.

    Can CPQ replace PLM?

    No. Product lifecycle management (PLM) manages product information, revisions and lifecycle processes. CPQ may consume approved PLM data.

    Does CPQ integrate with CAD?

    Some platforms integrate with CAD for parameter exchange, model generation or drawings. CAD integration is not universal and requires technical validation.

    Does CPQ support engineer-to-order products?

    Some implementations support ETO by collecting engineering requirements and initiating design work. CPQ may not fully automate novel engineering designs.

    What data does CPQ require?

    Typical data includes product options, rules, dimensions, component relationships, costs, prices, revisions, lead times and customer or channel-specific commercial policies.

    Who owns CPQ rules?

    Ownership should be agreed between product management, engineering, sales operations and IT. Engineering rules normally require technical approval, while pricing rules may require commercial approval.

    What is the main implementation challenge?

    The central challenge is converting informal product and pricing knowledge into maintained, testable models while keeping connected systems synchronized.

    How should a company evaluate CPQ?

    Evaluate product-model complexity, constraint depth, BOM and CAD requirements, pricing, ETO support, integrations, governance, performance and the effort required to maintain the model.

    Semantic map

    • CPQ → configures → configurable industrial products
    • Product configuration → applies → configuration rules
    • Configuration rules → prevent → invalid product combinations
    • Configured product → determines → configuration-based price and cost
    • CPQ → generates → customer quotation
    • Configured product → can generate → configurable BOM
    • EBOM → represents → engineering product structure
    • MBOM → represents → manufacturing product structure
    • CPQ → exchanges data with → ERP
    • CPQ → consumes approved product data from → PLM or PDM
    • CAD integration → can generate → product-specific models and drawings
    • ETO → requires → additional engineering work