RevOps and pipeline management. Who owns the stages, the data and the number.

The short answer. Structure first, habit second.

I'm Lauren Pearson, and most of the "our forecast is never right" conversations I have with founders trace back to the same gap: nobody in the business actually owns the pipeline's structure. Sales management owns running the deals. Marketing owns filling the top of it. But the stage definitions, the fields that must be filled in before a deal can move, and the method used to turn open pipeline into a forecast number, those need one owner too, and that owner is RevOps.

This piece is about that ownership layer specifically. If you want the fuller picture of how RevOps fits together as a function, our RevOps framework piece covers the whole data model and forecast approach end to end. If you want the day-to-day definition of the work sales managers do inside the structure RevOps sets, what is sales pipeline management is the right piece. And if you want the weekly habit that keeps a pipeline accurate once the structure exists, see pipeline hygiene, done weekly. What follows is specifically about who decides the rules those other pieces assume are already in place.

How it works in practice. Three things RevOps owns, and one it doesn't.

Stage definitions. RevOps writes, in plain language, exactly what must be true for a deal to sit in each stage, agreed jointly with sales leadership rather than imposed from outside it. A decision rule I give every client on this: a stage only counts as exited when the written exit criteria is met, not when a rep feels confident about the deal. The moment "I'm pretty sure this closes next month" is allowed to override the written criteria, every stage in the pipeline starts meaning something slightly different depending on who is reporting it.

Data rules. RevOps decides which fields are mandatory before a deal can advance, next step, close date, deal value, and builds that requirement into the CRM itself rather than a policy document nobody reads. A rule that lives only in a slide deck gets followed for the first month and ignored by the third.

Forecast methodology. RevOps agrees, with sales leadership, which method turns raw pipeline into a forecast number: weighted pipeline by stage probability, manager commit, or a blend of both, and applies it consistently across every team and region rather than letting each sales manager use their own formula.

What RevOps does not own: the deals themselves. Running the actual sales conversations, deciding when to push on a stalled deal, coaching a rep through a difficult negotiation, that stays with sales management. RevOps builds the structure the pipeline runs on; it does not run the pipeline itself.

On the question of how big the pipeline should be relative to quota, there is no single correct multiple, whatever a vendor benchmark deck implies. A commonly used industry rule of thumb puts coverage at three to four times quota for shorter, simpler sales cycles, rising towards four to seven times for longer enterprise deals, but the more reliable method, and the one I ask RevOps teams to build towards, is to calculate the target as one divided by the team's own actual historical win rate, rather than borrowing a fixed number from another company's sales motion. A team converting one in five opportunities needs roughly five times coverage; a team converting one in three needs roughly three.

What good looks like. A short checklist.

• One written stage-definition document, agreed by RevOps and sales leadership together, not maintained separately by each.
• Mandatory stage-exit fields enforced in the CRM itself, so a deal physically cannot advance without them.
• A single forecast methodology applied the same way across every team and region.
• A monthly review comparing what was committed against what actually closed, with any gap investigated rather than simply logged.

A worked scenario, illustrative rather than a specific client result, shows why the data rules matter as much as the definitions themselves. A 30-person SaaS sales team I describe here had a tidy-looking stage-definition document that nobody disagreed with on paper. Its forecast was still wrong most quarters, because the CRM let reps move a deal forward without entering a close date or next step, so "confidence" quietly filled the gap the missing fields should have closed. Once RevOps made those two fields mandatory for stage advancement, the forecast did not become perfect, but the gap between committed and actual narrowed within two quarters, because the number was finally built from data the system had actually required rather than data a rep had been willing to type in.

Pitfalls to avoid. Where pipeline governance breaks down.

The first pitfall is letting stage definitions exist as a document rather than as rules the CRM enforces. Written policy nobody is forced to follow drifts within a quarter, usually in the direction of making it easier to look like the pipeline is healthier than it is.

The second is treating the coverage ratio as fixed regardless of win rate or deal size. A target borrowed from a benchmark report written for a different kind of sales motion will either make the team chase pipeline volume it doesn't need, or leave it under-pipelined without anyone noticing until the quarter is nearly over.

The third is RevOps and sales leadership deciding the forecast methodology separately, each building their own version. Two forecasts in one business is worse than one bad forecast, because leadership then has to referee which number to believe instead of acting on either.

The fourth is skipping the monthly accuracy review. Forecast calibration problems are easy to see in hindsight and easy to miss in the moment, which is exactly why a scheduled, recurring check matters more than an annual retrospective ever will.