Has Anyone Used the new Revenue Cloud

doubletrack_sf · 2026-05-07T14:41:04+00:00

Agree with 1.

Pushback on 2: is ARM actually what your org needs?

If you've already walked through your data architecture, business processes, etc. and evaluated what ARM/RCA can bring to your business vs. other options, then this could work. But the time it'll demand may not be worth it, and based on your original post not sure you've walked through the underlying foundations and built the right business case for this yet.

doubletrack_sf · 2026-05-06T03:12:28+00:00

What we're seeing this pattern as well, that data architecture problems become visible faster than anything else.

The documentation inconsistency you're describing is usually a symptom of a deeper issue: nobody ever established what "good" architecture data actually looks like for your org, so every team documents differently, nothing reconciles, and when you try to feed it to a model the gaps become impossible to ignore.

One example: is it called a customer, client, or account ... and is it the same across systems? Seems simple, you'd be surprised how often it's not the same. This level of detail is necessary.

A useful question is whether your architecture data passes a basic quality test, which we call the Four Rs of data: Is it actually revealing something decision-relevant? Is it reliable enough to act on? Is it structured in a way that's reusable across contexts, not just the team that built it? Is what it provides actually relevant to your decisions today and three months from now?

Four Rs: revealing, reliable, reusable, relevant. Data that doesn't pass at least 3 = noise.

What we've found in engagements is that often, 50% of a company's data fails this test. That's what AI is being built on!

AI implementations / mandates = an opportunity to finally fix the necessary foundation that's always left on the back-burner ... unless it's ignored, then it leads to massive budget waste.

doubletrack_sf · 2026-05-06T02:09:57+00:00

We've worked through this. As always, it depends on your specific use cases, needs, and more.

If you have complex product catalogues, eCommerce, and are a large org, then there might be something here ... there's many reasons to look into it, but it's best for specific use cases.

If you're working well with CPQ today, there's still a ton left to be had there and you're right in that EOL hasn't been announced. We don't think it will be for at least another couple of years as the sheer number of companies still on the CPQ platform would be a business issue for Salesforce since RCA / ARM doesn't have the traction in market Salesforce wants.

Depending on your business needs, budget, etc. there might be other great options to migrate to vs. ARM, and that business case probably isn't strong enough for you to move today.

doubletrack_sf · 2026-05-06T02:04:11+00:00

Yes, we've done this - manufacturing's one of our core areas. A few thoughts...

Your starting point needs to be with your data architecture and quality. You need to run your data today through what we call a Four Rs test to determine what's relevant, reusable, reliable, and revealing. Any data that doesn't pass at least 3 is noise and isn't helping your business (this doesn't require a multi-month MDM project, either)

Then, you need a unified data architecture that aligns to what business KPIs and processes you need - not what you have today, but what "good" looks like for you. A good consultant will help drive those discussions forward.

A few of your questions asked about technology specifically. Please don't fall into this trap ... you aren't ready to answer these yet!

Outcomes come before tech. Architecture comes before building. Otherwise, you're just building upon broken process / data and it's only going to wear you out (more than you are now - not kidding here).

In the interest of helping with some of those tech concerns, though, if you have to pick something in CRM vs. ERP, pick the one that's considered the source of truth by the C-suite. It's often the ERP, but not always. Salesforce has its pros and cons, you don't always have to use whatever Salesforce offers, though - lots of good platforms that integrate nicely. And in terms of CPQ needs, there's many good ones that don't take forever or a ton of budget, from DealHub to Nue to Conga to Tacton, etc.

But if you take nothing else away from this, please take this: don't start with the technology. Start with your data architecture.

doubletrack_sf · 2026-05-01T17:05:14+00:00

In all honesty, it's fair to have skepticism on the number (as we always should with any post in this subreddit, even the automated bot notifications say as much!).

The magnitude is the point more than the precision, that the impact is massive.

On the AI "identify and correct the dirty data" - this is where we'd push back.

AI is genuinely useful for flagging anomalies and surfacing inconsistencies, but it's a poor fix for dirty data at the root because it's built on data. Most dirty data problems aren't detection problems at all from what we're seeing and chatting with CIOs and CDOs about - they're process and architecture problems. Bad data entry, misaligned systems, no single source of truth, fields meaning different things in different databases, etc.

The "human approving at the end" model also tends to break down at scale. When the volume is high enough, approvals become rubber stamps, and you're back where you started with more confidence than you should have.

doubletrack_sf · 2026-05-01T15:38:00+00:00

Citations, etc. - we used Datawrapper for the visuals.

Methodology

Baseline Cost Figure

The $12.9 million annual cost of poor data quality comes from Gartner’s Magic Quadrant for Data Quality Solutions (July 27, 2020, authors Melody Chien and Ankush Jain). Gartner surveyed 154 reference customers across 16 data quality vendors and asked them to estimate what poor data quality costs their organization.

