---
title: "CPQ"
type: playbook
evidence_type: method
category: "Revenue Systems"
publisher: "LeanScale"
date_modified: 2026-07-27
word_count: 3763
topics: ["pricing-packaging", "revenue-operations"]
canonical_url: https://knowledge.leanscale.team/playbooks/cpq-playbook/
source: "LeanScale Knowledge Hub — https://knowledge.leanscale.team"
license: "Free to quote and cite with attribution to LeanScale."
---

# CPQ

**Evidence type:** method (what we prescribe)

Every CPQ project moves through the same four phases. Know what you produce in each one — and know that, like Quote to Cash, this is a project you win or lose in the Blueprint. 1 Blueprint Diagnose the pricing complexity, pick the tool, and scope every product, rule, and approval.

## Four phases, one motion.

Every CPQ project moves through the same four phases. Know what you produce in each one — and know that,
like Quote to Cash, this is a project you win or lose in the Blueprint.
1
Blueprint
Diagnose the pricing complexity, pick the tool, and scope every product, rule, and approval.
Output Tool pick + config spec
2
Build
Configure it — push where there's an API, IKEA-instructions where there isn't. In a sandbox, always.
Output Live config, cut over safely
3
Enable
Looms for everything, a phased rollout, a visual config tree, and a named client-side admin.
Output A team that owns it
4
Maintain
Handle the ad-hoc ripple, watch config drift, and teach them to self-serve.
Output Config that stays true
Start Here

## Kick off a project in one paste.

Don't dig through the GitHub repo. Copy this prompt, drop in the customer name, and send it to your Claude.
It clones the template, reads the AGENTS.md , and walks the Blueprint checklist with you.
paste into Claude
Copy prompt
# CPQ — kick off
Clone the LeanScale CPQ template repo for my customer [Customer Name] .
Then read AGENTS.md and run the Blueprint checklist:
1. Confirm access to the connected systems (CRM, current CPQ/quoting, billing).
2. Diagnose pricing complexity — required products, %-of-total, amendments, bundles, cross-family pricing.
3. Decide: do they even need a CPQ, and if so, which one? (run the decision tree)
4. Scope the products, bundles, pricing/product rules, and approval flows.
5. Pull billing frequency, payment terms, contract lengths, and every post-contract motion (co-term, amend, expand).
Ask me anything you need before you start.
What you get

## Blueprint.

This is the whole game. Before you touch a single field,
diagnose how complex the pricing really is — that answer picks the tool and sizes the build. Then scope every
product, bundle, rule, and approval, almost obsessively. CPQ is won or lost right here: the projects that go sideways
are the ones where a product, a bundle, or an approval got forgotten in discovery.
1.1 · The Complexity Diagnosis

### First question: do they even need a CPQ?

Complexity isn't the number of products — it's the logic around them . Plenty of companies can be served by
a few flows and never need a CPQ. The moment logic wraps the products, it stops being scalable and you need one.
You don't need a CPQ when…
Standard 2 / 3-year contracts , pricing doesn't really change
At most a yearly uplift % — a simple flow adds it
Expansion and renewal logic — buildable without a CPQ
A clean catalog you just quote off of
You need a CPQ when… (the triggers)
Required products — select A and B is forced in
Percentage-of-total pricing, or "ARR-related products only"
Mid-term amendments — exponentially hard to track by hand
Validation / product rules — quantity caps, price floors, allowed combos
Bundles — a parent product that pulls its components onto the quote
The failure mode
Try to hand-build this past the threshold and you end up with thousands of validation rules and
flows all firing at once — until the whole system slows to a crawl. That's the tell you're past the line and it's
time for a real CPQ.
1.2 · The Tool Decision Tree

### Be opinionated. Pick the tool the pricing demands.

