How should a RevOps team be structured?

There are three viable shapes — centralised, embedded and hybrid — and the choice should follow the problem you actually have. If definitions are contested and the forecast is untrustworthy, centralise: consistency is the constraint. If the functions move too slowly because operations is a bottleneck, embed. Above roughly two hundred people, most organisations end up hybrid, with a small central team owning shared definitions and data standards while embedded operators own execution.

Who should RevOps report to?

Most commonly the CRO, but reporting to a COO or CFO is increasingly common and produces a different function. Under a CRO, RevOps serves sales attainment and gets closer to the field. Under finance or operations, it serves forecast accuracy and planning, and tends to hold a firmer line on definitions because it is not reporting to the function it is governing. The second is structurally better for governance and worse for adoption.

How big should a RevOps team be?

We have not measured a defensible ratio and will not publish one. The useful question is not headcount but coverage: is there a named owner for every shared definition, every routing rule, every system of record, and the forecast? Run that inventory and the gaps tell you where the next hire goes, which is a better guide than any benchmark ratio — most of which trace back to vendor surveys that cannot be verified.

Should marketing ops and sales ops report into RevOps?

If the handoffs between them are where your problems are, yes — that is precisely the failure the combined function exists to fix, and leaving them separate guarantees nobody owns the transition. If each function's internal execution is the bottleneck and the handoffs are fine, a hybrid works better: shared definitions centrally, execution locally. Reorganising is expensive, so be sure which problem you have first.

ORGANISATION DESIGN

RevOps team structure: three shapes, and the failure that comes with each

There is no correct structure, only a structure matched to a constraint. Each of the three common shapes solves a real problem and creates a predictable one, and choosing well means knowing which problem you would rather have.

The question “how should we structure RevOps” is usually asked when something has already gone wrong — the forecast missed, two teams produced contradictory numbers, or a request queue stopped moving. That is useful, because the specific thing that went wrong is the information you need to choose.

The underlying trade-off is always the same: consistency between functions versus speed inside them. Every structure buys one with the other. Nothing gets you both, and organisations that believe they have found a shape that does have usually just not yet noticed which one they gave up.

The three shapes

Centralised

One RevOps function, reporting to a single leader, serving marketing, sales and customer success as internal clients.

Suits.: Organisations that need consistent definitions more than they need speed — typically because reporting is contested, the forecast is unreliable, or the same customer exists three times across three systems.
Fails by.: It becomes a ticket queue. Distance from the functions means requests arrive as specifications rather than as problems, and the team optimises for throughput on the queue rather than for outcomes it can no longer see.
The tell.: The team measures itself in tickets closed and cycle time, and nobody can name a process it changed this year.

Embedded

Operations people sit inside each function — marketing ops in marketing, sales ops in sales — with a dotted line to a central lead, or none at all.

Suits.: Organisations where the functions are genuinely different businesses, or where speed of response inside each function matters more than consistency between them.
Fails by.: The handoffs go unowned, which is where revenue actually leaks. Each embedded team optimises its own surface, the definitions drift apart, and the disagreement surfaces at the quarterly review as a reporting dispute nobody can resolve.
The tell.: Marketing and sales quote different numbers for the same funnel and both are internally consistent.

Hybrid

A small central team owns shared definitions, data standards and the systems of record; embedded operators own execution inside each function.

Suits.: Most organisations above roughly two hundred people. It is the common answer because it matches the actual structure of the problem: some decisions must be shared, most execution should be local.
Fails by.: The split of authority is left implicit and the two layers duplicate or contradict each other. Hybrid is the hardest to run because it requires writing down who decides what, and most organisations never do.
The tell.: A change ships twice, or a definition exists in two places with different wording.

The thing that matters more than the shape

A process step with two owners fails the same way as one with none. This is the single most useful idea in organisation design for revenue operations, and it means the structure is downstream of a more basic question: is there exactly one named owner for each shared thing?

Shared things are the definitions (what a qualified lead is), the systems of record (which system is authoritative for which field), the routing rules, and the forecast. An organisation that can name one owner for each of those works under any of the three shapes. One that cannot will fail under all of them, and reorganising will feel like progress for about two quarters.

Decide your structure in an afternoon

1
List every shared definition, rule and system of record
Lifecycle stages, qualification criteria, routing rules, required fields, and which system wins for each contested field. Most organisations have never written this down, and the writing is most of the value.
2
Put exactly one name against each
Not a team — a person. Where you can put two names, or none, you have found the actual problem, and it is almost never solved by changing the org chart.
3
Identify which constraint is currently binding
Are the functions producing contradictory numbers (consistency is binding — centralise the definitions), or are they blocked waiting on operations (speed is binding — embed the execution)?
4
Choose the shape that relieves that constraint, and name the failure you accept
Write the expected failure mode down at the time of the decision. It converts an inevitable future complaint into a known, monitored trade-off rather than evidence the structure was wrong.
5
Re-run the inventory in two quarters
Ownership decays. Fields get added, people leave, a new system arrives. The inventory is the artefact worth maintaining; the org chart is not.

WHERE THIS FAILS

Below about fifty people none of this applies. One person is the whole function and the structure question is premature. The inventory in the protocol is still worth doing, because it is what you will hand to the first hire.

Reorganising is expensive and is frequently the wrong lever. If the diagnosis is unowned definitions, assigning owners fixes it without moving anybody. Structure changes cost months of productivity and should be reserved for when the ownership fix has been tried and genuinely could not hold.

We publish no headcount ratios because we have not measured any, and the commonly cited ones trace back to vendor surveys that cannot be verified. Coverage of the inventory is the better test and you can run it yourself.

The inventory, as a working tool

Step one is the ownership inventory, and it is one of the free templates here — the same schema the paid audit tools use, downloadable as a spreadsheet with worked examples.

Free audit templates Job description template

COMMON QUESTIONS

How should a RevOps team be structured?: There are three viable shapes — centralised, embedded and hybrid — and the choice should follow the problem you actually have. If definitions are contested and the forecast is untrustworthy, centralise: consistency is the constraint. If the functions move too slowly because operations is a bottleneck, embed. Above roughly two hundred people, most organisations end up hybrid, with a small central team owning shared definitions and data standards while embedded operators own execution.
Who should RevOps report to?: Most commonly the CRO, but reporting to a COO or CFO is increasingly common and produces a different function. Under a CRO, RevOps serves sales attainment and gets closer to the field. Under finance or operations, it serves forecast accuracy and planning, and tends to hold a firmer line on definitions because it is not reporting to the function it is governing. The second is structurally better for governance and worse for adoption.
How big should a RevOps team be?: We have not measured a defensible ratio and will not publish one. The useful question is not headcount but coverage: is there a named owner for every shared definition, every routing rule, every system of record, and the forecast? Run that inventory and the gaps tell you where the next hire goes, which is a better guide than any benchmark ratio — most of which trace back to vendor surveys that cannot be verified.
Should marketing ops and sales ops report into RevOps?: If the handoffs between them are where your problems are, yes — that is precisely the failure the combined function exists to fix, and leaving them separate guarantees nobody owns the transition. If each function's internal execution is the bottleneck and the handoffs are fine, a hybrid works better: shared definitions centrally, execution locally. Reorganising is expensive, so be sure which problem you have first.