Why your Salesforce CPQ trial failed (and what to do instead)
The story is the same often enough to be a genre. A company between 50 and 300 people notices that its average selling price has moved. Somebody pulls the last two quarters of closed deals into a spreadsheet, discovers that the median discount is not 8% but 19%, and the obvious answer is CPQ. A trial starts. Four months later there is a half-configured price book, an approval flow that works for one product family, an invoice from an implementation partner, and a sales team still quoting the way it did in March.
It is tempting to conclude that the software was bad. It usually was not. Salesforce CPQ is a genuinely capable engine that runs quoting for some of the largest companies in the world. What failed was the shape of the project, and the shape is predictable enough that you can check for it before you start the next one.
The trial did not fail. It never started
Here is the thing worth being precise about: most stalled CPQ evaluations never got to the point of quoting anything. The elapsed time went somewhere else entirely — into the price book, the product bundles, the field mapping, the sandbox refresh, and the approval matrix that has to be modelled before the first quote can route. That work is real and, at enterprise scale, it is the work. At mid-market scale it is a four-to-six-week gap between signing and learning anything, and evaluations do not survive gaps like that. The champion gets a quarter-end. The consultant's statement of work runs out. The one admin who understood the object model leaves.
So the honest post-mortem is not "the tool was too complex." It is that the tool asked to be configured before it would answer the question you bought it to answer, and the question was urgent.
Four failure modes, in the order they happen
1. The configuration precedes the value
Nothing routes until the catalog is modelled. If your quoting problem is configuration complexity — engineered products, thousands of interdependent options, constraint solving — that sequencing is unavoidable and correct. If your quoting problem is discounting — a rep typed 32% and nobody with authority saw it — then you have spent six weeks on the part that was not broken.
2. The approval matrix models the org chart you wish you had
Enterprise approval design assumes a deal desk, regional directors, and a Finance approver who is not also the CFO doing payroll. A 120-person company has two sales managers and a CFO. Modelled faithfully, that org produces a two-rung ladder, and a two-rung ladder does not need a matrix. Most of the configuration effort in a mid-market CPQ rollout is spent building generality that the company will not use for three years.
3. Governance ends up as a workflow somebody owns
This is the failure that shows up in month eight rather than month two. The approval process is a flow: a person built it, a person can edit it, and under quarter-end pressure a person does. The audit trail records that the flow ran, not that the policy held. When Finance asks who approved 38% off in March, the answer is a screenshot of a configuration that has since changed.
4. Nobody measured the thing the project was for
Almost no stalled evaluation we have heard described had a number attached to it. Not "quotes routed per week," not "median approval latency," not "share of quotes that never needed a signature." Without those, the project cannot show progress, so it competes for attention against things that can — and loses.
The diagnostic: which problem do you actually have?
Before shortlisting anything a second time, answer three questions with real data. All three come out of quotes you have already sent.
- What is the median discount on quotes that carry any discount? Not the mean — two desperate 60% deals will drag a mean somewhere useless. This one number decides where your first threshold belongs, and it is the input most policies get wrong. There is a whole post on why.
- How many people would have to say yes, under the policy you would actually write? If the answer is one or two, you do not need an approval matrix. You need an ordered chain with two rungs that cannot be skipped.
- How much of your quoting time is pricing configuration versus discount negotiation? If it is mostly configuration, buy the configuration engine and budget for the project honestly. If it is mostly negotiation, the configuration engine is not the purchase.
The discount policy builder takes the first two and gives you a routing estimate and a written policy in about five minutes — free, no signup, and useful whether you buy anything or not.
What to do instead: govern first, configure later
The inversion that makes mid-market CPQ work is to put the control in place before the catalog is perfect. Discount governance does not depend on a modelled price book; it depends on a threshold, a role, and something that refuses. That is a week of work, and it is the week that returns money.
A rollout that has consistently survived contact with a quarter looks like this:
- Day one — write down the policy you already run. Including the parts nobody has written down. Enforcing your current policy is usually the finding; changing it is the second conversation, and it goes better with a quarter of data behind it.
- Day two — import accounts, contacts, and the products you quote most. Not the whole catalog. The top twenty SKUs cover the overwhelming majority of quotes at this size, and the long tail can arrive in month two without blocking anything.
- Day three — turn the ladder on with two rungs. A self-serve band, a manager band, and a ceiling. Add a director rung when you have a director.
- Week two — watch two numbers. The share of quotes that never routed, and the median time from submission to decision. If the first is under about 70%, your entry threshold is too tight. If the second is slow, the rung has one approver, not too much process.
- Month two — go back to the catalog. Now the configuration work is an improvement to something already running, which is a project that finishes.
The uncomfortable part
Governance is only a control if something refuses. A policy that a determined manager can wave through at 6pm on the last day of the quarter is not a policy; it is a strongly worded suggestion with an audit gap in the middle of it. That is the test to put to any tool on your next shortlist, ours included:
- Can a rep approve their own quote? (It should be refused by the server, not hidden in the UI.)
- Can an approval step be taken while an earlier one is still open?
- If a pending quote is repriced, does the approval carry forward onto numbers the approver never saw?
- Is there a discount past which nothing finalizes at all — with no approver who can override it?
- Does every decision land in a log that the feature code cannot write to selectively?
Those five answers matter more than the length of the feature list, and they are answerable in a demo rather than in a proof-of-concept. If a vendor needs four weeks of configuration before they can show you the refusals, that is the same project failing again with a different logo on it.
None of this is an argument that Salesforce CPQ is the wrong product. For a company with the catalog complexity and the admin capacity it assumes, it is frequently the right one, and our comparison page says where it beats us. It is an argument about sequencing: at 50–200 people, the discount is the leak, the configuration is the polish, and doing them in that order is the difference between a control that is live this month and a project that is still in discovery when the quarter closes.