Search for revenue operations and you will find a lot of writing aimed at companies that already have a revenue operations department. Maturity models. Alignment frameworks. Diagrams with six overlapping circles. None of it helps if you are twenty people and the reason you are reading is that your pipeline number stopped being believable.
So here is the version for that company.
What RevOps actually owns
Revenue operations owns the systems and definitions that revenue moves through. Not the selling. Not the marketing. The machinery underneath both, and specifically four things:
- Routing. What happens to a lead between arriving and being worked.
- Definitions. What a stage means, what qualified means, what counts as committed.
- Handoffs. How a deal moves between marketing, sales and onboarding without dropping context.
- Reporting. Where the numbers come from, and why the CRM and the board deck agree.
That is the whole remit. Everything else people attach to RevOps (enablement, territory design, compensation modelling, tooling strategy) sits downstream of those four. While they are broken, nothing downstream works properly.
Why it shows up earlier than founders expect
The common assumption is that RevOps is a scale problem, something to deal with after the Series B. In practice the need appears as soon as more than one person is selling, because that is when definitions begin to diverge.
Two reps, left alone, will develop two processes within a quarter. Both will be reasonable. Both will be internally consistent. Neither will match the other, and neither will match what the CRM was set up to expect eighteen months ago. Nobody makes a decision to let this happen — it is just what happens when a process is carried in people's heads instead of written down.
The symptoms are recognisable long before anyone uses the phrase "revenue operations":
- Two reps have worked the same account without knowing it.
- An inbound lead from last Tuesday is still sitting unassigned.
- The forecast is a spreadsheet the founder rebuilds on a Sunday.
- Nobody can say how many deals actually stalled last quarter, only that it felt like a lot.
- Onboarding asks the customer for information sales already collected.
None of these are individually alarming. Collectively they are a tax on every deal you run, and the tax compounds as the team grows.
Nobody decides to let the process drift. It drifts because it lives in people's heads instead of in a system.
The four things it fixes, in order
Order matters here more than people expect. Doing these out of sequence is the most common way a RevOps project produces a lot of activity and no improvement.
1. Definitions, before anything else
You cannot automate a process nobody has agreed on. The first job is deciding what your stages mean, and writing exit criteria that are observable facts rather than feelings: "buyer confirmed budget and named a decision date" instead of "had a good call."
This is unglamorous, and it is the most valuable week of the whole project. A pipeline with six honest stages forecasts better than one with ten interpretive ones. We wrote the full method in how to define sales pipeline stages with exit criteria.
2. Routing, because it is pure loss
Every hour an inbound lead sits unassigned is conversion you have already paid for and are now discarding. The canonical study on this audited 2,241 US companies and found that firms contacting a lead within an hour were nearly seven times more likely to qualify it. In the same audit, 23% of companies never responded at all, and the average response among those who did was 42 hours.
Routing is also the easiest item on this list to fix, because it is a configuration job rather than a behavioural one.
3. Handoffs, because that is where context dies
Marketing to sales, sales to onboarding. If the handoff is a Slack message, it works right up until the week someone is on holiday. Making it structural (required fields, an owner, a state the record has to be in) takes an afternoon and removes an entire category of recurring failure.
4. Reporting, last
Reporting is last because it is downstream of the other three. Build dashboards on top of undefined stages and unrouted leads and you get a very attractive picture of nothing. Fix the inputs and the reporting becomes almost boring to build.
A worked example at eighteen people
Abstract descriptions of RevOps are easy to nod along to and hard to act on, so here is a composite of the situation we see most often. Series A, $3.4M ARR, eighteen people, six of them in go-to-market: two AEs, one SDR, one marketer, a customer success manager, and a founder who still runs the important calls.
The symptoms they described at the first conversation:
- Pipeline "looked healthy" at about $1.1M against a $320k quarterly target
- They had missed the previous two quarters by 18% and 11%
- The board report took most of a Sunday to assemble
- Inbound was up, and the SDR said it did not feel that way
Four things came out of two hours of looking at the actual records.
| What we found | Measured | What it was costing |
|---|---|---|
| Inbound sat unassigned overnight and at weekends | Median 4h to first touch, 90th percentile 31h | Roughly a third of inbound was being worked after the buyer had moved on |
| Two AEs staged deals differently | Disagreed on 3 of 5 sample deals | The $1.1M number was not comparable across people |
| Deals were pushed rather than closed out | $390k had close dates moved 3+ times | 35% of the pipeline was not real |
| Onboarding re-asked for information sales had | Every deal, about 40 minutes | A worse first week for every new customer |
The honest pipeline after removing the stale deals was about $710k, not $1.1M. Against a $320k target and their true win rate of 29%, they needed roughly 3.4x coverage, which is $1.09M. So the real finding was not that the forecast was wrong. It was that they were roughly $380k short of the pipeline they needed, and the padding had hidden it for two quarters.
That is the actual value of this work. The missed quarters were not a closing problem, and no amount of sales coaching would have fixed them.
What got done, in what order
Weeks one and two went entirely on definitions: six stages, exit criteria written with both AEs in the room, and a shared rule for when a deal gets closed out rather than pushed. Nothing was automated during this period, which felt slow and was the reason the rest worked.
Week three was routing. Inbound assigned on arrival by round robin, enriched before the rep saw it, with an acknowledgement going out immediately and the owner's task due within the hour. Median time to first touch went from four hours to eleven minutes, and the 90th percentile from 31 hours to under two.
Week four was the handoff and the reporting. Required fields on the sales-to-onboarding transition removed the 40-minute re-interview. The weekly number stopped requiring an export.
The quarter that followed came in 4% under the committed number rather than 18%, and the commit had been set against criteria rather than optimism. The pipeline figure was lower all quarter and nobody minded, because it was the first one anybody trusted.
"We're too early for this"
This is the most common objection and it is right more often than RevOps people admit. If you are pre-product-market-fit, or you have one person selling and no repeatable motion, building systems around a process you are still inventing will slow you down and lock in guesses.
The question that settles it is not headcount or funding stage. It is whether two people now have to make the same decision the same way. One seller can hold the whole process in their head, and that is efficient. The moment there are two, the process has to exist outside anyone's head, or it starts to diverge the same week.
A reasonable test, in order:
- Is more than one person selling? If no, keep selling and write notes. You are not ready and you do not need to be.
- Can you describe your qualification standard in one sentence? If no, that is the work, and it takes an afternoon rather than a project.
- Would two reps stage the same deal identically? If no, you have already lost the ability to read your own pipeline.
- Does the weekly number require an export? If yes, someone is already doing RevOps manually every week.
Answer no to the first and this whole article can wait six months. Answer yes to the first and no to any of the rest, and the cost of waiting is being paid already, just not by anyone whose job it officially is.
Who does it before you can hire
Most SaaS companies feel the need for RevOps at least a year before they can justify the headcount. A capable RevOps lead is a $160k+ hire, and at Series A that salary competes directly with another engineer or another AE.
So the work gets split. In practice, one of four things happens:
| Who owns it | Works when | Fails when |
|---|---|---|
| The founder | Under ~10 people and pre-repeatability | It becomes the thing that only gets done at weekends |
| A sales leader | They have genuine systems instinct | Selling quarter pressure always wins over systems work |
| An ops-minded rep | Short term, for a specific fix | You have quietly taken your best rep off quota |
| A fractional partner | You want the function now and the hire later | They build something nobody on your team can run |
That last failure mode is worth naming plainly, because it is the risk of hiring anyone external for this work. If the engagement ends and your team cannot operate what was built, you have rented a dependency rather than bought a capability. Any partner worth using documents themselves out of the job from week one, which is why our ninety days end with a written playbook your team keeps.
How to tell if it is working
Three numbers, reviewed weekly. They are chosen because they move before revenue does, which means they tell you something while you can still act on it.
- Speed to first touch. Minutes from a lead arriving to a human or a sequence reaching them. Target: under an hour, every time, including weekends.
- Stage hygiene. The share of open deals that genuinely meet their current stage's exit criteria. This is the single best early predictor of whether a forecast will hold.
- Forecast variance. How far your start-of-quarter call lands from actual. Gartner found fewer than half of sales leaders have high confidence in their own forecast. The goal is being in the minority that does.
Tool counts, dashboards built and automations shipped are deliberately absent. They measure effort rather than result.
Where to start this week
Open your CRM and read your stage definitions out loud to two reps separately. If they describe the same stage differently, and they almost certainly will, you have found your first RevOps project. It costs an afternoon to fix.
Sources: Harvard Business Review, The Short Life of Online Sales Leads (audit of 2,241 US companies) · Gartner, State of Sales Operations Survey.
Frequently asked questions
What does revenue operations do in a startup?
Is RevOps the same as sales ops?
When should a SaaS startup start doing RevOps?
Can you do RevOps without a dedicated hire?
Zachary works with founder-led B2B SaaS companies between seed and Series B, as a fractional VP of Sales and Marketing and through the team that builds their revenue operation on Throughline.
Get a free GTM teardown