Most RevOps functions climb the same five stages in the same order, and most stall at the same one. Knowing which stage you are in tells you what to build next — and, more usefully, what not to.
RevOps functions tend to grow through the same five stages, in the same order, for the same reasons. The order is not fashion — each stage produces the thing the next one needs. What varies is how long a company spends in each, and whether it recognises the one where progress usually stops.
Stage 1 — Reconciliation
The function exists to make numbers agree. Sales has a number, finance has a different one, marketing has a third, and someone spends the first week of every month explaining the gap. Tooling is spreadsheets and exports.
This stage is not a failure. It is where you discover what your definitions actually are, and the artefacts it produces — an agreed definition of a qualified opportunity, of bookings, of churn — are load-bearing for everything after. The failure mode is staying here by turning reconciliation into a monthly ritual rather than a problem to eliminate.
Stage 2 — Instrumentation
The function starts fixing the source rather than the output: required fields, validation rules, stage-entry criteria, deduplication, a defined lead lifecycle. It is unpopular work, because it makes other people's jobs marginally harder in exchange for benefits they will not see for two quarters.
The trap is over-instrumenting. Every required field is a tax on the people entering it, and a field that is filled in carelessly is worse than one that is absent, because it looks like data. Instrument what you will actually use in a decision, and nothing else.
A required field nobody uses in a decision is a tax you collect and then throw away.
The rule most CRM admin backlogs need
Stage 3 — Reporting
Dashboards arrive. Pipeline coverage, conversion by stage, velocity, cohort retention, attribution of some flavour. Leadership is happy, because for the first time the business is legible.
This is where most RevOps functions stop, and it is the most dangerous stage precisely because it feels like arrival. The dashboards are genuinely good. The problem is that a dashboard transfers the entire burden of noticing onto a human, and humans are looking at the dashboard on Monday morning, not at the moment a deal goes quiet on a Thursday afternoon.
The symptom of a stalled stage three is a long list of well-maintained reports and no clear account of what changed because of them.
Stage 4 — Detection
The system stops waiting to be looked at. Instead of a chart showing stalled deals, something notices that a specific deal has been silent longer than its segment's median, checks whether that pattern historically preceded a loss, and tells the owner — with the evidence attached.
The technical work here is real but tractable. The hard part is organisational: detection produces a stream of things that someone must now be responsible for, and if nobody owns the response, detection degrades into a second inbox that everyone mutes. The teams that make this jump successfully define ownership before they turn detection on, not after.
Stage 5 — Execution
The system does not only detect. It prepares the response — a drafted follow-up, a re-scored and re-routed lead, a corrected stage, a renewal brief assembled from support and usage history — and either executes it under policy or holds it for one-click approval.
This is where the operating-system framing starts to be literal rather than marketing. The system holds state about your revenue engine, notices when reality diverges from what should be happening, and acts within limits you set.
The stages cannot be skipped
The temptation, having read the list, is to buy stage five. It does not work, and the reason is mechanical: detection and execution both consume the definitions and the data quality produced by stages one and two. Automation built on unreliable data does not fail loudly — it automates the unreliability, at speed, with a confident tone.
You can compress the stages. Instrumentation that used to take four quarters can take one when the system tells you which fields actually predict outcomes and which are decoration. But the order holds.
A better maturity metric than tool count
Most maturity models measure inputs — headcount, tools, processes documented. A more useful measure is decision latency: the median time between a fact becoming true in your business and someone acting on it.
- Stage 1–2: weeks. The fact is discovered during a reconciliation or a review.
- Stage 3: days. Someone sees it on a dashboard during their next check.
- Stage 4: hours. The system surfaces it to an owner when it happens.
- Stage 5: minutes. The response is prepared as the signal fires, and needs only approval.
Measured this way, maturity stops being about how sophisticated your stack is and becomes about how quickly your organisation can respond to something it already knows. That is the number worth moving.