Author
TL;DR CPQ analytics, as sold, measure execution: quote volume, cycle time, approval delays, discount frequency, win rate. None of it asks which configurations buyers refused, at what price, in which Customer Group. The configurations a buyer considered and rejected are a larger pricing dataset than the configurations anyone signed, and the quoting layer is the only place that record exists. Keep the version the buyer refused, and the analyzable set grows without a single additional sale.
- What CPQ Analytics Reports On, and the Question It Never Asks
- Why the Rejected Set Is the Larger Dataset
- A Refused Configuration Is a Consequential Choice, Not a Survey Answer
- What to Capture: The Frame, Not the Schema
- Why CPQ Analytics Belong to the Decision Layer, Not the CPQ Vendor
- The Tests: Is Your Quoting Layer Keeping Evidence or Discarding It?
- FAQs
A CPQ system (configure, price, quote) produces a record for every version of every quote it builds. Most deployments keep the last version and discard the rest. CPQ analytics then report on what survived: quote counts, cycle times, stalled approvals, discount requests. Useful numbers. They describe only the configurations that reached a signature, and a buyer priced several before choosing one or walking away from all of them.
What CPQ Analytics Reports On, and the Question It Never Asks
Ask a CPQ vendor what its analytics do and the answer is consistent across the category. Quote velocity, approval bottlenecks, discount frequency, quote conversion rate, rep productivity. Some add renewal tracking and pricing-accuracy checks against the ERP. All of it is execution measurement. It tells a sales leader how fast the quoting machine runs and where it jams.
Execution measurement is a legitimate job: a quote that sits in approval for nine days is a real problem, and a report that finds it earns its place. Reporting hygiene, the discipline of keeping quote, approval and renewal data clean enough to trust, sits upstream of everything in this piece.
None of it asks which configurations buyers refused, at what price, in which Customer Group. The vendor frames the quote as a step toward a signature, so the analytics measure the step. The pricing function needs the quote as an observation of a buyer choosing between priced alternatives. The record that holds that observation is the one most deployments overwrite: the intermediate quote, the version before the version that signed.
The configurations a buyer considered and rejected are a larger pricing dataset than the configurations anyone signed, and the quoting layer is the only place that record exists. The same holds for AI software pricing as for seat-based software. The evidence a pricing decision needs is produced inside the deal, before the outcome, and the tool that produced it discards it by default.
Why the Rejected Set Is the Larger Dataset
A won/lost record holds one row per deal. That row says a buyer either accepted a configuration at a price or walked away from the final one offered. Inside the deal, the buyer did considerably more.
What a buyer rejects on the way to a signature
The buyer priced an edition and asked what the next edition up would cost. Then they tested a lower quantity of the value metric to see where the unit price moved. They asked for a shorter term and watched the annual figure change, then dropped an add-on and restored it when the bundled price came in lower. They saw a net price and did not sign it, then saw another and did. Five observations, one signature.
Each of those is an observation with a configuration and a price attached. Each was refused by a buyer with budget authority, in a live negotiation, against real alternatives. In the patterns our library holds, the explored set runs an order of magnitude larger than the signed set. The shape of that ratio holds whether or not the deal closed.
Why the deal that closed is the least informative row
The signed configuration says one price worked for one buyer. It says nothing about the edition the buyer crossed out of, the quantity they refused, or the term they would not accept. The rejected configurations say where the price stopped working, and a pricing model is calibrated at its edges, not at its center.
Billing data is survivorship data: every invoice is a deal already won, so the meter’s history is written by winners. The refused version of a quote is the row survivorship removes. Only the quoting layer held it before it was removed.
CPQ analytics on the rejected set versus the signed set
Run the same instrument over a different population and the questions change. On the signed set, CPQ analytics answer how fast and how often. On the rejected set, they answer which edition boundary buyers in a given Customer Group will not cross and which value-metric quantity they cut back to. They also show where net price separated from list before anyone said yes. No new tool and no new sale are required: the population was already there, and the default setting discarded it.
If you cannot retrieve the configurations your last ten buyers refused, describe your quoting setup to a pricing expert and one will reply with whether the record is still recoverable.
A Refused Configuration Is a Consequential Choice, Not a Survey Answer
Peer-reviewed pricing research consistently finds that choices carrying real consequences predict what buyers pay far better than statements about what they would pay. The same research finds stated willingness to pay running above what buyers end up paying. The case for why willingness-to-pay surveys fail in B2B is already made; the point here is narrower.
A buyer walking away from a configuration in a live quote is making the most consequential choice available short of signature. Their budget was real. The alternative on the table was real. The refusal cost them the configuration they had just priced. A survey respondent gives up nothing by answering, which is why the same buyer will state one willingness to pay in a survey and refuse it in a quote.
Peer-reviewed work on subscription demand adds a second point: observed choices can identify willingness to pay without running price experiments on live customers. A company that keeps its refused configurations does not need to test prices on its base to learn where prices stop working. It has been running that observation, deal by deal, for as long as it has been quoting, and discarding the results.
This record is one line of decision evidence, the corpus a pricing decision calibrates on. That corpus spans win and loss events, the buyer’s choice set, billing, usage and cost data, and expert judgment. The buyer’s choice set is the line this piece is about. No meter generates it as exhaust, and the company already holds it.
Do Your Licensing and Packaging Decisions Survive Consequential Buyer Choices?
Refused configurations expose which of your licensing, packaging, and pricing decisions buyers reject when real money is on the line. A few questions return your pricing architecture score and show what to fix first.
What to Capture: The Frame, Not the Schema
At the frame level, the quoting layer should keep five categories. The configuration that was offered: which edition, how much of the value metric, what term, which add-ons. The price it was offered at, list and net. The stage at which the buyer refused it, what replaced it in the next version of the quote, and whether the deal closed on anything at all.
Those are categories in prose, not a data model. Where each lands in a given quoting stack, and how the capture is instrumented, is design work that differs by company.
This record exists whether or not usage is ever metered. The companion piece on pricing before the meter exists covers what to price on until usage can be counted; the rejected configuration is evidence in either state.
The version the buyer refused, kept rather than overwritten
The single change that turns a quoting system into an evidence source is keeping the version the buyer said no to. The test for a quoting layer is one question: when a rep changes a refused configuration, does the refused version survive with its price attached, or does the edit replace it? Most deployments answer the second, and an audit log nobody queries does not count as survival. Where the record survives, what the buyer refused and what they accepted can be read together.
Which pricing decision each rejection informs
A refusal points at one of the three pricing decisions, and the read decides which one. Three questions sort a refused configuration: did the buyer stop at an edition boundary, cut back the quantity of the value metric, or walk from a net price that had already separated from list? Each answer implicates a different decision, and the same refusal can implicate two. A refusal stored without the parameters that answer those questions has lost the decision it could inform.
When does a rejected configuration stop being evidence?
When the parameters that were refused are not recorded with it. A count of refusals says buyers said no; it does not say to what. A refused quote with its edition, its quantity, its term and its net price intact is an observation. Strip any one of those and it decays toward a count, and a count is not evidence. The same applies to the Customer Group: a rejection with no view of who refused it can be averaged, but it cannot be read.
The Pricing Architecture Assessment is the diagnostic for which of the three decisions your refusals are pointing at.
Why CPQ Analytics Belong to the Decision Layer, Not the CPQ Vendor
The vendor’s analytics answer an execution question: how fast do quotes move, where do approvals stall, which reps discount most. The pricing decision layer, where licensing, packaging and pricing choices are made, asks an evidence question: which configurations are refused at which prices in which Customer Groups. Same instrument, different owner of the question.
Most B2B pricing software solves the execution layer and leaves the architecture underneath untouched. It was built for that job. The deal desk sees the exceptions that were approved; the refusals this piece is about never reach it. The rejected-configuration record is a sensing input to the decision layer, and nothing in the quoting stack is built to route it there.
A CPQ vendor will add a report on request. The question of what the report is for belongs to the pricing function, and a company that has never asked it will be shown velocity dashboards indefinitely. Applied pricing-model research finds that models built from observable business phenomena outperform purely theoretical constructions, and the refusal record is exactly that phenomenon, sitting in a system the company already pays for.
The Tests: Is Your Quoting Layer Keeping Evidence or Discarding It?
Four questions, left for you to answer against your own quoting layer.
- For your last ten closed deals, how many configurations were priced before the one that signed, and can you retrieve them today?
- Can you name the configuration buyers most often refuse, and the price at which they refuse it?
- Does your quoting layer keep the version a buyer refused, or overwrite it with the version they accepted?
- If your CPQ vendor’s analytics disappeared tomorrow, which pricing question would you be unable to answer?
If the answer to the fourth is none, the analytics were never answering a pricing question. There is no score to compute and no target retrieval rate. A company that can answer the first three has an evidence source; one that cannot has a velocity dashboard.
One company’s record answers where its own prices stopped working. It cannot say whether that pattern belongs to the market or to this pricebook. Whether that Customer Group stops at the same boundary everywhere is one such question. Whether the explored-to-signed ratio is ordinary for the category is another, and which decision moves first when a refusal implicates two is a third. Those answers come from reading one record against many, which is what a pattern library built across decades of deals is for, and the reading is judgment work.
The fastest way to find out which one you have is to describe what your quoting layer keeps. A pricing expert replies with a read on where the record is recoverable and which of the three decisions it informs first. Where a company wants the capture to run continuously, LevelSetter is the infrastructure that records how buyers and reps interact with packaging and pricing before deals close. The read on what the record says stays with the expert.
