What is a pipeline waterfall — and how do you actually use it in 2027?

The two ways to build a pipeline waterfall

There are really two paths to a working waterfall, and most RevOps teams pick the wrong one first and pay for it in wasted engineering hours or a report nobody trusts.

The first path is the native-tool path: use whatever movement report your CRM ships with. Salesforce Pipeline Inspection is the obvious example — it's bundled into Sales Cloud Enterprise and above at no incremental cost, it tracks changes since a configurable snapshot date, and it can be filtered by owner, stage, and close-date range. Configured correctly, it produces all seven buckets without anyone writing a line of SQL. HubSpot's deal-stage reporting and Pipedrive's movement views offer thinner versions of the same idea — they show stage transitions but require more manual stitching to get a clean starting-balance-to-ending-balance reconciliation. The appeal of the native path is speed: a RevOps analyst can have a usable waterfall live in an afternoon, and because it sits inside the CRM, reps and managers see it in the same tool they already work in every day, which matters enormously for adoption. A rep who has to open a second dashboard to see their own pipeline hygiene simply won't, and a waterfall nobody opens might as well not exist.

The second path is the platform-or-BI path: either buy a dedicated forecasting tool (Clari, InsightSquared) or build the waterfall yourself on raw opportunity-history data in Sigma, Looker, or a similar BI layer. Clari Flow runs $60,000–$100,000 a year for a mid-market deployment and buys you cross-functional scenario modeling, AI deal scoring layered on top of the waterfall math, and workflow automation — auto-flagging a deal that's been pushed twice, for example, before a human even notices the pattern. It is genuinely a better product than a native CRM report at scale, and companies above roughly $100M ARR tend to find the price justified by the forecasting-accuracy gains alone, especially once finance starts asking pipeline questions that touch revenue recognition and not just sales activity. The BI-build option is the cheapest power-user move: you pull opportunity and stage-history objects directly out of Salesforce, model the seven buckets in SQL, and own every assumption in the calculation. This costs the price of a BI seat rather than a platform license, but it requires a RevOps or data function mature enough to maintain the pipeline — schema drift in stage names, a rep who mass-updates 40 deals in one afternoon, or a merged/deleted opportunity can all silently corrupt the math if nobody is watching. Teams that go this route often discover the hard way that Salesforce's field-history tracking has to be turned on for every field the waterfall depends on *before* the first bad quarter, not after — history tables don't retroactively fill in.

The decision isn't really about budget first — it's about how much you actually trust your CRM data and how many people need to consume the report. A single RevOps leader reviewing pipeline for themselves can live inside Pipeline Inspection forever. A 200-person sales org with three go-to-market segments, multiple currencies, and a board that wants a rollup slide every quarter usually outgrows the native tool within a year or two, not because the math changes, but because the audience and the filtering demands do. It's also worth noting that some teams run both simultaneously during a transition — native reports for reps' weekly self-review, a BI-built or platform waterfall for the exec and board layer — and that hybrid is often underrated precisely because it matches the report's granularity to its audience's actual decision-making need.

How to decide between them

The decision comes down to three questions asked in sequence: how clean is your stage-history data, how many stakeholders need to see the waterfall in a format they can self-serve, and what's your tolerance for maintaining a homegrown pipeline. If stage-history data is messy — reps skipping stages, no required fields on stage change, close dates that get bulk-edited without an audit trail — fix the data model before buying anything. No tool, cheap or expensive, produces a trustworthy waterfall on top of dirty stage timestamps; you'll just get a beautifully formatted wrong number. If the data is reasonably clean and the audience is under 20 people who all live in Salesforce daily, start with Pipeline Inspection; it's free and it proves out whether the discipline of reviewing pushes and regressions weekly actually sticks before you spend real money on a platform that solves a discipline problem with more dashboards. If the audience is board-level and cross-functional — finance wants ARR-adjacent views, customer success wants renewal-pipeline overlap, the CEO wants one number that reconciles across segments — that's the signal to move to Clari or a BI build, because native reports rarely handle the multi-object joins those audiences need.

This sequencing matters because skipping straight to a platform purchase is the single most common waterfall mistake RevOps teams make. Buying Clari does not fix a broken stage-progression policy; it just gives you a more expensive dashboard showing the same broken numbers with better formatting. The tool should always be the last decision, not the first — and the same logic applies one level down, to who gets access. Handing every AE a live waterfall view before they understand what "regression" even means in the CRM tends to produce defensive behavior (reps arguing about definitions in the forecast call) rather than the intended effect, which is reps self-correcting before the Tuesday one-on-one even happens.

