Usage Based Pricing Example: 7 Real Models Explained

Why Usage-Based Pricing Is Taking Over SaaS

If you've been selling software or services on a flat monthly retainer, you've probably noticed something: customers hate paying for stuff they're not using. Flat subscriptions made sense when software was opaque - you didn't know what anyone was actually consuming. Now everyone does. And buyers are pushing back hard.

Usage-based pricing (UBP) - also called consumption-based pricing, pay-as-you-go, or metered billing - flips the model. Customers pay based on what they actually consume. When they use more, they pay more. When they scale back, their bill drops. It's a simple idea that turns out to be a massive strategic lever for both the vendor and the buyer.

The numbers are clear. According to the latest OpenView data, adoption of usage-based pricing has grown from 27% of SaaS companies to well over 40% in recent years - and that number continues to climb. A separate survey by Metronome found that 77% of the largest software companies now incorporate consumption-based pricing into their revenue models. This is no longer an emerging strategy. It's the mainstream playbook for the fastest-growing segment of B2B SaaS.

Companies that implement UBP average around 120% net dollar retention, compared to roughly 110% for traditional subscription-only businesses. That gap compounds. A customer who starts small and grows into your pricing is worth dramatically more over their lifetime than one locked into a flat tier they'll eventually resent.

But - and this matters - usage-based pricing is not a silver bullet. The model has changed significantly in recent years, with most SaaS companies now gravitating toward hybrid structures rather than pure consumption billing. Understanding why, and choosing the right structure for your product, is the whole game.

This article walks you through seven real usage-based pricing examples, breaks down how each model works, explains what's changed in how companies are implementing UBP, and shows you what's worth copying - whether you're building a SaaS, running an agency, or restructuring how you sell your services.

What Is Usage-Based Pricing? (The Short Version)

Usage-based pricing is a billing model where customers are charged based on how much they actually use a product or service, rather than a flat monthly or annual fee. The model aligns cost with value: customers who use more, pay more. Customers who use less, pay less.

This is fundamentally different from traditional seat-based or flat-rate SaaS pricing, where the price stays the same whether the customer uses the product daily or once a month. UBP creates a direct economic link between product engagement and revenue - which is why it drives stronger net revenue retention.

Think of it like your electricity bill. You don't pay a flat fee for having electricity in your house - you pay for what you consume. The more you run, the more you pay. That same logic, applied to software and services, is what makes consumption-based pricing so intuitive to buyers and so powerful for vendors who execute it well.

The terminology gets confusing because vendors use different names for the same fundamental concept. Pay-as-you-go, metered billing, consumption-based pricing, and usage-based pricing all refer to variations of the same model. The key principle across all of them: the customer's cost scales with the value they receive.

The 4 Core Types of Usage-Based Pricing

Before the examples, you need to understand the building blocks. Most companies use one of these four structures, or a blend of them:

• Pure pay-as-you-go: No flat fee. You only pay for what you consume. This is the cleanest model and works best for infrastructure products with real marginal costs. Think AWS charging per second of compute time.
• Tiered usage: Different price rates kick in at different consumption thresholds. The first 10,000 API calls cost X per unit, the next 50,000 cost less per unit. Volume rewards heavy users and creates natural upgrade paths.
• Hybrid (subscription + usage): A flat base fee covers a certain amount of usage, and then overages are metered on top. This is by far the most common real-world implementation. Nearly 46% of SaaS companies now combine subscriptions with usage-based components. It gives you a predictable revenue floor while still capturing expansion revenue from power users.
• Credit-based: Customers pre-purchase credits and burn them down. Popular with AI tools because it gives the vendor predictable cash flow while still aligning cost with consumption. Autodesk uses a version of this with their Flex tokens, which grant access to a product for 24 hours at a time.

Here's something worth noting: pure usage-based pricing has actually cooled slightly as a standalone model. The trend is now toward hybrid structures that combine a fixed floor with variable upside. Companies using hybrid models - subscription plus usage - report the highest median growth rates, outperforming both pure subscription and pure usage-based companies. The hybrid captures the stability of predictable recurring revenue AND the expansion revenue that comes from consumption growth.

