What Is RevOps and Do You Actually Need It?
TL;DR: RevOps is the alignment of sales, marketing and customer success under shared processes, shared data and shared accountability. You need it when handoffs between those teams start losing revenue, which for most UK businesses lands somewhere between 15 and 30 people in go-to-market roles. Below that, the answer is cleaner processes and a CRM people actually use, not a RevOps hire.
What is RevOps?
RevOps - revenue operations - is the alignment of sales, marketing, and customer success under shared processes, shared data, and shared accountability. That is the whole definition. Everything else is implementation detail.
In practice it takes two forms, and most businesses conflate them. The first is RevOps as a function - a person, a team, a set of clearly owned responsibilities. The second is RevOps as a mindset - the way leadership decides to operate across go-to-market teams. If you hire someone with the title but leave the processes and data ownership unresolved, you end up with neither. The person has a job title and no authority to change anything that matters.
What a real RevOps function owns day-to-day: the tech stack configuration, pipeline stage definitions, revenue reporting, and - critically - the handoff points between go-to-market teams. The handoffs are where most revenue leaks happen. A lead goes cold between marketing and sales because nobody owns the trigger. A deal closes and the customer success team has no context because the handoff from sales was never defined. Those are RevOps problems. The function exists to own the join between systems and teams, and to do something useful with that ownership.
What is the difference between RevOps and Sales Ops?
Sales Ops improves how one team works. RevOps owns the joins between marketing, sales and customer success, and is accountable for the revenue number all three produce together. The difference is scope and accountability, not seniority.
Sales Ops is scoped to one team. Its job is to make the sales process work better - CRM hygiene, pipeline reporting, territory management, compensation modelling. That is genuinely valuable work, but it stops at the sales team boundary.
RevOps spans the full revenue journey, from first marketing touch through to post-sale renewal or account expansion. The accountability difference is significant. A RevOps function is accountable for forecast accuracy across marketing, sales, and customer success - not just within one of them.
A practical example: a Sales Ops person fixes the CRM so the sales team can use it properly. A RevOps function owns the data model that marketing uses to score leads, sales uses to manage pipeline, and customer success uses to track retention risk - and makes sure those three data models are consistent with each other. Those are different jobs.
Worth noting: a lot of UK SMEs already have someone doing parts of this job under a different title - operations manager, commercial analyst, HubSpot admin - without the formal ownership structure. That is a reasonable starting point. The question is whether the ownership is clear enough to be effective.
What are the signs you have a RevOps problem?
Five symptoms reliably point to RevOps rather than strategy or headcount: sales and marketing pulling different pipeline numbers from the same CRM, deals lost at handoffs with no clear owner, forecasts built in spreadsheets because nobody trusts the system, the same contact appearing multiple times with different data, and a recurring argument about lead quality that neither side can prove.
If two or more are true in your business, RevOps is your bottleneck, not your strategy, not your headcount, not your messaging.
Sales and marketing pull different pipeline numbers from the same CRM. This happens when there is no agreed definition of what counts as a qualified lead or an active deal. Each team filters differently and reports different totals. The argument at the QBR is a symptom of the missing definition, not a personality clash.
Deals get lost at handoff points with no clear owner. Someone books a discovery call and it sits. The handoff from marketing to sales has no defined trigger and no accountability attached to it, so the lead degrades while two teams assume the other one is handling it.
Forecasts are built in spreadsheets because nobody trusts the CRM. The system exists, but the data in it is incomplete or inconsistently maintained, so people default to their own tracking. At that point you are paying for a CRM to store historical data and running your business off spreadsheets that only one person understands.
The same contact appears three times in the CRM with different data attached. A data hygiene failure that compounds over time. Duplicate records mean any contact-level reporting is unreliable, and any automation built on top of that data will behave unpredictably.
Marketing says the leads were good, sales says they were not, and nobody can prove either position. There is no shared data model to arbitrate the argument, so the disagreement recurs every quarter. The cost is real - either marketing optimises for leads that do not convert, or sales deprioritises leads that would have.
Each of these is something you can verify by looking at your systems. If answering any of them requires a conversation rather than a data pull, that itself is the signal.
When RevOps is the wrong investment
If you have fewer than 10 to 15 people in go-to-market roles, you almost certainly do not need a dedicated RevOps function. You need cleaner processes and a CRM setup that people actually use.
RevOps cannot fix a product-market fit problem, a culture problem, or a leadership team that disagrees on strategy. If those things are present, adding process and tooling will make the dysfunction faster and more visible - not better. Automating a broken process produces broken outputs at greater speed.
The specific mistake worth naming: hiring a VP of RevOps before the systems and processes exist for them to operate on. That role costs £80,000 to £120,000 a year in the UK market. Without a usable CRM, agreed pipeline definitions, and buy-in from the sales and marketing leads, that person spends their first 18 months fighting for data access and process change - and then leaves. The role fails because the foundations were not there, not because RevOps does not work.
At early stage, the right answer is usually a fractional operator or a targeted implementation project. Fix the specific broken thing - the handoff, the CRM setup, the reporting - rather than hiring a full-time head to own a function that does not yet exist in any meaningful form.
At what size does RevOps start to matter?
Roughly 15 to 30 people in go-to-market roles is the usual threshold. Two other triggers matter as much as headcount: three or more disconnected systems each holding a version of the contact record, and leadership receiving conflicting pipeline reports before a board meeting.
Misalignment becomes genuinely painful when you cross roughly 15 to 30 people in sales. At that scale, pipeline visibility requires a system, and handoff failures start costing real revenue rather than just being mildly annoying. When there are two salespeople, a broken handoff process is recoverable. When there are fifteen, the same broken process is losing you deals every week.
Three or more disconnected systems is another hard trigger. When your CRM, marketing automation platform, support tool, and billing system each hold a version of the contact record with no single source of truth, any reporting becomes a manual reconciliation exercise. Someone is spending time every month producing a number that should be automatic.
When the CFO receives two different pipeline reports from the sales director and the marketing director before a board meeting, RevOps is no longer optional. That is the clearest organisational signal there is.
For UK recruitment agencies, this pain usually lives in the Bullhorn-to-CRM gap. Candidate data sits in Bullhorn. Client relationship data is either also in Bullhorn or in a separate CRM, with no shared pipeline logic connecting the two. Placements happen but the data that should inform business development activity is fragmented across systems that do not talk to each other.
For B2B scale-ups, the marketing-to-sales handoff typically degrades as headcount grows. When there are two salespeople, a marketing lead lands in an inbox and gets called. When there are fifteen, that same process breaks - there is no routing logic, no SLA, and no agreed definition of what constitutes a lead worth calling.
What RevOps needs in place to work
RevOps is not a solution you install. It depends on three things: a single source of truth for revenue data, leadership buy-in across sales and marketing, and someone with the authority to enforce process changes rather than just recommend them. If any one of the three is missing, the investment underdelivers.
A single source of truth for revenue data. That means a CRM that is actually used and maintained - not just licensed. If the sales team manages deals in their inbox and uses the CRM for end-of-month logging, you do not have a single source of truth. You have a reporting tool that is six weeks behind reality, and any RevOps function built on top of it will produce reports that nobody believes.
Leadership buy-in across sales and marketing. RevOps requires those two functions to give up some autonomy over their own processes and agree to operate inside shared definitions. If the sales director and marketing director are each running their own reporting and do not want that to change, a RevOps function cannot enforce anything. The authority has to come from above the function, not from within it.
Someone with the authority to enforce process changes, not just recommend them. Process recommendations without enforcement authority are just documentation that nobody follows. The most common way RevOps implementations fail is when the person in the role can identify the problem, document the fix, and present it - but cannot make the sales team adopt it because they have no mandate to do so.
One thing US-written content on this topic consistently ignores: for UK businesses, data alignment also has to be compliant. Merging contact data from three systems into one is not just a technical exercise - it carries GDPR implications around consent records, lawful basis for processing, and data retention. That needs to be designed in from the start, not bolted on after the fact.
Should you hire a RevOps lead, restructure internally, or go fractional?
Restructure internally when you already have capable people who need clarity of ownership and leadership will back the change. Hire full-time once the systems exist and the volume of work justifies dedicated headcount. Use fractional or project support when you have specific bottlenecks to fix and cannot yet justify a full-time person.
There are three realistic options, and they are not equally valid at all stages.
Option 1 - Internal restructure. Works when you have capable people already doing parts of this job who just need clarity of ownership. The risk is that without a clear mandate from leadership, restructuring existing roles often just adds responsibility without removing conflicting accountability. The operations manager now owns RevOps but is still being held to their previous targets by a manager who has not changed what they measure. Useful at early stage when budget for a new hire is not there, but only if leadership will actually back the ownership change.
Option 2 - Full-time hire. Makes sense when the systems exist, the data model is reasonably clean, and the volume of work justifies dedicated headcount. You need someone technical enough to work inside the systems but senior enough to hold the conversation with sales and marketing leadership. That combination is genuinely hard to find. Worth taking time over the hire rather than settling for someone who can do one but not the other.
Option 3 - Fractional or project-based support. The right answer when you have specific bottlenecks to fix and cannot yet justify a full-time person. A broken handoff process, a CRM that nobody trusts, an integration between Bullhorn and HubSpot that does not exist - these are scoped problems that a fractional operator can diagnose and build. The distinction is diagnose and build, not advise. Advice without implementation is how consulting projects produce documents that sit in Google Drive and change nothing.
If the consultancy route looks right, here is what a good RevOps consultancy engagement in the UK actually looks like.
If you are not sure which of these applies to your situation, that is usually a sign that the diagnosis needs to come before the decision. A HubSpot systems audit is where that conversation starts - it maps the specific gaps in your systems, processes, and handoffs, and gives you a clear picture of what actually needs fixing before you commit to how to fix it.