Concrete numbers behind each option

The benchmarks that make a waterfall diagnostic rather than decorative are bucket-specific, and they hold roughly steady across native and platform implementations because they're properties of the sales process, not the software.

Created pipeline should run 1.5–2.5x quota for the period, with 60–70% of that creation landing in the first four to six weeks — a late-quarter spike in created pipeline is a red flag for reps dumping low-quality opportunities into the funnel to pad their numbers going into the forecast call. Stage-progressed should represent 30–50% of starting pipeline; below 20% suggests deals are stalling rather than advancing, which is often a qualification or champion-engagement problem rather than a market problem. Stage-regressed is the tightest band: under 10% of starting pipeline is healthy, and anything over that usually means reps are advancing deals prematurely to look good on a stage-3+ pipeline metric, then walking them back once the deal's real status becomes undeniable. Closed-won should track to historical win rate against created and progressed volume — if closed-won consistently exceeds created, the business is depleting pipeline faster than it's replacing it, a treadmill dynamic that looks stable on a coverage report and is anything but.

Pushed is the bucket worth watching most closely because it's the one every team under-measures. Industry benchmarks for high-performing teams put push rate at 5–8% of ending pipeline; above 12% requires intervention, and above 30% of period-opening pipeline means the forecast leadership is reading is functionally fiction — AEs either can't predict close dates or are sandbagging them, and either way the number in the board deck is wrong. In the worked case that motivated a lot of this framework — a $25M ARR Series B company that looked healthy at 3.2x coverage — 38% of open pipeline had been pushed at least once in a single quarter, stage-regression ran 14%, and quota attainment was stuck at 71% despite the pipeline dashboard looking fine every week. After instituting a rule that no opportunity could be pushed without manager sign-off and reviewing every regression in the weekly forecast call, pushes dropped to 18% and regressions to 7% the following quarter, and attainment moved to 86%. None of that diagnosis was visible from a snapshot; it only showed up once the waterfall math was actually run.

It's worth being honest about how these ranges shift by segment. Enterprise motions with 6-9 month cycles tend to run higher push rates by nature — a deal genuinely can slip a legal review by three weeks without anything being wrong — so the 12% intervention line often gets relaxed to somewhere near 15-18% for that segment specifically, while SMB and transactional motions with 30-45 day cycles should be held to the tighter band because there's simply less legitimate reason for a short-cycle deal to keep sliding. Blending segments into one waterfall number, the same mistake as blending marketing-sourced and sales-sourced pipeline, hides which population is actually driving the unhealthy push rate.

Implementation details and sequencing

Getting a waterfall from "built" to "actually used" is a sequencing problem more than a technical one. Start by locking the period boundary — most teams use fiscal week or fiscal month as the waterfall's atomic unit, since anything longer (quarterly-only) hides the exact week a deal slipped, and anything shorter (daily) creates noise nobody can act on. Next, define stage-progression and stage-regression unambiguously in the CRM: a regression should only fire on an actual backward stage move, not a field update, and progression should require the exit criteria for the prior stage to be met, not just a picklist click. Skipping this step is why so many waterfalls get built twice — the first version, built on unenforced stage definitions, gets thrown out within a month because nobody trusts the regression numbers.

Once the buckets are defined, wire the report to run automatically on a fixed weekly cadence rather than being pulled ad hoc — a waterfall that only gets generated when someone remembers to ask for it never becomes a habit, and habit is the entire value of the report. A typical RevOps cadence looks like: the waterfall auto-generates Monday morning, AEs justify every pushed deal in their Tuesday one-on-one, managers triage regressed deals stage-by-stage on Wednesday, the numbers feed the Thursday forecast call for commit and best-case calls, and any hygiene actions get logged by Friday so the following Monday's waterfall shows whether the intervention actually worked.

The last implementation detail that separates a waterfall that sticks from one that gets abandoned after a quarter is ownership. RevOps should own the generation and the bucket definitions, but the accountability for what happens in each bucket has to sit with sales management — a manager who has to explain a 20% regression rate in the Wednesday triage changes rep behavior far faster than a RevOps analyst flagging the same number in a Slack message. Treat the waterfall as a management ritual with a report attached to it, not a report that management is expected to independently interpret.