Why Usage-Based Pricing Is Accelerating Now

Usage-based pricing isn't new - AWS pioneered it for infrastructure in the early 2000s. So why is it accelerating now across all of SaaS?

Three structural forces are driving it:

1. Automation reduces the logic of seat-based pricing. Software increasingly automates manual processes. The more successful a product is, the fewer user seats a customer actually needs. If your automation tool eliminates the need for three analysts, charging per analyst seat is backwards - it penalizes adoption. Consumption pricing (tied to what the automation produces) is the only model that makes sense.

2. AI makes per-seat pricing incoherent. AI takes automation further, eventually eliminating the need for whole teams of people for ongoing routine work. You can't charge per human user for a product that replaces human users. As one vendor put it: "We have per-user products which are for humans. And we have consumption products, they are for agents and robots." The two categories require completely different pricing structures.

3. API-first products have no users to count. For many software companies, the value is delivered through an API - software talking to software, not a human logging in. There's no seat to sell. Usage-based pricing is the only logical model when the entire value chain is automated.

Nearly 50% of companies that have adopted UBP did so in the last two years alone. The snowball effect is real: as more companies implement it successfully, the customer expectation shifts, and vendors still on flat subscriptions start to look behind the curve.

7 Usage-Based Pricing Examples Worth Studying

1. AWS - Pure Pay-As-You-Go Infrastructure Pricing

Amazon Web Services is the canonical example of usage-based pricing done right. Before AWS, companies had to guess their future server capacity and buy expensive hardware upfront. AWS turned computing into a utility - you pay for compute hours, storage per GB, and data transfer, measured at a granular level. An EC2 instance might be billed per second. Run a server for 45 minutes, you pay for 45 minutes.

The pricing metric is directly tied to resource consumption. That alignment is why AWS generates billions in expansion revenue without a sales team knocking on every door - as your workload grows, your spend grows automatically. There's no renegotiation, no upgrade call, no procurement friction. Your usage just expands and the bill reflects it.

AWS also maintains a free tier for new users, which is a classic land-and-expand play: get customers using the product when the cost is essentially nothing, prove value, and then grow with them. By the time they're running meaningful workloads, switching costs are high and expansion is automatic.

What to steal: If your product has real marginal costs that scale with usage - compute, storage, AI tokens, data transfer - pure pay-as-you-go is defensible. Don't subsidize your heavy users through flat pricing. Those are the customers generating the most value from your product and they should be paying accordingly.

2. Twilio - Per-Unit Communication Pricing

Twilio charges per SMS, per voice minute, per verification call. There's no flat license fee for the core API. Developers can start sending a handful of messages for almost nothing, prove value in their product, and then Twilio grows with them as the product scales. They actually offer four usage-based payment options: pay-as-you-go, volume discounts, committed-use discounts, or a combination of all three.

This model is powerful because it collapses the sales cycle. A developer doesn't need procurement approval to experiment. They put in a credit card and start. By the time enterprise procurement gets involved, Twilio is already embedded in the product's infrastructure - it's a switching cost conversation, not a buying decision.

That's the land-and-expand strategy at its most effective: the initial decision is so low-friction that the "selling" happens through product adoption, not through a sales rep's pitch deck. Twilio's usage pricing strategy is one of the most recognized consumption-based pricing successes in the middleware sector.

What to steal: Low-friction entry. If you can make it nearly free to start and expensive only at scale, you win the land-and-expand game. The best customers you'll ever have are the ones who grew into your pricing - they understand the value, they've built on top of your product, and they're expanding because their own business is growing.

3. Snowflake - Multi-Dimensional Usage Pricing

Snowflake is one of the more sophisticated usage-based pricing examples. They charge across multiple dimensions simultaneously: compute usage (measured in credits - seconds of processing power for data queries), storage (average amount of compressed data per month), and data transfer (moving data across regions). Each dimension has its own pricing, and they compound based on actual workload intensity.

This model perfectly aligns cost with workload intensity. A customer doing light queries on small datasets pays almost nothing. An enterprise running complex analytics on petabytes of data pays proportionally. Snowflake's strategy has attracted some of the world's largest companies - including Mastercard, Disney, and Pfizer - precisely because the pricing scales with what they're actually doing on the platform.

