What the role actually is
Revenue operations owns the system that revenue moves through, end to end, across every function that touches a customer. That means the definitions — what a lead is, what a stage means, when revenue counts — the tooling those definitions live in, the handoffs between marketing, sales and delivery, and the forecasting that comes out the other end.
The distinguishing feature is scope. Sales operations owns the sales process. Marketing operations owns the marketing machinery. RevOps owns the whole path and, critically, the seams between them, which is where most revenue leaks in a company large enough to have separate teams.
In practice, a RevOps person spends their time on four things: making sure the pipeline data is trustworthy, making sure handoffs between functions do not drop context, producing a forecast anybody can defend, and removing friction from the path a customer takes from first touch to signed.
It is worth knowing that the title is used loosely at small scale. A lot of jobs advertised as RevOps in a twenty-person company are sales operations roles, or CRM administration roles, with a more current name attached.
The clearest way to place it against neighbouring roles: sales operations makes the sales team faster, marketing operations makes the marketing engine run, and revenue operations makes the numbers coming out of all of them mean the same thing.
When you genuinely should hire one
Hire when you have genuinely separate functions with genuinely separate systems. Marketing generating leads in one tool, salespeople working them in another, delivery picking them up in a third — and each function optimizing its own numbers. That is the problem RevOps was invented for and it does not have another solution.
Hire when the forecast matters to someone outside the business. Investors, lenders, a board, an acquirer. Producing a forecast that survives scrutiny requires stage definitions, historical conversion rates and disciplined data entry, and somebody has to own all three continuously rather than assembling them quarterly.
Hire when the seams are visibly costing you. Leads that marketing considers qualified and sales considers junk, deals that reach delivery without the context that was promised, expansion opportunities nobody owns because they sit between two teams. Those are seam problems and they are structurally nobody's job.
Compensation for these roles varies widely — broadly, a mid-level revenue operations manager in the US market tends to sit somewhere around the ninety to a hundred and thirty thousand range, with senior and director-level roles well above that. Treat that as general market context rather than a target; it moves sharply with sector and with how technical the role is expected to be.
Where the hire fails
It fails most often on timing. A business where the founder is the entire sales function does not have a revenue operations problem — it has a pipeline architecture problem, which is a build with an end date rather than a role with a salary. A RevOps hire in that situation will spend their first year building what a project would have delivered in weeks, and then be underemployed.
It fails when there is no data to operate on. The role assumes a pipeline with recorded activity, defined stages and history. In a business where the pipeline is the founder's memory, the first year is data entry archaeology, and the person you hired for systems thinking is doing clerical work.
It fails when the role has no authority over definitions. RevOps only works if this person can decide what a qualified lead is and have that decision stick across functions. Without that, they document disagreements rather than resolving them, and the weekly argument about the numbers continues with better minutes.
And it fails in the way every operations hire fails: they become the system. The forecast is trustworthy because they personally reconcile it, the definitions hold because they personally enforce them, and none of it is written down. That is a single point of failure sitting on top of your revenue reporting.
There is also a common misfire where the role is hired to fix a forecasting complaint. Forecasts are unreliable because stage definitions are vague and history is thin, and a new person cannot retroactively create either. They will produce a more carefully caveated version of the same guess.
What has to exist first
More than one function. If sales, marketing and delivery are the same two people, there are no seams to own, and the work that looks like RevOps is actually pipeline design.
A pipeline with stages that mean something — entry and exit conditions tied to observable events rather than adjectives — and enough recorded history that conversion rates by stage exist. Without those, forecasting is not a discipline problem, it is an absence of inputs.
Written definitions for the handful of words that cause arguments: lead, qualified, active client, closed. One sentence each, one named owner, stored where the number is displayed. RevOps maintains and enforces those definitions; it cannot invent them into a business that has never agreed on them.
And a decision about authority, made before the hire. What this person can change unilaterally, and what requires your agreement. A revenue operations manager with responsibility for the numbers and no authority over the definitions behind them has been given an unwinnable job.
How to tell which you need
Count the functions that touch a customer and have their own owner. Three or more, with separate systems and separate targets, and RevOps is a real role — hire it, and hire it before the seams cost you another year.
One or two, and what you have is a pipeline that has never been architected. That is genuinely a different purchase: stages with real conditions, follow-up that runs from the system, a handoff artifact into delivery, and the four numbers that make forecasting possible. Weeks of work, not a salary line, and it produces the substrate a RevOps hire would need anyway.
The honest test is whether you would still have a job for this person in year two once the initial build is done. If the answer is maintaining and improving a system several teams depend on, hire. If it is running a system one person uses, you are hiring a project.
If you are between the two — growing, functions starting to separate, forecast starting to matter — build the architecture now and hire the role in twelve months. The person you hire then will be measurably better than the person you would hire today, because you will know what you are asking them to run.
One practical shortcut: look at who currently gets asked when two functions disagree about a number. If that is always you, the seam exists and somebody other than the founder should own it.
RevOps owns the seams between functions, so the job only exists once there are several. With one sales function and no recorded history, what looks like a RevOps hire is a pipeline build.