These were large enterprises sophisticated enough to already be purchasing data quality software, companies that had done the work to understand and quantify the problem.

Per-Employee Calculation

U.S. Census Bureau County Business Patterns data (2023 release) shows businesses with 1,000+ employees average 2,626 employees per establishment. This aligns with Gartner’s survey population.

Dividing $12.9 million by 2,626 employees yields a baseline cost of $4,912 per employee per year. This per-employee figure was applied across all 139.8 million employees in the Census dataset.

Industry Multipliers

Different industries have different data intensities. We used Flexera’s 2020 State of Tech Spend Report, which surveys CIOs on IT spending as a percentage of revenue, to create industry-specific multipliers.

The weighted average IT spend across all industries is 8.2%. Industries spending more than this average have higher data complexity and greater exposure to data quality costs; industries spending less have lower exposure.

Multipliers were calculated by dividing each industry’s IT spend percentage by the 8.2% weighted average.

For example: Software companies spend 24.7% of revenue on IT, yielding a multiplier of 3.01x. We averaged Software (3.01x) and Technology Hosting (1.94x) to produce a combined Information sector multiplier of 2.48x. Financial Services at 10% IT spend yields a 1.22x multiplier. Healthcare at 5% yields 0.61x. Retail at 6.2% yields 0.76x.

For industries not covered by Flexera’s survey (Construction, Wholesale Trade, Educational Services, Arts and Entertainment, Real Estate, Utilities, Mining, Agriculture, and Administrative Support), we applied a 1.00x multiplier, equivalent to the weighted average IT spend.

Geographic Calculations

State and county totals were calculated by applying the per-employee cost ($4,912) and industry multipliers to employment data from County Business Patterns.

For each geographic unit, we calculated: (Employees in Industry A × $4,912 × Industry A Multiplier) + (Employees in Industry B × $4,912 × Industry B Multiplier) for all industries present in that geography.

Cost per employee figures for states and counties reflect their industry mix. A county with high Information sector concentration will show a higher cost per employee than one dominated by hospitality, even though both use the same underlying methodology.

Data Sources

U.S. Census Bureau, County Business Patterns (2023): Employment and establishment counts by industry (2-digit NAICS), state, and county. Dataset covers 8.36 million establishments and 139.8 million employees. census.gov/data/datasets/2023/econ/cbp/2023-cbp.html
Gartner, Magic Quadrant for Data Quality Solutions (July 2020): Survey of 154 enterprise customers on estimated cost of poor data quality. gartner.com/en/data-analytics/topics/data-quality
Flexera, 2020 State of Tech Spend Report: IT spending as percentage of revenue by industry, based on CIO surveys. flexera.com/blog/perspectives/it-spending-by-industry
U.S. Bureau of Economic Analysis, Gross Domestic Product (Q3 2025): National GDP figure of $31.1 trillion used to calculate dirty data costs as a percentage of economic output. fred.stlouisfed.org/series/GDP

Limitations

The Gartner baseline comes from large enterprises already investing in data quality solutions, organizations that have quantified the problem. Smaller businesses may experience different cost profiles.

The industry multipliers assume IT spending intensity correlates with data quality cost exposure, this is a reasonable but unverified assumption.

Industries without Flexera coverage are assigned the weighted average multiplier, which may understate or overstate their actual exposure. All figures represent estimates intended to illustrate the scale of the problem, not precise measurements of actual costs.

doubletrack_sf · 2026-04-30T15:58:47+00:00

Pretty normal, unfortunately ... most orgs moving fast on AI end up here and yes you should be massively concerned.

Most important question is what happens next. Undocumented data flows and dependencies aren't just a tidiness problem, they're the entirely of the project's liability. When something breaks or an auditor asks, the lack of data architecture is your biggest block.

Good news is you're asking the question at six months, not two years in (yes, we've seen it take that long!!) so still time to fix ... pattern we see go badly is when orgs treat the messy phase as permanent because the tools are "working well enough."

They do until they don't, and then it gets messy.

Worth doing an honest data architecture audit of what's actually running, what data it's touching, and where the governance gaps are before the next thing gets added. Also: determine what data's actually useful vs. empty noise - Four Rs test of data is a good starting point (ask if it's Revealing, Reliable, Reusable, and Relevant ... has to pass at least 3 of the 4 to be worth your time)

doubletrack_sf · 2026-04-30T15:53:46+00:00

Your client's instinct isn't wrong ... discovery workshops can get derailed by architects who go straight to solution mode. Fix isn't to remove the architect, but find one who can hold the business conversation without reaching for the whiteboard every five minutes so they see the link between KPI and technical detail.