Snowflake also gives customers spending controls: you can set limits on credit consumption to prevent runaway costs, which addresses the biggest objection to usage-based billing at the enterprise level. That transparency is why large procurement teams trust the model - they can budget for a reasonable range and won't get blindsided.

What to steal: If your product has multiple resource types - compute plus storage plus bandwidth, or contacts plus emails plus integrations - pricing each independently can actually make the value proposition clearer, not more confusing, as long as you keep the dashboard transparent and give customers spending controls.

4. OpenAI - Token-Based Credit Model

OpenAI's API is priced per token - roughly every four characters of text. Every LLM call, every inference cycle has a real marginal cost, and OpenAI passes it directly to the customer. The consumer-facing product uses a hybrid model: a subscription for standard access, with usage-based charges for heavy API consumption.

This is instructive because the same underlying AI is priced completely differently depending on who's buying and how. The API is priced on pure consumption while the app runs on a subscription baseline. Same technology, different pricing architecture based on customer behavior and cost predictability expectations.

AI-native companies are increasingly being forced into this structure. As one analysis notes, generative AI content creation comes with new underlying costs that have to be reflected in pricing - you can't absorb variable compute costs under a flat subscription without destroying your margins on your heaviest users. The token model solves this cleanly.

What to steal: Match the pricing model to how each customer segment actually uses the product. Enterprise API customers want consumption pricing because it scales with their builds. Consumer app users want subscription simplicity because they don't want to track tokens. You don't have to pick one model for your entire product - you can run different pricing architectures for different go-to-market motions simultaneously.

5. Slack - Active-User Billing (The "Fair Billing" Model)

Slack uses what they call a "Fair Billing Policy." You pay for the number of active users in your workspace - but if a user goes inactive, Slack automatically stops charging you for them and adds a prorated credit to your account. You only get billed for users who actually log in during the billing period.

This eliminates the "ghost user" problem where companies pay for thousands of employees who never log in. It builds enormous goodwill and makes Slack an easy choice for large enterprises who've been burned by bloated seat counts in other software contracts. It's worth noting this applies specifically to self-serve plans.

The signal this sends to buyers is powerful: Slack is confident enough in its product that they're willing to automatically remove you from billing for value you're not getting. That's the kind of trust signal that closes enterprise deals. Most SaaS companies make customers fight for credits. Slack gives them automatically.

What to steal: Proactively remove friction from the billing relationship. If you can prove you won't charge customers for value they're not getting, you close deals faster and retain them longer. Customers who trust your billing don't scrutinize it at renewal. Customers who don't trust it will find a reason to leave.

6. Stripe - Percentage of Transaction Revenue

Stripe takes a percentage of every transaction processed through their platform. There's no subscription, no seat fee, no setup cost for the core product. If you process $0 this month, you pay $0. If you process $10 million, you pay accordingly.

This is outcome-based pricing in its purest commercial form. Stripe's revenue is literally tied to their customers' business success. When customers grow, Stripe grows. That alignment creates a real structural incentive to genuinely help customers succeed - because it's directly profitable to do so.

From a sales perspective, Stripe's model also eliminates the ROI objection entirely. A prospect can't ask "is this worth it?" because the answer is mathematically obvious: if you process payments, you need a processor, and Stripe's fee comes out of revenue you've already generated. The cost justifies itself with every transaction.

What to steal: If you can tie your fee to a measurable business outcome - revenue generated, meetings booked, cost saved - you remove the "Is this worth it?" objection entirely. The ROI case writes itself. Performance-based pricing components aren't just good for customers; they're a sales shortcut because the math does the persuasion for you.

7. Datadog - Multi-Product Modular Usage Billing

Datadog is worth studying as both a success story and a cautionary tale about complexity. Datadog offers more than 20 separately priced products - infrastructure monitoring, APM, log management, database monitoring, security, real user monitoring, and more. Each requires a separate purchase and introduces its own usage-based charges.

