Where SaaS revenue usually leaks
Most SaaS companies set prices once, at launch, and then spend years building features on top of them. The plans stay the same while the product doubles in value. The result is a familiar pattern: a cheap entry tier that most customers never leave, a middle tier priced for a smaller product, and a stack of discounts that sales gave away and nobody removed.
Monetisation looks at the whole picture at once. It reads what customers actually pay, not what the pricing page says they pay, and compares the two.
The revenue streams that matter for SaaS
- Subscriptions and plan mix. How revenue spreads across tiers and whether customers cluster at the bottom.
- Annual billing. The share of revenue on yearly plans and the discount offered for it.
- Usage pricing and overages. Whether heavy users pay more than light users.
- Seats. Whether team growth inside an account turns into revenue.
- Upsell and cross sell. Add-ons and premium features that sit outside the main plans.
- Trials. Trial length, card upfront or not, and how many trials convert.
- Discounts. Coupons, sales discounts and promotions that never end.
- Retention offers. What happens when a customer clicks cancel.
What the audit typically finds in a SaaS
Each finding below is a hypothetical example of an opportunity type. Your audit shows only what your own data supports, each with an estimated range, a confidence level and the method in plain words.
No annual plan, or an annual plan nobody sees
A company with only monthly billing collects less cash upfront and loses more customers every month. A company with an annual plan hidden behind a toggle that defaults to monthly gets a small yearly share. The audit measures your current annual share and estimates the effect of making yearly the default. The details are on the annual plan pricing page.
An underpriced middle tier
When 70 percent of paying accounts sit on the cheapest plan while using features that cost you money to serve, the plan boundaries are in the wrong place. The audit looks at usage per account by plan and flags tiers where usage has outgrown price.
Discounts that outlive their reason
A 30 percent launch discount applied "forever" in 2024 is still costing revenue in 2026. The discount leakage monitor lists every active discount, how much it costs per month and when it was created.
Seats that are free in practice
If a plan includes "unlimited users", the largest customers pay the same as the smallest. The audit compares account size to revenue and estimates per seat or per team pricing.
Heavy users on flat prices
Where the product has a natural unit (projects, records, API calls, messages), the audit checks whether the top 10 percent of accounts by usage pay meaningfully more than the median. When they do not, it estimates a usage tier or an overage price.
Data sources to connect
You can start with Stripe alone. Each extra source sharpens the estimates.
| Source | What it gives the model | Plan needed |
|---|---|---|
| Stripe (restricted read-only key) | MRR, ARR, plan mix, discounts, churn, expansion, annual share | Starter |
| Your website | Pricing page structure, plan names, trial terms, paywall | Starter |
| Google Analytics 4 and Search Console | Traffic, pricing page visits, conversion to signup | Starter |
| Product database (read-only) or CSV | Usage per account, feature adoption | Growth |
| HubSpot or Salesforce | Sales discounts, deal size, sales cycle | Growth |
Starter includes 3 connected sources and Growth includes 10. The plan limits are listed on the pricing page.
A worked example, entirely hypothetical
Take a SaaS with 400 paying customers. 300 are on a 49 USD Basic plan, 100 are on a 149 USD Team plan, and everyone pays monthly.
Current MRR is (300 × 49) + (100 × 149) = 14,700 + 14,900 = 29,600 USD.
The audit might surface three opportunities.
| Opportunity | Method in plain words | Estimated monthly impact (low, expected, high) |
|---|---|---|
| Annual plan at 20 percent off, default on | 25 percent of new customers choose yearly, churn on those accounts falls from 3 to 1 percent per month | 300, 700, 1,100 USD |
| Team plan from 149 to 179 USD for new customers | 100 accounts' usage is 2.4 times Basic; 6 percent fewer Team signups assumed | 900, 1,600, 2,300 USD |
| End 22 legacy 30 percent discounts at renewal | 22 accounts × average 15 USD discount; 10 percent of them assumed to churn | 180, 260, 330 USD |
The arithmetic for the Team change, expected case: if the 100 Team accounts were all on 179 USD, MRR from Team would be 17,900 USD, 3,000 more than today. The audit applies it only to new and renewing accounts over the period, subtracts the assumed signup loss, and shows about 1,600 USD expected. Each number is an estimate, not a guarantee of results, and the method sits next to it.
How experiments run in a SaaS
Every opportunity has a "Run experiment" button. In SaaS, three delivery types are common.
Pricing page variants with a holdout
On Growth and Scale, a small JavaScript snippet on your pricing page shows variant A or B to each visitor, with a holdout group that always sees the current page. Typical tests: yearly toggle default, plan order, highlighted plan, price display per month or per year. Measurement comes from your analytics and Stripe signups.
A change you make in your own billing
You create a new price in Stripe for new customers, and Monetisation records the date. It then compares revenue and conversion after that date against the trend from your baseline period. This suits price increases, new annual plans and new overage prices, where a split test on a pricing page is not practical.
A playbook
Some changes are operational, such as ending legacy discounts at renewal or adding a retention offer to the cancel flow. Monetisation turns these into a checklist and measures the outcome on the metric you pick.
Results show lift, an interval and a verdict: win, flat, loss or not enough data. Losses are shown too, because a pricing test that loses still tells you something.
Why read-only matters for pricing work
Pricing data is sensitive and the billing account is the last thing anyone wants an outside tool to touch. Monetisation uses a restricted read-only key for Stripe and never changes prices, charges, customers or subscriptions. Every change in your billing is one you make yourself, after looking at the estimate and the method. Your data is not used to train AI models.
When pricing is not the answer
Sometimes the audit says the opposite of what a founder expects. If churn is high in the first 60 days, a price increase is unlikely to help, and the higher-value opportunity is onboarding or a retention offer. If traffic to the pricing page is tiny, the first job is the pricing optimization software basics: clearer plans and a working annual option, rather than fine-grained tests.
For SaaS products with an API at the core, the monetize API page covers usage tiers, overages and rate limit plans in more depth.
Getting started
Run a sample audit on the homepage with your website address and the SaaS business type. You see the first 3 opportunities with their estimate ranges and a revenue stack map in about a minute, with no card. To connect Stripe and see the full audit, pick a plan on pricing and get started.
Questions
How often should a SaaS company review its pricing?
A full review once or twice a year is common, with lighter checks every quarter. Pricing drifts as the product grows, so a tier that fitted the product at launch is often underpriced two years later.
What is the quickest pricing win for most SaaS companies?
Offering an annual plan with a clear discount is usually the fastest change to ship, because it needs no new features. It improves cash flow and tends to lower churn, since yearly customers renew less often.
Does Monetisation change my prices in Stripe?
No. Every connector is read-only. Monetisation shows the opportunity, the estimate and the method, and you decide whether to create a new price in your own Stripe account.
How do I know a price increase did not hurt conversion?
Run it as an experiment. Pricing page variants run through the snippet with a holdout group, and billing changes are measured as a dated intervention against your baseline trend, with a verdict of win, flat, loss or not enough data.
Is this useful for a SaaS with fewer than 100 customers?
Yes, for packaging, annual plans and discount leakage. Experiments with very small traffic often end with not enough data, and Monetisation says so plainly instead of inventing a winner.
See what your own site is leaving on the table
A sample audit reads your public pages and returns the first three opportunities with estimates and methods. About a minute, no card.