How to Build a Driver-Based Forecast in Six Steps

A trend forecast takes history and projects it forward, so it can only tell you what happens if the future looks like the past. A driver-based forecast expresses each financial line as a formula of operating quantities, so you can change the quantities and see the effect.

The two aren't enemies. Use a trend view as a sanity check on your driver model: if the driver-based result differs sharply from the trend, make sure you can explain why. Also use drivers only where they add insight. Rent doesn't need a driver. Revenue, payroll, cost of goods, customer support and hosting usually do.

Be wary of the temptation to model everything. A driver model with 200 inputs is a maintenance burden that nobody trusts. The goal is a handful of drivers that explain most of the movement, updated from real data on a regular schedule.

Work through them in order:

1. Choose the outputs. Decide which lines the forecast must produce, such as revenue, gross margin, operating expense, cash and headcount.
2. Find the drivers. For each output, identify the few operating quantities that explain most of it, such as leads, conversion, average contract value, ramped sales reps, customers and tickets per customer.
3. Write the relationships. Express each output as a formula of its drivers, and document each formula in plain language.
4. Separate fixed, step and variable costs. Rent is fixed, a support manager for every set number of agents is a step cost, and payment processing fees are variable.
5. Feed in the data. Pull actual driver values from your CRM, billing, support and HR systems, or type them in on a schedule if you have to.
6. Run scenarios. Change several drivers at once, such as lower conversion and slower hiring, and see the effect on cash and margin.

Keep every input on an assumptions tab, so nothing is buried inside a formula.

Say you sell software with an average annual contract value of $12,000. Say you get 400 qualified leads in a month, 20 percent become opportunities and 25 percent of those close. Say that's 80 opportunities and 20 new customers, so new ARR is 20 times $12,000, or $240,000.

Now link the cost side. Say you have 400 customers today and each opens 1.5 support tickets a month, at $14 of cost per ticket. Say support cost is 400 times 1.5 times $14, or $8,400 a month. If you add the 20 new customers, support cost rises to about $8,820, and it scales as customers grow.

The sales side can use capacity instead: say each ramped rep closes $30,000 of new ARR a month and you have three, so capacity is $90,000. If you find the lead-based forecast says $240,000 and your reps can only handle $90,000, one of them is wrong. That kind of conflict is the reason to build drivers. It also links to unit economics; see SaaS unit economics for how those drivers turn into payback.

Before you trust the forecast, backtest it. Feed last year's actual driver values into the model and compare its output with what really happened. Large gaps mean a driver is missing or a relationship is wrong. Fix those first.

Then check the assumptions themselves:

• Are conversion rates and average contract values based on recent data, not your best month?
• Does hiring include realistic start dates and ramp time?
• Do capacity limits, such as reps, support agents or production hours, cap the output in the model?
• Does growth make sense compared with benchmarks? SaaS Capital reported a median ARR growth rate of 25 percent for private B2B SaaS companies in 2024¹, so a forecast far above that needs an explicit reason.

Record which assumptions you're least sure about and give them ranges, then look at what happens at each end.

A forecast helps only if it's updated. Set a monthly rhythm: close the books, refresh driver actuals, compare against the forecast in a budget vs actual report and update the outlook. Review misses by driver, not just by dollar amount. If revenue was short, was it lead volume, conversion or deal size?

Keep the model small enough that one person can maintain it. Add drivers only when a variance keeps recurring without explanation. As the company grows, planning tools such as Jirav and Cube can pull actuals from accounting and operating systems into driver-based plans; compare them in Jirav vs Cube vs Mosaic and confirm in a demo how driver logic is built and who maintains it. A starting structure for software companies is in the early-stage SaaS model guide, and for analyzing what changed between periods, the price-volume-mix analysis template separates price, volume and mix effects. The customer profitability analysis template shows where drivers like cost to serve come from.