Within each product, you pay based on usage volume: per host, per GB ingested, per million log events indexed, per million LLM requests monitored. The bill is the sum of all these dimensions, and they compound. Datadog uses a high-water mark billing model for host-based products: it measures your host count every hour, discards the top 1% of hours with the highest usage, and bills you for the entire month based on the 99th percentile peak. In practice, if your infrastructure scales up for a five-day traffic spike, Datadog bills you at that peak rate for the entire month - not just those five days.

This produces strong revenue growth for Datadog - their revenue has consistently grown over 25% year-over-year - but it also produces real frustration among customers who encounter surprise invoices. Teams report receiving invoices that were significantly higher than budgeted, not because they misunderstood the product, but because the pricing model has layers of complexity that only reveal themselves at scale or during unexpected traffic events.

The lesson here is that Datadog's modular usage pricing is genuinely powerful for high-growth enterprise infrastructure teams, but the transparency problem is real. When customers can't forecast their bill, they either over-provision on committed contracts or churn when the invoice arrives. The product is excellent; the billing experience requires active management to avoid surprise costs.

What to steal: Modular usage pricing works when the product delivers strong enough value to justify the complexity. But Datadog also illustrates that multi-dimensional UBP without proactive spending controls and transparent dashboards creates friction that erodes trust. If you're building a complex usage model, invest in the customer-facing cost transparency tooling before you launch pricing, not after.

Bonus Example: Mailchimp - List Size and Send Volume Hybrid

Mailchimp's pricing scales with both list size and email send volume. As a business's email list grows and their sending frequency increases, their Mailchimp costs grow proportionally. This links price paid to value derived: a bigger list means more reach, more revenue potential, and a higher bill that customers can justify because it corresponds directly to their business growing.

Mailchimp also maintains a free tier for small lists - classic land-and-expand. Get customers using the product when the cost is essentially nothing, then grow with them as their list and their business scale. If a user exceeds the number of emails they're allotted in a period, they pay overage fees for each additional send. This creates natural expansion revenue without any sales motion at all.

What to steal: If your product's value scales with a customer's business growth, make your pricing reflect that. Customers should understand intuitively why their bill went up - and feel good about it, because it means their business is growing too. That's the psychology you want to engineer into your pricing model.

The Biggest Mistakes Companies Make With Usage-Based Pricing

I've seen enough pricing transitions go sideways to know where the landmines are. Here are the ones that actually cost companies money:

Choosing the wrong usage metric. The metric you charge on has to pass three tests simultaneously: it scales with the value the customer receives, the customer can understand it in under two sentences, and you can meter it accurately. If any of those three fail, your pricing model will break. A good example of getting this wrong: charging per "database row" that inflates from routine background operations the customer doesn't control. They feel penalized for something they didn't do, and trust evaporates. The strongest metrics in SaaS usage-based pricing tend to be API calls, active users, records processed, GB stored or transferred, and tokens consumed - all things the customer has direct control over and can clearly observe.

Building complexity before transparency. The best-performing usage-based companies obsess over their pricing dashboard. Customers will only trust consumption-based billing if they can see their usage in real time. If they get a surprise invoice they didn't see coming, you've created a support nightmare and a churn risk simultaneously. Build the usage transparency layer - spending alerts, usage dashboards, projected billing - before you launch the pricing model. Not after.

Ignoring the forecasting problem. Your finance team will dislike variable revenue for the first several months. Monthly revenue varies based on customer usage, which makes it harder to predict what you'll bring in next quarter. This is a real operational cost that a lot of founders underestimate. The fix: track committed MRR (from base subscriptions) separately from usage MRR (from consumption). You need both numbers to manage your business properly. Pure usage MRR is not a stable forecasting input on its own.

Setting commission structures that fight your pricing model. If sales reps are compensated purely on contracted annual value but the customer only actually consumes 75% of what was projected, you get misalignment everywhere. The most successful usage-based SaaS companies have modified traditional commission structures to include payments based on customers' increasing consumption over time - not just the initial signature. That aligns rep behavior with what actually drives revenue: customer adoption and growth, not just deal size.

Skipping the customer communication plan. When you transition existing customers to usage-based pricing, announce it early. If a transition will take six months, send reminders at 90, 60, and 30 days. For customers whose bills would increase significantly, offer credits that ease the transition over one or two billing cycles. Make the end date non-negotiable - open-ended migrations create a two-tier pricing mess that's difficult to unwind. The quality of your communication directly determines how much support volume you have to handle.

