The RevOps operating model for mid-market companies

An operating model is what survives when people leave. We've watched RevOps functions collapse three months after the senior leader walks out because nothing was written down at the layer it needed to live. The model isn't a wiki page. It is the explicit who-does-what across the four revenue layers, refreshed quarterly. This piece walks through those layers, the RACI by role, the cadence, and how the shape changes for sales-led, product-led, and hybrid companies.

What is a RevOps operating model?

A RevOps operating model is the documented set of decisions, processes, systems, and analytics that define how a company plans, generates, closes, and retains revenue. It answers four questions in writing: who owns what, how the work gets done, where the data lives, which numbers tell us it is working. Andy Grove made the same point in High Output Management: the output of an organization is the output of its managers. RevOps writes that relationship down across the revenue org.

For mid-market companies ($30M to $500M ARR), the model matters more than at any other stage. Below $30M, founders hold most of the context in their heads. Above $500M, dedicated function leaders own slices of it. In the middle, RevOps is the only function that touches all four layers at once. Without a written operating model, the company runs on tribal knowledge, which has a half-life of about eighteen months.

Pavilion's 2024 State of RevOps report found that 72% of RevOps leaders said their function was responsible for revenue planning, but only 41% had a documented operating model that survived a leader transition. That gap is the failure mode this piece is built to prevent.

The four layers of a RevOps operating model

The operating model breaks into four layers. Each layer has its own decisions, its own cadence, and its own owners. Skipping a layer is the single most common reason RevOps functions stall.

Layer 1: strategy and planning

The strategy layer is where the year gets built. RevOps owns three artifacts here: the annual revenue plan, the capacity model, and segmentation.

The annual revenue plan ties bookings targets to headcount, ramp time, win rates, average deal size, and pipeline coverage. Bessemer Venture Partners' State of the Cloud research has shown that companies whose plans assume more than 4x pipeline coverage at the start of a quarter outperform peers by a real margin, because they have room for the deals that slip. The capacity model is the same math run differently: how many quota-carriers, ramped at what speed, producing what each, get us to the number? When the two artifacts disagree, somebody is going to miss.

Segmentation is the third piece. SMB, mid-market, and enterprise segments have different sales cycles, different gross retention rates, and different cost-to-serve profiles. Salesforce's 2024 State of Sales report found that 81% of high-performing teams had distinct playbooks per segment, compared to 54% of underperformers.

Layer 2: process and workflow

Process is the layer where the operating model is actually felt by humans. It is also the layer that gets ignored most often, because people assume the CRM workflow is the process. It isn't. The CRM workflow is the process frozen in software at one point in time. The process itself lives in a document that explains who does what, when, and why.

Four process artifacts belong in every mid-market RevOps run book: lead routing rules with response SLAs, opportunity stage definitions (what has to be true to enter and exit each stage), handoff agreements between marketing, sales, and CS, and the deal desk charter.

Get the process layer right and most CRM problems sort themselves out. Get it wrong and no amount of automation rescues you. Common RevOps mistakes and how to avoid them covers the specific failure modes we see most often.

Layer 3: systems and data

Systems are the layer companies tend to over-invest in and under-govern. The CRM (usually Salesforce or HubSpot), the analytics warehouse (Snowflake, BigQuery, or Redshift in most mid-market stacks), marketing automation, the CS platform, contract and billing systems, and the integrations between them. The temptation is to keep adding tools. The discipline is to keep the data clean enough that the tools you already own actually work.

Governance is the unglamorous half of the systems layer: field-level ownership, naming conventions, deduplication rules, mandatory fields by stage, and the audit trail that lets you trust the number on the board slide. McKinsey's 2023 research on data quality in revenue functions found that B2B companies lose 12% of annual revenue to bad CRM data, mostly through misrouted leads, duplicate accounts, and inaccurate forecasts. That is a governance problem dressed up as a tooling problem.

For a fuller treatment of the stack itself, see the RevOps tech stack: what you actually need.

Layer 4: insights and analytics

The insights layer is where the operating model proves its worth. Four reports belong on every mid-market RevOps dashboard: the forecast (committed, best case, pipeline, with the variance from last week), attribution, retention (gross and net by cohort), and leakage (where deals die in the funnel, where contracts churn early).

Pavilion's 2024 data shows the median mid-market company forecasts within 10% of actual at the halfway point of the quarter, but the top quartile hits 5% by the end of week two. That gap is mostly a function of stage definitions and rep discipline, not the forecasting tool. If your stages are subjective, your forecast will be too.

Multi-touch attribution models look sophisticated but most break down when sales cycles run longer than 90 days, which they almost always do in mid-market B2B. Harvard Business Review's 2022 piece on attribution argued that single-source attribution, while less elegant, produces more actionable insights for sales-led teams. See RevOps metrics that actually drive revenue for what to track.

Who owns what: the RevOps RACI by layer

The single most useful artifact in a RevOps operating model is the RACI matrix. R is responsible (does the work). A is accountable (owns the outcome, only one per row). C is consulted. I is informed. That last bit about "only one A per row" is where most RACI exercises quietly fail.

Two things to notice. RevOps is accountable on three of the four layers, but responsible on only the first. RevOps owns the integrity of the operating model; the field functions own the execution. Second, finance is consulted on planning and informed on process, but not heavily involved in either. That changes above $300M, where finance and RevOps usually share a planning seat. Below that, the line is cleaner if RevOps owns the math and pulls finance in to sanity-check it.

For the team structure that supports this, see how to structure a revenue operations team.

What cadence keeps the operating model alive?

A RevOps operating model dies on the shelf. What keeps it alive is a cadence at four time horizons. Each ritual has a layer it serves, an owner, and an output that updates the run book.

