Verified against ChatGPT · 2026-08-14
Build a revenue forecast from named drivers instead of a single trend line extrapolated forward
Constructs a forward revenue forecast by building up from the specific drivers that actually generate the revenue (leads, conversion, price, retention) rather than extrapolating a historical growth rate, so the forecast can be interrogated driver by driver instead of accepted or rejected as one black-box number.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build a revenue forecast for the period below using a driver-based buildup — projecting from the specific components that generate revenue — rather than simply extrapolating a historical growth rate forward. A trend-line extrapolation is easy to produce but impossible to interrogate; a driver-based buildup can be checked piece by piece.
REVENUE MODEL / HOW REVENUE IS ACTUALLY GENERATED
Monthly new leads x demo-to-close conversion rate x average annual contract value, plus existing customer renewals.
HISTORICAL DRIVER DATA
Averaging 140 leads/month over the last 2 quarters, 14% demo-to-close conversion, $8,400 average contract value, 88% renewal rate on existing accounts.
FORECAST PERIOD
Next 4 quarters.
DRIVER ASSUMPTIONS FOR THE FORECAST
Expecting leads to grow to 180/month by Q3 due to a new marketing channel launching; conversion rate assumed flat; a known batch of 12 large contracts renews in Q2.
BUILD STEPS
1. Break the revenue model into its actual components (e.g. new leads x conversion rate x average deal size, or active customers x retention rate x average revenue per customer) rather than working with a single blended revenue growth percentage.
2. For each component, state the historical value, the assumed forward value, and the specific reason for any change between them — a driver assumption that just repeats the historical value unchanged should say so plainly ("held flat, no change assumed"), and a driver assumption that changes from history must state why, not just what.
3. Multiply the components together for each period in the forecast horizon to produce total revenue, showing the calculation, not just the final total.
4. Identify which single driver the total forecast is most sensitive to — the one where a modest error in the assumption would move total revenue the most — and say so explicitly, since that's the assumption most worth double-checking or tracking closely once the forecast period begins.
Do not smooth the forecast into an artificially even trend line if the underlying drivers imply lumpiness (e.g. a seasonal conversion rate, a known cohort of contracts renewing in a specific month) — let the forecast reflect the actual shape the drivers imply, even if that shape is uneven.
OUTPUT FORMAT
1. Driver table: component | historical value | forecast assumption | reason for any change.
2. Period-by-period revenue calculation showing the multiplication, not just results.
3. Most sensitive driver, named explicitly, with a one-line reason.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The core mechanical advantage of a driver-based buildup over a trend-line extrapolation is that every component is independently checkable against something real — a lead-volume assumption can be checked against the marketing team's own pipeline plan, a conversion-rate assumption can be checked against the sales team's recent close rates — whereas a single blended "revenue will grow 15% next year" number gives the requester nothing to push back on except a gut feeling about whether 15% sounds right. Requiring an explicit reason for any driver assumption that changes from its historical value, and an explicit "held flat" note for any that don't, closes a specific gap where GPT-5.1 might otherwise quietly assume improvement across every driver simultaneously (more leads, better conversion, higher deal size all at once) without ever being asked to justify why all three would improve together — stacking optimistic assumptions across multiple drivers compounds multiplicatively and can produce a wildly inflated forecast that no single assumption looks unreasonable in isolation. The instruction to preserve lumpiness rather than smoothing the forecast into an even trend line matters because real revenue often isn't even — a known batch of contract renewals landing in one specific quarter, or a seasonal conversion pattern, produces a forecast with real peaks and troughs, and a model that defaults to a smooth month-over-month growth curve for presentation tidiness would actively hide information the requester needs, like a cash crunch in the quarter before the big renewal batch lands. Naming the single most sensitive driver at the end gives the forecast an actual use during the period it covers — instead of just filing the forecast away, the requester knows which one number to track most closely as actuals come in, since that's the one whose error would move the whole forecast the most.
What you get back
Q1: 140 leads x 14% x $8,400 = $164,640 new business, plus renewals. Q2: 155 leads (ramping toward 180) x 14% x $8,400 = $182,280 new business, plus a named batch of 12 renewing contracts at 88% retention adding roughly $88,704. Most sensitive driver: the assumed conversion rate held flat at 14% — a 2-point miss on conversion moves new-business revenue by roughly 14%, more than an equivalent miss on lead volume alone.
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