There's no great tool in this category — they all make trade-offs. So we don't try to support all of them; we pick
the one the customer's pricing actually requires, and we're clear about what they give up. Walk it in order:
1
Already on Salesforce CPQ and it works? → Keep it.
CPQ is End of Sale — frozen but fully supported. Don't manufacture a migration. You can add licenses and keep running; you just can't buy it net-new anymore.
2
Is the pricing genuinely complex? → the most-capable stack.
Cross-family pricing, deep product/pricing rules, granular amendments — this is where a real CPQ earns its keep. Net-new, that means Deal Hub (our most-proven) or Nue for usage-heavy, Salesforce-native motions. Salesforce CPQ is still the most capable engine, but you can't sell it to new customers.
3
Simple, guided, cost-sensitive, non-technical admin? → HubSpot.
HubSpot's native CPQ is incredibly guided — a non-technical admin can configure it. Know the ceiling going in, and don't scope past it.
4
Bundles required? → RevOps.io is out.
RevOps.io doesn't support bundles . If the book of business needs a parent-with-components structure, it's disqualified — full stop.
5
Net-new Salesforce that can't buy CPQ? → Revenue Cloud, carefully.
RCA is CPQ's official successor, but peers call it immature and over-complicated — worse than standard CPQ today. Evaluate, don't assume. (See the companion guide below.)
If · complex pricing, net-new, Salesforce-centric
Deal Hub (default) · Nue for usage
Our most-implemented, most-familiar choice — and familiarity is quality. Accept its pricing restrictions up front (see the gotchas). Reach for Nue when it's usage-based and AI-forward.
Else · simple motions, budget, guided admin
HubSpot native — or just flows
HubSpot CPQ if they live in HubSpot and want easy. If it's truly simple — flat terms, an uplift %, standard renewals — don't sell them a CPQ at all. Build the flows.
Say the quiet part
The strong opinions online ("Deal Hub is more flexible than Salesforce CPQ!") are almost always someone
who never learned to configure CPQ . Salesforce CPQ is the most capable engine there is — it's just brutally
complex, and if you don't know it, you'll hate it. Deal Hub is more restricted , not more powerful. Get that
straight before you let a customer's hype pick the tool.
1.3 · The Tools, at a Glance

### Six tools — their sweet spot and their hard limit.

Know each one's ceiling cold. The trap is letting a customer's excitement about a tool override what its pricing
engine can actually do.
Salesforce CPQ
Most capable
The most freedom — before/after/on-init/on-save pricing rules, deep product rules
Best API / CLI footprint → agent-buildable
End of Sale — can't buy net-new; keep if they have it
Deal Hub
Our default
Most-proven for us; guided selling, bundles OK
Can't price across product families (repeatable tables)
Docs are rough — you'll be on calls with their reps
HubSpot
Simple & guided
Non-technical admin can run it; fast to stand up
2026 updates claim proper bundles & product fixtures — verify
Renewal rollups need the code-node license upgrade
RevOps.io
Lightweight
Simple usage tiers, metered logic built in
No bundles — disqualified for bundled books
May not even need a full sandbox to test
Nue.io
Usage / AI
Newer; Salesforce-only , usage-based & AI-forward
Saw them at Dreamforce — worth hands-on evaluation
Good candidate for consumption-first motions
Revenue Cloud (RCA)
CPQ's successor
Salesforce's official replacement for CPQ
Immature / over-complicated today — peers rate it below CPQ
Pricing itself is hard to even get from Salesforce
Living doc
These ceilings move every release. HubSpot's bundling, Deal Hub's workarounds, Nue's roadmap — all
shifting. Run a per-tool refresh before you commit a customer, and fold what you learn back into this playbook on
every close-out. We partner with the best; if a better tool shows up, we switch.
1.4 · Discovery

### The six buckets — and the one that always kills you.

