A spreadsheet can show revenue climbing neatly from left to right and still be completely useless. The difference is whether it behaves like the business. This revenue model example starts with the machinery underneath the number: customers arriving, accounts growing, customers leaving, prices changing, and cash landing on a different schedule than revenue.
I built versions of this model because top-down targets always felt a little suspicious. โWe need $5 million next yearโ is a fine destination. It is not an operating plan. A useful model lets you pull one lever, watch the second-order effects, and ask a better question: what would have to be true for this plan to work?
The revenue model example: a small SaaS business
Imagine a B2B SaaS product with a $1,000 average monthly subscription. It begins January with 100 customers and $100,000 in monthly recurring revenue, or MRR.
The business has four primary motions:
- It adds 12 new customers each month.
- It loses 2% of starting customers each month.
- Existing customers expand by 1% of starting MRR each month.
- New customers begin at the current average subscription price.
For January, new MRR is 12 customers multiplied by $1,000, or $12,000. Logo churn is 2% of 100 customers, which is two customers. Churned MRR is therefore $2,000. Expansion MRR is 1% of the $100,000 starting MRR, or $1,000.
The month closes at:
`Ending MRR = Starting MRR + New MRR + Expansion MRR - Churned MRR`
`$111,000 = $100,000 + $12,000 + $1,000 - $2,000`
The February starting point is Januaryโs ending MRR. Repeat the logic month by month, and the model begins to reveal its character. New sales drive the visible growth. Retention decides whether the growth has a floor under it. Expansion compounds quietly in the background, like the useful stat on the back of a trading card.
Start with cohorts, not a blended churn fantasy
A shortcut is to apply 2% churn to total MRR every month. It is fine for a quick sketch, but it gets weird when the business is changing. New customers may churn faster than mature customers. Larger accounts may expand more. Annual contracts create lumpy timing. A blended rate can hide all of it.
For a model that informs actual decisions, track customer cohorts by their start month. Each cohort gets its own row or table: customers acquired, beginning MRR, churn, expansion, and ending MRR. Januaryโs new customers become a January cohort. February becomes another.
This takes a little more setup, but it answers questions a blended model cannot. Are we acquiring customers who stick? Is the product improving for newer cohorts? Is a rising net revenue retention number coming from real customer value or a handful of oversized expansions?
You do not need enterprise-grade data architecture to begin. A clean export, a spreadsheet, and a willingness to name assumptions honestly will get you surprisingly far.
Separate bookings, revenue, and cash
These numbers are often thrown into the same bucket. They should not be.
Bookings represent contracted value. Revenue is recognized as the service is delivered. Cash is when money actually arrives. In a monthly credit-card SaaS business, they may sit close together. In annual invoiced contracts, implementation projects, or ecommerce preorders, they can behave like three different products.
Suppose a customer signs a $12,000 annual contract in January and pays immediately. Cash received in January is $12,000. Bookings are $12,000. If the service begins that month, recognized revenue may be $1,000 per month for the next year.
The revenue model should include all three views when payment terms matter. Otherwise, you can report healthy growth while accidentally designing a cash crunch. That is a very unfun surprise, usually discovered at the exact moment a team wants to hire.
For an ecommerce business, the same distinction shows up differently. Orders are placed today, payment processors remit later, products ship on another schedule, and returns reverse part of the picture. Revenue may look strong while contribution margin is getting chewed up by shipping, discounts, and returns. The model needs to respect the system it is modeling.
Make the inputs visible enough to argue with
A good model has an assumptions area that looks almost boring. That is a compliment.
Keep price, lead volume, conversion rate, sales cycle, new customers, churn, expansion, payment terms, and gross margin in clearly marked input cells. Do not scatter hard-coded numbers through 14 tabs like little financial land mines.
Then build scenarios. A base case is your best operational estimate, not the optimistic case with a fake mustache. A downside case might assume a longer sales cycle, lower win rate, and higher churn. An upside case should be tied to a believable mechanism, such as a new channel proving repeatable or an onboarding change improving activation.
The useful question is not โWhich scenario is right?โ None of them will be exactly right. The question is which assumptions matter enough to change what you do next.
If cutting monthly churn from 2% to 1.5% adds more annual revenue than increasing lead volume by 20%, that is not just a spreadsheet result. It is a product, Customer Success, and onboarding priority.
Use leading indicators before the revenue appears
Revenue is late. By the time a renewal fails, the warning signs have often been hanging around for months.
For a SaaS product, model a few leading indicators alongside the revenue line: activation rate, weekly active teams, adoption of the feature linked to value, support volume, stakeholder engagement, and time to first outcome. The exact set depends on the product. The point is to connect a revenue assumption to observable behavior.
If you assume expansion rises from 1% to 2% monthly, write down why. Maybe accounts using a workflow three times per week have historically added seats. Maybe a new usage threshold triggers a natural upgrade conversation. If no behavior supports the assumption, it is not a forecast. It is decorative optimism.
What this revenue model gets wrong on purpose
Every model is a compression. The first version will likely ignore sales rep ramp time, seasonality, implementation capacity, bad debt, price packaging changes, usage overages, downgrades, and the occasional large deal that turns a chart into a lie.
That is okay. The goal is not to recreate the business at one-to-one scale inside a workbook. The goal is to include the variables that materially change a decision.
Add complexity only when it earns its keep. If annual contracts are 70% of your bookings, model contract timing. If one enterprise customer represents 15% of MRR, model that account individually. If churn is low and stable across a self-serve product, a simpler cohort model may be enough for now.
A model should feel more like a well-designed control panel than an old Windows utility with 400 unlabeled buttons. You should know what each input does, what it affects, and what you would do if it moved.
Turn the model into an operating habit
The most useful revenue models are not rebuilt during planning season and abandoned until someone asks for a forecast. Update actuals monthly. Compare them with the prior forecast. Mark the variance. Then explain it in plain language.
Maybe new logo revenue missed because lead quality fell. Maybe it hit plan, but churn rose in the smallest customer segment. Maybe expansion beat expectations because a new integration made the product more central to a customerโs workflow. Those explanations become the next version of the model.
Over time, the forecast becomes less about being perfectly correct and more about learning where your business is sensitive. That is the real payoff. Build the first version small, make the assumptions visible, and let reality edit it every month.
