A CPQ implementation turns how you sell and price into rules Salesforce can enforce. Document how you price and clean the catalog first. Then build bundles, pricing, approvals and quote documents, and connect renewals and your ERP. Test with real deals before rollout. For a new project, the platform is Revenue Cloud, since Salesforce CPQ is end of sale for new customers. Existing CPQ orgs should read our migration guide first.
What are the phases of a CPQ implementation?
There are ten phases, and business decisions come before configuration in every one. Most delays come from starting the build before pricing logic is agreed.
- Discovery of how you sell and price: deal types, channels, discount habits and who can approve what.
- Product catalog cleanup: retire dead products and agree which ones stay live.
- Bundles and options: what requires, excludes or includes what, and how reps are guided through it.
- Pricing and discount rules: the order in which list price, tiers, agreements and discounts apply.
- Approvals: thresholds, approvers and what happens when someone is out.
- Quote templates and documents: layout, terms, languages and e-signature.
- Contracts, renewals and amendments: how an accepted quote becomes something you can change later.
- ERP and billing integration: which system owns orders, invoices and product data.
- Testing with real deals: rebuild recent quotes and compare the results.
- Rollout: one team, region or product line first, then expand.
If you are still choosing between standard Quotes, CPQ and Revenue Cloud, settle that first. Our guide to quoting options in Salesforce covers the choice. This article assumes you have made it.
How long does a CPQ implementation take?
It depends far more on your pricing complexity and data than on the software. The table below shows what tends to lengthen or shorten a project.
| Driver | Increases effort | Reduces effort |
|---|---|---|
| Product catalog | Many near-duplicate SKUs and products nobody has retired | A short, agreed list of live products |
| Pricing logic | Rules that live in spreadsheets or one person's head | Pricing written down and signed off by finance |
| Configuration rules | Deep bundles with many dependencies between options | Few bundles with simple required options |
| Revenue models | One-time, recurring and usage charges on the same quote | A single revenue model |
| Renewals and amendments | Active contracts that must migrate and co-term correctly | New business only in phase one |
| Integration | ERP or billing that must receive orders and return status | Quotes that finish in Salesforce for now |
| Decision-making | No single owner for pricing questions | One business owner with authority to decide |
| Channels | Partners or self-service buyers quoting alongside reps | Rep-led quoting only |
Two projects with the same product count can differ widely in effort. A scoped discovery phase, built on your real deals, is the honest way to get a timeline.
How do you prepare the product catalog and pricing data?
Clean it before anyone configures it. A CPQ project is often the first time every product, price and discount sits in one place, and the contradictions show.
Start with what you actually sold. Pull a year or two of closed deals and list every product, bundle and option on them. Anything not on that list is a candidate for retirement. Keep products that only exist for renewals, but mark them so reps cannot quote them to new customers.
Revenue Cloud uses an attribute-based catalog. A product can carry attributes such as size, tier or region instead of existing as separate SKUs. That can collapse many near-identical products into a few, but only if someone decides which differences are real. Do that grouping as a business exercise, with product management and finance in the room.
- Export the current price list and every discount schedule, including the ones in spreadsheets.
- Mark each product as live, renewal-only or retired.
- List every input that changes price: quantity, term, region, measurement, customer tier or usage.
- Write the pricing sequence in plain language, step by step, and get finance to sign it.
- Decide which system owns the product master and how new products reach Salesforce.
Price inputs are not always quantities. For a painting and construction company, guided selling calculates labor and materials from square footage by job type. Its painting, drywall, construction and mold-remediation divisions each have separate product catalogs and pricing. Capturing those inputs cleanly was as important as the prices themselves.
How should you design bundles and quote documents?
Model bundles the way customers buy, and keep documents simple enough to maintain. Both get harder to change once reps rely on them.
For each bundle, write down which options are required, which exclude each other and which are added automatically. Test those rules with the people who fulfill orders, since they know which combinations cannot be built. Guided selling questions help when reps do not know the catalog well.
Quote templates carry legal terms, branding and line detail. Agree one owner for template wording, usually sales operations with legal review. Decide how quotes are signed as well. The painting and construction company's estimators now produce professional quotes on iPads, with e-signature in the field.
How should CPQ approvals be designed?
Design approvals around risk, not habit. Route only the quotes that change margin, terms or exposure, and route them to someone who can decide quickly.
A rule that sends every quote to the CFO will be worked around within weeks. Tiered thresholds work better: by discount level, deal size, product line or non-standard terms. Decide which approvals can run in parallel and which must run in sequence. Name a delegate for every approver, so a vacation does not stall the quarter.
- Set thresholds from margin impact, not from round discount numbers someone picked years ago.
- Require a reason on every approval request, so the audit trail explains the exception.
- Re-trigger approval only when an approved quote changes in a way that matters.
- Test routing with deal desk staff before launch, using real edge cases.
Approval tooling differs between Salesforce CPQ and Revenue Cloud, and between editions. Confirm what your licenses include before you design complex multi-step chains.
How does CPQ integrate with ERP and billing?
Map one deal of each type from quote to invoice before you build anything. That map defines the integration scope and shows where identifiers must match.
Decide which system owns each record: product master, price list, order, contract, invoice and payment status. Then decide when data moves. Does an accepted quote create an ERP order at once, or after a credit check? What happens when a sync fails halfway? Include an amendment and a renewal in the walkthrough, because those break more integrations than new sales do.
Revenue Cloud Advanced adds contracts, consumption and invoicing on the platform. That can move billing into Salesforce, or you can keep it in your finance system. Either choice is valid, but it must be made before pricing is configured. Our ERP integration guide covers the patterns in more depth.
Quoting also connects to delivery. At the painting and construction company, approved timesheets flow into work orders and opportunities. Managers see job costs against the estimate in real time, with budget alerts.
How should you test a CPQ implementation?
Test with real deals, not invented ones. Rebuild a set of recently closed quotes in the new system and compare totals, terms and approval routing with what was actually sent.
- Pick deals across every product line, region, channel and revenue model.
- Include the awkward ones: large discounts, non-standard terms and multi-year ramps.
- Run an amendment and a renewal on migrated contracts, then compare against billing.
- Check the ERP or billing side, not only the quote total.
- Have deal desk staff flag which historical quotes were exceptions.
Every discrepancy is useful. It usually means a rule was misunderstood or was never written down. Fix the rule, record the decision, and re-run the whole set, since pricing changes often have side effects.
Why do CPQ implementations fail?
Most fail on business decisions, not technology. Pricing that nobody owns, a catalog nobody cleaned and renewals nobody tested cause more trouble than any configuration.
- Configuration starts before pricing logic is agreed, so rules are rebuilt as opinions change.
- Sales designs pricing alone, and finance later finds conflicts with how revenue is recognized.
- The old catalog is migrated unchanged, carrying years of clutter into the new system.
- Legacy CPQ rules and scripts are copied line by line instead of redesigned for Revenue Cloud.
- Approvals are added last and either fire on every quote or on none.
- Active contracts are loaded late, and the first renewal cycle produces wrong quantities.
- The ERP integration is scoped after the build, so orders still get re-keyed.
- Nobody owns the catalog after go-live, so it decays within a year.
How should you scope phase one?
Scope phase one around one sales motion that works end to end. A narrow scope that reaches the ERP beats a broad one that stops at the quote.
Pick one product line, region or team. Include its catalog, pricing, approvals, quote document and the handoff to fulfillment or billing. Leave partner quoting, usage pricing or a second division for later phases, unless they are the main reason for the project.
- Choose a segment with a supportive sales leader and stable pricing.
- Agree what stays manual in phase one, and write it down.
- Decide how in-flight quotes and open renewals are handled on cutover day.
- Name post-launch owners: a deal desk lead, a finance lead and a trained admin.
- Set a change process, since a small rule change can alter thousands of future quotes.
Once phase one quotes correctly and finance trusts what arrives downstream, expand one segment at a time. Each new segment is faster, because the catalog, pricing and approval patterns are already proven.