Daily rituals are short and operational. Pipeline hygiene checks, routing exception triage, and an end-of-day forecast snapshot in the warehouse so trend lines are reliable. A daily ritual that takes more than thirty minutes per person isn't a ritual; it's a job.

Weekly rituals are diagnostic. The Monday forecast call (the CRO and sales managers walk the deals, RevOps walks the math), the funnel review, and the systems standup. Pavilion's 2024 benchmark data shows companies with a documented weekly forecast call hit their quarterly number 18 percentage points more often than companies that forecast on an ad-hoc basis.

Monthly rituals are tactical: a handoff audit, a leakage review, a goal-to-actual on the capacity model, and a deal desk retrospective.

Quarterly rituals are strategic. The QBR, a refresh of the segmentation cuts based on actual performance data, a pricing and packaging review, a tech stack audit, and a refresh of the operating model document itself. The quarter is the unit of time at which the operating model gets updated, not the year. Things change too fast in mid-market for an annual refresh to keep up. For a model of how the quarterly review should run, see quarterly operations reviews that drive results.

What is a RevOps run book?

A RevOps run book is the single document (or wiki space, or Notion folder, or whatever your team actually opens) that contains the operating model, the RACI, the cadence, the SLAs, and the playbooks for the most common situations. It is what a new RevOps hire reads in their first week and what a departing RevOps leader hands to their successor.

The run book has four sections that mirror the four layers, plus a fifth for the cadence and a sixth for incident playbooks (what we do when forecasting goes sideways, when a CRM integration breaks, when a major customer escalates). The best run books we've seen are forty to seventy pages of plain prose, not 200 pages of decorated process maps. Writing it is the act of building it.

A useful test: if you fired the senior RevOps leader on a Friday, could the team execute the next quarter's close from the run book alone? If not, the run book has gaps. Find them now, before the test becomes involuntary.

How do you document the operating model without bloating it?

You document the operating model by writing prose, not by drawing diagrams. Diagrams age fast and hide the assumptions. Prose forces clarity. A new hire who reads "leads from inbound demo requests are auto-assigned to the SMB SDR pod within two minutes, with a fallback to the round-robin if no SDR is online" understands the rule. A flowchart with the same information requires interpretation.

Three rules keep the run book lean. First, document the what and the why, not the how-to. The how-to lives in tool-specific documentation. The run book explains the policy. Second, version the document and put a "last reviewed" date on every section. If a section hasn't been reviewed in two quarters, it is probably stale. Third, link out instead of embedding. The run book points to the live capacity model in Sheets, the live forecast dashboard in Tableau, the live RACI in Notion. The run book is the table of contents for a system, not the system itself.

OpenView's 2024 SaaS Benchmarks data on RevOps maturity suggests companies with a maintained run book onboard new RevOps hires roughly 22% faster and report fewer forecasting "surprises" of more than 10% variance. The maintenance is the whole game.

How does the operating model change for sales-led, PLG, and hybrid?

The four layers are the same. The weight inside each layer shifts based on the motion. Sales-led companies invest most heavily in process, because the rep is the sale. Product-led companies invest most heavily in systems and insights, because the product is the sale and the data is the only signal anyone has to work with. Hybrid companies have to do both.

In a sales-led model, the process layer is where most of the weekly work happens. Lead routing, stage discipline, and deal desk decisions move the number. ProductLed and Pavilion benchmarks suggest sales-led RevOps teams typically allocate around 40% of headcount to process owners.

In a product-led model, the work shifts to systems and insights. The product produces the signal, the warehouse stores it, and the analytics turn it into a buying intent score. ProductLed's 2024 PLG benchmarks suggest companies above $20M ARR running a PLG motion typically have 50% or more of RevOps headcount on the data side. The deal desk still exists for enterprise-tier deals, but it is a smaller slice of the function.

Hybrid is the hardest. Most mid-market SaaS companies are hybrid in practice. The trap is to copy a pure sales-led playbook and bolt PLG signals on the side, or to copy a PLG playbook and pretend the enterprise deals will close themselves. Gainsight's 2024 Pulse research on hybrid go-to-market found that companies who execute hybrid well treat the two motions as separate operating models that share infrastructure, with explicit handoff rules between them.

For the broader picture of how RevOps fits inside operations strategy, see the operations scaling playbook and aligning operations strategy with business goals.

How do you build the operating model from scratch?

If you are starting cold, the order matters. Strategy first (you cannot route leads to a segmentation that doesn't exist). Process second (you cannot pick a CRM stage model without knowing what stages mean to your team). Systems third (the systems serve the process). Insights last (you cannot measure what you have not yet defined). Building your first revenue operations function covers the staffing and sequencing side of the same question.

The first ninety days for a new RevOps leader should produce four things: a written operating model draft, the RACI signed off by the CRO and the field function heads, a confirmed weekly cadence, and a baseline of the four insights reports running in production. After that, the work is iteration on what already exists.

Key takeaways

A RevOps operating model is the documented who-does-what across four layers (strategy, process, systems, insights) refreshed quarterly. It is the artifact that survives leader transitions, and it is the thing most mid-market RevOps functions don't actually have.

The RACI matrix puts one accountable owner on each layer. RevOps is accountable on three of the four. The cadence keeps the model alive. The run book is the table of contents, not the system itself.

Sales-led, product-led, and hybrid companies use the same four layers with different weights. Hybrid is the hardest because it is two operating models sharing infrastructure, and the handoff rule between motions has to be written down somewhere a new hire can find it.

If you can answer four questions in writing (who owns what, how the work gets done, where the data lives, which numbers tell us it's working), you have an operating model. If you can't, you have a function that runs on memory, and memory leaves with the people who have it. The complete guide to revenue operations is the hub for the rest of this cluster.