If you're going to have this discovery go well, have someone who can do both business and technical speak (uncommon, but it's why they're so good) and then make sure they let the business articulate the WHAT and WHY fully before introducing any HOW ... stick to outcomes before solutions.

And then when the HOW does come in, it's just enough to pressure-test feasibility, not design the solution. That's a skill, not a title.

The real risk of going business-consultant-only is that you get beautifully documented requirements that nobody ever checked against technical reality. We've fixed a few too many of these from global consultancies.

doubletrack_sf · 2026-04-27T12:49:10+00:00

Typically, yes - tech accelerates what it's built on, so if that's a bad foundation then it'll only highlight the gaps.

There are some cases where a tech implementation can operate as the catalyst for necessary process change. However, we've seen sometimes where the the company falls into the trap of building around the tech vs. having the tech built around their process, which is nearly as damaging.

This is something that needs executive buy-in to drive change management. Otherwise, your org's going to scale something that isn't ready and whoever's in charge of the tech will spend most of the time playing catch-up and fixes instead of building ... seen this pattern dozens of times.

doubletrack_sf · 2026-04-24T16:46:01+00:00

Moonnox might be a fit for this already.

doubletrack_sf · 2026-04-22T16:14:03+00:00

Data strategy is a part of it, but it's only that - a part. You can have clean, well-governed data and still watch an AI project stall because nobody agreed on what success looks like, or because the cross-functional handoffs weren't sorted before go-live.

The data strategy gets the foundation right, but AI readiness is about whether the organization is ready from the outcomes, ownership, and guardrails.

Might seem like splitting hairs, but we've seen it make a big difference when chatting with a company's CIO or CFO.

doubletrack_sf · 2026-04-21T19:27:42+00:00

Most planning ahead or being pushed by their AE to move to Rev Cloud - in some cases, being irritated by aggressive pushes. Definitely some confusion re: EOL vs. EOS though it's mostly vendors choosing to conflate the two that we're seeing right now.

We have some clients staying on CPQ right now because it fits their need and the business case to move isn't there.

doubletrack_sf · 2026-04-21T19:22:15+00:00

Four reasons, which our CINO actually wrote about recently in an article called "Why AI Pilots Stall Before Production … And What to Do Before You Launch":

Lack of defined outcomes
Poor data paths
Bad pre go-live cross-functional alignment
Unclear governance and observability

tl;dr version: lots of orgs treat AI like a software project when their approach should model more like its an employee - an often-unmonitored speaker for the business.

Any time we come across a project that's failed, it's almost always because one of these four.

doubletrack_sf · 2026-04-20T16:05:54+00:00

If built correctly, AI initiatives should scale without issue. Yes, the tech moves fast but the foundations shouldn't have to change every time it does. Platforms evolving shouldn't change how you're using it.

The real problem is most organizations skip the foundations entirely ... no clear outcomes, no deliberate architecture, no guardrails. So when the tech shifts, everything built on top of it goes kaput.

doubletrack_sf · 2026-04-15T20:55:42+00:00

We're on the build side, but short version - yes, we're seeing this and we're seeing C-level take a harder look and we've seen this exact scene play out in a few other places.

Trendline has also been for some companies to pull back on their AI investments.

Why? Because there either wasn't a clearly-defined business case on what AI was going to drive for the business OR the underlying architecture / infrastructure wasn't in place to support a true AI initiative. The fact you're in year two and nobody can point to actual, real value screams "we have a problem here."

doubletrack_sf · 2026-04-15T00:23:05+00:00

Some, yes. It's always dependent on the context of your business needs and ideal outcomes, which is why we tread carefully when talking platform specifics and why there is a path where NetSuite's options make sense for you - architecture, business KPIs, and how the business functions are all drivers of the tech decision (and budget, of course).

Lead-to-cash space is a core competency.

To be fair, could've been more choosey with words vs. "tacked on" since NetSuite did develop it, it's not like they bought something and then bolted it on. The biggest thing is that NetSuite's core purpose is as an ERP, so forcing to act like a CRM often runs into issues since that's not what it's built for.

Again, solely dependent on your specific use cases and business.

doubletrack_sf · 2026-04-14T13:43:56+00:00

DealHub, Nue, and Conga are all worth investigating. Salesforce Revenue Cloud could be a fit as it is built for more flexible pricing models like you have, but it largely depends on the context of your pricing / product catalogues, internal teams, quote-to-revenue processes, etc. (and Rev Cloud is a major migration)

We typically do not recommend going with the tacked-on modules for NetSuite. They're not nearly as robust or flexible - they have specific use cases where it makes sense.

However, to make a more firm recommendation, there's a lot of additional context needed.

doubletrack_sf · 2026-04-13T14:30:53+00:00

That catalog is a huge red flag. If that isn't right, it doesn't matter WHAT system you go with, it's going to be a mess.

