If you're running Salesforce Sales Cloud with a legacy CPQ build, you're probably dealing with a familiar mix of strengths and friction. Quotes still go out. Approval paths still work. But every exception, custom rule, billing edge case, and integration touchpoint now carries more strategic weight than it did a few years ago.
That’s the practical reality of steelbrick salesforce cpq today. It isn’t just a product story. It’s a RevOps decision about whether your current quote-to-cash process still supports how your business sells, prices, renews, reports, and scales.
For teams in California, the question gets more specific. Salesforce-heavy B2B organisations often have dense integration layers across Sales Cloud, Account Engagement, HubSpot, finance systems, partner workflows, and tax logic. When a CPQ platform shifts from growth product to legacy product, those dependencies matter fast.
The SteelBrick Legacy and Salesforce CPQ Evolution
SteelBrick mattered because it solved a problem that many B2B sales teams had normalised. Reps were building quotes through spreadsheets, workaround fields, approval emails, and disconnected templates. Sales ops owned pricing logic in one place, finance kept contract nuance elsewhere, and CRM data quality suffered in the middle.
That’s why the early native architecture was important. SteelBrick wasn’t just another quoting layer. It lived on Salesforce, which made it much easier to align quoting with opportunities, products, approvals, and reporting.
From QuoteQuickly to Salesforce CPQ
The origin story explains a lot about the product’s DNA. SteelBrick began in 2009 as QuoteQuickly. By 2010, it had only about five customers and $10,000 in revenue, then rebranded to SteelBrick CPQ in 2014 and later reached 300% year-over-year revenue growth by Q4 2015, which helped drive Salesforce’s acquisition and the move toward a more unified Quote-to-Cash approach with billing capabilities (salesforce cpq history).
That sequence matters for operators because it shows what the platform was built to do well. It was designed for fast, structured quoting inside the Salesforce ecosystem. It wasn’t originally built as a broad revenue platform with every downstream process under one roof.
A lot of teams still refer to the platform as SteelBrick, even when the product name in the org is Salesforce CPQ. In practice, those references usually point to the same architectural lineage.
Why the native model changed adoption
When product catalogues got more complicated, the cost of bad quoting rose quickly. Bundles, subscription terms, partner discounts, implementation fees, usage components, and negotiated contract pricing don’t fit neatly into a simple opportunity amount field.
Native CPQ changed that. It gave RevOps teams a way to:
- Keep product logic in Salesforce instead of across disconnected files
- Tie approvals to actual pricing rules rather than rep judgement alone
- Improve forecast confidence because quote structure matched CRM structure
- Reduce rework for finance when the sold deal reached contracting or billing
The biggest operational win wasn’t prettier quotes. It was getting sales, finance, and CRM reporting to speak the same language.
If you're evaluating adjacent roles or specialist implementation support, the broader Salesforce category gives useful context on the breadth of Salesforce talent and solutions.
Where SteelBrick sits now
The legacy is strong, but the market moved. Salesforce ended sales of legacy SteelBrick CPQ by Q1 2025 as it shifted customers toward Revenue Cloud (salesforce cpq history). For current users, that doesn’t erase the value SteelBrick created. It does change how you should think about roadmap, support horizon, and future-fit architecture.
That’s the key distinction. A platform can still be valuable in production and still be the wrong place to add more complexity.
Unpacking Core CPQ Capabilities for Modern RevOps
A rep in California builds a quote that looks right on screen, wins internal approval, and then stalls because the services mix cannot be delivered under the customer’s term structure. That is the kind of failure RevOps inherits when CPQ is treated as a quoting add-on instead of a control point for the commercial model.
When Salesforce CPQ works, configure, price, and quote all reinforce the same operating rules. Sales moves faster, finance sees cleaner inputs, and downstream teams spend less time correcting what should have been prevented upstream.
Configure means controlled selling
Configuration is where product strategy becomes operational policy. Reps select products, bundles, options, quantities, and commercial terms inside a guided flow instead of building deals from memory or copying an old quote.
That matters most in businesses with mixed revenue models. SaaS subscriptions, onboarding services, support tiers, partner pricing, renewals, and usage-based components create edge cases quickly. In practice, invalid configurations do not stay in sales. They spill into provisioning, billing, and renewals.
Useful configuration design usually includes:
- Bundle rules that require the components needed to deliver what was sold
- Exclusion rules that block combinations your team cannot support or invoice correctly
- Guided selling prompts that help reps choose the right package for the buyer’s scenario
- Term alignment rules that keep subscription dates, services timing, and contract structure consistent
I see the same trade-off in many CPQ projects. Teams want to encode every exception because each one feels justified. The better approach is to govern the common selling paths well and route true exceptions through review. That keeps the catalog usable and the rule set maintainable.
Price means one pricing policy the business can defend
Pricing is where trust is won or lost. Salesforce CPQ can support pricing methods such as volume-based pricing, percent-of-total calculations, contracted account pricing, and approval controls within the same framework, as noted earlier from the SteelBrick and Salesforce CPQ overview.
For RevOps, the benefit is governance as much as speed.
A pricing engine should give the business one place to manage list price, contracted price, partner terms, promotional logic, and approval thresholds. If those decisions live partly in Salesforce, partly in spreadsheets, and partly in rep habit, approvals stop being a policy control. They become a rescue function.
| CPQ pricing function | Operational benefit |
|---|---|
| Volume pricing | Keeps pricing logic consistent across teams and territories |
| Percent-of-total pricing | Supports services or add-ons tied to the value of the core product |
| Contracted pricing | Preserves negotiated account terms without manual rework |
| Approval thresholds | Reduces margin leakage and keeps exceptions visible |
For California businesses, this has a practical angle beyond process hygiene. Multi-entity selling, reseller arrangements, and services sold alongside subscriptions often create tax, invoicing, or booking complications if pricing logic is inconsistent. RevOps should design pricing rules with finance and legal in the room, not after deployment.
Practical rule: If reps still ask Sales Ops how to price common deal shapes, the pricing model is incomplete.
Quote means a reliable handoff to the rest of revenue
The quote is the customer-facing output, but the operational value sits behind it. A clear quote helps the rep close. A well-structured quote also gives legal, finance, customer success, and billing a usable record of what was sold, on what terms, and with which dependencies.
That reduces a specific class of downstream issues. Teams see fewer contract corrections, fewer invoice disputes, weaker chances of revenue leakage, and better renewal context because the original commercial structure is easier to trust.
Quote design should reflect how the business delivers and bills, not just how marketing wants the document to look.
What modern RevOps teams should assess now
For existing SteelBrick and Salesforce CPQ users, the primary question is not whether the platform can generate a quote. It is whether the current design still supports the business you run today and the migration path you may need next.
In healthy deployments, CPQ reduces manual work without shifting complexity to finance, support, or billing. Product rules stay understandable. Approval paths reflect policy. Quote templates match commercial reality. Ownership is clear between RevOps, finance, and the Salesforce admin team.
What usually works:
- A focused set of product and pricing rules that cover standard deal patterns
- Clear ownership across RevOps, finance, legal, and Salesforce administration
- Approval logic tied to margin, term risk, or policy exceptions
- Quote templates built for customer clarity and downstream processing
What usually fails:
- Encoding every historical exception into the system
- Using CPQ to compensate for unresolved product packaging problems
- Letting business units create unmanaged custom logic
- Designing quotes without considering billing, provisioning, or contract operations
The strongest CPQ setup is not the most complex one. It is the one your team can govern, explain, audit, and adapt as your quote-to-cash process changes.
Driving ROI with Strategic CPQ Use Cases
A California SaaS company misses quarter-end because sales can produce quotes, but finance cannot trust them. Product bundles vary by rep. Discounts sit in email threads. Amendments take longer than new business. In that situation, CPQ ROI comes from control and throughput across the revenue process, not from prettier quote documents.
For RevOps leaders still running SteelBrick or Salesforce CPQ, the best use cases are the ones that remove recurring friction in quote-to-cash and create a cleaner path to migration later. If a use case saves time for sales but adds reconciliation work for billing or order management, it is a weak ROI story.
Use case one with complex product catalogues
Complex catalogues are where CPQ usually proves its value first. This is common in California B2B firms selling subscription products with add-ons, implementation services, partner pricing, and term variations.
When product selection depends on rep memory, pipeline quality degrades fast. Quotes go out with incompatible options, services get missed, and downstream teams spend time correcting basic packaging errors. A well-structured CPQ flow reduces quote creation time and standardises how reps assemble valid offers, which is one reason many teams saw measurable gains from SteelBrick deployments in the market (regional SteelBrick CPQ benchmarks).
The practical RevOps payoff shows up in four places:
- fewer quote corrections before signature
- less manual help from sales ops
- cleaner handoff from opportunity to quote
- better visibility into which packages sell
That matters during migration planning too. If the current catalog is chaotic, a new CPQ platform will expose the same problem rather than fix it.
Use case two with controlled discounting
Discount governance is one of the clearest ROI cases because it affects margin, approval speed, and forecast confidence at the same time.
I usually see two failure modes. Either reps have too much freedom and finance learns about pricing issues after the quote is out, or approval paths are so slow that sellers bypass process to keep deals moving. Neither scales well, especially for California companies with multi-entity approval policies, reseller arrangements, or stricter review requirements on contract terms.
CPQ improves this when pricing logic is tied to policy. Approval thresholds, floor prices, term exceptions, and regional rules should sit inside the quoting workflow so reps know what will pass before they send the quote.
The goal is disciplined speed.
Faster approvals inside guardrails often improve win rates more than broad discount flexibility because the buyer gets a credible, approved quote sooner and internal teams avoid rework.
Use case three with product expansion
Expansion revenue often gets lost in execution, not strategy. Teams know which add-ons should attach. Reps just do not introduce them consistently, especially late in the cycle when they are trying to close.
Guided selling helps if it is selective. Start with pairings that have a clear commercial rationale and operational support behind them. If support, billing, or provisioning cannot deliver the added product cleanly, do not force it into the quote flow just to raise average deal size.
Good starting points include:
- Core platform plus onboarding
- Subscription plus premium support
- Channel sale plus partner-specific services
- Renewal quote plus expansion module
RevOps judgment matters in this situation. A few high-confidence prompts usually outperform an oversized ruleset filled with edge-case suggestions that reps learn to ignore.
Use case four with large and messy quotes
Large quotes create a different kind of ROI case. The issue is less about seller convenience and more about operational resilience.
Teams selling detailed service packages, large catalogues, or enterprise agreements with many line items need a quoting process that can handle scale without introducing errors, delays, or reporting noise. SteelBrick was often used in these environments because it could support high line-item volumes. The more important question for RevOps is whether the underlying quote design still works when the transaction gets complex.
Large quotes expose structural problems quickly:
- duplicate or unclear SKUs
- inconsistent naming conventions
- overlapping bundle logic
- weak ownership between sales, finance, and operations
If those issues exist, CPQ can process the quote but still leave the business with contract confusion, billing exceptions, and poor renewal data.
How to present the ROI internally
Leadership rarely approves CPQ work because the product catalog is hard to manage. They approve it because revenue execution is slow, margins drift, and handoffs break.
Frame the case around operating outcomes and migration readiness.
| RevOps concern | CPQ outcome |
|---|---|
| Slow quote turnaround | Faster quote creation and approval flow |
| Margin inconsistency | Better discount governance |
| Weak expansion motion | Guided cross-sell and upsell prompts |
| Forecast distrust | Cleaner opportunity and quote structure |
| Sales ops bottlenecks | Less manual intervention |
For existing Salesforce users, that is SteelBrick's enduring legacy. It turned pricing and packaging into an enforceable operating model. The next step is deciding which use cases still deserve investment, which ones should be simplified, and which ones belong in the architecture you adopt after the sunset.
Navigating the SteelBrick CPQ Sunset
A sales team closes a complex deal on the last day of the quarter. Finance catches a pricing exception after the quote is signed. Ops discovers the approval path lives in an old custom rule nobody fully understands. That is the core SteelBrick sunset problem for many Salesforce teams. The risk is not the product name changing. The risk is running core revenue operations on logic the business can no longer explain or safely extend.
What the sunset changes in practice
The end-of-sale milestone changes how RevOps should evaluate every request that touches quoting, pricing, approvals, and downstream billing. Once a platform is in legacy status, new custom work stops being a simple enhancement decision. It becomes a carry-forward decision.
For existing Salesforce users, that means asking a harder question before approving any change. Will this logic survive a migration, or are you paying to preserve debt?
I usually advise clients to separate changes into two groups. The first group protects current revenue execution, such as fixing approval failures, correcting contract output, or stabilizing integrations. The second group adds new commercial complexity, such as custom pricing models, exception-heavy bundles, or one-off partner logic. The first group may be necessary. The second group needs executive review.
Delay has a cost, even if the system still works
A wait-and-hold strategy can be reasonable if quoting is stable, the catalog is controlled, and the business is not changing pricing structure every quarter.
That is not the situation I see most often.
Many SteelBrick environments are still absorbing changes from packaging updates, new finance controls, billing requirements, and regional sales motions. In California, that pressure is often higher because companies are balancing subscription, services, partner resale, and tax handling in the same quote-to-cash flow. Each new exception makes the eventual migration harder to scope, harder to test, and harder to govern.
The immediate issue is not only technical debt. It is operating debt. Admin time rises. Approval paths become less reliable. Revenue reporting starts depending on workaround fields and manual interpretation. Contracting and billing teams spend more time correcting transactions that should have been structured properly upstream.
California-specific constraints deserve their own planning track
California-based firms often have a denser set of dependencies around CPQ. Multi-entity operations, local tax treatment, partner channels, and tight connections between Salesforce and the broader martech stack can turn a standard migration into a commercial redesign project.
Treat that as a planning requirement, not an implementation surprise.
I recommend a separate workstream for California-specific exceptions. Document tax-sensitive products, usage or consumption pricing, reseller motions, contract language dependencies, and any quote data that feeds ERP, billing, or recognition workflows. A clean inventory of those items will do more for migration accuracy than another round of UI tweaks in the legacy system. Teams that need a structured sequence for that work should build a formal project roadmap.
The practical decision framework
Most companies are choosing among three paths, but the right choice depends less on software preference and more on business volatility.
Contain the current SteelBrick build
Use this path if the commercial model is stable, the rule set is documented, and the business needs time to prepare. Success depends on strict change control. No speculative customizations. No new quote logic without an end-state owner.Move to Revenue Cloud inside Salesforce
Use this path if leadership wants tighter alignment across quoting, billing, renewals, and revenue operations in one ecosystem. The trade-off is implementation effort. Teams usually need to simplify old exceptions before the new model becomes manageable.Choose a different CPQ architecture
Use this path if the current Salesforce-centered design no longer fits how the business sells, bills, or supports channel complexity. This can reduce admin strain, but only if integration ownership is clear and the data model is redesigned with downstream processes in mind.
The wrong move is carrying every historical rule into the next platform. The right move is deciding which rules still reflect how the business sells today.
A short migration-readiness checklist
Before approving another quarter of legacy investment, answer these questions:
- Which pricing and approval rules are still active, and who owns each one?
- Which SteelBrick customizations exist only because another system was never fixed?
- Which quote fields drive finance, billing, provisioning, or renewal processes downstream?
- Which exceptions are specific to California operations and which are global?
- Which data objects need cleanup before migration starts?
If those answers are incomplete, start there. Our team usually pairs this review with a data migration assessment and cleanup plan so the eventual platform decision is based on process truth, not assumptions.
The SteelBrick legacy was never just feature depth. It was control over how revenue moved from quote to contract. The sunset forces a more disciplined question. Which parts of that control model still deserve to exist in your future architecture, and which parts are expensive history?
Best Practices for CPQ Migration and Integration
A California sales team closes the quarter on a Friday, then spends the next week fixing quote errors, tax exceptions, and approval paths that no longer match how the business sells. That is the primary migration problem. The platform change only exposes it.
SteelBrick estates usually carry years of pricing exceptions, channel one-offs, and downstream dependencies into billing, finance, and reporting. A migration goes well when the team treats CPQ as revenue infrastructure, not just a quoting tool.
Start with process evidence
Screenshots of the current setup are not enough. RevOps needs evidence from live deals, approval logs, amendment patterns, order handoffs, and finance exceptions. That is how you separate design intent from actual operating behavior.
Document five things early:
- What sellers are expected to do
- What admins changed to keep deals moving
- What finance requires before an order can move downstream
- What legal or deal desk reviews repeatedly
- What channel or California-specific exceptions recur
I usually push clients to review recent quotes across direct, partner, renewal, and amendment scenarios. If a pricing rule exists in production and nobody can tie it to a current commercial policy, it should not get a free pass into the new design.
For teams sequencing discovery, redesign, and rollout in phases, a structured project roadmap helps clarify dependencies before build work starts.
Map the data model around commercial meaning
Field mapping matters, but it is rarely the hard part. The harder question is whether the current product, pricing, and contract structures still reflect the business you are running now.
A bundle may exist because sales wanted speed three years ago. A discount field may exist because finance lacked a cleaner control point. A custom quote object may be carrying information that belongs in billing or provisioning. If you migrate those patterns without review, you preserve technical debt and call it progress.
This is also where California requirements deserve explicit review. Tax treatment, entity structure, reseller arrangements, and approval controls often differ from the rest of the business. Handle those cases deliberately instead of burying them in custom rules that nobody wants to own later.
If your team needs a practical reference for cleanup and transfer planning, use these data migration best practices for CRM and RevOps projects.
Put integrations in scope from day one
Integration mistakes are expensive because they show up after go-live, when quotes stop flowing cleanly into contracts, billing, or reporting.
Map every handoff the quote touches. That usually includes Salesforce objects, ERP or billing platforms, e-signature, tax engines, subscription systems, partner workflows, and marketing attribution if leadership expects quote data in pipeline reporting. In Salesforce environments, I also look closely at whether Account Engagement, HubSpot, or custom lifecycle reporting depends on CPQ-generated fields that were never formally governed.
Teams that delay this work usually end up rebuilding quote logic twice. Once in CPQ, then again in integrations.
Build governance before configuration
A migration team needs more than an admin and an implementation partner. It needs decision-makers who can resolve trade-offs quickly.
Include these groups early:
- Sales leadership to validate approval design and selling motion
- RevOps to own process design, reporting, and system accountability
- Finance to define pricing controls, order handoff, and revenue implications
- Legal or deal desk to review contract exception patterns
- IT or enterprise systems to manage integration standards and support model
- Marketing operations if quote data affects attribution or lifecycle reporting
The practical question is simple. Who can say no to an exception request when it creates long-term maintenance cost? If that answer is unclear, the new platform will inherit the same governance problem as SteelBrick.
Evaluate the target architecture based on operating fit
Revenue Cloud may be the right destination. It is not automatically the right answer.
Some Salesforce customers need deep native alignment because quoting, approvals, account hierarchy, and renewals all need to stay tightly coupled to the CRM. Others are carrying complexity that would be easier to manage in a best-of-breed CPQ paired with a cleaner integration layer. The deciding factor is not feature volume. It is operational fit across sales, finance, support, and partner channels.
At MarTech Do, we usually guide clients through three decision filters: what must stay native in Salesforce, what should move into a cleaner commercial model, and what should be retired entirely. That approach keeps the migration grounded in business design instead of loyalty to legacy architecture.
Your RevOps Action Plan for Quote-to-Cash Excellence
If your organisation is still on steelbrick salesforce cpq, the right move isn’t panic. It’s disciplined assessment followed by deliberate execution.
The teams that handle this well don’t start by choosing a product. They start by clarifying what their quote-to-cash process must do for the business over the next few years.
Audit the current state
Start with evidence, not assumptions.
- Catalogue your live CPQ logic. Document active product rules, price rules, discount schedules, approvals, templates, and renewal processes.
- Find manual interventions. Ask sales ops and finance where they still step in after quote generation.
- Review integration dependencies. Map how CPQ data flows into Sales Cloud, Account Engagement, HubSpot, billing, and reporting.
- Identify recurring exception patterns. If the same exception appears repeatedly, it usually signals a broken commercial design rather than a one-off request.
A current-state audit should also look at reporting quality. If quoting logic and opportunity reporting don’t align, leadership is likely making decisions on incomplete or distorted signals.
Define the future state
At this point, teams often move too quickly. A migration target should match your operating model, not just vendor direction.
Use decision criteria such as:
| Decision area | Questions to answer |
|---|---|
| Commercial complexity | Do you need only quoting discipline, or broader revenue lifecycle control? |
| Admin capacity | Can your internal team support a more complex platform long term? |
| Integration model | How tightly must CPQ connect with MCAE, HubSpot, finance, and reporting? |
| Change readiness | Can sales and finance absorb process redesign now? |
If Revenue Cloud is in scope, assess it against your actual process needs, not just roadmap pressure. This overview of Salesforce Revenue Cloud is useful when you're comparing legacy CPQ with a broader revenue platform.
Execute with tighter control than you think you need
Execution discipline matters more than ambition.
A strong rollout usually includes:
A prioritised rule set
Rebuild the logic that matters most first. Don’t migrate historical clutter just because it exists.A phased release plan
Start with the highest-volume quote scenarios before handling edge cases.User training tied to real deals
Reps learn faster with actual selling paths than with abstract system demos.Clear ownership after go-live
Someone must own catalogue governance, rule changes, approval policy, and reporting validation.Post-launch monitoring
Track adoption issues, quote exceptions, approval delays, and reporting mismatches early.
The cleanest migration isn’t the one with the most features at launch. It’s the one sales actually uses correctly.
Keep the broader GTM architecture in view
Quote-to-cash doesn’t sit in isolation. If your team is redesigning commercial workflows, that’s also the right moment to review enrichment, routing, handoff logic, and pipeline design across the wider stack.
For some organisations, that includes GTM engineering tools such as Clay to improve account research, segmentation, and workflow precision upstream of the sales process. The key is making sure those inputs strengthen CRM and quoting discipline rather than adding another layer of data noise.
A good RevOps plan leaves you with fewer exceptions, clearer ownership, and a revenue system your team can govern.
If your team needs help evaluating a legacy CPQ build, planning a migration, or tightening the full quote-to-cash process across Salesforce and HubSpot, MarTech Do can help you audit the current state, map the right future architecture, and execute without creating more operational debt.
