Most companies still talk about revenue as if it behaves like a funnel.
Top of funnel. Mid funnel. Bottom of funnel.
The mental model suggests linear movement. Add more at the top and more will come out at the bottom. Improve one stage and overall performance improves.
In practice, revenue behaves nothing like that.
It behaves like an operating system.
What Happens When You Change One Part of the Revenue System?
Every change introduced into the system affects something else. Tighten qualification and pipeline volume falls. Add pricing controls and sales cycles extend. Increase pressure on new business and renewals begin to suffer. Adjust compensation and deal structure changes almost immediately.
None of these shifts are random.
They are responses.
When revenue performance changes, it is rarely because one stage stopped working. It is usually because the system adjusted to pressure elsewhere.
This is where the funnel metaphor becomes misleading.
Funnels isolate stages. Operating systems connect them.
An operating system is shaped by decisions about incentives, ownership, authority and trade-offs. Those decisions determine how people behave long before metrics move.
Because behaviour moves first, the reaction to a change often appears in a different metric from the one being managed. When I review a change, I pair the metric it is meant to improve with the metrics most likely to react. For the four examples at the start of this section:
- Tighter qualification: pipeline volume alongside win rate and sales cycle length. Lower volume is acceptable if conversion improves enough to cover it.
- New pricing controls: discount depth alongside cycle length and the number of deals waiting for approval.
- More pressure on new business: bookings alongside renewal rate, expansion and the time account managers spend with existing customers.
- A compensation change: deal structure, including contract length, payment terms and product mix, in the first weeks after the plan goes live.
If only the intended metric is tracked, the reaction tends to be noticed a quarter later and attributed to the wrong team.
What the Funnel Model Leaves Out
The funnel picture also leaves out three parts of the system that matter:
- Everything after the signature. Renewal, expansion and referral sit outside the funnel, so the model has nothing to say about them.
- Handovers between teams. Context and accountability have to pass from one team to the next at several points, and the funnel has no step for that transfer. The sales-to-CS handoff is the clearest example.
- Feedback loops. A customer who was poorly set up affects next year’s renewal. An unrealistic target affects what reps are willing to report.
Stage metrics are still worth tracking. Conversion by stage shows where the system’s behaviour becomes visible. The cause usually sits elsewhere, in an incentive, a definition or an approval rule, and that is where the fix has to be made.
Forecast Volatility and Margin Erosion as System Outputs
Consider forecasting volatility. Many organisations treat it as a pipeline hygiene problem. In reality, volatility is often the output of incentive design, target realism and how leadership reacts to bad news. The system teaches people what is safe to report.
Or consider margin erosion. It is easy to attribute it to discount discipline. More often, it reflects competitive positioning, quota pressure and approval dynamics that reward short-term closure over long-term structure.
Revenue outcomes are behavioural outputs of structural choices.
Both problems can be diagnosed as system effects with data most companies already hold.
For forecast volatility, I look at when deals move between forecast categories and who moves them. If downgrades cluster in the last weeks of the quarter, people are holding bad news until it can no longer be avoided. I also ask what happened the last time a manager called their number down early. If the answer was a difficult conversation and closer inspection, the system has taught managers to wait.
For margin erosion, I break discounts down by week of the quarter, by the rep’s attainment when the deal closed and by approval route. If discounts deepen late in the quarter or for reps behind their number, the cause sits in quota design and the approval rules. If discounts are deep across the board regardless of timing, the price itself or the competitive position is the more likely cause.
Why Optimising One Stage Creates Pressure Elsewhere
When leaders optimise locally, conversion rate, average deal size, pipeline coverage, the system compensates globally. Gains in one area frequently introduce pressure somewhere else. This is how misalignment compounds.
That does not mean performance cannot improve.
It means improvement requires understanding second-order effects before they appear.
The practical tool is a short impact review before any significant change to targets, pricing, compensation, territories or stage definitions. It has four parts:
- State the metric the change is meant to move, and by roughly how much.
- Name the two or three metrics most likely to react, and the team that will feel each reaction.
- Set a review date early enough to adjust the change within the same quarter.
- Agree in advance what reaction would lead you to adjust or reverse the change.
The fourth part matters most. Without it, every side effect turns into a debate about whether the change caused it. Pairing each target with the metrics that react to it, and agreeing what will happen if they move, is the same principle behind the RevOps metrics that actually matter.
The Questions to Ask Before Changing the System
Strategic revenue leadership involves asking different questions.
What behaviour is this incentive encouraging? Where will pressure accumulate if we push here? What trade-off are we implicitly accepting? Who owns enforcement when tension appears?
These are operating system questions.
They are most useful when they are built into the way changes get approved. I add them to the template for any proposal that changes compensation, pricing, territories, qualification criteria or forecast rules. The person proposing the change answers them in writing, and the leaders whose teams will absorb the pressure review the answers before the decision is final.
This adds a step to each decision. It also moves the discussion of side effects to a point where the change can still be adjusted.
RevOps as the Architect of the Revenue System
RevOps, when positioned correctly, acts as the architect of that system. Not by adding dashboards, but by modelling consequences before they compound.
Acting as the architect comes down to owning four things:
- A map of the main dependencies in the revenue system, showing which incentives, definitions and approval rules affect which outcomes.
- The impact review for changes to targets, pricing, compensation and territories.
- The shared definitions every team reports against, so a change in one place is visible everywhere.
- Paired metrics in leadership reporting, so each headline number appears next to the one most likely to react to it.
A small RevOps team can do this if it is involved before decisions are made. Whether it is involved depends on its mandate and reporting line, which I cover in how to structure a RevOps team.
Treat revenue like a funnel and you will manage symptoms.
Treat it like an operating system and you can design outcomes intentionally.
The difference becomes visible over time.