Picture the quote for a production line upgrade. It includes the equipment and the commissioning labor. It also includes a multi-phase rollout, operator training days and a service agreement that bills monthly for five years. Each of those pieces is priced differently, and the customer still expects one clear number. This article explains where solution selling CPQ requirements diverge from how Salesforce CPQ (configure, price, quote) models a deal. It also shows how to decide whether your current setup can handle the next three years of mixed-revenue quoting.
TL;DR
- Salesforce CPQ is end of sale, not end of life. Salesforce stopped selling it to new customers in March 2025. Existing customers can still use it, renew it, add users and receive support. No end-of-life date has been announced.
- For solution sellers, the practical issue is modeling, not product status. One quote may mix hardware and services, labor pricing, project-based quoting, recurring revenue and usage charges. That mix stresses a bundle structure built around subscription line items.
- The usual symptoms are workarounds, not outages. Services get priced in spreadsheets and pasted back, and labor gets estimated offline. Margin only becomes visible after the quote is assembled. Quote Calculator Plugin (QCP) code ends up carrying logic that business rules should own.
- You have three paths:
- Stay on Salesforce CPQ.
- Reimplement on Revenue Cloud Advanced (RCA).
- Keep Salesforce CRM as the system of record and replace only the quoting layer with a configurator built for complex, mixed-revenue solution bundles.
- Bottom line: map your revenue streams against one real solution quote before you choose a platform. If more than half the quote's value is assembled outside the CPQ, you are paying for the modeling gap, not the license.
What Solution Selling Actually Demands From CPQ
In solution selling, the unit of sale is an outcome, not a SKU. That changes what a CPQ has to calculate. A customer buying a production line, a fleet upgrade or a managed facility is buying more than equipment. The deal also includes commissioning, training days, a project schedule and a service contract that bills monthly for five years.
That single quote has to resolve several different pricing models at once:
- One-time hardware pricing, often configured and cost-rolled from components
- Labor pricing by role, rate card, region and estimated hours
- Project-based quoting with phases, milestones and deliverables that carry their own margins
- Recurring revenue lines with start dates, terms, escalators and renewal behavior
- Usage or consumption charges that are forecast rather than fixed
The mechanics of putting products, services and subscriptions in one deal are a topic of their own. What sets solution selling apart is the labor, the project structure and the rules that connect them to the equipment.
Each stream has a different margin profile and a different downstream consumer:
- Finance needs the recurring portion separated for revenue recognition.
- Operations needs the labor and project scope to plan capacity.
- Manufacturing needs the configured hardware as a bill of materials (BOM) it can actually build.
- Sales needs one number the customer understands.
Where the modeling breaks first
The configurator is rarely the first thing to break. The first failures happen in the connective tissue. For example, a rule might say: if you selected this equipment class and this service tier, commissioning requires these labor hours at this rate in this region. When that rule lives in a rep's head or a sales engineer's spreadsheet, the quote is only as good as the person assembling it.
How Salesforce CPQ Models a Mixed Deal, and Where That Design Strains
Salesforce CPQ handles moderate-complexity quoting well, and it is reasonable to keep using it for that. Its bundle and subscription model is mature, and its approval framework is familiar. It does the job for catalogs with manageable option counts and predictable service attachments.
The strain shows up along specific, identifiable design lines.
Bundle structure built for subscription-first thinking
Salesforce CPQ's product and option model is strongest when the deal is a configurable subscription with add-ons. Mixed revenue forces that model to stretch:
- Labor becomes a product whose quantity really means hours.
- A project phase becomes a bundle that really means a schedule.
- Nested bundles multiply option records, and large configurations get heavier to calculate as the catalog and rule count grow.
Rule maintenance and custom logic accumulate
Product rules and price rules cover a lot. But solution pricing often needs conditional math that does not fit declaratively. Examples include rate-card lookups, effort estimates driven by configuration attributes and margin floors that vary by revenue stream. That logic tends to migrate into the Quote Calculator Plugin.
QCP works, but it is code inside a managed package. It needs developers and regression testing at every release. It also becomes a migration liability later.
Margin visibility arrives late
Hardware often comes from the configurator, services from a spreadsheet and recurring lines from manual entry. When that happens, blended margin is something you calculate after the quote exists. You cannot steer it while you build the quote. Discount guardrails and threshold-based approvals can only govern what the system can see.
The downstream handoff
A solution quote has to become something operational: an order, a project plan and a service contract. In manufacturing, it also has to become an ERP-ready BOM (enterprise resource planning). When the quote's structure does not carry that detail, someone rebuilds it after close. That rebuild is where quote-to-contract drift starts.
Three Honest Paths for Salesforce CPQ Customers
Nothing forces existing Salesforce CPQ customers to migrate, so treat this as a portfolio decision rather than a deadline. Below is a short view of each path through a solution-selling lens. The full comparison of the three paths covers each one in more depth.
Stay on Salesforce CPQ
Staying is defensible when your solution bundles are stable, your services attach predictably and your QCP footprint is small. You keep a known system, a trained admin team and your existing approval workflows.
The trade-off is that Salesforce CPQ no longer receives meaningful new feature development. Any capability gap you have today, you will most likely still have in two years. Budget honestly for the workarounds and revisit the decision every year.
Reimplement on Revenue Cloud Advanced
Salesforce's strategic investment has moved to Revenue Cloud Advanced, now part of Agentforce Revenue Management. It is the forward path inside the Salesforce ecosystem. It has a broader revenue lifecycle scope, including billing and revenue management, plus an attribute-based catalog and a different data model.
The important caveat is scope. Moving from Salesforce CPQ to RCA is a reimplementation, not an upgrade. Catalog, rules, approvals, templates and integrations are redesigned rather than ported. RCA is the right investment for organizations whose priority is a unified revenue platform and whose configuration needs are moderate.
Keep Salesforce CRM and replace only the quoting layer
The hard part of your business may be the configuration and the mixed-revenue math rather than billing. If so, you can keep Salesforce CRM as your system of record and change only where configure, price, quote happens. This limits how much of your system the project touches. Accounts, opportunities, forecasting and reporting stay where they are. The project focuses on product modeling, pricing rules and document output.
How Experlogix CPQ Approaches Mixed-Revenue Solution Quoting
Experlogix CPQ integrates with Salesforce CRM and runs inside the Salesforce workflow. Reps configure, price and quote in the opportunity and account context they already know.
Keeping Salesforce CRM as the authoritative system of record avoids copying records into a separate platform and syncing them back. That copy-and-sync pattern brings stale records, sync failures, duplicates, reporting built on copies and extra middleware to maintain.
For solution selling specifically, the relevant depth is in the modeling layer:
- A logic-driven rules engine for complex, configurable products, with dependencies and constraints that keep configurations valid
- Guided selling that steers users toward valid, complete solutions instead of leaving attachment decisions to memory
- A low-code rule builder, so business users and admins can add products, adjust pricing rules and change logic without depending on developers
- Multi-level BOM generation, routing validation and ERP handoff, so a configured hardware solution becomes something production can act on
- Automated approval workflows tied to margin and discount thresholds, so margin control applies to the assembled quote
- Quote and proposal document generation tied to the configured quote
On the services side of a solution quote, Experlogix CPQ is built for engagements that are scoped from several inputs:
- Labor categories
- Skill-based rates
- Deliverable definitions
- Timeline dependencies
Instead of rebuilding each scope from old statements of work, CPQ can generate a work breakdown structure (WBS) from libraries of service templates organized by engagement type. Each template contains pre-validated work packages with estimated effort ranges. Consultants see whether a quote hits target margins while they are configuring it. Quotes below target margins trigger approval workflows.
The same mechanics apply when equipment manufacturers move toward servitization. Hybrid product-and-service deals bring multiple pricing models, labor scoping, fragmented margins and longer contract lifecycles.
Be clear about fit. A deep configurator is not the constraint you need to solve in these cases:
- Your catalog is simple.
- Your sales motion is self-service SaaS.
- Your organization has already committed to a Revenue Cloud Advanced reimplementation for billing and revenue lifecycle reasons.
The Bottom Line on Solution Selling CPQ After Salesforce CPQ End of Sale
Salesforce CPQ remains usable, renewable and supported, and end of sale does not require you to move. The question that matters for solution sellers is narrower. Can your quoting layer model hardware and services, labor pricing, project-based quoting, recurring revenue and usage charges inside one governed structure? Or does it assemble part of the deal and leave the rest to spreadsheets?
Judge the answer with three criteria:
- Completeness: What percentage of total quote value does the system calculate, rather than someone entering it manually?
- Governability: Can approvals, discount guardrails and margin thresholds see every revenue stream on the quote?
- Ownership: Can your admins change a rate card, add a service tier or adjust a solution bundle without a developer or a consultant invoice?
Teams that close this gap get something concrete in return:
- A quote that also works as an operational document
- Margin that is visible while the deal is being built, not after
- Admins who can respond to pricing changes directly
You might get there by staying on Salesforce CPQ, reimplementing on Revenue Cloud Advanced or replacing only the quoting layer while keeping Salesforce CRM. Either way, the evaluation method is the same.
Start with one artifact. Take your hardest real solution quote from the last quarter, the one with equipment, labor, a project schedule and a recurring component. Map every line to where its number actually came from, and mark each one as system-calculated, spreadsheet-derived or expert judgment. That single page will tell you more about your CPQ strategy than any feature comparison.
Veelgestelde vragen
What is solution selling in CPQ?
Solution selling in CPQ means quoting an outcome rather than a single SKU. One quote combines configured hardware, labor, project phases, recurring service agreements and sometimes usage charges. The CPQ has to price each stream correctly, apply the rules that connect equipment choices to the service scope and still produce one number the customer understands.
How should CPQ price labor and professional services?
Labor should be priced by rules, not by spreadsheets. Rules can price by role or labor category, skill-based rate, rate card, region and estimated effort. Ideally the effort is driven by what was configured. For example, a given equipment class and service tier should automatically imply a set of commissioning hours at the right rate. Experlogix CPQ supports services quoting built from labor categories, skill-based rates and deliverable definitions. It also calculates margin in real time as the quote is configured.
Can CPQ quote project phases and milestones?
Yes, when the CPQ can carry project structure rather than treating a phase as a generic bundle. Phases, milestones and deliverables should each carry their own effort and margin, so the quote can become a project plan after close. Experlogix CPQ can generate a work breakdown structure from service templates. For example, a system integration project might be generated with five phases: Discovery, Design, Build, Test and Deploy. Each phase includes deliverable-based work packages that the consultant can adjust.
How do you measure whether your CPQ supports solution selling?
Use three criteria:
- Completeness: the share of total quote value the system calculates rather than someone entering it manually
- Governability: whether approvals, discount guardrails and margin thresholds can see every revenue stream
- Ownership: whether admins can change rate cards, service tiers and solution bundles without developers or consultants
A practical test is to map your hardest recent solution quote line by line. Mark each line as system-calculated, spreadsheet-derived or expert judgment.
Quote the Whole Solution, Not Just the Hardware