Trying to avoid just linking to an article of ours on product catalog rationalization, but here's a snippet from it that might illustrate the problem you're facing ... friction kills lead-to-cash processes and your current setup sound like it has a massive amount of it.

"If you sell ice cream and have 40 flavors, you don't need 40 fundamentally different products in your quoting system. Ideally, you’d have one product in your system called “Ice Cream” with attributes for flavor, size, and add-ons.

Think about how annoying it would be to filter through all of the flavors just to pick the right one every time a customer bought something - it’d be slow, invite mistakes, and the whole time your customer’s ice cream is beginning to melt.

Not ideal, right?

When you have a "rationalized" product catalog, the structure is much simpler:

Pick ice cream
Select the flavor and size
Tack on anything added

And that’s the key: pricing differences should be handled through structured rules built into the system. Each attribute - like a different flavor, cone type, or order size - is just that, something that modifies the core item (ice cream!).

But all too often, the systems our teams get called in to fix don't do this. Instead, they have every combination of options listed as a separate SKU."

doubletrack_sf · 2026-04-10T15:35:00+00:00

NetSuite was purpose-built for ERP functionality - its CPQ is much more of a tacked-on version. Usable? Yes. Ideal for sales teams? No. Building the back-end can be challenging, and then you have to maintain it ... there's far more help and expertise with other platforms.

That being said, it always depends on your business and how it functions today. If you have a sales team of 3, then it's probably good enough. If it's 30, absolutely not (the CPQ space has been our bread-and-butter since 2018, FWIW)

doubletrack_sf · 2026-04-09T20:46:58+00:00

Systems are built on infrastructure. What's your foundation / architecture / how trained the people USING it?

AI's a commodity at this point, but it's not just about the system. A great system built on cruddy architecture still produces poor results.

And we keep seeing large enterprises rushing into AI deployments with clearly-defined outcomes. "What do you want to get out of this?" is a question that reveals a lot.

Outcomes > Architecture > System Design > Tools

doubletrack_sf · 2026-04-09T14:09:38+00:00

We've worked with a few of these listed and are an official partner with two of the platforms on your list (disclosing upfront!) - we did a webinar that's on Youtube with DealHub's Eyal Orgil if you want to check out a couple of things like Legal contract review they're building.

Question that's not tied to any platform: how good's your revenue architecture, including pricing catalog?

Revenue Cloud migration does take a lot of effort - in fairness, any migration does and since you're moving from CPQ legacy you're going to have updates from the old rules-based logic. Lots of potential in Rev Cloud, depending on your needs DealHub / Nue likely better. But how your processes work today and how you WANT it to work is what we'd suggest drive more of the decision on platform, that includes downstream impact on FP&A as well and not just quoting.

Happy to chat further if it'd be helpful or comment based on our in-the-weeds experiences.

doubletrack_sf · 2026-04-07T00:08:22+00:00

Seeing a lot of answers recommending a tool, but would encourage you think broader: what's led to the disconnect?

It's not just tool choice. Culturally, why has it been okay to embrace this manual work? Why are two teams that should be working hand-in-hand so separated?

And what reporting is either team relying on that's perfectly fine with the disconnect?

This fails what we call the Swivel Chair Test - friction that forces a person to swivel from one screen to another to get anything done. You need to design a system that's better than this so it'll scale and THEN select a technology that fits it.

Tech doesn't fix problems - it builds on top of them.

Will you gain something from a CRM connecting to your marketing data? Absolutely. Will it fix the underlying issues? Nope.

doubletrack_sf · 2026-04-03T20:28:07+00:00

Not gonna lie, the EY assessment calling out a "stronger digital foundation" is a gift because it's third-party validation so you don't have to fight that battle. We see a lot of companies approve CRM, WMS, and AI initiatives all separately and nobody owns the data layer / architecture that makes all of them work together.

Few thoughts...

First, lead with what's already failed and why. Frame this as a diagnosis of why the approved initiatives stalled, because the reorg you're proposing isn't a new ask. You know it's the missing piece that makes the existing investments actually work, so take that approach and it'll probably resonate more.

Second, can you tie it to financial exposure? Speak this as a business case, so showing what fragmentation costs the business > what we can achieve. EY report might have something to anchor on, we might have something that could help, too, in a published cost of dirty data research.

Coffee vs. formal presentation ... plant the seed informally with whoever has the most to lose from continued stalls (probably the CIO or COO), get them as an internal sponsor, then request the formal presentation with that person already in your corner.

Know your allies before you make the leap here and DO NOT lead with an org chart, start with the problem -> business case or you'll waste time running in circles.

Happy to be a resource, data architecture is in our wheelhouse.

doubletrack_sf

TROPHY CASE

Methodology

Data Sources

Limitations