GTM Engineering & Operations - Revenue Operations: What It Owns and How to Build the Function
Revenue operations is the function that makes a revenue team's numbers mean the same thing to everyone who reads them. It owns process, definitions, forecasting methodology, territory and compensation design, and the health of the systems all of that runs on.
It is also the function most likely to be hired and then structurally prevented from doing its job. This page covers what RevOps genuinely owns, the authority it needs, a maturity model to locate yourself on, and how to build the function without recreating the reporting desk that most companies end up with.
6 min read5 sectionsGTM Engineering & Operations
What you'll take away
- RevOps owns process and definitions across marketing, sales and customer success — not just sales admin.
- Without authority to block a tool purchase or reject a process change, RevOps is a reporting analyst with a different title.
- The four maturity stages are reactive, standardised, automated and predictive. Most companies are stuck between the first two.
- RevOps designs; GTM engineering builds. Merging the two produces a design backlog nobody has time to work on.
What revenue operations actually owns
The scope is broader than sales operations and narrower than "everything the revenue team does". These six areas are the core, and each should have a named owner inside RevOps even in a one-person function.
- Definitions and the data dictionary
- What counts as a qualified lead, an opportunity, an active customer, churn. Written down, versioned, and enforced through required fields and validation rules rather than through training sessions.
- Process design across the full funnel
- Stage definitions with exit criteria, handoff points with owners and SLAs, escalation paths. Explicitly spanning marketing, sales and customer success — the cross-functional scope is what makes it RevOps.
- Forecasting methodology
- How the forecast is built, which signals feed it, how commit and best-case are defined, and how accuracy is measured after the fact. RevOps owns the method; the sales leader owns the number.
- Territory, quota and compensation design
- How the market is divided, how targets are set and how behaviour is incentivised. Comp design is where strategy becomes behaviour, and it is routinely done without the data to support it.
- System architecture and tool governance
- Which tools exist, what each is authoritative for, how they connect, and who can buy a new one. Without this, layer overlap and contradictory data are guaranteed.
- Reporting and analytics infrastructure
- The metric definitions, the warehouse models and the dashboards. Everyone should be able to get the same answer to the same question without asking a person.
The RevOps maturity model
Four stages. The value of the model is locating yourself honestly, because each stage has a specific next action and skipping ahead does not work.
| Stage | What it looks like | Next action |
|---|---|---|
| Reactive | Spreadsheets, manual reporting, definitions vary by team, forecast is a negotiation | Write the definitions down and get them signed off. Nothing else works until this is done. |
| Standardised | Shared definitions, one CRM, consistent stages, reporting agrees across teams | Automate enforcement — required fields, validation rules, routing in code rather than in habit |
| Automated | Routing, enrichment, scoring and hygiene run without human intervention; SLAs monitored | Build the warehouse and the historical snapshots that make trend and cohort analysis possible |
| Predictive | Forecasts from historical patterns, churn risk surfaced early, scenario modelling | Maintain rigorously. This stage decays fastest because the models silently drift with the business. |
Most companies are somewhere between reactive and standardised, and try to jump to predictive because that is what the tooling market sells. Predictive models built on inconsistent definitions produce confident forecasts that are wrong in ways nobody can debug.
How to build the function
Whether this is your first RevOps hire or a rebuild, the same sequence applies. The first three steps are documentation and agreement, which is why they get skipped and why skipping them fails.
Audit the current state without changing anything
Document existing definitions, stages, tools, reports and manual processes exactly as they are. Two weeks. The output is uncomfortable to read and is the most valuable artefact the function will produce in its first year.
Get definitions agreed in writing
One document: ICP, lifecycle stages, qualification criteria, opportunity stages with exit criteria, churn definition. Signed off by marketing, sales and customer success leadership. Verbal agreement is not agreement.
Establish the governance rules
Who can create fields, who approves tool purchases, how process changes are proposed and reviewed. Boring, and it is what prevents the definitions from drifting within two quarters.
Rebuild the data model to match the definitions
Required fields, validation rules, picklist standardisation, object relationships. This is engineering work — either RevOps has that capacity or it needs a build partner.
Instrument the funnel end to end
Stage transition timestamps, immutable source attribution, handoff logging. Without this, everything from stage three onwards is guesswork.
Automate the enforcement
Routing, enrichment, hygiene jobs, SLA alerting. Enforcement through systems rather than through reminders is the difference between a process and a suggestion.
Build reporting on the warehouse
Metric definitions in version control, dashboards from the warehouse, snapshots preserved. Now the numbers survive a pipeline redesign.
Set a quarterly review cadence
Definitions, stages, comp design and stack reviewed every quarter. RevOps output decays by default; scheduled maintenance is what keeps stage three from sliding back to stage one.
The mistakes that make RevOps ineffective
- Hiring RevOps into a sales ops job
- If the mandate is quotas, territories and CRM admin for reps, that is sales operations. Marketing and customer success data will continue to degrade because nobody owns them.
- Placing RevOps under finance
- It becomes accurate, backward-looking and structurally unable to change how the revenue team operates. Reporting to the revenue leader is what gives the function operating authority.
- Expecting design and build from one person
- The build backlog always exceeds the available week, at which point design stops. Separate the roles or pair a RevOps designer with external engineering capacity.
- Buying a tool before agreeing definitions
- A tool configured against undefined process encodes the ambiguity permanently and makes it more expensive to fix later.
- Treating it as a reporting function
- If RevOps spends most of its week producing reports on request, it has become a service desk. Automate the reports and reinvest the time in process and systems.
Frequently asked questions
What is revenue operations?
- Revenue operations is the function that owns process, definitions, forecasting methodology, territory and compensation design, and system architecture across marketing, sales and customer success. Its purpose is to make the revenue motion consistent and measurable end to end.
What is the difference between RevOps and sales ops?
- Sales operations supports the sales team specifically — quotas, territories, CRM administration for reps. RevOps owns process and data across the entire revenue motion including marketing and customer success. The cross-functional mandate is what distinguishes it.
Who should RevOps report to?
- The revenue leader — CRO, or the CEO in companies without one — with a mandate across all customer-facing functions. Reporting into finance turns it into a backward-looking reporting function; reporting into sales causes marketing and customer success data quality to degrade.
When should we hire our first RevOps person?
- When nobody can answer a pipeline question without opening a spreadsheet, or when two teams report different numbers for the same metric. In practice that is usually somewhere between fifteen and thirty people in the revenue organisation.
Does RevOps replace GTM engineering?
- No. RevOps designs the process and defines what the systems should do. GTM engineering builds and maintains those systems. One person can do both briefly, but the build backlog grows faster than the design work, and design is what stops first.
A RevOps roadmap only counts once it ships
We provide the engineering half: data model rebuilds, enforcement automation, warehouse and reporting infrastructure — so your RevOps design becomes systems rather than a backlog.