A driver-based model is a financial model where every important number is computed from an underlying operational input, not typed in directly. Revenue is not a number. Revenue is price times volume, where price comes from the price book and volume comes from a funnel: traffic times conversion times close rate times average deal size. Change the conversion rate and the whole forecast moves with you.
The opposite — what most founders build by default — is a static model. Static models are spreadsheets where someone typed "$240,000" into the January revenue cell and "$252,000" into February because it felt about right. Static models are easy to build, useless when conditions change, and dangerous when investors stress-test them. They cannot answer the question "what happens if our close rate drops 20%?" because there is no close rate. There is only the number someone typed in.
Driver-based modeling fixes this. It is the difference between a forecast you defend with "here is the math" and a forecast you defend with "here is what I think." For early-stage operators, our startup finance hub is the broader context; this post zooms into the modeling layer specifically.
What "driver-based" actually means
A driver is any operational input that produces a financial output through a known relationship.
The classic SaaS revenue driver chain looks like this:
Monthly visitors
× landing-page conversion rate
= sign-ups
Sign-ups × trial-to-paid rate
= new customers
New customers × average price
= new MRR
(New MRR - churn MRR + expansion MRR)
= net new MRR
Net new MRR cumulated over time
= ARR
Every line on the income statement traces back to a driver. The driver is what changes when the business changes. Conversion improved? Update one cell. Pricing changed? Update one cell. Hired three sales reps? The ramp-and-quota driver feeds new bookings automatically.
The downstream value: a single driver change updates the entire model — revenue, cost of revenue, gross margin, operating expense, cash flow, and the burn rate. No manual rewiring. No "let me get back to you with the updated forecast" emails.
Why founders trip into static models anyway
Static models are not built out of laziness. They are built because:
The team is small and the data is thin. With three months of operating history, drivers feel speculative. You do not know your true conversion rate yet; you have a sample of 47 sign-ups. Typing in a revenue number feels more honest than dressing up a guess as a calculation.
The board asks for a number, not a model. When an investor says "send me your Q3 forecast," the path of least resistance is to type the number into a cell and email the spreadsheet. Building the underlying driver model takes a day. The number takes ten minutes.
Drivers compound errors. A static model has one number that might be wrong. A driver model has ten inputs, any of which can be wrong, and the outputs can drift further from reality than the static guess. Founders new to driver modeling get burned once by a sensitivity stack and never come back.
These are real reasons, but they collapse under the first scenario question that matters. The minute someone asks "what if X?" — what if pricing moves, what if a key channel dries up, what if hiring slips by six weeks — the static model has to be rebuilt from scratch. The driver model answers in a sentence.
The four building blocks
Every driver-based model is constructed from four kinds of drivers. Get all four right and the model holds up under stress.
1. Revenue drivers
These produce the top line. The two universal revenue drivers are price (what a customer pays per unit per period) and volume (how many units you sell per period). Everything else is a refinement.
For SaaS: volume decomposes into traffic, conversion, sales cycle, win rate, and average deal size. Price decomposes into list price, discount rate, and contract length. The a16z 16 startup metrics primer is a useful cross-reference for which drivers investors will press on first.
For services: volume decomposes into billable hours, utilization rate, and project mix. Price decomposes into bill rate by role and overage policy.
For e-commerce: volume decomposes into sessions, add-to-cart rate, checkout completion, and items per order. Price decomposes into average order value and discount mix.
The first time you build the model, write every revenue driver on one page. If a driver does not show up somewhere, the model will silently break.
2. Cost-of-revenue drivers
These produce gross margin. For SaaS, the typical drivers are hosting cost per customer, support cost per ticket (× tickets per customer), and payment-processing fees. For services, it is fully-loaded cost per billable hour. For e-commerce, COGS per unit plus fulfillment plus payment processing.
The mistake: bundling COGS into one line and forgetting it. The fix: split COGS into the two or three drivers that actually move it, then watch each independently.
3. Headcount drivers
These produce the operating expense line and, in service businesses, also feed revenue. Headcount is rarely just "salary expense." A real headcount driver decomposes into:
- Hire date — when the person starts
- Ramp curve — what fraction of full productivity they deliver in months 1, 2, 3, 4+
- Fully-loaded cost — salary plus benefits plus payroll taxes plus equipment plus software
- Productivity output — bookings, support tickets handled, lines of code shipped, customers serviced
A 20-person company should have 20 rows in the headcount driver tab, each producing its own monthly cost and (where applicable) monthly output. This is the single biggest lift versus a static "$1.2M salary expense" line — and the only way to answer "what happens to burn if we delay these three hires?" in under thirty seconds.
4. Capital drivers
These produce the balance sheet and cash flow. The four common capital drivers: capex (equipment, leasehold improvements, software platforms over $10K), working capital (AR days, AP days, inventory days), debt service (loan principal and interest), and equity raises (round size, timing, dilution).
Small companies often ignore the working capital drivers. This is a mistake. A 30-day shift in AR can be the difference between making payroll and not making payroll, even at constant revenue. Model it — our cash flow forecasting workflow shows how the working capital drivers chain into the 13-week view.
A worked example: one driver, three statements
A 12-person SaaS company is modeling Q3. They forecast:
- Sign-ups: 800/mo (driver: 40,000 visitors × 2% conversion)
- Trial-to-paid: 12%
- Average MRR per paying customer: $400
- Churn: 3.5% monthly
- S&M cost per sign-up: $35
This produces 96 new paying customers per month, $38,400 in new MRR, ~$8,800 in churn (off a $250K base), net new MRR of ~$29,600, monthly S&M of $28,000.
Now the founder runs a scenario: what if we raise prices from $400 to $480 per month (20% increase)?
In a static model, the founder retypes the revenue line. In a driver model, they change one cell — the average MRR per customer driver — and watch the ripple:
- New MRR: $38,400 → $46,080 (the same 96 customers now pay 20% more)
- Churn MRR: depends on whether the price change increases churn — model that as a separate driver, say 3.5% → 4.2% monthly, which lifts churn from $8,800 to $10,500
- Net new MRR: $29,600 → $35,580
- Gross margin: improves slightly (hosting cost per customer is roughly fixed)
- Cash inflow timing: unchanged (annual contracts still bill annually)
- Sales productivity per dollar of S&M: improves (same cost, higher revenue per close)
- Burn rate: drops by ~$6,000/month
The same change in a static model requires rewriting six cells. The driver model required one. The difference is not just speed — it is the ability to ask the next question. "What if pricing goes up and churn goes up more than we expected?" Change one more driver. The model answers.
When the driver-based model is wrong for you
There are two situations where static beats driver:
Pre-revenue, pre-data. If you have no operating history, your drivers are guesses dressed up as math. A two-month-old company building a 30-driver model is performing rigor, not exercising it. Build a one-page static budget. Update it monthly as data comes in. Switch to driver-based once you have six months of real numbers in at least three of the four driver categories. Paul Graham's Default Alive or Default Dead is the right mental model for that early window — runway first, model later.
One-shot exercises. If you need a number for a one-time board ask — say, "what would a $5M acquisition look like?" — building the full driver tree is overkill. Run a back-of-the-envelope static model, label it clearly as a scenario, and move on. Driver modeling pays off for the financial system you use repeatedly, not for one-time questions.
For everything in between — most companies past Series A — driver-based is the right default.
The four most common driver-modeling mistakes
1. Hard-coding inside formulas. A driver model is only as good as its cleanest inputs cell. The minute someone types =B14*1.15 inside a formula, the 15% is invisible to anyone reviewing the model. The discipline: every assumption lives in its own cell on the assumptions tab. Every formula references the assumption. No exceptions.
2. Driver explosion. It is tempting to add a driver for everything — driver for the price of coffee, driver for the office plant maintenance contract. Stop at the top 15-20 drivers that actually move the outputs by more than 1%. Every additional driver below that threshold adds maintenance cost without adding insight.
3. Stale drivers. Drivers need monthly maintenance. The conversion rate from twelve months ago is not the conversion rate today. Build a checklist: every month, the finance owner reviews the top 10 drivers and updates them with actuals. Without this, the model decays into a static model with extra steps.
4. Confusing drivers with forecasts. A driver is the structural input — "average sales cycle length is 47 days." A forecast is what you expect that driver to do — "sales cycle will compress to 38 days as the new onboarding flow rolls out." Keep the two separate. The driver cell holds the current reality. The forecast tab holds the changes you expect over the planning horizon.
How to build one in a week
Day 1: Map the four driver categories on paper. Write down every revenue driver, COGS driver, headcount driver, and capital driver. Do not build anything in a spreadsheet yet.
Day 2: Build the assumptions tab. One driver per row. Source from billing, GL, ATS, and CRM. Label every driver with its current value and where the data came from.
Day 3: Build the headcount tab. One person per row. Hire date, ramp curve, fully-loaded cost, productivity output.
Day 4: Build the P&L tab. Every revenue and cost line is a formula that references the assumptions tab.
Day 5: Build the cash flow tab. AR timing, AP timing, capex, debt service, equity raises. If you want a head start, our financial model template is a clean skeleton you can wire your drivers into.
Day 6: Sensitivity. Pick three drivers. Build a 5×5 sensitivity table for each against a key output (cash balance at year-end is the usual choice).
Day 7: Stress test. Hand the model to someone who did not build it. If they cannot explain what each driver does without you in the room, the model is too complex. Simplify until they can.
FAQ
What is the difference between driver-based modeling and zero-based budgeting?
Driver-based modeling builds a forward forecast from operational inputs. Zero-based budgeting is an annual exercise that justifies every line item from zero each year. They complement each other — zero-based budgeting forces you to validate the drivers; driver-based modeling extends those validated drivers into a working forecast.
Do I need a special tool, or can I do this in Excel?
Excel and Google Sheets are sufficient for companies up to about $20M ARR. Past that, the model usually outgrows what one spreadsheet can hold and teams move to dedicated FP&A platforms — Cube, Mosaic, Pigment, Vena. Tooling does not change the underlying discipline. A bad driver model in Pigment is still a bad model.
How many drivers should my model have?
For a Series A SaaS company, expect 30-60 drivers across the four categories. Fewer than 20 and the model is probably oversimplified. More than 80 and it is probably overcomplicated. The right number is the one where every driver moves the cash output by more than 1% under reasonable changes.
How is driver-based modeling different from rolling forecasts?
A rolling forecast is a process — re-forecasting every month for the next 12 months instead of holding the annual budget static. Driver-based modeling is a structure — building the forecast from operational inputs. The two pair: rolling forecasts run faster and stay more accurate when the underlying model is driver-based.
Should I share my driver model with investors?
Yes. The cleanest fundraises happen when the founder hands the investor the model, walks them through the top five drivers, and lets them stress-test it themselves. A driver model that survives investor stress-testing is the strongest credibility signal a founder can deliver in a Series A or B raise. Pair the driver tour with the unit-economics framing from our SaaS unit economics guide and you have most of an investor's diligence questions answered before they ask.
The takeaway
Driver-based modeling is the difference between a forecast that breaks the first time conditions change and a forecast that flexes. It is not harder to build than a static model — it is harder to build the first time, and then permanently easier from week two onward.
For early CentSight users, the platform pulls drivers directly from your billing, CRM, and accounting systems so the assumptions tab stays current without manual updates. The forecast moves when the business moves.