Usage-Based Pricing vs. Subscription Pricing: When to Use Each

This question comes up in every pricing conversation I have with founders. Here's the honest filter:

Usage-based pricing works when:

• Your product has variable usage across customers - some use a little, some use a lot, and flat pricing subsidizes light users at the expense of heavy ones
• The value a customer gets clearly scales with their consumption - more emails sent, more data processed, more API calls made equals more value received
• You want to lower the barrier to entry and accelerate land-and-expand growth - pure UBP lets customers start for essentially nothing and grow in
• Your product has real marginal costs that increase with usage - compute, AI tokens, data storage, transaction volume
• Your customers are developers or technical buyers who are comfortable with consumption billing from their experience with cloud infrastructure

Subscription pricing still works when:

• The value is primarily "access to the tool" - nobody wants to pay for Figma by the frame, or pay for a CRM by the number of times they log in
• Your customers need predictable costs for annual budget planning, especially in enterprise procurement environments where variable invoices create friction
• Your marginal cost is essentially zero - adding one more user doesn't cost you anything meaningful
• Your product delivers value through presence and availability rather than through active consumption

The hybrid is usually right for most B2B businesses. A base subscription that covers predictable baseline usage, plus metered overages for heavy consumption. You get revenue floor stability for forecasting and upside capture from power users. The hybrid approach captures the benefits of both predictability and scaling, and data consistently shows hybrid models delivering the strongest median growth rates among SaaS companies.

How to Pick Your Usage Metric (This Is the Whole Game)

The usage metric you choose determines everything about whether your pricing model works. It's not the tier structure. It's not the per-unit rate. It's the metric itself. Get this wrong and no amount of optimization downstream saves you.

Your usage metric has to pass three tests:

1. It scales with value delivered. As the customer gets more value from your product, the metric goes up. This sounds obvious but it's easy to get wrong. Charging per "feature unlock" doesn't scale with value. Charging per email sent, per contact in database, per transaction processed, per API call made - those scale with value because using more of the product produces more output for the customer.
2. The customer understands it without a tutorial. If you have to explain how your pricing metric works in more than two sentences, it's wrong. The customer should be able to look at their usage dashboard and immediately know what drives their bill and what they can do about it. Metrics customers can't observe or control will generate support tickets and build resentment.
3. You can meter it accurately and in real time. If you can't track the metric reliably, your billing breaks and your customer relationship breaks with it. This requires real investment in the metering infrastructure before you launch. Automated event collection that ensures every billable unit is captured without data loss is non-negotiable. Spreadsheets cannot handle this at scale.

Common strong value metrics by product type: API platforms - API calls or requests. Communication tools - messages sent, minutes used. Data platforms - GB stored, GB transferred, compute minutes. AI tools - tokens consumed, tasks completed. Email platforms - contacts, emails sent. Payment processors - transaction volume or value.

Once you have your metric, the second question is how to structure the rates. Volume discounts - where the per-unit price decreases as consumption increases - reward your best customers and create natural incentives to grow. They're also a retention mechanism: a customer using your platform at a volume tier that gives them a meaningful per-unit discount has a real switching cost - they'd lose that discount if they moved to a competitor and had to rebuild their volume.

How to Implement Usage-Based Pricing Without Breaking Your Business

Transitioning to a usage-based model requires more than updating your pricing page. Here's how to approach it as an operational change, not just a pricing decision:

Step 1: Identify your value metric through customer data. Start with your usage analytics. What features do your best customers use the most? What actions correlate with renewal and expansion? What behavior predicts churn? Your pricing metric should be the thing your best customers do a lot of, your churned customers did very little of, and your power users are doing at 10x the median rate. That's your value metric.

Step 2: Design your model structure before building the billing infrastructure. Decide: pure UBP, tiered, hybrid, or credit-based? For most B2B companies, hybrid wins. Set your base subscription floor - what does a customer pay just to have access? Then define your usage tiers - what are the thresholds, and what does overage cost? Consider volume discounts for high-consumption customers. Document all of this before writing a line of billing code.

