A look under the hood at what configuration, pricing rules, and quote generation actually do day to day. Not a beginner's "what is CPQ," and not a sales pitch.
Lamar Falconer
Founder & CEO, AltoLeap
July 8, 2026
7 min read
CPQ software works by turning your product knowledge into rules a computer can enforce. A salesperson picks options, the system checks whether that combination is actually buildable, calculates the price and margin, routes any exceptions for approval, and generates the quote document, all in one governed flow. For made-to-order manufacturers, that means the mechanics of how CPQ works matter far more than the acronym. This is a look under the hood at what configuration, pricing rules, and quote generation actually do day to day. It isn't a beginner's "what is CPQ" (our CPQ guide covers that), and it isn't a sales pitch.
If you build custom equipment, configured components, or engineered products, you already know the problem CPQ is meant to solve. Quotes depend on dimensions, materials, options, and current costs. The knowledge lives in a few experienced heads and a fragile spreadsheet. A slow or slightly-wrong quote costs you the bid or the margin. Here's how the software addresses that in practice.
Think of CPQ as a governed quote-to-order workflow with five stages:
Industry analyst Gartner defines the CPQ category around exactly these capabilities: product and option selection, pricing, proposal generation, and order capture ahead of downstream submission. The value for a made-to-order shop is that each stage is enforced by rules instead of tribal knowledge, so the quote a junior rep sends on a Friday afternoon reflects the same logic your best estimator would apply.
The configuration model is the heart of CPQ, and it's where most articles wave their hands. In practice, the model is a set of interlocking rules: attributes (the choices, like length, voltage, or material grade), constraints (which combinations are allowed), calculations (deriving raw-material length or processing time from the inputs), BOM-line rules (which parts get added), routing rules (which operations are required), and validation tests that confirm the whole configuration holds together. Microsoft's product-configuration documentation lays this out as attributes driving constraints, calculations, BOM lines, route operations, and validation, with each valid configuration getting its own identifier.
That distinction between valid and buildable is the one that trips up made-to-order manufacturers. A configurator that only prevents impossible option combinations still isn't guaranteeing you can build the thing profitably on the shop floor. The rules have to encode real engineering and manufacturing logic, which is why setup is a product-data project, not just a software install.
Once a configuration is valid, the pricing engine goes to work. CPQ can handle far more than a fixed list price: option pricing, cost-plus markup, volume and block pricing, percent-of-total pricing, contracted and customer-specific pricing, channel discounts, and manual discounts. Salesforce's CPQ pricing training documents these patterns and the mechanism that ties them together: the price waterfall.
A price waterfall is the staged path from a starting price to the final net price, with each stage feeding the next. For a made-to-order product it might look like this:
| Stage | What it does | Made-to-order example |
|---|---|---|
| Base / list price | Starts from a base model or product family | Base skid, pump package, conveyor, cabinet |
| Configuration adjustments | Adds option, material, and calculated costs | +oversized motor, +stainless, +longer run |
| Cost-plus / margin rules | Applies markup to derived costs | Labor + routing time × rate + target margin |
| Discounts | Volume, customer, or channel pricing | Repeat-customer tier, distributor discount |
| Approvals | Holds exceptions for sign-off | Discount past threshold → sales manager |
| Net price | Final quoted figure | The number on the quote |
For engineered products, price often depends on live operational data such as current material costs, capacity, and lead times. That's why pricing accuracy is really an integration question, which we'll get to.
Approval rules evaluate quote conditions (discount level, net total, product type, warranty exceptions, partner terms) and route the quote through the right approver or approval chain automatically, rather than relying on someone to remember to ask. On the output side, quote and proposal generation runs off document templates with template tags that pull configuration and pricing data into a formatted customer document (SAP's CPQ training covers this template mechanism). The same generation step can produce internal handoff data, but whether that data is production-ready is a separate matter.
CPQ sits beside your ERP, not on top of it. Your ERP owns inventory, costs, capacity, parts, delivery dates, and production execution; CPQ consumes that data to quote accurately and hands its output back for fulfillment. Tacton's material on ERP/CPQ integration describes this two-way flow: sales gets access to real costs and lead times, and production gets an order it can act on.
Here's the distinction that matters most for made-to-order manufacturers, and one most content glosses over: the difference between a sales BOM, an engineering BOM, and a manufacturing BOM. Some CPQ systems generate only a flat sales list. More capable ones generate a nested BOM hierarchy, routing, material and labor rollups, and even CAD outputs (Experlogix documents this range). A commercially valid quote is not automatically a production-ready order.
According to Tacton's 2026 manufacturing survey (a vendor-sponsored study, worth weighing accordingly), only 23% of manufacturers automatically generate a valid manufacturing BOM directly from a sales quote. The gap between "quote accepted" and "shop floor can build it" is where margin quietly leaks.
CPQ delivers for made-to-order manufacturers only when the configuration rules, pricing logic, and BOM outputs are owned and maintained as living product data — not configured once and forgotten.
AI has a real but bounded role in CPQ today. It's genuinely useful for pricing guidance, deal scoring, configuration suggestions, proposal summaries, and extracting structured data from RFQs and drawings (pulling dimensions, tolerances, and notes out of a PDF into usable fields). Where AI should not be in charge is the deterministic core: exact compatibility, compliance, BOM inclusion, routing, and margin-approval logic still belong to explicit rules.
Tacton's 2026 report puts it bluntly: AI doesn't fix a broken digital thread on its own, and without connected, reliable data underneath, it has nothing trustworthy to reason over. (We go deeper on where AI pays off across manufacturing operations in a dedicated piece; for CPQ, treat AI as an assistant to the rules, not a replacement for them.)
The most common misconception is that the hard part is installing the software. It isn't. The hard part is the product data, rule ownership, integration, change management, and ongoing maintenance. Gartner's peer lessons emphasize requirements analysis, stakeholder buy-in, proof-of-concept testing, data consolidation, training, and phased rollout. That's the organizational work, not the license. Before CPQ can work well, your options, rules, costs, price books, BOM logic, routing logic, drawings, part numbers, revisions, and lead times all need a clear owner. Get that right and CPQ compounds; skip it and you've automated a mess.
A short conversation is the fastest way to know whether CPQ is worth it for you. Book a Fit Call and we'll walk through your quoting process, or start with an AI Opportunity Blueprint to find the highest-value automation before you build anything.
It uses a configuration model (attributes, constraints, dependencies, calculations, BOM-line rules, routing rules, and validation tests) to confirm a chosen combination is both valid and manufacturable, not just sellable.
No. CPQ sits beside the ERP. The ERP owns inventory, costs, capacity, parts, and production execution; CPQ uses that data to quote accurately and hands its output back for fulfillment.
It works best when engineering knowledge can be standardized into reusable rules. Configure-to-order fits naturally; pure one-off engineer-to-order work still needs engineering review, though CPQ can accelerate the repeatable parts.
Some systems output only a flat sales BOM; more capable ones generate a nested BOM hierarchy, routing, and material/labor rollups. For made-to-order manufacturers, that difference is worth scrutinizing before you buy or build.
AI can assist by suggesting configurations, summarizing proposals, and extracting data from RFQs, but validated configuration and pricing rules still require engineering and commercial governance.