Your company has a "Head of Revenue Operations."
Their calendar is full of Salesforce configuration tickets. They spend their days building reports, fixing broken automations, managing user permissions, and responding to "can you add a field?" requests from sales managers.
You don't have a RevOps leader. You have a CRM administrator with an inflated title.
That's not an insult. It's a misdiagnosis. And it's one of the most expensive mistakes a scaling company can make, because you'll spend two years wondering why your revenue operations aren't strategic — while the person in the role never had the mandate, the skills, or the organisational position to be strategic in the first place.
The Role Confusion Problem
Revenue Operations is one of the fastest-growing functions in B2B SaaS. It's also one of the most poorly understood.
Here's what happens at most companies.
The CRM gets messy. Reports are unreliable. Sales leaders complain about data. Someone says "we need RevOps." The company hires someone who's good at Salesforce. They call them "RevOps Manager" or "Head of Revenue Operations."
That person starts doing what they know: fixing the CRM. Building flows. Creating dashboards. Cleaning data. Responding to tickets.
Twelve months later, the CRM is cleaner, but the revenue operations are no more strategic than they were before. Pipeline governance is still ad hoc. Forecasting is still a spreadsheet exercise. The handoff between marketing, sales, and CS is still held together with Slack messages and goodwill.
The CRM got better. The operating model didn't change.
Two Fundamentally Different Jobs
Let me draw the line clearly. These are two distinct roles that require different skills, different seniority, and different organisational positioning.
The CRM Administrator
A CRM admin makes the tools work. Their domain is the system layer.
- Configuring Salesforce, HubSpot, or whatever CRM the company uses.
- Building and maintaining automations, flows, and workflows.
- Managing user permissions, roles, and profiles.
- Creating reports and dashboards based on requirements from stakeholders.
- Handling data imports, deduplication, and cleanup.
- Troubleshooting integration issues between systems.
This is valuable, necessary work. Every company needs it. But it's implementation work, not architecture work.
The RevOps Leader
A RevOps leader designs how the revenue engine works. Their domain is the operating model.
- Defining the end-to-end revenue process from lead to renewal.
- Designing pipeline governance — stage definitions, qualification criteria, forecast methodology.
- Architecting the data model that supports strategic decision-making.
- Aligning incentive structures across sales, marketing, and CS.
- Building the measurement framework that connects activity to outcomes.
- Partnering with finance on capacity planning, territory design, and comp modelling.
- Evaluating the tech stack against business requirements and making build-vs-buy decisions.
A CRM admin asks "how should I configure this?" A RevOps leader asks "what should this system enforce and why?"
Both questions matter. But they operate at fundamentally different altitudes.
Why Companies Confuse Them
The confusion is understandable. Here's how it happens.
The pain is felt at the system level
When something breaks, it breaks visibly in the CRM. A report is wrong. A flow misfires. A field is missing. The symptom is always technical, so the instinct is to hire a technical person to fix it.
But the root cause is usually architectural. The report is wrong because the stage definitions aren't governed. The flow misfires because the process it automates was never properly designed. The field is missing because nobody architected the data model to support the analysis the business now needs.
Hiring a CRM admin to fix an architecture problem is like hiring a plumber to fix a foundation crack. They'll patch the pipes. The building will still shift.
The title inflation problem
RevOps is a hot function. Companies want to attract talent. So they put "Revenue Operations" in the title of what is functionally a CRM admin role.
The candidate gets a bigger title than the job warrants. The company gets to say they have a "RevOps team." And the actual strategic work — operating model design, governance architecture, incentive alignment — doesn't get done because nobody in the org has the mandate or capability to do it.
Leadership doesn't know what strategic RevOps looks like
If you've never worked with a genuinely strategic RevOps leader, you don't know what you're missing. You assume that clean dashboards and working automations are what RevOps delivers.
It's like a company that's never had a CFO assuming that the bookkeeper is handling the finance function. The books balance. But nobody's doing financial planning, capital allocation, or investor strategy.
The Symptoms of a Miscast RevOps Function
You can diagnose this problem by looking for specific patterns.
- RevOps is a ticket queue. The team spends most of its time responding to requests from sales, marketing, and CS leaders. "Build me this report." "Add this field." "Fix this automation." They're executing other people's specifications, not designing the system.
- RevOps reports too low. If your RevOps leader reports to a Sales VP, they're a sales operations function with a rebrand. Strategic RevOps needs to sit at the same level as sales, marketing, and CS leadership — not inside one of them.
- Nobody owns the operating model. Ask "who decides how our pipeline stages are defined?" If the answer is "the VP of Sales" or "it depends" or silence, then nobody is doing the architectural work.
- The tech stack is growing but the process isn't improving. New tools get added. New integrations get built. But the fundamental way the revenue engine operates hasn't changed in two years. That's a sign of system administration without system design.
- Forecasting is still a manual exercise. If your forecast is built in a spreadsheet by a VP who calls each manager on Thursday afternoon, your RevOps function hasn't architected a governance-based forecasting process. It's just administering the CRM that the manual process runs alongside.
What a Real RevOps Leader Does Differently
Let me give you concrete examples of the work that separates architecture from administration.
They design the data model, not just the fields
A CRM admin adds fields when asked. A RevOps leader designs the underlying data architecture — which objects exist, how they relate to each other, what the source of truth is for each data element, and how the model supports both current reporting needs and future analytical requirements.
The difference shows up a year later when the company needs segment-level cohort analysis and either has the data structure to support it or doesn't.
They own the forecast methodology, not just the report
A CRM admin builds the forecast report. A RevOps leader defines what "commit" means, how deals qualify for each forecast category, what the governance rules are for forecast changes, and how the methodology connects to the board's planning model.
The admin gives you numbers. The leader gives you a system that produces reliable numbers.
They challenge the process, not just implement it
A sales VP says "I want reps to log all their activities in Salesforce." A CRM admin builds the activity tracking. A RevOps leader asks: "What decision will this data inform? Are we tracking this because it drives insight or because someone thinks more data is always better? What's the rep burden versus the analytical value?"
The willingness to push back — to question whether the request is the right request — is the hallmark of a strategic operator.
They connect incentives to architecture
When a RevOps leader sees reps sandbagging deals into the next quarter, they don't just flag it. They trace the behaviour to the comp plan, model the second-order effect, and propose a structural fix that changes the incentive rather than adding another monitoring layer.
A CRM admin builds a dashboard that shows the sandbagging. A RevOps leader redesigns the system so sandbagging stops being rational.
They evaluate the tech stack against the operating model
When a VP wants to buy a new forecasting tool, a CRM admin evaluates the integration requirements. A RevOps leader asks whether the forecasting problem is a tooling problem or a governance problem — and whether the £60k/year spend would be better invested in fixing the pipeline governance that makes the current forecast unreliable.
That question alone can save hundreds of thousands in unnecessary tooling.
The Seniority Question
Here's an uncomfortable truth that most companies don't want to confront.
Strategic RevOps requires senior operator experience. Not just CRM certification. Not just analytics skills. Experience running revenue operations in complex, scaling environments where the decisions about operating model design, governance architecture, and cross-functional alignment had real consequences.
You can't promote a two-year CRM admin into a strategic RevOps leader role and expect the architecture to follow. The skills are different. The judgement is different. The organisational influence required is different.
That doesn't mean you need to hire a VP immediately. It means you need to be honest about what level of RevOps capability you have versus what you need.
Many companies would be better served by:
- Keeping their CRM admin focused on system administration (and valuing that work properly).
- Bringing in a senior fractional RevOps leader to do the architectural work — operating model design, governance frameworks, incentive alignment, tech stack strategy.
- Eventually hiring a full-time RevOps leader once the architecture is established and the company knows what "good" looks like.
The worst outcome is giving someone the title without the experience and expecting architectural thinking to emerge from operational execution. It won't.
How to Know Which One You Need
The answer depends on where you are.
- Under £5M ARR: You probably need a strong CRM admin who can keep the systems running cleanly. Strategic RevOps at this stage often comes from the founder or CRO, with occasional external support for specific architectural decisions.
- £5M–£20M ARR: You need both. The CRM admin handles day-to-day operations. The strategic RevOps capability — whether full-time or fractional — designs the operating model, builds governance, and architects the systems that will carry you through the next stage of growth.
- £20M+ ARR: You need a RevOps leader with a team. The leader does architectural work. The team handles administration, analytics, and execution. If your "RevOps team" is entirely administration with no architectural leadership, you're underinvesting in the function that determines how efficiently you convert investment into revenue.
The Question to Ask Tomorrow
Look at your RevOps function — whether it's one person or ten — and ask a simple question.
"What percentage of this team's time is spent responding to requests versus designing systems?"
If the answer is 80% or more on requests, you have an administration function. That's fine, as long as you know it. The danger is believing you have strategic RevOps when what you actually have is a well-run help desk for your CRM.
The CRM admin keeps the engine running. The RevOps leader decides what kind of engine to build.
You need both. Just don't confuse one for the other.