There's a downstream effect worth planning for too: once a waterfall has run for two or three consecutive quarters, it becomes the natural input for a rep-level scorecard — not to punish individuals, but because a rep whose deals push at 3x the team average is either working a genuinely harder territory or needs coaching on qualification, and the waterfall is the only report that separates those two explanations from a flat win-rate number. Finance teams that adopt the ARR-adjacent version of this report also tend to ask RevOps to reconcile it against the billing system's actual bookings monthly — a good checkpoint, since a waterfall that never gets reconciled against ground truth can drift from reality for months without anyone noticing, the same failure mode as the CRM data problem the whole exercise was meant to catch in the first place.

Related questions

How is a pipeline waterfall different from pipeline coverage?

Coverage is a point-in-time ratio (open pipeline divided by quota) and can look identical for a healthy business and a treadmill business. The waterfall shows the movement between periods — created, progressed, regressed, won, lost, pushed — that explains why coverage is what it is.

What causes a high push rate?

Usually one of two things: AEs setting unrealistic close dates to hit a forecasting requirement, or genuine deal unpredictability in a long, multi-stakeholder sales cycle. A push rate consistently above 12% of ending pipeline points to a forecasting-discipline problem rather than a market problem.

Should marketing-sourced and sales-sourced pipeline be waterfalled separately?

Yes, once volume supports it — blending the two masks whether a created-pipeline shortfall is a demand-generation problem or a sales-prospecting problem, and those require entirely different fixes.

Can a small startup pipeline benefit from a waterfall?

Yes; even a handful of deals per month benefits from seeing whether new opportunities are simply replacing won and lost deals or whether pipeline is genuinely compounding, and whether "progress" is real advancement or premature stage-jumping.

Does segment (enterprise vs. SMB) change what a healthy waterfall looks like?

Yes — longer enterprise cycles tolerate a higher push rate for legitimate reasons like procurement delays, while SMB and transactional deals should hold to tighter bands since there's less structural reason for repeated slippage.

FAQ

What's the actual formula for a pipeline waterfall? Starting balance + created + stage-progressed − stage-regressed − closed-won − closed-lost − pushed = ending balance. Every bucket should reconcile exactly; if it doesn't, there's untracked movement (a deleted or reassigned opportunity, usually) that needs to be found before the report can be trusted.

How often should RevOps actually run the waterfall? Weekly for most B2B SaaS sales cycles. Monthly is workable for very long enterprise cycles, but weekly is what catches a pushed deal before it becomes a pattern instead of an incident.

Does a pipeline waterfall replace a forecast? No — it's diagnostic, not predictive. It explains why last period's forecast was right or wrong by showing exactly where pipeline moved; the forecast itself still requires a rep and manager judgment call layered on top.

What's the single most common mistake teams make building one? Buying a platform before fixing stage-progression definitions. No tool — free or six figures — produces a trustworthy waterfall on top of unenforced or inconsistent stage-exit criteria.

Is percentage or absolute dollar value the right way to present a waterfall to executives? Absolute dollars first, percentage as a secondary annotation. A 50% jump in created pipeline sounds significant until you see it moved from $200K to $300K against a $2M quota — percentages alone hide magnitude.

Who should own the waterfall inside the org? RevOps owns the report's generation and bucket definitions; sales management owns accountability for what the pushed and regressed numbers actually mean in the weekly forecast call.

Sources

• Salesforce, "Pipeline Inspection in Sales Cloud," official documentation, 2025.
• Clari, "Pipeline Reports and the Waterfall Methodology," product documentation, 2024.
• SaaStr, "The Pipeline Waterfall: The Most Important Report You're Not Running," Jason Lemkin, 2023.
• Pavilion, "2024 Forecasting and Pipeline Health Survey," GTM benchmarks report.
• Gong Labs, "What Top-Performing Sales Teams Do Differently in Pipeline Management," 2024 study.
• Bessemer Venture Partners, "State of the Cloud 2025," sales efficiency benchmarks.
• Force Management, "Command of the Message and Pipeline Hygiene Frameworks," 2024.
• RevOps Co-op, "Building a Pipeline Waterfall in Sigma — A Practical Guide," community playbook, 2024.

Related on PULSE

• How do you operationalize colo and hyperscaler partner-sourced pipeline handoffs between sales, finance, and delivery when no data engineer and leadership only reviews ARR waterfall monthly?
• How do you score ARR waterfall for event-sourced pipeline on Pipedrive without another point solution?
• Top 10 revenue waterfall metrics for hyper-long sales cycles
• How do you build a lead-to-revenue waterfall in 2027?
• How do you compare board-ready ARR waterfall exports from CRM vs billing system?