CPQ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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.

• 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.

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