Configure-Price-Quote projects are quietly notorious in the Salesforce world. A new implementation promised in twelve weeks routinely lands at twenty-four, sometimes thirty, and the overrun usually runs three to four times the original quote. The cause is almost always the same, and it is not technical. The discovery phase under-counted how complex the pricing model already was, because the people who sponsored the project genuinely believed it was simpler than it is.
The sales leader describes the model as three products with two tiers. The reality, once you talk to deal desk and finance, involves fifteen approval paths, a scatter of legacy customer-specific discounts, and a quoting spreadsheet the team has maintained by hand since 2017. That spreadsheet is the warning sign and the gift. If your sales team built a quoting spreadsheet because Salesforce could not do what they needed, the spreadsheet contains the real requirements. Get a copy in the first meeting and read every formula.
The seven questions
Every CPQ engagement we have landed on time produced written answers to these seven questions before a single object was configured. The questions are deceptively short. The answers rarely are.
How many distinct pricing models do you have?
Not products. Models. Subscription per user is one. Tiered usage metering is another. Perpetual licence with annual maintenance is a third. A ramp deal with a contract term is a fourth. Most teams run between two and five, and each must be modelled separately.
watch for: "we just sell software"How does a price actually reach a customer today?
Walk the path. Who builds the quote, in what tool, through which approvals, and how long does the loop take when nothing goes wrong? CPQ has to replace every step of that loop, not only the calculation.
What does the approval matrix actually look like?
Ask deal desk for the rules and expect more than you bargained for. Margin thresholds, term-length thresholds, discount thresholds, segment overrides, regional variations. This is where projects bloat from weeks into months.
watch for: "we'll figure that out in build"What product bundles exist, and what governs them?
"You cannot buy A without B." "More than five of C includes D free." Easy to write down, hard to maintain if there are dozens and they change quarterly. If the product team adds constraints every quarter, design the constraint layer for a non-developer owner.
What does the renewal motion look like?
New-business and renewal quoting feel similar and behave differently. Renewals involve uplift logic, prorations, and mid-term amendments. If renewals are more than a third of revenue, design that flow at the same time, not later.
Where does the quote need to land?
CPQ produces a quote, the quote becomes a proposal, the proposal gets signed, the signature triggers contract creation, billing, and provisioning. Walk the entire downstream path. Each handoff is a failure point and belongs in scope.
What happens when a deal is unusual?
Every B2B team has a "strategic" category negotiated bespoke. Small in count, meaningful in revenue. Your system needs a documented escape hatch, either a manual override with clear approval or a path that bypasses CPQ entirely.
If the answer to any of these seven is "we are still figuring that out", the project is not ready for build. It is ready for more discovery.
Every CPQ build is a model of how you price
It helps to see the shape of the thing you are modelling. A quote branches into product configuration, discounting, and approval, and each of those branches into rules that someone in your business already enforces by memory or by spreadsheet. The implementation makes that tree explicit. The scoping decision is which branches you can defer to a second version without breaking the first.
The phase plan that lands on time
Once the seven questions have written answers, the implementation falls into four phases. The durations assume a single business unit, not a global rollout, and they hold up only when discovery was done honestly.
Red flags during discovery
"We'll figure out the approval matrix during build." You will figure out a third of it, ship, and spend the next year amending the rest.
"Pricing changes next quarter, so model the new pricing." Model the current pricing. The new pricing will also change before it launches.
"Deal desk will document the rules during your sprint." They will not, because they are closing the quarter. Send a consultant to shadow them for two days.
Block two days of the deal-desk team's calendar at the start of discovery. Not a kickoff. Two days of watching them build quotes. The cost of those two days is the highest-leverage decision in the entire project.
The phase-zero artefact
Before configuration begins, the team produces one document: a pricing architecture brief, ten to fifteen pages. It contains written answers to all seven questions, an entity diagram of products, bundles, and rules, the approval matrix as an enumerated table, a list of edge cases explicitly out of scope for version one with their workarounds, and a sign-off page carrying the names of the deal-desk, finance, and sales-operations leads. If you cannot produce this document, the project is not ready to start. If you can, it usually lands on time. And it lands faster still when a single executive sponsor, someone whose quarterly number depends on the project, is the one who decides in week eight what gets deferred.