CPQ Guide

Tag: sales engineering

  • 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

  • What Is CPQ Software? A Manufacturing-Focused Guide

    CPQ software means Configure, Price, Quote software. In manufacturing, it is used to select and validate product options, apply technical and commercial rules, calculate costs and prices, generate customer quotes, and—when supported—produce manufacturing data such as bills of material, drawings or configured product records.

    Manufacturing CPQ is more than a tool for adding discounts to a sales proposal. It can act as a controlled translation layer between a customer requirement and the engineering, commercial and production systems needed to fulfill it. For example, a CPQ application might help configure an industrial pump by checking flow, pressure, fluid, materials, motor size, seal type and certification requirements before calculating the price and creating a quote.

    The exact scope varies considerably between products. Some CPQ platforms focus mainly on guided selling, configuration and quoting. Others support engineering calculations, configurable bills of material, computer-aided design (CAD) automation, 2D or 3D visualization, and integration with enterprise resource planning (ERP), product lifecycle management (PLM) or manufacturing execution systems (MES). Buyers should verify each capability rather than assume that every CPQ product provides the full manufacturing stack.

    What does CPQ stand for?

    CPQ stands for Configure, Price, Quote:

    • Configure: select valid product options and define technical requirements.
    • Price: calculate costs, list prices, customer-specific prices, discounts, freight, taxes or other commercial values.
    • Quote: present the configured product, price, assumptions, delivery information and commercial terms in a formal quotation.

    In a simple sales environment, these steps may be limited to selecting options and applying a price list. In a manufacturing environment, configuration can include dimensional calculations, capacity checks, component selection, material compatibility, electrical load validation, safety requirements and the creation of downstream product data.

    A useful manufacturing definition is:

    Manufacturing CPQ is software that controls the configuration and commercial definition of complex products, validates technical requirements, calculates a price and produces a quote or production-ready handoff according to the capabilities of the implementation.

    For a broader overview, see the manufacturing CPQ guide.

    How manufacturing CPQ works

    A CPQ implementation normally combines a product model, rules, calculations, pricing data, document templates and integrations. The user may be a salesperson, sales engineer, distributor, dealer, customer or internal application engineer. The system guides that user through a controlled configuration process.

    1. The user defines requirements

    The process starts with a customer requirement rather than an internal part number. A user might specify pump flow and pressure, conveyor length and load, an air-handling unit capacity, a vehicle body configuration or the dimensions of a machine enclosure.

    Requirements can be entered as selections, measurements, free text, imported data or answers to guided questions. A well-designed model asks only relevant questions. For example, a pump configuration may reveal seal and impeller options only after the user selects the fluid and operating temperature.

    2. The product model presents valid choices

    The product model represents the product structure, options, attributes, dependencies and rules. It may contain models, modules, features, components, accessories, services and replacement choices.

    For example, a configurable electrical control panel model may include:

    • enclosure size and material;
    • incoming voltage and frequency;
    • motor starter or variable-frequency drive selection;
    • number and rating of motor circuits;
    • operator interface and communication protocol;
    • environmental protection rating;
    • certification and documentation requirements.

    The model should expose valid commercial choices without requiring the user to understand every internal component number. This is one difference between a product model and a static online catalog.

    3. Rules validate the configuration

    Configuration rules determine which combinations are allowed, required, recommended or prohibited. A rule might state that a particular motor is available only above a certain voltage, that a material is unsuitable for a specified chemical, or that a larger frame requires a different baseplate.

    Common rule types include:

    • Compatibility rules: prevent incompatible options from being selected together.
    • Dependency rules: make one option require another option.
    • Exclusion rules: prevent a combination that cannot be manufactured, certified or sold.
    • Conditional visibility rules: display questions or options only when they are relevant.
    • Validation rules: check ranges, units, capacities, clearances or required information.
    • Selection rules: recommend or automatically select components based on requirements.

    Manufacturing CPQ may use rules-based configuration, constraint-based configuration, guided selling or a combination of these approaches. Rules-based configuration explicitly evaluates conditions and actions. Constraint-based configuration solves for permissible values within technical limits. Guided selling simplifies the user experience by asking requirement-oriented questions and steering the user toward appropriate products. These approaches overlap, but they are not interchangeable.

    4. Engineering calculations refine the product

    Some products cannot be configured accurately using option dependencies alone. The system may need to calculate dimensions, capacity, performance or component sizes.

    Examples include:

    • selecting a pump impeller and motor from flow, head and efficiency requirements;
    • calculating the number of conveyor sections from length and transfer requirements;
    • sizing a heat exchanger from flow, temperature and duty values;
    • choosing structural members from span, load and deflection constraints;
    • calculating cable, breaker or enclosure requirements for an electrical assembly.

    These calculations may be native to the CPQ platform, implemented through an external engineering service or handled by an integrated design application. A CPQ buyer should establish whether the required calculation method is supported, how units and rounding are handled, and how engineering formulas are tested and governed.

    5. The system calculates cost and price

    Pricing is separate from configuration. Configuration determines what the product is; pricing determines what the customer should be charged.

    A manufacturing pricing model can include component costs, labor, purchased items, overhead assumptions, tooling, freight, installation, services, currency, regional price lists, customer agreements, quantity breaks, margins and approval thresholds. Some implementations calculate estimated manufacturing cost before applying a margin. Others use a maintained selling price for each option or a combination of both.

    Pricing logic may also depend on technical attributes. A larger machine may require additional labor or shipping. A material change may affect both component cost and manufacturing process. A custom engineering requirement may add a non-recurring engineering charge rather than a standard option price.

    6. The system generates the quote

    The quote typically includes a description of the configured product, quantities, prices, discounts, lead-time assumptions, terms, exclusions and validity dates. It may also include images, technical specifications, performance curves, configuration summaries and customer-specific language.

    Quote generation is not the same as proposal design. A document can look professional while still containing an invalid configuration. Manufacturing CPQ should generate the commercial document from the validated configuration and the approved price result, reducing the risk that the proposal and the intended product diverge.

    7. The configuration is handed to downstream systems

    After approval, the configured result may be sent to an ERP system for order processing, a PLM system for product and revision control, a product data management (PDM) system for design files, a CAD system for design automation, or a manufacturing execution system for production execution.

    The handoff can include a configured product identifier, options, attributes, quantities, prices, a bill of material, routings, drawings, files, customer requirements or engineering tasks. The exact output depends on the product, the CPQ platform and the surrounding architecture.

    What data does manufacturing CPQ require?

    A CPQ project depends on more than a price list. Its data foundation usually includes the following.

    Data area Typical content Why it matters
    Product structure Models, modules, options, components and accessories Defines what can be configured
    Technical attributes Dimensions, capacities, materials, ratings and performance values Supports validation and calculations
    Configuration rules Dependencies, exclusions, constraints and required selections Prevents invalid or incomplete products
    Cost data Material, labor, purchased-part and service costs Supports margin and profitability decisions
    Pricing data Price lists, discounts, currencies and commercial policies Produces a consistent customer price
    Manufacturing data Parts, quantities, revisions, routings or work instructions Supports order and production handoff
    Document data Templates, specifications, drawings and certificates Creates a complete customer or internal package

    Data ownership is often distributed. Engineering may own technical rules, product management may own options, finance may own pricing policies, manufacturing may own routings and IT may own integration services. A governance model is required to resolve conflicts and control changes.

    CPQ, configurable products and manufacturing outputs

    Configurable BOMs

    A bill of material (BOM) lists the components required to build a product. A configurable BOM contains alternative, conditional or variable components that depend on the selected configuration.

    For example, a machine may use one motor for a standard voltage and another for a high-voltage option. A CPQ system can identify the correct component when the electrical requirement is selected, provided the relevant product and BOM logic has been modeled.

    EBOM and MBOM

    An engineering bill of material (EBOM) describes a product from an engineering or design perspective. A manufacturing bill of material (MBOM) describes how that product is assembled or produced, including manufacturing-specific groupings, consumables, packaging or process requirements.

    CPQ may generate or select an EBOM, an MBOM, a commercial BOM, or an intermediate configuration structure. It should not be assumed that a CPQ-generated BOM is automatically suitable for production. Transformation, approval, revision control and ERP or manufacturing-system ownership may still be required.

    CAD and engineering automation

    CAD automation connects configuration inputs to parametric models, assemblies, drawings or other design files. A configured machine might produce a dimensioned layout, a vehicle configuration might generate a body variation, or a tank selection might produce a product-specific drawing.

    CAD automation is an advanced capability, not a mandatory component of every CPQ system. Where it is required, evaluate supported CAD platforms, template management, model regeneration, drawing rules, file naming, revision control, processing time and failure handling. The CAD and engineering automation guide covers these considerations in more detail.

    Where CPQ fits in the manufacturing technology stack

    CPQ usually sits between customer-facing channels and enterprise product, commercial and manufacturing systems. It should complement—not replace—systems with different responsibilities.

    System Primary responsibility Typical CPQ relationship
    CRM Customer, opportunity and sales activity management Provides opportunity context and receives quote status or values
    ERP Orders, inventory, purchasing, finance and core enterprise transactions Receives approved configuration, order and pricing data
    PLM Product definition, lifecycle, revisions and engineering governance Provides controlled product data or receives configured product records
    PDM CAD files, documents and design data management Stores or supplies controlled engineering files
    CAD Geometry, assemblies, drawings and design models May be driven by configuration inputs
    PIM Product information for catalogs and commerce channels May supply descriptions, attributes and media
    MES Shop-floor execution, production tracking and quality processes May receive production-relevant configuration data

    These systems may exchange data through APIs, middleware, files, events or direct connectors. Integration design should identify the system of record for each data object. For example, CPQ may calculate a quote price, ERP may create the sales order, PLM may control the approved product definition and MES may control production execution.

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

    A manufacturing CPQ example: configuring an industrial pump

    Consider a manufacturer selling centrifugal pumps for industrial applications. A sales engineer enters the required flow rate, discharge pressure, fluid type, temperature, installation arrangement, power supply and certification requirements.

    1. The configuration model identifies appropriate pump families.
    2. A performance calculation checks whether the selected pump can meet the duty point.
    3. Material rules exclude an impeller or seal material that is incompatible with the fluid.
    4. The system selects a motor and frame based on power, voltage and regional requirements.
    5. Accessory rules add a baseplate, coupling guard, instrumentation or documentation package.
    6. The cost model calculates material, purchased components and engineering effort.
    7. The pricing model applies the relevant customer price list, margin and discount authority.
    8. The quote includes performance information, scope, delivery assumptions and price.
    9. If supported, a configurable BOM, product record, drawing or ERP order structure is generated.

    This example shows why manufacturing CPQ cannot be evaluated only by asking whether it can create a PDF quote. The important questions include whether the model can represent the product, whether the rules are maintainable, whether calculations are reliable, whether the selected components are traceable and whether the result can be used by engineering and production.

    Manufacturing workflows supported by CPQ

    Configure-to-order

    Configure-to-order (CTO) uses a predefined product architecture with controlled options. The product is configured from known modules and manufactured or assembled after the order. CTO is often a strong fit for CPQ because the possible combinations can be modeled in advance.

    Engineer-to-order

    Engineer-to-order (ETO) requires significant engineering work for an individual order. CPQ can capture requirements, apply preliminary rules, estimate price and create an engineering work package, but it may not fully automate design or production. An ETO workflow should make the boundary between automated configuration and engineering review explicit.

    Make-to-order and assemble-to-order

    Make-to-order (MTO) products are produced after an order rather than from finished-goods inventory. Assemble-to-order (ATO) products are assembled from stocked or planned modules after order entry. CPQ may support either workflow by producing a valid configuration and the required component or assembly information.

    The manufacturing workflows guide explains how CPQ fits into CTO, ETO, MTO and ATO processes.

    Benefits of CPQ for manufacturers

    • Fewer configuration errors: rules prevent or flag invalid combinations before order entry.
    • Shorter quote preparation: reusable models and automated calculations reduce manual effort.
    • More consistent pricing: common price logic, approval policies and discount controls reduce spreadsheet variation.
    • Better sales-engineering capacity: experts can focus on exceptions and high-value technical work rather than repetitive checks.
    • Improved handoff quality: validated options and requirements can accompany the order or engineering request.
    • Faster product knowledge distribution: dealers and sales teams can use approved rules instead of relying on informal expertise.
    • Traceability: the selected options, rule outcomes, prices and revisions can be recorded with the quote.
    • Better visibility into product complexity: configuration data can reveal frequent exceptions, costly options and unprofitable combinations.

    Benefits depend on model quality, data accuracy, user adoption and integration. Implementing a CPQ interface without maintaining its product rules will not solve inaccurate product data.

    Limitations and risks

    CPQ is not a substitute for disciplined product management or engineering governance. Common limitations include:

    • Model complexity: large product portfolios can create difficult-to-maintain rule networks.
    • Data ownership problems: conflicting part numbers, prices, revisions and option definitions can undermine trust.
    • Incomplete engineering coverage: a sales configuration may not capture every design or manufacturing requirement.
    • Integration dependency: stale ERP, PLM or CAD data can produce incorrect results even when the CPQ logic is sound.
    • Exception handling: ETO products and unusual customer requirements still need human review.
    • Performance concerns: complex calculations, CAD generation or large product models may affect response times.
    • Governance burden: every new option, component, rule and price change requires testing and controlled release.
    • False automation expectations: generating a quote does not automatically mean that an order is ready for production.

    How to evaluate CPQ software for manufacturing

    Evaluation should begin with representative products and real configuration scenarios rather than generic feature checklists. Test standard configurations, invalid combinations, boundary values, engineering exceptions, customer-specific pricing and downstream outputs.

    Evaluation area Questions to ask
    Configuration depth Can the system model modules, attributes, dependencies, constraints and dimensions?
    Rule maintenance Who can create, test, approve and release rules? Are dependencies understandable?
    Engineering calculations Can formulas, units, tolerances and external calculation services be supported?
    BOM output Does it generate a configurable BOM, EBOM, MBOM or only a commercial summary?
    CAD automation Can it drive the required CAD templates and produce controlled files or drawings?
    Pricing and costing Can it handle cost rollups, margins, currencies, discounts, approvals and customer agreements?
    Workflow Does it support CTO, ETO, MTO, ATO, dealer and sales-engineering processes?
    Integration Are APIs, events, connectors and ownership boundaries suitable for the existing architecture?
    Governance Are versioning, testing, audit history and release management available?
    Scalability Can the system handle the number of products, rules, users, regions and transactions required?

    Documented vendor capabilities should be separated from capabilities that require customization, partner services or a separate application. The manufacturing CPQ comparison and selection resources can help structure an evaluation.

    Implementing CPQ in a manufacturing business

    A practical implementation usually starts with a bounded product family and a measurable workflow problem. Choose a product with meaningful configuration complexity but sufficiently reliable source data.

    1. Define the business case: identify quote delays, configuration errors, engineering workload, margin leakage or poor handoffs.
    2. Map the current workflow: document how requirements, options, prices, approvals, BOMs and orders move between teams.
    3. Inventory product data: reconcile part numbers, options, revisions, costs, prices, drawings and existing spreadsheets.
    4. Design the product model: separate customer-facing choices from internal components and engineering attributes.
    5. Capture and test rules: identify dependencies, exclusions, calculations, limits and unresolved exceptions.
    6. Define system ownership: decide which system owns product definitions, prices, customers, orders, CAD files and production data.
    7. Build integrations deliberately: specify data contracts, error handling, synchronization frequency and security.
    8. Test realistic scenarios: include valid, invalid, incomplete, boundary and exceptional configurations.
    9. Train users and administrators: explain both the workflow and the reason behind important rules.
    10. Establish governance: control changes to products, formulas, pricing, documents, integrations and releases.

    Implementation planning should include migration, testing, deployment, adoption, maintenance and performance measurement. The CPQ implementation guide provides a framework for these activities.

    Is CPQ software the same as a product configurator?

    No. A product configurator focuses on defining a valid product from available options and requirements. CPQ includes configuration but also covers pricing and quoting. A manufacturing product configurator may produce a technical configuration without calculating a customer price, while a sales CPQ application may calculate a price without generating a production-ready BOM or CAD file.

    Some platforms combine these functions in one application. Others integrate a configurator, pricing engine, document generator and engineering tools. The distinction matters when defining requirements and comparing software.

    Semantic map

    The main entities and relationships in this guide are:

    • CPQ software connects customer requirements with product configuration, pricing and quoting.
    • Product models represent configurable products, options, attributes and components.
    • Configuration rules prevent invalid combinations and identify required selections.
    • Engineering calculations translate requirements into technical selections or dimensions.
    • Configured products can generate commercial summaries, BOMs, drawings or engineering tasks.
    • Pricing models convert configuration data, costs and commercial policies into a quote price.
    • CRM manages customer and opportunity context, while ERP manages orders and enterprise transactions.
    • PLM and PDM manage product revisions and engineering files rather than replacing CPQ.
    • CAD automation can generate product-specific geometry and drawings from configuration inputs.
    • CTO, ETO, MTO and ATO define different relationships between configuration, engineering and production.

    Frequently asked questions

    1. What is CPQ software in manufacturing?

    It is software that helps configure complex products, validate technical and commercial rules, calculate prices and generate quotes. Depending on the implementation, it may also generate BOMs, drawings, engineering outputs or production handoffs.

    2. What does CPQ stand for?

    CPQ stands for Configure, Price, Quote. The terms describe product selection and validation, price calculation, and quotation generation.

    3. How is manufacturing CPQ different from sales CPQ?

    Sales CPQ often focuses on guided selling, pricing, discounts and proposals. Manufacturing CPQ may additionally manage engineering constraints, calculations, configurable BOMs, CAD automation and order-to-production data.

    4. Does every CPQ system generate a BOM?

    No. Some systems produce only a configured quote or commercial product summary. Others can generate configurable BOMs or integrate with ERP, PLM or engineering systems to create downstream structures.

    5. Can CPQ generate CAD drawings?

    Some platforms support CAD or design automation, while others require a separate CAD automation service or integration. Buyers should verify supported CAD systems, templates, file outputs, revisions and exception handling.

    6. Can CPQ replace ERP?

    No. ERP normally manages orders, inventory, purchasing, finance and other enterprise transactions. CPQ can provide validated configuration and pricing data to ERP.

    7. Can CPQ replace PLM?

    No. Product lifecycle management systems manage product definitions, revisions, changes and lifecycle governance. CPQ may consume approved product data or create a configured product record, but the responsibility boundary must be defined.

    8. Is a product configurator the same as CPQ?

    No. A configurator determines a valid product. CPQ includes configuration plus pricing and quoting, although the two functions are frequently delivered together.

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

    It can support ETO by collecting requirements, applying preliminary rules, estimating price and creating an engineering task. It may not fully automate the custom design or eliminate engineering review.

    10. What is the difference between CTO and ETO?

    Configure-to-order uses a predefined product architecture and controlled options. Engineer-to-order requires significant product-specific engineering for an individual order.

    11. What is the difference between EBOM and MBOM?

    EBOM is an engineering view of product structure. MBOM is a manufacturing view describing how the product is assembled or produced. A CPQ output may be one of these or an intermediate configurable structure.

    12. Does CPQ calculate manufacturing cost?

    Some implementations calculate or roll up estimated material, labor, purchased-part and service costs. Others focus on selling price and margin rules. Costing capability must be verified for the target product and accounting model.

    13. Who maintains CPQ configuration rules?

    Ownership is commonly shared by product management, engineering, manufacturing, sales operations, finance and IT. A defined governance process is needed to approve, test and release changes.

    14. Can distributors and dealers use manufacturing CPQ?

    Yes, if the implementation supports the required channels, permissions, territories, price lists and product visibility. Dealer users may need a simpler guided experience than internal engineers.

    15. Can customers configure products through CPQ?

    Some implementations expose a self-service or ecommerce experience. The model should be designed so that customers see appropriate choices without exposing internal components or unsupported engineering complexity.

    16. What integrations are common for manufacturing CPQ?

    Common integrations include CRM, ERP, PLM, PDM, CAD, PIM, MES and ecommerce systems. The specific integration depends on which system owns each data object and workflow.

    17. How should a company start a CPQ implementation?

    Start with a defined product family and workflow problem, audit the source data, model representative rules, test real scenarios and establish system ownership before expanding the scope.

    18. What are the main risks of implementing CPQ?

    Typical risks include poor product data, unmaintainable rules, unclear ownership, weak integration design, inadequate testing and the assumption that quoting automation automatically creates production-ready information.

    19. How does CPQ reduce configuration errors?

    It applies dependencies, exclusions, constraints, calculations and required-field checks during configuration. This prevents or flags invalid combinations before a quote or order is released.

    20. What should manufacturers evaluate in a CPQ vendor?

    Evaluate configuration depth, rule maintenance, calculations, BOM and CAD outputs, costing, pricing, workflow support, integrations, governance, scalability and implementation requirements using real product scenarios.