At Candybox, we've spent a ton of time auditing GTM systems for SaaS companies as part of our RevOps work. After enough of them, certain patterns get hard to ignore, and one keeps showing up in how teams talk about RevOps maturity.
Most RevOps maturity content gives you a single score. That's a problem.
You read the framework, map your org onto each pillar, average it out, and land on a "Stage 2" or a "Stage 3." The number doesn't tell you which pillar is dragging the others down, where the actual risk is, or what to fix first.
In our experience, that's not quite how it works.
Take three SaaS orgs we audited in the last six months:
- One had 550+ active OAuth tokens hitting a single CRM instance, through around 90 connected apps and 70 flows.
- Another had over 2,000 Setup Audit Trail changes in the six months after a RevOps lead handoff.
- A third had one person running its entire RevOps function (Salesforce admin, CPQ configurator, flow builder) and she was a couple of months away from retirement with no structured handoff built in for her replacement.
None of these orgs sat at "Stage 2." Or 3, or 1. They were at Stage 1 in one pillar and Stage 3 in another, simultaneously. The single-score frame missed what was actually going on: the gap between your highest and lowest pillar is where the real risk lives.
This hits harder in SaaS than in most industries. ARR forecasting, NRR reporting, expansion motions and PLG-versus-sales-led handoffs depend on multiple RevOps pillars being in step. One weak pillar leaks into all of them.
We've built our own version of this framework, scored around the gap instead of the average.
Take the RevOps Maturity Snapshot →
The Four Stages of RevOps Maturity, Translated Into What They Actually Feel Like
The standard RevOps maturity scale is four stages: Ad Hoc → Emerging → Scaling → Strategic. Most maturity content describes each in abstract framework language that's hard to map onto a real org.
Here's what each stage actually feels like to a VP of RevOps inside it.
Stage 1 — Ad Hoc. Every quarter starts with someone asking "Wait, can we trust the pipeline number?" Reporting is whatever someone exported into a spreadsheet last Friday. The symptom we look for in audits is tribal knowledge, which means that institutional memory lives in one or two people's heads, not in the system.
Stage 2 — Emerging. Some things are documented. Some things are automated. But the processes only get followed when the same person is in the room. SLAs exist more as Slack messages than enforcement rules. We see a lot of partially in Stage 2: partial integrations, partial dedupe, a partial data dictionary.
Stage 3 — Scaling. End-to-end processes are version-controlled. SLAs are enforced and monitored. Tools are bi-directionally integrated. There's an actual data model, and it's mostly current. Reporting is generally trusted. The Stage 3 symptom: the next person who joins can figure out how the system works without scheduling a meeting with the one person who built it.
Stage 4 — Strategic / Optimized. Forecasting is within 10%. Dashboards cascade from executive OKRs. Routing optimizes itself based on win-rate. Data quality is monitored, rather than audited. The operational investment of staying at Stage 4 is real, and truthfully, a Stage 3 baseline across all six pillars is enough to run a healthy business.
Three Real SaaS Audits Results
1. A B2B PLG SaaS company at scale
When we ran the audit, the Systems & Technology pillar scored a clean 3. They had:
- Sophisticated PLG data model
- 55 active integrations
- A well-designed conversion pipeline.
Genuinely impressive engineering. But the Data & Governance pillar was barely above a 1.
- Their Segment integration was provisioned with a System Administrator profile
- Three different Reverse ETLs (their own product, Hightouch, and Segment) were all writing to their CRM simultaneously with Modify All permissions and no field-level ownership model.
- Same fields, three writers, last writer wins, no visibility.
Their stack was "Scaling." The governance layer underneath it was "Emerging." The gap is what made the stack dangerous, not the stack itself.
2. A mid-market B2B SaaS we audited last quarter
Systems scored a 3: Salesforce, CPQ, Pardot, NetSuite via Boomi, ZoomInfo, Chili Piper, all integrated and centrally administered.
People & Enablement scored a 1.5. Their entire RevOps function was one person, who was retiring in a few months, with no documented enablement, no onboarding framework, and no overlap planned with the incoming admin.
Systems were "Scaling." The people layer was "Ad Hoc." In a real handoff scenario, that gap is a Q of lost momentum minimum.
3. A Series-B SaaS following a RevOps handoff
The Setup Audit Trail showed 2,453 (!) changes in the six months after their previous RevOps lead left. Their SQO flow was at version 14 with no documentation of what each iteration changed. The quote approval process had iterated V1 → V2 → V3 in the same period, with the V1 and V2 versions still active and unlabeled.
Strategy & Alignment scored a 2 because they had a clear new GTM motion in flight.
Processes & Workflows scored a 1.5 because every workflow was actively being rewritten by someone new, on top of the previous person's undocumented work.
Strategy was clear, but execution was a moving target. The gap made every weekly forecast call a renegotiation.
In all three: the average pillar score landed around a 2. Not particularly alarming on its own. The gap between the highest and lowest pillar, which was 1.5 in every case, was the actual operational risk.
Why the Gap Matters More Than the Average
Here's the thing about RevOps pillars: they don't fail in isolation. A Scaling Systems layer cannot operate safely on top of an "Ad Hoc" Data layer. The pillar scoring lowest caps what your highest-scoring pillar can actually deliver.
This is the part of maturity diagnostics that most frameworks understate. If your Systems pillar is at 3 and your Data pillar is at 1, you don't have a Stage-2 RevOps function. You have a Stage-1 RevOps function with expensive Stage-3 tooling sitting on top of it. The integrations will keep firing but the data they generate will keep being wrong.
We see this often enough that it's worth naming as a pattern: the higher the gap between your strongest and weakest pillar, the more operational debt you accumulate per quarter. Stage 1 alongside Stage 3 is more dangerous than Stage 2 across the board, because the high-functioning pillar generates volume the low-functioning one can't govern.
The single-score frame oversimplifies and produces remediation plans that miss the actual problem.
That's why we built our own framework around the gap, not the average: every pillar is scored independently, the highest-versus-lowest delta is surfaced first, and the remediation roadmap that comes out of it is sequenced by which gap is doing the most damage.
This way, you fix the thing that's capping the rest of the org, not the thing that scored lowest in isolation.
How to Spot Your Own Gap
The diagnostic itself is simple. Take our 6 min. survey here and we'll deliver your results as well as what we'd attack first.
The real value is in being honest about what you'd actually score.
For each of our six RevOps pillars — People & Enablement, Systems & Technology, Strategy & Alignment, Processes & Workflows, Data & Governance, AI Orchestration and Analytics & Forecasting — answer one question:
If I had to walk a new VP of RevOps through this pillar tomorrow, and they asked me how it works, what evidence could I show them? A document? A dashboard? A person?
- A pillar scoring at 1 has no evidence because it lives in someone's head.
- A pillar scoring at 2 has partial evidence, most likely a doc that's six months stale, a dashboard nobody reviews.
- A pillar scoring at 3 has current evidence that a stranger could read and understand.
- A pillar scoring at 4 has evidence and a system that improves itself.
Score yourself across all pillars. Look at your highest score and your lowest score. The gap between them is the number that matters.
What to Do With the Gap
Don't try to lift everything at once. Most orgs we audit instinctively want to attack the lowest-scoring pillar first. That's not always right.
The actual play depends on which pillar is the laggard. A few examples:
- If your Data & Governance pillar is the laggard and your Systems pillar is racing ahead, every quarter you wait is a quarter of bad data getting baked into more reports. Fix the data first; the systems will catch up.
- If your People & Enablement pillar is the laggard, the priority is documentation and knowledge transfer before the bus factor catches you.
- If your Strategy & Alignment pillar is the laggard, no amount of process work downstream will compensate.
The pattern we keep seeing in mid-market SaaS: the laggard is almost always Data, People, or Processes. Almost never Systems. Of the three audits above, every single one had Systems as its highest-scoring pillar and either Data, People, or Processes as its lowest. That's the gap most often worth closing first.
The Bottom Line
Your RevOps maturity isn't a number. It's a vector — seven pillars, each at a different stage, with a gap between the highest and the lowest. The average is a vanity score. The gap is the work.
What we see in almost every audit: every stakeholder scores their own pillar one stage higher than their peers do.
👉 The Head of RevOps rates Systems a 3; the same week, Sales calls it a 2.
👉 Marketing scores Strategy & Alignment a stage above what Finance scores it.
The gap on paper ends up narrower than the gap in practice, which is exactly the operational debt leadership teams keep underestimating.
That's why we built the RevOps Maturity Snapshot — the same framework we run on every Candybox audit, compressed into 18 questions and 6-8 minutes. Unlike the standard maturity quizzes that average you down to a single stage, this one scores each pillar independently and surfaces your highest-versus-lowest gap first. You’ll get a full diagnostic and a recommendation on what to attack first.
When we run the full version with clients, the output is a sequenced remediation roadmap. The same kind of plan that turned the three audits in this post into actual fixes. The snapshot is the entry point to that work.
No sales call. No pitch deck. Just the diagnostic and our recommendation on what to attack first.
→ Take the RevOps Maturity Snapshot
.png)
