Most CPQ projects start with the product catalog. That seems logical. List the products, define the bundles, set up the rules. But the part that determines whether the system actually works — the pricing engine — usually gets treated as a configuration task rather than a design decision.
That’s where things go wrong.
Pricing in a B2B company isn’t just a number in a field. It’s a set of business rules, relationships, and exceptions that have evolved over years — often without ever being written down. When you force that into a CPQ tool without first understanding the logic underneath, you end up with a system that’s technically live but commercially broken. Sales reps work around it. Finance doesn’t trust it. The tool that was supposed to bring consistency creates a new kind of chaos.
I’ve built pricing engines in Salesforce CPQ and Revenue Cloud for companies from industrial manufacturers to SaaS businesses. The problems are always the same regardless of the platform. The technology works fine. The pricing logic just wasn’t designed.
Before you configure anything, understand how pricing actually works
This sounds obvious. It’s the step that gets skipped most often.
Every company I’ve worked with has someone who knows the pricing. Usually one person, sometimes two. They carry the logic in their heads: which customers get which discounts, how volume breaks work, when to override standard pricing, which partner tier gets what margin.
This is the classic problem: important knowledge living in one person’s head instead of in a system. It works fine at low volume. It becomes a bottleneck and a risk as the business grows. If that person leaves, goes on vacation, or is just unavailable when a quote needs to go out — the process stops.
The first step before any CPQ work isn’t configuration. It’s extraction. Sit down with the people who know the pricing and document what actually happens. Not what the price list says. What actually happens when a real deal gets quoted.
You’ll find a few consistent things. The published price list is a starting point, not the truth. There are customer-specific agreements that override standard pricing. Volume discounts follow a structure nobody has written down. Channel and partner pricing has its own rules. And there’s a layer of discretionary discounting that lives entirely at the rep level, governed by nothing except what they think they can get away with.
All of this needs to be mapped before a single pricing rule gets created in the system.
The price waterfall
The concept that makes pricing manageable is the price waterfall. It’s a sequence of steps, each one adjusting the price based on a specific type of rule, flowing from the top (list price) down to the bottom (what the customer actually pays).
List price. The published price for a product. This is the baseline everything adjusts from.
Contracted price. If the customer has a pre-negotiated price — a master agreement, an annual price lock, a strategic account deal — that replaces list price as the starting point for all other calculations.
Volume discounts. Discounts that apply automatically based on quantity. These should be defined in discount schedules, not applied manually by reps on every quote.
Discretionary discount. The manual discount a sales rep applies during negotiation. This is where most pricing governance problems live. Without guardrails, reps discount to whatever they think will close the deal. With guardrails — floor prices, approval thresholds, maximum discount percentages — you maintain margin while still giving sales room to negotiate.
Channel margin. If the deal goes through a partner or distributor, their margin gets applied as a separate layer. This keeps channel economics visible and separate from customer-facing pricing.
Net price. What flows to the opportunity, the order, and eventually the invoice.
The power of the waterfall is transparency. Sales sees the list price and their discount authority. The channel sees their margin. Finance sees the full picture from list to net. Management can run reports on discount patterns and margin erosion without digging through individual quotes.
Without this structure, nobody can answer basic questions. What’s our average discount? Which reps discount the most? Which product lines have the thinnest margins? With a waterfall, these are standard reports. Without one, every answer requires manual work.
Four decisions to make before touching CPQ
Get these wrong and the CPQ tool will faithfully automate your mistakes.
How many price books do you need? A price book is a collection of prices for your products. If you sell to different segments, regions, or through different channels, you may need multiple price books. But be careful — one price book per scenario becomes unmaintainable fast. A better approach in most platforms: use a single standard price book and handle segment- or channel-specific pricing through rules and contracted pricing. This keeps the catalog clean and the logic centralized.
Where do volume discounts live? They should be in discount schedules, not applied manually by reps on each quote. A discount schedule defines tiers: at quantity X, apply discount Y. The design choice: do discounts apply per product, or across the whole quote? Per product is simpler and more predictable. Cross-quote bundled discounting is more flexible but harder to manage. Most companies start per-product and add the more complex logic later if the business needs it.
What are the guardrails on manual discounting? Reps can discount up to 10% on their own. 10–20% needs a sales manager. 20–30% needs a VP. Over 30% needs an executive. The exact numbers depend on your margins, but the principle is universal: define the lanes, enforce them in the system, and route exceptions through approvals. Without this, every deal is a negotiation between the rep and their manager over email, with no audit trail.
How does channel pricing work? Partners buy at a partner price (list minus their margin) and sell at or near list to the end customer. In CPQ, the partner discount is a separate step in the waterfall, not mixed in with customer-facing discounts. This separation is essential for reporting — you need to know what the end customer paid and what the partner earned, independently.
Product catalog design affects pricing complexity
The pricing engine sits on top of your product catalog, and catalog design directly affects how complex the pricing logic becomes.
Separate what you sell from how you price it. A product in your catalog should represent what the customer buys, not every variation of how it might be priced. If you sell a machine in three configurations, that might be one product with options or three separate products. The right answer depends on whether the pricing logic differs by configuration.
Bundles need explicit pricing logic. Does the bundle have a single price, or are components priced individually with a bundle discount on top? Can individual components be discounted separately, or only the bundle as a whole? These questions need answers before configuration starts.
Subscription products need term logic. If you sell subscriptions or service contracts alongside one-time products, the pricing engine must handle both recurring and non-recurring line items on the same quote. This includes proration, co-termination (aligning multiple subscriptions to the same end date), and renewal pricing.
What a well-built pricing engine gives you
When the pricing logic is properly designed, a few things change.
Quotes go out faster. Reps don’t need to check with anyone for standard pricing. Volume discounts apply automatically. Approval routing is built in. Time from “customer asked for a quote” to “quote is in their inbox” drops from days to hours.
Margin becomes visible. Management can see discount patterns across reps, regions, product lines, and channels. They can spot margin erosion before it becomes a trend.
Channel consistency improves. Partners get the right price without calling your team. Different partner tiers automatically resolve to different margins.
Renewal and expansion pricing has a foundation. If the original deal was priced through a structured waterfall, the renewal quote inherits that context. The account team can see what was quoted, what discounts applied, and what the contractual terms are.
Audit and compliance are built in. Every pricing decision is tracked. Approval chains are documented. Discount exceptions have a paper trail.
The gap between system live and organization adopted
One thing I’ve learned from doing this work over and over: the pricing engine can be ready in weeks. Getting the organization to trust it takes months.
The system goes live, and reps still call the pricing person to double-check. Managers still manually review quotes that are within policy. Partners still email for prices that are in the portal.
This adoption gap is real. It’s not a training problem. It’s a trust problem. People need to see the system produce correct results consistently before they stop using their old workarounds. Plan for it.
In closing
A pricing engine isn’t a configuration task. It’s a design decision. Get the logic right first. Document what actually happens in your business today. Then build a system that reflects that reality — with structure, guardrails, and transparency built in.
The technology is the easy part. It always is.