Beta

Revenue Plan Feasibility Auditor

Tests a revenue plan against the history meant to support it. For each source, new business, expansion, and retention, it computes the deals, opportunities, and pipeline the target requires, then flags any assumed win rate, deal size, sales cycle, or per-seller workload that is more aggressive than the company has actually produced. Re-prices the target at historical rates, checks the date pipeline must be created by, flags sources and dependencies with no named owner, and holds back on any source with too little history to judge.

Any CRM

The problem

Most revenue targets are built top down and then handed to sales as a quota. Win rate, deal size, cycle length, and seller workload are assumed, usually a little better than last year on every line at once, and nobody checks them against what the company has actually produced.

How it works

01Reads a won-and-lost deal history and a plan with one row per revenue source: new business, expansion, and retention
02Computes what each target requires: closed-won deals, opportunities worked, pipeline created, and opportunities per seller
03Compares the assumed win rate, deal size, sales cycle, and per-seller workload to the same four numbers from the trailing history, and flags any that are more aggressive than a tolerance
04Re-prices the target at historical rates, shows the date pipeline must be created by to close inside the plan period, and flags any source or dependency with no named owner

Tested against known answers

Revenue Plan Feasibility Auditor

A synthetic closed-deal history of 151 won and lost deals across three deal types, five of them older than the trailing year and so to be ignored, plus two open deals and three malformed rows, tested against a four-source plan with known answers: one source whose assumptions were all beyond history, one source that matched history exactly as a control, one with too little history to judge, and one source the tool does not model.

4 of 4 assumptions

Over-assumed source correctly flagged

1/1

Control source correctly left unflagged

1/1

Thin-history source correctly held back

3/3

Malformed history rows excluded

→Correctly computed new business history from 100 closed deals: a 22% win rate, a 50,000 average won deal, a 74-day median cycle, and 20 closed deals per seller, then flagged all four plan assumptions beyond history (a 30% win rate, 36.4% higher; 60,000 deals, 20% higher; a 55-day cycle, 25.7% faster; 41.7 opportunities per seller, 108.5% more).
→Correctly re-priced the 6,000,000 new business target at historical rates: the 333 opportunities the plan counted on delivered 3,666,667, a 2,333,333 gap, 38.9% of the target, while five older wins outside the trailing year were ignored instead of inflating the average.
→Correctly returned supported with a zero gap for an expansion source whose plan matched history exactly, and correctly held a retention source with only six closed deals at insufficient history, with no attainable figure, instead of guessing at a rate.
→Correctly flagged a retention source with no named owner and a dependency with no named owner, reported them without changing any numeric verdict, and correctly moved a 50% tolerance to one flagged assumption (stretch) and a 120% tolerance to none (supported).

The new business target needed a 30% win rate, 60,000 deals, a 55-day cycle, and 42 opportunities per seller. History showed 22%, 50,000, 74 days, and 20. At the rates the team had actually produced, the same pipeline delivered about 3.67 million of the 6 million.

See the full test run →

Questions about Revenue Plan Feasibility Auditor

Does an unsupported verdict mean the target is impossible?

No. It means the plan depends on several improvements at once and nothing in the history supports them. The follow-up is which specific changes would make those improvements real, and who owns each, not simply lowering the number.

What happens when there is not enough history for a source?

It is reported as insufficient history with no verdict and no attainable figure, instead of guessing from a handful of deals. The report says what data would unlock a judgment.

How is this different from a pipeline forecast?

A forecast projects from open pipeline. This tests the assumptions the target itself is built on, against closed history, before the year starts.

Runs against your CRM using your own credentials, through your own AI instance. We don't copy, store, or retain your data.

Deploy this in your CRM