What Is RevOps? The Complete Guide to Revenue Operations

What is revenue operations?

Revenue operations is the function that owns the systems, data, and process shared by marketing, sales, and customer success. It exists because those three teams generate revenue together but, left alone, instrument it separately — and three separate instruments produce three separate versions of the truth.

The practical definition we use with clients: RevOps owns everything between the teams. Marketing owns campaigns. Sales owns conversations. CS owns renewals. RevOps owns the CRM object model, the lifecycle stages, the routing, the attribution, the definitions, the handoffs, and the reporting layer that sits on top of all of it. When a deal moves from stage 2 to stage 3, RevOps owns what that means and whether the system enforced it.

Why RevOps exists: the three-funnel problem

Every B2B company starts with one funnel that lives in a founder's head. Then it hires a marketer, who builds a demand funnel. Then it hires reps, who build a sales funnel. Then it hires CS, who build a retention funnel. Nobody decides to fragment the revenue engine — it fragments as a byproduct of hiring.

The symptoms are predictable, and they show up in the same order:

• Definition drift. Marketing's MQL and sales' qualified lead stop meaning the same thing. Nobody notices for two quarters.
• Handoff leakage. Leads sit unrouted for days. The SLA exists in a doc, not in the system.
• Attribution arguments. Marketing claims pipeline sales says it sourced. Both are reading real data from different systems.
• Forecast drift. The number the board sees and the number the CRO believes diverge, and the gap gets closed by gut feel.
• Tool sprawl. Each team buys its own point solution to fix its own view of the problem, which deepens the fragmentation.

RevOps is the structural answer: one function, accountable to the full revenue number, that owns the connective tissue. Not a referee between departments — an owner of the system all three run on.

What does a RevOps team actually do?

Ask ten companies and you will get ten answers, because most RevOps job descriptions are written by people who have never run the function. In practice the work falls into five buckets, in the order you should build them.

1. 01
   Systems architecture

   CRM object model, lifecycle stages, required fields, validation rules, integrations between the CRM and everything else. This is the foundation; skip it and every later layer inherits the mess.

2. 02
   Data quality and governance

   Deduplication, enrichment, normalisation, ownership rules, and the maintenance jobs that keep them true. Data quality is not a project. It is a recurring operational job with an owner and a schedule.

3. 03
   Process design and enforcement

   Stage exit criteria, routing rules, SLAs, approval flows, handoff triggers. The word that matters is enforcement — a process that lives only in a document is a suggestion.

4. 04
   Analytics and forecasting

   Pipeline coverage, conversion by stage, velocity, CAC and payback, NRR. The output is a forecast the CEO can defend to a board, built on numbers anyone can trace back to a record.

5. 05
   Enablement of the system

   Making the above usable: fields reps will actually fill, dashboards managers actually open, and a weekly cadence that turns the data into decisions.

Notice what is not on the list: running campaigns, sitting on calls, closing deals. RevOps builds and runs the machine. The revenue teams operate it. Blur that line and you get a very expensive admin.

RevOps vs sales ops vs marketing ops

The three overlap enough that the labels get used interchangeably, which causes real hiring mistakes. The distinction that matters is scope of accountability.

The most common structural error we see: a company hires a RevOps lead but leaves system ownership with the individual departments. The RevOps hire is now accountable for a number they cannot influence, because they cannot change the systems that produce it. That role churns inside a year, every time.

When do you need RevOps?

The trigger is structural, not a headcount number. You need RevOps when the revenue system has more moving parts than any one person can hold in their head — which for most B2B companies happens somewhere between $1M and $5M ARR, but the ARR is a symptom, not the cause.

Four signals that you have crossed the line:

• Nobody can explain a forecast miss within a day. The data exists, but reconstructing what happened takes a week of manual work.
• Two functions report the same metric differently and both can defend their number.
• Onboarding a new rep takes longer than the sales cycle because the process lives in tribal knowledge.
• Your last three tool purchases were each meant to fix reporting, and reporting did not improve.

If none of these are true, you do not need RevOps yet — you need to keep selling. Hiring the function early, before there is a system worth operating, produces beautifully architected infrastructure for a motion that has not been proven.

The RevOps metrics that matter

A RevOps function that reports forty metrics is reporting none of them. The working set is small, and each one has to have a decision attached to it — if no decision changes when the number moves, stop reporting it.

Start with pipeline coverage and stage conversion; everything else is a refinement on top of those two. The full working set, with the decision attached to each, is in the 12 RevOps metrics that matter — and building the reporting layer that keeps them current is its own discipline, covered in revenue analytics.

How to build a RevOps function from scratch

The sequence matters more than the speed. Every step below assumes the previous one holds, and skipping ahead is the single most common reason RevOps builds stall at month four.

1. 01
   Agree the definitions before touching a system

   Write down what a lead, an MQL, an SQL, an opportunity, and a closed-won deal mean. Get marketing, sales, and CS to sign the same document. This takes about a week and prevents about six months of rework.

2. 02
   Audit what you actually have

   Every system, every integration, every field, every report someone depends on. Most companies discover 40% of their fields are unused and two integrations are silently failing.

3. 03
   Rebuild the object model to match the definitions

   Stages with exit criteria the system enforces. Required fields only where a decision depends on them. One source of truth per data point, with a named owner.

4. 04
   Fix the handoffs

   Routing rules, SLAs, and automated triggers between every pair of teams. This is where most recovered revenue actually comes from — leaked leads convert at zero.

5. 05
   Build the reporting layer last

   Dashboards built on a broken data model just make the breakage look official. Once the model holds, the reporting is close to trivial.

6. 06
   Install the cadence

   A weekly pipeline review, a monthly metrics review, a quarterly system review — each with a fixed agenda and a named owner. Without cadence, the system decays back to entropy in about two quarters.

RevOps as a service: agency, fractional, or in-house?

The build above needs senior judgement early and steady hands later, which is why the staffing question rarely has a single answer. In rough terms:

• In-house wins once the system is stable and the job becomes daily operation, enablement, and incremental improvement. It is the expensive option for the build phase, because the person who architects well is rarely the person who wants to maintain it.
• Agency wins for the build: architecture, migration, and process design are project-shaped work needing a range of specialisms you would otherwise hire four people for.
• Fractional wins when you need senior judgement on a recurring basis but not forty hours of it — typically post-build, pre-first-hire.

Most companies get the best outcome from a sequence rather than a choice: agency or fractional for the build, in-house for the run, with the agency staying on for the quarterly system review. We break the economics down in RevOps agency vs in-house and what a revenue operations consultant actually does.

The mistakes that cost the most

• Buying tools before fixing definitions. A new platform will faithfully reproduce your existing ambiguity, faster and at higher cost.
• Treating data quality as a one-time cleanup. It decays continuously. Without a recurring job and an owner, you will re-run the same cleanup every year.
• Reporting without enforcement. A dashboard showing that reps skip stage 2 does not stop reps skipping stage 2. Validation rules do.
• Hiring RevOps into a department. Put the function under one of the three teams and it will optimise that team's number at the expense of the other two.
• Over-instrumenting an unproven motion. If you do not yet know which channel works, you do not need an attribution model. You need more experiments.

What good looks like

A working RevOps function is quiet. The tell is not a beautiful dashboard — it is the speed at which the company can answer a hard question. Ask a mature revenue org why last quarter came in 8% under plan, and you should get a specific, traceable answer in under five minutes: stage 3 conversion dropped six points in one segment, driven by two competitors entering, first visible in week four.

That is the deliverable. Not the CRM, not the reports, not the tool stack — the ability to explain the revenue number and act on the explanation before the quarter closes.