How to Build a Cohort-Based Revenue Forecast

A pipeline forecast tells you what new revenue will close. It says nothing about what happens to the revenue you already have, which for most B2B SaaS companies is the larger number by a wide margin. A cohort model fills that gap by using the observed behavior of your existing customers rather than a single churn assumption applied to everything.

What is a cohort-based revenue forecast?

A forecast built from the revenue curve each customer group follows after it starts, applied forward to younger groups.

Group customers by the month they became customers. For each group, plot total revenue in month one, month two, month three, and onward. Older cohorts have long curves. Newer cohorts have short ones. The forecast comes from assuming a young cohort will follow a shape similar to the mature cohorts that came before it.

The result is a projection of the recurring base that accounts for when revenue leaves rather than assuming it leaks evenly. That timing distinction is the whole point, because churn in B2B SaaS clusters around renewal anniversaries rather than spreading across the year.

How do you build the curves?

Track net revenue per cohort by month since start, indexed to the cohort's month one revenue.

Indexing matters. A cohort that started with $200,000 and one that started with $50,000 cannot be compared in absolute dollars, but their index curves can be laid on top of each other directly.

The figures above illustrate the structure of the output rather than serving as benchmarks. Two features are worth noting in any real version. Enterprise curves often cross above 100 percent because expansion outweighs churn. SMB curves usually decline and then flatten once the population stabilizes into committed users.

Use net revenue rather than logo counts. A logo retention curve and a revenue retention curve can point in opposite directions, and the revenue curve is the one that forecasts. The mechanics behind that measure are covered in the net revenue retention glossary entry.

How do you turn curves into a forward number?

Multiply each live cohort's starting revenue by the index value for the month it will reach in each future period, then sum across cohorts.

A cohort that started six months ago and is projected into next quarter needs index values for months seven, eight, and nine. Pull those from the average of mature cohorts, weighted toward recent ones so the projection reflects current product and pricing rather than a version of the company from three years ago.

Add new customer cohorts on top. Those come from the pipeline forecast, which is how the two models connect. New bookings create a cohort, that cohort enters the curve at month one, and it contributes to the recurring base for every period afterward.

Build the output as a monthly waterfall. Beginning revenue, churned customer revenue, churned product revenue, product decreases, new customer revenue, new product revenue, product increases, ending revenue. Beginning revenue for any month equals ending revenue from the month before, which forces the model to reconcile. A waterfall that reconciles by month is the single most useful artifact this build produces.

Which cohorts should you actually split?

Start month and segment. Stop there until each cell holds enough accounts to be stable.

Every additional dimension divides your data. Split by month, segment, product, and region and you will produce cohorts of four accounts whose curves swing wildly on a single departure. Those swings look like insight and are noise.

Segment is the split that earns its cost, because retention behavior differs sharply between an enterprise account with a procurement process and an SMB account paying by card. If your volume supports only one dimension beyond start month, make it segment.

How do you spot a cohort about to break?

Watch support engagement, since both silence and heavy ticket volume predict departure.

The curve tells you what happened. Leading indicators tell you what is about to. One of the more useful signals in ORM customer data is support case volume, and the relationship is not linear. Accounts with no support cases at all are at risk, because nobody is using the product. Accounts with seven or more cases in a year are also at risk. Accounts with three to five cases, typically lower severity, are the least likely to churn, since they are engaged and getting help.

Feed that signal into the cohort model as an override rather than a rate change. If a subset of accounts in a given cohort carries a risk flag, model those accounts separately rather than degrading the whole cohort curve. Overrides applied to the entire group destroy the historical comparison that makes the model work.

What breaks a cohort model?

A change in the business that makes old cohorts unrepresentative of new ones.

Cohort forecasting assumes the future resembles the past for customers who look alike. Pricing changes, a move upmarket, or a shift in contract length all break that assumption, and the model will keep producing confident numbers built on a company that no longer exists.

This is the general failure mode for forecasts of every type. Models miss because something in the business or the market changed while the assumptions stayed fixed. A competitor enters and applies pricing pressure, average deal size falls, and expansion within existing cohorts slows. The model needs to detect that shift quickly rather than at the next annual review.

Recalculate curves quarterly and compare recent cohorts against the mature average. When a recent cohort diverges from the pattern by more than a few points, treat it as a signal about the business before you treat it as a modeling problem. Pair this build with a pipeline-side forecast using how to forecast revenue, and use the forecast accuracy glossary entry to define how you will grade the output.