Playbook · CPQ

The CPQ playbook.

Everything an architect or engineer needs to run one of these projects end-to-end — Blueprint → Build → Enable → Maintain. One of the beefiest, most handcrafted motions we run: configure, price, quote. Start with the five-minute audio brief, then open the repo.

4Phases
6Tools mapped
PricingDecides everything
SandboxNo exceptions
Watch or listen first · 5 min

The audio brief.

One narrator, five minutes, the whole shape of the project — now with the deck that runs alongside it. Play it before you open anything else; it's the fastest way to get into the right mindset for a CPQ build. In a hurry? Change the speed under the deck — it sticks next time.

0:00 / 0:00
Speed
1 / 1
Chapter 1 Narrated brief · generated with ElevenLabs · Download ↓
Chapters
The whole idea

The tool is never the first question. How complex their pricing is decides everything — which tool we recommend, how hard the build is, and whether they even need a CPQ at all.

The Shape

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.
OutputTool pick + config spec
2
Build
Configure it — push where there's an API, IKEA-instructions where there isn't. In a sandbox, always.
OutputLive config, cut over safely
3
Enable
Looms for everything, a phased rollout, a visual config tree, and a named client-side admin.
OutputA team that owns it
4
Maintain
Handle the ad-hoc ripple, watch config drift, and teach them to self-serve.
OutputConfig 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 
# 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

A customer-specific repo

The clone becomes part of the customer's brain — every product, rule, and tool decision from this project informs their agent for the next one.

Inside it

Skills, an AGENTS.md + a gotchas library

Per-platform build guides for Salesforce, Deal Hub, and HubSpot, IKEA install instructions, and a repo of real formulas and gotchas ripped from past builds.

1
Phase 1

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 — RunPod-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. Mistral 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 tool recommendation

The decision and the why — which tool, driven by the pricing complexity, and exactly what they give up by choosing it. Includes any license upgrades (e.g. HubSpot code nodes).

02

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

Salesforce flows & rules

The amendment-cascade automations, uplift flows, expansion/renewal logic — the patterns that update the quote, opp products, opp, and contract ARR in lockstep.

Reuse

Deal Hub formulas & templates

The product-import Excel template, repeatable-table filters, and the co-term field scaffolding — the stuff their own docs won't teach you.

Gotcha

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

What kicks off maintenance.

Any one of these reflows the CPQ, its rules, the revenue fields, and often the approvals.

Trigger

New product

A new SKU means new groupings, pricing, bundles, and validations to allow (or block).

Trigger

Pricing-rule change

New prices or a new pricing model — reflows the config and the revenue math.

Trigger

Rep-rule change

New guardrails on what a rep can configure, discount, or combine.

Trigger

Approval change

A new threshold or a new approver in the manager → exec → finance → product chain.

Trigger

Packaging / bundle change

New bundles or product combinations — new configurations to permit or restrict.

Trigger

A new / changed motion

A new way to sell, renew, or expand needs its own logic and guided path.

4.2 · The Enablement Paradox

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 ↗
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

This landing page + brief

The playbook overview and the 5-minute audio brief — the front door for anyone running a CPQ project.

For the team

The one-paste prompt

Clone-for-customer → AGENTS.md drives the Blueprint checklist, starting with the pricing-complexity diagnosis and the tool decision tree.

For the client

Tool pick + config spec

The three Blueprint deliverables — signed off before Build, inherited by their admin after.

In the repo

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.

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 →