Step 3: Build the metering and transparency infrastructure. You need automated event collection that captures every billable unit in real time. You need a customer-facing usage dashboard so customers can see exactly where they are and what they're on track to be billed. You need spending alerts that notify customers before they hit overages - not after. This infrastructure investment is what separates usage-based pricing that builds trust from usage-based pricing that creates billing disputes.

Step 4: Communicate the transition early and completely. For existing customers, announce changes with enough lead time. For new customers, make the pricing calculator the first thing they see after signup - not the last thing they see when the invoice arrives. Show them example bills based on typical usage patterns. Clarity upfront dramatically reduces churn risk downstream.

Step 5: Update your sales compensation and internal metrics. Pay reps on consumption growth, not just initial deal size. Track committed MRR and usage MRR separately. Monitor net dollar retention as your primary health metric - it captures expansion and contraction from existing customers, which is what usage-based pricing is designed to optimize. Watch logo churn too: one of the benefits of UBP is that the barrier to staying is lower, since a customer who cuts back doesn't have to cancel - they just use less and pay less.

Step 6: Iterate based on data. Your pricing won't be right on day one. Track customer behavior, monitor whether your value metric actually correlates with expansion, and be willing to change it. Algolia redesigned their pricing structure eight times after founding. New Relic made the switch from subscriptions to UBP in full public view as a public company. Mixpanel changed their pricing metric from raw events to tracked users when they realized events wasn't correlating to perceived value. This iteration is normal. What matters is staying close to how customers experience value and adjusting as you learn.

Usage-Based Pricing and the AI Disruption

AI is doing something unusual to SaaS pricing: it's simultaneously making usage-based pricing more necessary and more complicated to implement.

On the necessity side: AI-powered products have highly variable output-driven usage patterns. The amount of value an AI tool delivers depends entirely on how much you use it and what you use it for. A flat subscription where light users subsidize power users doesn't work when the power users are running complex, compute-intensive workloads. You end up losing money on your best customers or overcharging your smallest ones. Neither outcome is sustainable.

On the complication side: AI products often have multiple layers of underlying costs - inference compute, context window size, model tier, output format - that don't map cleanly to a single customer-facing metric. The industry is still figuring out how to abstract these costs into pricing that customers understand and trust. Token-based billing (OpenAI's model) is the current leading approach, but it requires customers to develop intuition for a unit of measurement that didn't exist five years ago.

The direction is clear though: as AI agents replace human workflows, per-seat pricing collapses. Companies will increasingly need to charge per task automated, per outcome delivered, or per unit of work completed. Traditional per-seat and feature-based pricing becomes structurally misaligned with how value is delivered. The companies that get ahead of this transition will have a significant competitive advantage over those scrambling to rearchitect their monetization when the market forces the change on them.

Should You Use Usage-Based Pricing for Your Agency or SaaS?

If you're running an agency, this question is more relevant than most people realize. Retainers where clients pay flat fees but use wildly different amounts of your team's time are the service equivalent of a broken flat-rate SaaS model. Some clients send one email a month and expect everything turned around same-day. Others submit 30 requests, require two strategy calls, and want detailed reports on everything. You're charging them the same amount.

Restructuring to include outcome-based components - a base retainer that covers a defined scope, plus performance bonuses or hourly overages for expansion work - is the agency version of hybrid pricing. You get revenue floor stability and you capture the upside when clients are getting disproportionate value. It also makes the value conversation explicit: you're not selling "a retainer," you're selling "outcomes, at a rate that scales with what you deliver."

For SaaS founders, the filter is simpler: do you have customers who use dramatically different amounts of your product? If yes, flat pricing is probably costing you expansion revenue on your power users while overcharging your light users. The hybrid model - base access fee plus metered overages - is almost always the right starting point. Pure UBP only makes sense if you have real marginal costs that scale with usage and customers who are already comfortable with consumption billing from their existing toolset.

For frameworks to restructure your agency's revenue model, the 7-Figure Agency Blueprint covers the specific pricing and positioning changes that get agencies past the retainer ceiling.

Usage-Based Pricing and Outbound Sales: What Changes

