CPQ Implementations Go Wrong Before Anyone Touches Configuration
I’ve sat in a lot of CPQ kickoff meetings, and there’s a particular kind of confidence in the room during the first one that I’ve learned not to trust. Everyone’s aligned. Sales wants faster quotes. Finance wants pricing accuracy. Leadership wants a shorter deal cycle. The project charter reads like a case study before a single product rule has been built. Then, somewhere around week three, someone asks a question that sounds small — usually something like “so who actually approves an exception discount above twelve percent” — and the room goes quiet in a way that tells you everything about how the next four months are going to go.
CPQ, more than almost any other part of the Salesforce ecosystem I’ve implemented, gets blamed for failures that have nothing to do with the tool. I’ve reviewed post-mortems where the conclusion was “the configuration was too complex” or “the product catalog wasn’t set up right,” when the actual root cause was that two departments had never agreed on how discounting authority should work, and the CPQ build simply made that disagreement visible instead of causing it. The system didn’t create the conflict. It just refused to let the conflict stay comfortably vague, the way it had for years inside people’s heads and side conversations.
Pricing politics existed long before the project started
Here’s something I wish more sponsors understood going into a CPQ engagement: your organization already has a pricing and discounting culture, whether or not anyone’s ever written it down. It lives in email threads, in verbal exceptions a regional sales director grants because a rep is having a hard quarter, in the informal understanding that “everyone knows” a certain customer always gets an extra five points off. That culture is often inconsistent, sometimes unfair, and almost always undocumented — and CPQ, by its nature, forces you to encode a decision about it into rules that either allow a behavior or block it.
I worked on an implementation for a manufacturing distributor where this played out almost exactly as I’m describing. Sales leadership had told us, confidently, that discount approval followed a clean three-tier structure based on percentage thresholds. It sounded reasonable, and we built to that specification. During UAT, one of the senior reps flagged that the tool was blocking a quote he considered routine — a bundle discount he’d been applying for two years that didn’t map to any of the three tiers we’d been told about, because it had originally been a verbal arrangement between him and a VP who’d since left the company. Nobody had thought to mention it because, to him, it wasn’t an exception. It was just how that particular deal type worked. We ended up pausing configuration for nearly three weeks while sales and finance actually negotiated, for the first time in writing, what the real discounting rules should be. The CPQ build wasn’t the hard part of that project. Getting two departments to agree on a policy they’d been quietly disagreeing about for years was the hard part.
Why “let’s just replicate current process” is a trap
A phrase I hear constantly early in these projects is some version of “let’s just replicate what we do today, and we’ll optimize later.” I understand the instinct — it feels lower risk, and it avoids forcing difficult conversations before the team has built trust in the new system. But I’ve come to think it’s usually a mistake, because “what we do today” typically isn’t one process. It’s several slightly different processes that different regions or product lines have drifted into independently, none of which anyone has compared side by side until the CPQ project forces the comparison.
Replicating “current process” without first reconciling those variations means you’re not simplifying anything. You’re building permanent configuration to support inconsistency, which then has to be maintained indefinitely by whoever inherits the CPQ instance after the consultants leave. I’d rather have that reconciliation conversation up front, uncomfortable as it can be, than discover eighteen months later that the system has three parallel discount-approval paths because nobody wanted to have the conversation about which region’s process should actually be the standard.
The product catalog reveals more than anyone expects
There’s a specific moment in most CPQ projects where the product catalog cleanup starts, and it tends to surface problems that have nothing to do with the CRM. I’ve seen catalogs with duplicate SKUs for the same product because two sales regions independently created their own versions years apart. I’ve seen bundles that made sense when they were created but no longer reflect what the company actually sells, kept alive because nobody wanted to be the one to formally retire them. I’ve seen pricing tiers that were set based on a cost structure that changed two reorganizations ago and never got revisited.
None of that is a CPQ problem. It’s an accumulated organizational-memory problem that the CPQ project happens to force into the open, because you genuinely cannot build accurate product rules on top of a catalog nobody trusts. I tell clients early on that catalog cleanup will probably take longer than they expect, and that the time isn’t wasted — it’s usually the first time in years anyone has been forced to look at the full product and pricing picture in one place, and what they find is often more valuable to the business than the CPQ tool itself.
Where the actual implementation work should start
Given all of this, my approach to a CPQ engagement now looks different than it did earlier in my career. I don’t start with product rules or discount schedules. I start with a small set of forcing questions, put in front of both sales and finance leadership together, in the same room:
- Who has actual authority to approve an exception, at each threshold, and is that authority tied to a role or to a specific person’s judgment?
- Which product bundles or pricing structures exist because of a real, current business reason, versus because nobody’s gotten around to retiring them?
- Where do regional or team-level variations in process reflect a genuine business difference, versus an inconsistency that’s crept in over time?
- What happens today when a deal doesn’t fit any existing rule — and is that exception path something the business wants to preserve, or something it’s been quietly hoping would go away?
Getting real, specific answers to those questions, ideally in writing and with both departments agreeing to the same version of the answer, takes longer than most project timelines budget for. But every CPQ implementation I’ve seen struggle after go-live struggled because those questions were assumed rather than asked, and the technical build ended up encoding disagreements the organization hadn’t actually resolved.
The build is the easy part
I don’t say that to undersell the technical work — CPQ configuration has real complexity, and a poorly built product rule engine can absolutely cause problems on its own. But in my experience, the projects that go smoothly are the ones where, by the time configuration starts, the hard organizational decisions have already been made. The projects that struggle are the ones where the build is used as a substitute for those decisions, in the hope that a well-designed system will somehow resolve a disagreement that people weren’t willing to resolve directly.
If you’re heading into a CPQ project, my honest recommendation is to spend real time, before any configuration begins, getting sales and finance to agree — on paper, not just in a meeting that everyone nods through — on how pricing authority actually works in your organization. It’s not the exciting part of the project. It’s the part that determines whether the exciting part actually holds up.
Disclaimer: Client scenarios described in this article are illustrative composites drawn from common patterns seen across Salesforce implementation work, not references to any specific identifiable client or engagement.