What Revenue Operations Is - Scope, Mandate and the Artefacts It Owns

Revenue operations is usually defined by its aspiration — alignment, a single source of truth, the connective tissue of go-to-market — which describes an outcome without telling you what the function does on a Tuesday, what it decides, or what should be taken away from it.

A more useful definition starts from ownership, because the arguments that actually consume a RevOps team are arguments about who gets to decide something.

An Operational Definition

Revenue operations owns the systems, data and process by which revenue is generated and measured, across marketing, sales and customer success.

Three parts of that carry weight. Owns means holding decision rights rather than offering recommendations, because a function that can only advise cannot maintain a data model that anyone is free to overrule. Systems, data and process excludes strategy, targets and headcount, so RevOps decides how the pipeline is modelled without deciding what the pipeline should be worth. And across all three is the whole reason the function exists, since sales ops that occasionally touches marketing is still sales ops — the defining characteristic is a single owner for a customer journey that crosses three teams which previously governed it with three separate sets of assumptions.

Stephen Diorio and Chris Hummel make the organisational case for this at length in *Revenue Operations: A New Way to Align Sales & Marketing, Monetize Data, and Ignite Growth* (Wiley, 2022), which is the most substantial treatment of the model as a management structure rather than a job title.

Ownership Tested Against System Artefacts

Ownership is easier to test than to define, and the test is whether the function controls the settings that determine what the business reports — which three specific HubSpot artefacts illustrate better than any definition does.

Forecast categories. HubSpot's forecast tool assigns deal stages to categories — Not forecasted, Pipeline, Best case, Commit and Closed won — and those assignments determine which deals appear in a forecast at all, so whoever controls that mapping controls the number presented to the board without altering a single deal record. HubSpot's documentation on setting up and customising pipelines covers the configuration; the decision about which stage belongs in Commit is not a configuration question.

Stage probability. Weighted pipeline is computed by multiplying the amount in each stage by that stage's probability, and the forecast probability on a deal updates automatically when a user moves it, using the win probability set against the destination stage — one of the system-managed fields listed in HubSpot's default deal properties. A team that adjusts stage probabilities to make a weighted number look reasonable has changed the forecast without changing anything about the deals, which is why the probability schedule belongs to the function accountable for measurement rather than the one accountable for the number.

Lifecycle progression. HubSpot documents that lifecycle stages do not move backward — a record already marked Customer will not be downgraded when a new deal is created — and that an enabled sync applies a primary company's stage to its associated contacts in that direction only. A process designed without knowing this produces reporting that quietly disagrees with what the sales team believes is happening.

None of those three would be recognised by leadership as a strategic decision, yet each of them silently determines what leadership sees — which is the practical content of the phrase "single source of truth".

The Mandate: Included Responsibilities

The CRM data model — objects, properties, associations, lifecycle — together with the process encoded in systems, meaning routing, handoffs, stage definitions, automation and service levels. The decisions inside each of those are covered separately for onboarding, workflow enrolment and data quality.

Definitions belong here too, particularly the ones teams would otherwise resolve differently: what a qualified lead is, when a deal enters pipeline, what counts as churn.

So does reporting integrity, which is not the same as building every chart. The function owns the definitions beneath the charts so that two teams cannot compute the same metric two ways.

The technology stack — selection, integration, administration and retirement — sits inside the mandate, as does data quality across hygiene, deduplication, enrichment and governance. And forecast mechanics belong here, though the forecast number itself does not.

The Mandate: Explicit Exclusions

This list is the more useful of the two, because scope creep is the mechanism by which the function fails without anyone deciding to end it.

Quota and territory setting is modelled and implemented by RevOps but owned by sales leadership. Pricing and packaging belong to product and finance. The forecast number belongs to whoever is accountable for hitting it, even though the machinery producing it does not. Campaign strategy and creative remain with marketing, and hiring and performance management remain with the revenue teams themselves.

Being the help desk is the exclusion that matters most in practice, because a function whose week is consumed by password resets and one-off report requests has been absorbed into support and will never reach the architectural work it was created for. A function without an explicit not-list becomes the place every unowned task lands.