One thing most pricing guides completely ignore: usage-based pricing changes how your sales team operates. When a rep's commission is based on contracted annual value but the customer only actually consumes 75% of what was projected, you get friction everywhere. Either the customer wants credits, the rep gets penalized at renewal, or you build a compensation system that fights your pricing model. You need to think about how your comp plan evolves alongside your pricing architecture.

The upside for outbound sales is real though. Usage-based models collapse the initial deal size needed to get a customer in the door. Instead of selling a $50k annual contract to prove ROI upfront, you can get a customer started for almost nothing, let the product prove itself, and expand from there. The initial objection - "we're not sure this will deliver enough value to justify the investment" - largely disappears when the entry point is low. If you're running cold outreach to SaaS prospects, leaning into the "start for free, pay as you grow" angle is a legitimate objection crusher.

When you're prospecting into companies that have adopted or are likely to adopt usage-based pricing models - SaaS, tech companies, API-first businesses, AI startups - targeting the right contacts matters as much as the message. I use ScraperCity's B2B lead database to filter prospect lists by industry, job title, and company size so I'm reaching CFOs and VP Engineering at SaaS companies, not generic "business owner" lists. Pair that with a tight cold email sequence built around their pricing pain and you're reaching the right buyers before your competition even knows the deal is available.

If you need to find the direct email or phone number for a specific decision-maker once you've identified the company, an email finding tool will get you past the gatekeeper faster than any other approach.

For a proven structure on how to run discovery with prospects once they're in the funnel, the Discovery Call Framework is worth downloading - it works whether you're selling SaaS, services, or anything in between.

Usage-Based Pricing Metrics to Track After Launch

Once your usage-based model is live, your standard SaaS metrics need an update. The traditional MRR number is no longer a single clean figure - it becomes two numbers you need to track separately.

Committed MRR is the revenue from base subscriptions - the floor. This is predictable and forecastable. Usage MRR is the revenue from consumption overages and variable billing. This fluctuates based on customer behavior. Total MRR is a blended estimate of both, and using it as your only financial health indicator will give you misleading signals.

The metrics that matter most in a usage-based model:

• Net Dollar Retention (NDR): The single most important metric. It captures expansion revenue from existing customers growing their usage alongside contraction from customers pulling back. UBP companies targeting 120%+ NDR means for every $100 in ARR last year, you have $120 this year from the same cohort - before any new customer acquisition. That's the compounding power of the model working correctly.
• Usage growth rate per account: Are accounts consuming more month-over-month? This is a leading indicator of expansion revenue and product health. Flat or declining usage per account is a retention warning sign even if logo churn is low.
• Average revenue per account at different usage tiers: This tells you whether your pricing tiers are calibrated correctly. If 80% of accounts are in your lowest tier and barely touching the next one, your upgrade threshold may be set too high.
• Time-to-first-overage: How long does it take a new customer to hit their first metered overage? If this is happening in the first billing cycle, you may have set your base tier too low and you're creating sticker shock. If it never happens, you may have set it too high and you're leaving expansion revenue on the table.

The Bottom Line on Usage-Based Pricing

Usage-based pricing isn't a silver bullet, and it's not right for every product. But the direction is clear: buyers want to pay for value, not access. The companies winning right now are the ones that identified their true value metric, built the metering and transparency infrastructure to support it, and designed a pricing model that grows with their customers instead of fighting them.

The seven examples in this article - AWS, Twilio, Snowflake, OpenAI, Slack, Stripe, and Datadog - cover the full spectrum from pure pay-as-you-go to complex multi-dimensional billing. Find the one that's structurally closest to your business. Then ask one question: what is the single metric that scales most directly with the value my customer gets from my product?

Answer that, and you have the foundation. The tier structure, the rate card, the overage policy - all of that is downstream of getting the metric right. The metric is the leverage point. Everything else is execution.

If you want to pressure-test your pricing strategy with people who've actually built and sold companies, I go deeper on this inside Galadon Gold. And if you're building an outbound motion to sell into SaaS companies using any of these pricing models, grab the Agency Contract Template - it's structured for the kinds of deals you'll close at the enterprise level.