A rep at a mid-size gasket manufacturer quotes the same part number to three customers in the same week. One gets list price. One gets a 12% discount. One gets a custom margin floor because the sales manager made a call two years ago and nobody documented it. All three quotes went out the door. Only one of them was intentional.
That's the problem CPQ pricing solves. Not by adding more spreadsheets, but by encoding the rules your business already has into the system that generates quotes.
CPQ pricing is the decision engine inside a configure-price-quote system that determines which price a rep sees for a given product in a given context. It's not a single number stored in a database. It's a set of rules, conditions, and formulas that fire in sequence when a rep builds a quote.
When a rep opens a quote in a CPQ system, they don't browse a spreadsheet and pick a number. The system looks at who the customer is, what's being ordered, and how much, then presents the correct price. The rep sees the output. The logic stays out of their hands unless they've been explicitly granted override permissions.
For discrete manufacturers, this matters more than it does for software companies. Your products have real cost structures. A price that looks competitive on a 50-unit order destroys margin on a 5-unit order. CPQ pricing handles that distinction automatically, so the rep doesn't have to do the math and doesn't have the opportunity to guess wrong.
The logic breaks into three components: price books, conditional pricing rules, and calculated fields.
A price book is a structured list of products and their base prices, organized by customer segment, channel, or territory. Most manufacturers already have something that functions like a price book, usually a spreadsheet, a locked tab in the ERP, or a PDF the inside sales team keeps on their desktop. In a CPQ system, price books are first-class objects with access controls attached.
A manufacturer might maintain three: one for direct end customers, one for distributors, and one for OEM accounts. Each has different list prices for the same SKUs. When a rep starts a quote, the system assigns the right price book automatically based on the account record in the CRM. A rep working a distributor account never sees the direct pricing. They can't accidentally (or intentionally) quote from the wrong list.
This alone eliminates a large category of quoting errors. The rep isn't choosing which price list to open. The system chooses for them based on how the account is classified. For more on how price books fit into the broader quoting architecture, see the CPQ fundamentals overview.
Price books handle the baseline. Conditional rules handle everything else.
A conditional pricing rule says: if a specific condition is true, apply a specific price adjustment. The conditions can pull from almost anywhere. Customer type, deal size, product combination, quantity thresholds, rep-entered attributes, or custom fields from the account record.
A few examples from real manufacturing configurations:
These rules run in a defined sequence. If two rules apply to the same line item, the system resolves them in a priority order you set. The rep sees the final price. They don't see the rule chain, and they can't override it unless they've been explicitly granted that permission.
This is where the tribal knowledge problem gets addressed. The distributor discount your inside sales manager has been applying manually for three years can be written as a rule. It runs the same way every time, for every rep, on every quote. The institutional knowledge stops living in one person's head.
Some prices aren't stored as fixed numbers at all. They're calculated fresh each time a quote is built, based on current inputs.
Calculated fields are formulas that derive a price from other variables. Common patterns in manufacturing include cost-plus pricing (pull the current standard cost from the product record, add a target margin percentage, output a floor price), weight-based pricing (multiply unit weight by a per-pound rate and add a handling fee), and margin-floor enforcement (if the rep enters a custom price, the system checks it against the cost-based floor and flags or blocks anything below threshold).
The practical effect is that the system stays current without manual updates. If raw material costs shift and you update the standard cost in your ERP, the calculated floor prices on new quotes reflect the change automatically. No one has to remember to update the spreadsheet.
Price books, conditional rules, and calculated fields aren't separate features. They layer on top of each other in sequence. The price book sets the starting point for a given customer segment. Conditional rules apply adjustments based on what's in the quote and who the customer is. Calculated fields handle anything that needs to be derived rather than looked up, and they can also serve as guardrails that prevent the adjusted price from going below a defensible floor.
For a manufacturer who's outgrown spreadsheet quoting, this is the architecture worth understanding before evaluating any CPQ vendor. The question isn't whether a tool has pricing features. It's whether you can encode your actual rules without a custom development project every time the business changes. The posts on tiered pricing and formula-based pricing go deeper on specific patterns if you're trying to figure out which of these applies to your situation.