Distinction from Sales Operations and Marketing Operations

These are used interchangeably and are genuinely different.

Sales operations serves the sales organisation through territory, quota, compensation administration, pipeline hygiene, tooling and deal desk, and its scope ends at that team's boundary. Marketing operations serves marketing through campaign execution, automation, scoring and routing up to the handoff, and attribution modelling.

Revenue operations owns the layer both of those sit on. Where each optimises within a team, RevOps is accountable for what happens between them, and for the fact that a lead, an opportunity and a customer are one entity described three ways.

The practical test is who owns the handoff. Where the answer is that the teams agreed a process, you have sales ops and marketing ops working cooperatively. Where one person can change the handoff definition and both teams live with it, you have revenue operations.

Past roughly fifty revenue employees, running both becomes workable — specialists inside each team, plus a function owning the shared layer — which is a division of labour rather than duplication.

Reporting Lines and Their Consequences

The reporting line determines what the function is permitted to be.

Reporting to a CRO is the arrangement we encounter more than any other and it works, carrying the risk that RevOps becomes sales ops with a broader title because that is where the pressure originates. Reporting to a COO or CFO buys independence and governance discipline at the cost of distance from the revenue teams and a reputation as finance's enforcement arm. A dedicated leader reporting to the CEO is the strongest arrangement at scale and uncommon below a few hundred people.

The arrangement that reliably fails is RevOps reporting into sales while being asked to arbitrate between sales and marketing, because it will resolve in favour of whoever conducts its performance review.

Function Design by Organisational Scale

Below fifty revenue employees the function tends to be one person, part-time, who became the de facto administrator by being the one who understood the CRM. The correct scope is narrow — one CRM, clean data, defined stages, reporting that reconciles — and the characteristic failure is buying tools to solve process problems.

Between fifty and two hundred and fifty it becomes a small dedicated team of two to five, with enough work to specialise across systems, analytics and enablement. This is where the mandate has to be written down, because it is where the function either establishes decision rights or becomes a permanent ticket queue.

Above two hundred and fifty it becomes a function with sub-teams and often embedded specialists inside each revenue team alongside a central group owning shared architecture. The failure here is central and embedded teams making conflicting decisions because nobody defined which one wins.

Indicators of Unmet Need

Marketing and sales report different numbers for the same thing and both are defensible. Nobody can say confidently how many opportunities came from a given source. The CRM contains fields nobody can explain and reports nobody trusts. Handoffs happen by direct message. The forecast is assembled by hand each week from exports. Every new tool creates another source of truth. A leaver takes an undocumented process with them.

Two of those are enough, because the cost is already being paid — in reconciliation time, in decisions made on numbers people privately distrust, and in deals lost through the gap between two teams.

Failure Modes

It becomes a ticket queue, which happens gradually as the team says yes to every request until the backlog is entirely small work and the architectural work never starts. An explicit request process with a service level and a protected share of capacity for planned work is the defence.

It is given no decision rights, which makes owning a data model impossible in practice because any team can overrule a structure it finds inconvenient.

It optimises for whichever team applies the most pressure, which produces a system serving one team well and the customer journey badly.

It builds for a company it does not have — attribution modelling before lead sources are clean, forecasting sophistication before stage definitions mean anything — where sequence matters more than ambition.

It documents nothing, and since undocumented systems decay in proportion to how clever they are, this is a function constructing its own future emergency.

Establishing the Function

Write the mandate including the not-list, and have it agreed by the leaders of all three teams. Establish decision rights over the CRM data model explicitly and in writing, naming who may overrule whom. Fix definitions before systems, because no amount of configuration repairs a definition that two teams read differently. Make one number trustworthy and defend it, since credibility comes from a figure nobody argues with rather than from a roadmap. Document as you go.

The order of those steps matters more than the pace at which they are completed. The failed RevOps functions we have been asked to repair began at step three with steps one and two unresolved, and spent their first year discovering they had no authority to do the work they were hired for.

If you are assessing an existing operation rather than standing one up, an audit reaches the same conclusions faster — the method is covered in how to conduct a RevOps audit, and scope is on our store.