Usage-Based Pricing for SaaS: The Complete Deep Dive
Usage-based pricing charges customers based on actual consumption rather than fixed subscription fees. This guide covers how usage-based models work, the revenue predictability challenges they create, how to design hybrid structures that balance predictability with upside, selecting the right pricing metric, and real-world examples of successful usage-based pricing in practice.
Usage-based pricing aligns cost with customer value but creates revenue unpredictability. Hybrid models (base fee plus overage) solve this by combining predictable revenue with upside potential. Pricing metric selection is critical: choose metrics customers understand and that scale with their value. Usage-based companies typically achieve higher NRR as customers expand naturally with growth.
Understanding Usage-Based Pricing Models
Usage-based pricing (also called consumption-based or metered pricing) charges customers based on how much they use the product. Instead of a fixed monthly subscription fee, customers pay based on units consumed: API calls made, data stored, messages sent, reports generated, or any other measurable consumption unit.
The fundamental advantage is alignment. A customer who uses your product more gets more value and pays more. There is no friction around seat counts or tier selection because the price naturally adjusts to usage. A startup using 10 million API calls per month and a large enterprise using 1 billion API calls both pay proportionally to their consumption.
The challenge is revenue predictability. With subscription pricing, you know exactly what you will collect next month: customer count times subscription price. With usage-based pricing, revenue depends on how much customers consume, which varies month to month and is harder to forecast. A single large customer changing usage patterns can materially affect monthly revenue.
Common Usage-Based Pricing Metrics
The pricing metric is the unit you charge for. Different metrics work for different types of products. Per-API-call pricing works for infrastructure and communication tools (AWS charges per API call, Twilio charges per message sent). Per-active-user pricing works for products that scale with team size but where not every user is always active. Per-gigabyte pricing works for storage and data products.
The best pricing metric has three properties: (1) it scales with customer value (a customer using twice as much gets twice as much value), (2) it is transparent to the customer (they understand what they are paying for), and (3) it is measurable and auditable (you can verify how much they consumed). Avoid metrics that are opaque or that create perverse incentives.
Three real-world examples illustrate different approaches. Datadog charges per host monitored (a server or container sending data). As a customer's infrastructure grows, they naturally use more hosts and their bill increases. This aligns perfectly with Datadog's cost structure (more hosts means more data ingestion). Slack charges per active user (someone who logged in during the month). This makes sense because active users create value through collaboration. Mapbox charges per map load or API call. This works because developers can see the direct correlation between their usage and their bill.
The Revenue Predictability Challenge
The core problem with usage-based pricing is forecasting. Assume you have 100 customers on usage-based pricing, averaging 50 million API calls per month at $0.0001 per call. That is $500k monthly revenue. Next month, what if five large customers use 20 per cent less? Revenue drops to $450k. What if they use 20 per cent more? Revenue jumps to $550k. This volatility makes cash flow planning difficult.
This unpredictability creates two operational problems. First, you struggle to forecast cash and may underprepare for growth (or misjudge a slowdown). Second, investors dislike unpredictable revenue, especially at Series A and beyond. They want to model the business with confidence. A usage-based company showing volatile quarter-to-quarter revenue makes them nervous about sustainability.
Many successful usage-based companies have discovered that the real solution is the hybrid model: a base monthly fee plus usage overages. Instead of pure usage-based pricing, you charge a base fee (say £2,000 per month) that includes a certain amount of usage (1 million API calls), then charge for overages. This provides a guaranteed baseline revenue (the base fee) while capturing upside when customers expand beyond the base allocation.
Hybrid Pricing: Base Plus Usage
Hybrid pricing combines the best of both worlds. The base fee creates predictable recurring revenue. The overage fees capture expansion revenue when customers grow. This structure is increasingly the standard in mature usage-based companies.
The mechanics are straightforward. A customer on a £5,000 per month plan gets 5 million included API calls. Beyond 5 million, they pay £0.001 per additional call. If they use 7 million calls in a month, they owe £5,000 + (2 million calls times £0.001) = £7,000. The base fee ensures you collect at least £5,000 that month. The overage captures upside.
Hybrid pricing also addresses a psychological problem with pure usage-based pricing: unlimited exposure. A customer worries that if they accidentally send 1 billion API calls due to a bug, their bill will be catastrophic. With a base plan, overage charges are typically capped per month (a hard limit above which no more charges accrue), which reduces customer anxiety.
Modeling Hybrid Usage-Based Businesses
Modelling a hybrid usage-based company requires tracking both the base revenue and the variable usage revenue. Your financial model needs to project: (1) customer count and growth, (2) average base plan mix (how many customers on which tiers), (3) expected overage rates (what percentage of customers overage, and how much), and (4) total revenue as base revenue plus overage revenue.
The best-practice approach is cohort-based analysis. Track customer cohorts and measure both their base revenue and overage revenue separately. A January cohort acquired at an average £2,000 base plan might generate £2,000 in base revenue and £300 in overage revenue in month 1 (total £2,300 ACV). By month 6, as they have grown, they might be generating £2,000 base plus £800 in overages (£2,800 ACV). This expansion in overage revenue is the expansion engine driving growth.
Net revenue retention for hybrid businesses is often extremely high, typically 120 per cent to 150 per cent. This is because base revenue is sticky (customers rarely downgrade plans) but overage revenue scales with customer growth. A customer who grows their usage 30 per cent grows their bill 30 per cent without any sales effort. This organic expansion is what makes hybrid usage-based models so powerful.
Pricing Metric Selection: How to Choose
Selecting the right pricing metric is one of the most important decisions in a usage-based business. Choose wrong, and you either limit your growth potential (a metric too small creates unsustainable pricing) or make your pricing incomprehensible to customers (a metric too complex creates confusion).
Start with first principles: what creates value for your customer? If you are a logging platform, value is correlated with the volume of logs ingested. If you are a payment processor, value is correlated with transactions processed. If you are a document management system, value might be correlated with documents stored or searches performed. The metric should match the value driver.
Test your metric by asking: (1) Can customers easily understand what they are paying for? (2) Can they predict their monthly costs? (3) Does it scale with their value? (4) Is it easy to measure and audit? If you answer no to any of these, rethink the metric. Bad metrics create customer frustration and make the sales process harder.
Benchmarks and Real-World Examples
Stripe charges per successful transaction (with different rates for different payment methods). A business processing £1 million in payments at 2.4 per cent pays £24,000 in Stripe fees. As a business grows, their Stripe bill grows proportionally. Stripe's NRR is exceptionally high (likely 140 per cent plus) because their customers naturally expand usage as their payment volume scales.
AWS charges per resource consumed (compute hours, storage capacity, data transfer). A customer running 10 servers paying £0.10 per hour for compute plus storage costs might spend £5,000 per month. If they double their infrastructure to 20 servers, their bill doubles naturally. AWS customers show massive expansion revenue simply from organic growth.
Twilio charges per message sent. A high-volume customer sending 10 million SMS per month at £0.007 per message spends £70,000 monthly. As their customer base grows and they send more SMS, their bill increases naturally. This creates a virtuous cycle: Twilio becomes stickier as customers integrate deeper, and customers naturally expand consumption as they grow.
These examples share a common pattern: the pricing metric aligns perfectly with customer growth. As customers succeed and grow, they naturally consume more, their bill increases, and Stripe/AWS/Twilio capture the expansion value without additional sales effort. This is why usage-based pricing is so powerful for infrastructure and platform products.
Implementation Considerations
Building a usage-based business requires operational maturity. You need robust metering (the ability to accurately count consumption), billing infrastructure that can handle variable charges, and customer-facing dashboards showing usage and projected costs. Getting these wrong creates operational nightmares.
Metering must be accurate and real-time. Customers need visibility into their usage so they can predict their costs. A platform that silently racks up charges then bills the customer a month later creates distrust. Invest in customer dashboards showing live usage and projected monthly costs. This transparency reduces churn and reduces surprise complaints.
Billing infrastructure must handle monthly reconciliation correctly. At the end of each billing month, you tally actual usage, apply the pricing formula, and generate an invoice. This must be auditable and defensible. Get this wrong and customers will dispute charges, creating friction and churn.
The sales process also changes. You cannot do a demo and immediately close with pricing, because pricing depends on their expected usage. You need consultative sales: understand the customer's scale, forecast their usage, and present a price estimate. This makes the sales cycle longer but also creates an opportunity to understand customer needs deeply.
When Usage-Based Pricing Works and When It Does Not
Usage-based pricing works brilliantly for certain product categories and fails for others. It works for infrastructure (AWS, Google Cloud), communication APIs (Twilio), observability (Datadog), and billing/payment processing (Stripe, Chargebee). In these categories, usage correlates directly with customer value and scales as the customer grows.
Usage-based pricing is harder for products where value is not directly tied to usage. A project management tool's value is not correlated with how many tasks are created; it is correlated with team collaboration. A recruitment tool's value is not correlated with how many applications are processed; it is correlated with quality of hires. For these products, per-seat or per-account pricing works better than usage-based.
The rule of thumb: if usage scales with customer value and customer growth, use usage-based. If usage is decoupled from value, use fixed pricing. Hybrid models work everywhere because the base fee captures value independent of usage while the usage component captures expansion.