Monetization strategy, a framework to find the next dollar across your revenue stack

Why most monetisation plans stall

Most companies do have a monetisation strategy. It usually lives in a founder's head or a slide from last year's board meeting, and it says something like "raise prices at some point, maybe add an enterprise tier, look at partnerships".

The problem is not a lack of ideas. It is that the ideas are never compared with each other. Without a common unit, a price increase, a new add-on and a sponsorship programme all sound equally plausible, so the team picks the one that feels most urgent or the one a competitor just launched.

A working strategy replaces that with a short, ranked list where every item has a size, a confidence level, an effort and a test.

The four-step framework

The framework below works for SaaS, apps, publishers, marketplaces, e-commerce and API businesses. The streams differ by business type, the steps do not.

1. Inventory. List every stream you use and every stream you could plausibly use.
2. Size. Estimate the monthly impact of each opportunity as a low, expected and high range, with the method written next to it.
3. Prioritise. Rank by expected value adjusted for confidence, against effort and risk.
4. Test. Run the top bets as experiments with a baseline, a change and a verdict.

Then repeat. Every test result updates the assumptions behind the next round of sizing.

Step one, inventory the whole revenue stack

Start wide. The point of the inventory is to stop you from optimising one stream while ignoring three others that were never considered.

For each row, write down the current state in one line: "not used", "used, never tested", or "used and tested in the last year". Most teams find that half the rows are "not used" and most of the rest are "never tested".

Step two, size each opportunity with a stated method

Sizing does not need a data science team. It needs three numbers per opportunity and an honest assumption.

The general form is: affected base x rate of change x value per unit, minus the cost of side effects. A price increase, for example, is the number of accounts affected, multiplied by the price change, minus the revenue lost to any extra churn.

Always size as a range. A single number creates false precision and makes every later comparison look more certain than it is. Our page on how estimates work explains the range method in detail.

A worked sizing example

Take a hypothetical SaaS business with 800 paying accounts, 92,000 USD in monthly recurring revenue, and three ideas on the table.

Idea A, a 10 percent price increase on the 300 accounts on the Team plan at 150 USD. Extra revenue is 300 x 15 = 4,500 USD a month. If 3 percent of those accounts churn because of the increase, the business loses 9 accounts x 165 USD = about 1,485 USD. Net expected value is about 3,000 USD a month. With churn between 1 and 6 percent, the range is about 1,500 to 4,000 USD.

Idea B, an annual plan at 20 percent off, currently not offered. If 15 percent of new and existing monthly customers switch, and annual customers churn less, the main gain is retained revenue rather than new revenue. Suppose monthly churn is 3 percent and annual customers effectively churn at a third of that. Switching 120 accounts at an average 115 USD saves about 120 x 115 x 0.02 = 276 USD a month in churned revenue, minus a 20 percent discount on those accounts (120 x 115 x 0.2 = 2,760 USD). Read naively, that loses money. The cash flow benefit of a year paid up front matters, but the monthly revenue impact is negative unless the discount is smaller or churn is much higher.

Idea C, usage overages on the API call limit. If 40 accounts exceed their plan limit by an average of 20 percent and you charge 30 USD per block over the limit, at an average of two blocks per month that is 40 x 2 x 30 = 2,400 USD a month.

Idea B looked like the obvious move before it was sized. Written out, it only makes sense with a smaller discount or as a cash flow decision, which is a different goal. That is the value of sizing: it kills or reshapes ideas before they reach the roadmap. For a deeper look at annual pricing, see annual plan optimization.

Step three, prioritise by expected value, confidence and effort

A simple score works well enough:

Score = expected monthly value x confidence factor / effort in weeks

Use a confidence factor of 0.8 for high, 0.5 for medium and 0.2 for low. Effort is the rough number of team weeks to ship and measure.

Then apply a risk filter. A price increase on all customers at once carries more risk than one applied to new customers first. A change you can reverse in a day carries less risk than a change customers see on an invoice. When two ideas score closely, start with the reversible one.

Watch for hidden dependencies

Some ideas only work once another is in place. Overages require metering. A paywall test requires knowing which content returning users read. Mark these dependencies, and treat the enabling work as part of the effort of the first idea that needs it.

Step four, test against a baseline

Every top idea becomes an experiment with five parts:

• Hypothesis. "A 10 percent price increase on new Team signups raises revenue per new account without reducing conversion by more than 5 percent."
• Metric. The one number that decides the outcome.
• Baseline. The trend before the change, ideally several weeks or months of it.
• Change. The exact variant, price or rule.
• Verdict rule. What counts as a win, flat, loss or not enough data.

Some changes can be split tested, for example two versions of a pricing page with a holdout group. Others cannot, for example a new price applied in billing. For those, measure the change as a dated intervention against the baseline trend, and be honest about the wider interval that comes with it.

Record losses as carefully as wins. A failed test that was well run is information. A failed test that was quietly forgotten is a mistake waiting to be repeated.

Different businesses, different starting points

The framework is the same, but the first rows of the inventory differ by business model.

• SaaS. Start with pricing, packaging and annual plans. Our SaaS pricing strategy guide covers the value metric and grandfathering in detail.
• Publishers and content sites. Start with revenue per visitor by page group, then affiliate and membership. The guide to how to monetize a website ranks those streams.
• Apps. Start with paywall placement and trial design.
• Marketplaces. Start with take rate by category and payment fees.
• API businesses. Start with usage tiers and overages.

What a good strategy document looks like

The output of the framework fits on one page:

1. Current revenue by stream, with the share of total.
2. The top ten opportunities, each with a range, confidence, effort and method.
3. The three experiments running now, with their start dates and verdict rules.
4. The results of the last quarter's experiments, including losses.
5. The next three experiments in the queue.

That page is easy to discuss with a board, a finance lead or a co-founder because every number has a visible source.

Keeping the strategy alive

A strategy written once and filed away decays fast. Prices drift, discount habits creep in, new competitors change what customers expect. A monthly check of a few numbers catches most of it:

• Share of new revenue that came with a discount
• Annual share of recurring revenue
• Revenue per visitor or per active user
• Expansion revenue as a share of new revenue
• Churn by plan

If any of these move more than a few points, re-size the related opportunities.

Doing this with software instead of a spreadsheet

The framework works in a spreadsheet, and many teams start there. It becomes hard to maintain once you have more than a handful of streams and data sources, because every re-sizing means pulling fresh numbers by hand.

Monetisation is revenue optimization software that does the inventory, sizing and test tracking from read-only connections to your billing, analytics, CRM and website, across 16 revenue streams. Every opportunity shows an estimated range with the method in plain words, and every estimate is labelled as an estimate, not a guarantee of results. To see how it reads your business, run a sample audit on your site.