Most of a CPQ scope has to be asked , not read from systems. Get almost obsessively thorough here. The whole
risk of the project is the rule, bundle, or approval nobody mentioned in discovery.
① Products & Bundles
The #1 killer
Every product, its groupings, how it's quoted
Bundles — parent + components, their own qty/pricing
Never scoped as tightly as it needs to be
② Pricing & Rules
Guardrails
How each product is priced; discount rules
Validations — qty caps, price floors, allowed combos
%-of-total and cross-family pricing needs
③ Approvals
Often deeper than scoped
Manager → exec → finance → product
Buildable — even with flow approvals
Watch complex routing by amount / ARR / quote type
④ Billing & Contracts
Drives RevRec
Billing frequency (feeds revenue recognition)
Payment terms
Odd contract lengths (8 / 16-mo) change everything vs 12 / 24 / 36
⑤ Post-contract
Co-term = hardest
Amendments — upsell / downsell mid-term
Expansions, renewals, roll-ups
Co-terming — the single hardest piece to implement
⑥ Usage & Capacity
Downstream
Usage tiers — stair-step, volume, unlock-lower-tier
How usage is metered & billed (usually back-end finance)
Inventory/capacity gates (niche — GPU/compute-capacity style)
Scope it like Blueprint
Products are where every project dies. Keep a shared product sheet with the client from day one
(you'll reuse it for enablement) and pin down how each one is billed, grouped, priced, and quoted before you
pick a tool — because the pricing rules decide whether the tool can even do it.
1.5 · The Hard Scenarios

### Amendments and co-terming are where it gets exponential.

Keep it tool-agnostic in discovery: capture how they want to amend and co-term ideally, then check whether
the tool can do it. These two are the ones that blow up scope.
1
Amendments ripple through the whole data model
In Salesforce, one mid-term change touches the quote, quote lines, opportunity products, opportunity, and contract — and every ARR value on them. Salesforce CPQ automates that cascade; most other tools don't. Only standard Salesforce CPQ has a real mid-term amendment feature; elsewhere you build flows or treat it as a nice-to-have.
2
Co-terming is the most complicated thing you'll build
Aligning end-dates across products — regardless of system — is the single hardest piece. Deal Hub's "solution" is a maze of random fields and background calculations that even experienced Deal Hub people can't parse. Ask early and explicitly whether they co-term.
3
Renewal roll-ups have a licensing tax on HubSpot
HubSpot moves line items to the renewal deal instead of copying them — leaving the new-business deal empty. To roll them up you need a code node (an upgraded license) that looks up the lines, recalculates, and re-creates them via workflow. Flag the license cost in the recommendation.
1.6 · Usage-Based Pricing

### The tiers are easy now. The metering is the question.

Configuring usage tiers — commitment-plus-overage, stair-step, volume, unlock-the-lower-tier — is mostly a solved
problem; even RevOps.io has metered logic. The real work is downstream .
What's simple
Quote the committed products + the usage rate on top
Tier logic: $1 → 100, then $0.50, then $0.25 , or unlock-lower-tier
Add services and products alongside the usage lines
Most tools have config-free switches for this today
What's the real question
How is usage metered — and who owns it?
Usually the back-end finance system (connected to the product DB), not the CRM
Most teams don't report usage inside the CRM — don't force it
How much interaction do they want between billing and the CPQ?
When metering earns its place
You don't usually need a dedicated metering tool — until the stack demands it. One client went full enterprise (SAP)
with per-model rate cards where inputs price differently than outputs ; that granularity is where
metering matters. Otherwise: quote the tiers, let finance track consumption in the back end (the legendary "Wang
report" — one monthly source-of-truth spreadsheet), and keep it off the CRM.
The Deliverable

## What Blueprint hands over.

Three artifacts come out of Blueprint, and everything in Build is downstream of them. Get them signed off before
you configure a single rule.
01

### The product & pricing spec

The shared sheet: every product, bundle, grouping, price, and discount rule — the thing that's
never scoped tightly enough , scoped tightly. This is the map engineering builds to.
03

### The config blueprint

Product/pricing rules and validations, the approval flows, the post-contract motions (amend,
co-term, expand), and the billing + contract-length handling. The full logic layer, on paper.
Use it
Feed all three to Claude as the reference for what Build produces. Each engagement's version looks
a little different — but the shape of the deliverable is always these three.
2
Phase 2

## Build.

Be honest about this: CPQ is handcrafted, artisanally
engineered work. There's no clean CLI that auto-builds one. How much you can automate comes down to the tool's API
surface — and where you can't push, you write the IKEA instructions and click through with the engineering team.
2.1 · Configure It

### Push it, or write the IKEA instructions.

The config spec from Blueprint is the build. Whether we deploy it programmatically comes down to the tool's
CLI / API surface — which varies wildly across the six.
If · the tool has a real API / CLI
Plug in and push
Salesforce CPQ has the best footprint — load the official docs, grep them, and get an agent meaningfully into the session (domain knowledge still needed to troubleshoot the nuances). Deal Hub imports products from an Excel sheet — build the product playbook as a template and let Claude fill it.
Else · closed / GUI-only tool
The IKEA instructions
Deal Hub's API is wonky; most tools are worse. Produce step-by-step, screenshot-grade install instructions — "build this, this way; then this" — for the engineering team to execute by hand. Same standard, more clicks.
2.2 · The Examples Repo

### Rip the formulas, flows, and gotchas from past builds.

The compounding asset. Load the repo with real, working examples so the next build isn't from scratch — "if you're
doing something like this, here's what good looks like." Export them from implementations we've already shipped.
Reuse

### The Deal Hub null-date trick

A date formula can't check for null directly — a blank reads as a specific old sentinel date (e.g. Jan 1, 1969 ). To test "is this empty," compare against that date. Nobody documents this.
Gotcha

### Deal Hub pricing order-of-operations

Pricing always calculates after selection — so you can't price a product off another product in a different family. Salesforce CPQ lets you choose before / after / on-init / on-save. Design around it.
On research
When you need market intel on a tool, run firm research, not a deep massage — a focused sweep of
Reddit, Salesforce threads, and release notes for current capabilities as of the build date. Enough to decide; not
a hundred-agent dissertation.
2.3 · Sandbox & Cutover

### Sandbox everything. Then flip it when reps are asleep.

The one non-negotiable of the whole playbook. You do not tinker in prod.
Sandbox — one billion percent
Salesforce CPQ → a full sandbox
Deal Hub → its own sandbox + a full Salesforce sandbox to test against; build in DH sandbox, push to prod
HubSpot sandbox is weak — sandbox where you can anyway
RevOps.io is the only one you might safely build live — and it still has a test mode
Cutover timing — like a CRM migration
Pricing fixes (from RevOps / legal / finance) → ship ASAP
Deep changes — workflows, approvals → after hours
Cut over when the sales team isn't using it — Friday afternoon / over the weekend
Brief the broader team the Wednesday before
Watch for moving targets
Price, packaging, or a motion can change mid-build and force a pivot — the same trap as Quote to
Cash, where a customer changed their price book twice and a two-week build stretched to three months. Lock the spec,
and re-confirm it right before cutover.
3
Phase 3

## Enable.

Do enablement right and Maintain gets cheap. Ship the same
things every time — a shared product sheet, Looms for everything, a phased rollout, and a visual config tree — and hand
the back end to a named client-side admin.
📄 Documentation
Read
The shared product sheet — client + us, no surprises
How to configure a quote, publish & send
The approval process & what needs one
What reps can & cannot touch
🎥 Looms
Watch
100% of everything gets a Loom
Kavean shot ~100 for the MediaFly build
The searchable library the admin inherits
🎧 Podcast
Listen
Every enablement gets an audio brief (ElevenLabs)
People retain audio they'd skim as text
This page's brief is the template
3.1 · The Phased Rollout

### Leadership → a rep or two → the whole team.

Never flip it on for everyone at once. Phase the access and let each group surface what's missing before the next
one gets in — the QA / UAT catches the products, rules, and pricing that didn't carry over.
Wed · before
Pre-brief
Walk the broader team through what's changing before it lands.
Phase 1
Leadership tests
They run quotes through every motion and sign off on the logic.
Phase 2
1–2 reps test
Real sellers catch missing products, rules, and mismatched pricing.
Fri · 2pm
Full launch
Cut the whole team over, then support & monitor through the first weeks.
3.2 · The visual config tree
Clicking through a raw CPQ is miserable unless you're deeply technical. So pull the
validations and product rules out of the CPQ into a clean, clickable tree — pick a product,
see what you can add, with the incompatible options grayed out. Same idea as our GTM Lifecycle artifact: turn
the config into something a human can actually navigate. A great enablement asset and a QA tool.
3.3 · Clone the repo into their brain
We clone this CPQ repo for each customer . Every product, rule, and tool decision becomes part of
their agent's context going forward — so the next project on that account, and every ad-hoc change, starts faster.
Enablement isn't a handoff; it's compounding context . Teach the admin enough on the back end that
they can add a product or tweak a rule without us.
4
Phase 4

## Maintain.

CPQ generates more ad-hoc work than almost anything we
run — every product, price, rule, or approval change ripples through the config. The goal of Maintain is to make
most of that the client's job, not ours.
4.1 · Ad-hoc Triggers

### Enable so well they don't need you.

Counter-intuitive, but it's the play. If enablement lands, the client maintains the config themselves — and we go
spend our hours on higher-leverage work.
The MediaFly proof
Right before handoff, the MediaFly team was already in the back end building their own
products and adjusting their own rules. That's the target state: teach them enough that day-to-day
upkeep never routes back to us.
The trade we make on purpose
Yes, we give up some ad-hoc revenue on the account
We buy back capacity for higher-leverage projects
The clone + Looms + config tree are what make self-serve stick
4.3 · When to Revisit

### On events, and on trajectory.

Don't just build for how they sell today. Read where the company is heading and make sure the tool can carry them
there — sometimes the readiness is in the tool selection itself.
Event-based
Revisit when the model changes
New product line, new bundle, or a pricing change
A new selling, renewal, or expansion motion
New approval logic or commission plan
Trajectory-based
Pre-build for the next stage
Heading upmarket or toward usage billing? Get them ready for ramp deals , consumption pricing , and — for a frozen Salesforce CPQ org — an eventual, deliberate move onto Revenue Cloud . Preset it so they can turn it on.
Companion Reference

## Salesforce CPQ vs. Revenue Cloud.

The one decision this playbook keeps bumping into: a frozen CPQ org and where it goes next. We built a full
client-ready decision guide for it — the names, the timeline, the architecture, the honest gap list, and the
stay / migrate / greenfield verdict. Load it inline, or open it in a new tab.
leanscale-cpq-vs-revenue-cloud.netlify.app
Open ↗
▶
Load the decision guide
Loads the real guide inline. Or open it in a new tab ↗
What You Hand Over

## The assets, in one place.

The team gets this landing page with the brief, a one-paste prompt, and the template repo behind it. The client
gets a tool recommendation, a product & pricing spec, a wired CPQ, Looms, and an admin who owns it.
For the team

### Per-tool build guides + gotchas

Salesforce / Deal Hub / HubSpot build skills, IKEA install instructions, and the ripped-formula, ripped-gotcha library — enablement for our team and our agents.
The bet
CPQ is one of our most complex, most handcrafted projects — and the tooling in this category is immature enough
that a repeatable, opinionated playbook is the edge. Diagnose the pricing, pick the tool that fits
it, build to one standard, and enable so well the client barely needs us. This gets us ~60% of the way — the
rest we learn on every close-out and fold back in.
✓
Closeout

## Debrief the project.

When a CPQ engagement wraps, spend sixteen
minutes with the debrief agent. Teamwork already knows what got built and when. This is for the
part none of our systems can see — the call that could have gone either way, the thing the customer
wanted that you refused, the near-miss that never became an incident, and above all the places
this playbook turned out to be wrong. What comes out of it gets written back into this page.

### Before you start

Two minutes of thinking beats sixteen minutes of recall. Have these in your head —
you don't need notes, and you definitely don't need a script.
The tool call — which CPQ you landed on, whether you got to choose it, and whether this customer needed one at all.
Which of the six buckets bit you — and whether it showed up the way the playbook warns it will.
How far the amendment logic went — co-terming, mid-term changes, and where you drew the line on what not to build.
Sixteen minutes, one sitting. It's a voice conversation, so your browser will
ask for microphone access — use headphones or the agent will hear itself. Chrome is the safer bet
over Safari.

#### What this is, and isn't

It's a craft debrief , feeding straight back into this playbook.
It is not an assessment. Nothing here goes near performance review.
It's attributed — Anthony reads it with your name on it.
"This took two weeks longer than it should have because of X" is the most useful thing
you can say . Say it.

#### If it doesn't load

No mic prompt? Check the padlock in the address bar — the browser may have blocked it.
Agent talking over you? Headphones. It's hearing itself through your speakers.
Still stuck? Message Anthony rather than burning fifteen minutes on it.
The transcript takes a moment to generate after you hang up. You'll get a recap
emailed to you.

### Hand over the artifacts too

The debrief asks what you built that's worth reusing. This is where you actually hand it
over — dashboards, field maps, flows, templates, scripts, spec docs. Files land in the
project's Drive folder; links go into the artifact register so the next person can find them.
Thirty seconds, and do it while the project is still in your head.
“I'll upload it later” is exactly how assets end up trapped on an account.
Add an artifact →
LeanScale · Delivery OS
The CPQ playbook — the internal standard for diagnosing pricing complexity, picking the right configure-price-quote
tool, and building it to one standard across Salesforce, Deal Hub, and HubSpot. Blueprint, Build, Enable, Maintain.
Tool capabilities change every release — verify per-tool before you commit a customer.

#### The four phases

Blueprint — diagnose, decide, scope
Build — push or IKEA, sandbox, cutover
Enable — Looms, phased rollout, config tree
Maintain — triggers & the enablement paradox
www.leanscale.team

## Canonical

https://knowledge.leanscale.team/playbooks/cpq-playbook/