Revenue Operations (RevOps) is one of those terms that’s everywhere right now and rarely explained properly. It gets used to mean CRM admin. It gets used to mean data analytics. It gets used to describe a job title that means something different at every company that uses it.
So let me try to explain what I think it actually means, because it’s the foundation of most of the work I do and it’s worth being precise about.
This post sits alongside What is a Fractional CRO?; RevOps is the infrastructure that makes fractional commercial leadership actually work.
The short version
RevOps is the infrastructure that makes revenue predictable.
Not the people who sell. Not the strategy. The infrastructure: the systems, processes, and data architecture that sit underneath the revenue function and determine whether the business can actually see what’s happening, forecast where it’s going, and trust what it’s measuring.
If sales is the engine, RevOps is the dashboard, the fuel system, and the diagnostic computer. You can have a powerful engine and still be flying blind.
What’s actually in scope
When I talk about RevOps in practice, I mean four things.
CRM architecture. How the pipeline is built. What the stages mean. What data lives where. Whether the fields people fill in are the ones that matter. Whether the setup reflects how the business actually sells or how someone imagined it might sell three years ago.
Most CRMs I inherit are set up once, never revisited, and gradually drift further from reality as the business changes. The result is a database that stores data without producing insight, and a pipeline that can’t be trusted. If you’re on HubSpot, HubSpot for B2B Founders covers the specific configuration decisions that actually matter.
Revenue reporting. What the business can measure and what it can’t. Conversion rates at each stage. Average deal cycle. Win/loss breakdown by segment, deal size, rep. Forecast accuracy over time.
Most businesses at the £500k–£5M stage can tell you how much they’ve closed this quarter. Very few can tell you why. The reporting infrastructure is the difference between knowing the outcome and understanding how you got there.
Process architecture. The documented, agreed-upon way the business sells. Stage definitions with exit criteria. Qualification frameworks. Discovery guides. Handover points between marketing, sales, and customer success.
This sits at the intersection of sales methodology and RevOps. You can’t build a pipeline that means anything if the stages mean something different to every rep. And you can’t build reliable reporting if the underlying process is inconsistent. Pipeline Stage Definitions with Exit Criteria has a working template for this.
Tech stack management. What tools you’re using, whether they talk to each other, whether they’re actually being used, and whether the cost and complexity is justified by the value they produce.
A lot of B2B businesses at growth stage have a tech stack that’s been accumulated rather than designed. A tool gets added to solve one problem, another gets added six months later, nobody’s quite sure what integrates with what, and the CRM is receiving data from four sources of varying quality. Sorting that out is RevOps work.
What RevOps isn’t
It’s not just CRM admin. CRM admin is part of it, but RevOps is concerned with whether the CRM is configured correctly, whether it’s generating useful insight, and whether the process it’s supposed to reflect actually matches how the business sells. Admin is the execution. RevOps is the architecture.
It’s not a separate department. In most B2B businesses at the scale I work with, RevOps isn’t something you need a dedicated team for. It’s a set of responsibilities that should sit with whoever owns the revenue function, and that function should include it explicitly. The problem arises when nobody owns it.
It’s not a technology problem. The tools are downstream of the process. A broken process configured beautifully in Salesforce is still a broken process. Every time I see a founder about to spend significant money on a new CRM or a new sales tool, the first question is whether the problem is actually the tool or the process running on it. Usually it’s the process.
And it’s not something you can defer. This is the mistake I see most often. The thinking goes: we’ll sort out the process and the reporting once we’re bigger. Once we have more reps, more data, more time.
But the CRM you configure when you have three deals in the pipeline is the CRM you’ll be using when you have thirty. The bad habits that get embedded early compound. And the longer you leave it, the more painful the rebuild.
Why this matters for B2B founders specifically
Founder-led businesses have a particular RevOps problem. The founder usually has an intuitive, accurate mental model of the pipeline: who’s likely to close, which deals are real, what the actual revenue is going to be for the quarter.
The problem is that model lives in one person’s head. It doesn’t scale. It can’t be delegated. It isn’t visible to the team or the board. And when the founder tries to step back from the day-to-day, the business suddenly can’t forecast because the only person who could is no longer engaged with every deal.
There are more specific signs that a sales function is over-reliant on one person in Signs Your Sales Process Is Founder-Dependent.
Building the RevOps infrastructure forces that mental model into systems. The pipeline stages get defined. The qualification criteria get written down. The forecast process becomes something the team runs, not something the founder holds in their head.
That’s the transition from founder-led sales to a functioning revenue operation. And RevOps is the mechanism that makes it possible.
The test worth running
If you want to know how your RevOps is doing, ask yourself three questions.
Can anyone in your business tell you your conversion rate from first meeting to close without looking it up manually? Can you produce a 90-day revenue forecast with a reasonable margin of error (say, within 20%), using your CRM data? And if you were out of contact for a week, would your pipeline review still happen and still be useful?
If the answer to all three is yes, your RevOps is in reasonable shape. If the answer to any of them is no, there’s work to do.
The good news is it’s usually less complicated to fix than people expect. The foundations (pipeline architecture, stage definitions, a small number of meaningful metrics) can be put in place in a few weeks. Getting the team to use them consistently takes longer, but that’s a management problem, not a technical one.
The bad news is it takes someone deciding to prioritise it. And in most founder-led businesses, that hasn’t happened yet.
If you’re approaching Series A and want to understand what the revenue infrastructure needs to look like at that stage, the Series A Sales Infrastructure Checklist covers the specific milestones. For a real-world example of RevOps work on a B2B services pipeline, the B2B Services Pipeline case study shows what the before and after looks like. And if you want to understand what it would look like to get this in place properly, Discovery Week is where that conversation starts: a structured diagnostic that maps exactly where the gaps are and what needs building first.