What is Usage-Based Pricing? Definition + Examples

Created time

Jun 1, 2026 06:48 PM

Title length (<60)

Author

Mike Heap

Ecomm?

What does usage-based pricing actually mean?

⚡

TL;DR: Usage-based pricing ties your bill to a metered unit of consumption. A fair model has three things, all on your side: the unit is something you can count yourself, the rate is published, and there's no vendor judgment about whether a unit counts.

At the simplest level, usage-based pricing ties your bill to a metered unit of consumption. OpenView calls it "the next evolution in software pricing"; Stigg defines it as charging "based on how much they use a product". The history runs seat-based, then usage-based, then (now, with AI) outcome-based, and most vendors sit somewhere along that line.

What separates a fair usage-based model from a punishing one comes down to three things, and they all sit on your side of the table:

The unit is something you can count yourself. A ticket, an API call, a gigabyte. You can pull the number from your own systems and check the vendor's maths, so you're not taking anything on faith.

The rate is published. You can see the per-unit price before you sign, and model your bill from it.

There's no vendor judgment about whether a unit counts. The meter is mechanical. Nobody at the vendor decides, after the fact, whether your usage qualified.

Hold onto that third one. It's the line that separates usage-based pricing from outcome-based pricing, where the vendor does decide whether each unit counted as a "win". I'll come back to it in the misconceptions section.

How does usage-based pricing work? The common models and meters

⚡

TL;DR: Two questions decide a usage-based plan: what unit you're metered on (an API call, a token, a ticket) and how the rate is shaped (pay-as-you-go, tiered, prepaid credits, or hybrid). The unit matters more than the rate, because the unit is what decides whether you can predict the bill.

Two questions decide everything about a usage-based plan: what unit you're metered on, and how the rate is shaped. In our experience the unit matters more than the rate, because the unit is what decides whether you can predict the bill.

On the rate side, there are four shapes you'll see:

Pay-as-you-go. A flat rate times the units you consume. The simplest model, and the least predictable, since nothing smooths a spike.

Tiered / volume pricing. The per-unit rate falls as your volume rises, so the unit gets cheaper at scale. This is the most common shape in mature usage-based products.

Prepaid credits. You buy a bundle of credits up front and draw them down with usage. It bolts budget control onto a usage-based meter, which is why teams that want a known ceiling like it.

Hybrid. A base subscription plus metered usage above a threshold. This is the boring-but-effective shape most vendors land on: a predictable platform fee, with usage layered on top.

For the canonical examples, look at the businesses built on the model. AWS bills per compute-hour and per gigabyte; Twilio bills per message and per minute.

Snowflake bills per compute credit, the OpenAI API per token, Stripe a percentage per transaction, Datadog per host (fun fact: the OpenAI token bill behind a lot of today's AI tools is itself usage-based, so the model gets passed straight through to you). In every case the bill scales with consumption rather than with how many people have a login.

Diagram of the four usage-based pricing shapes branching from a usage-based pricing parent: pay-as-you-go, tiered or volume, prepaid credits, and hybrid.

The part those guides skip is the one a support buyer actually needs: how AI customer service vendors bill, and which of them are genuinely usage-based. We've spent a lot of time inside these pricing pages, and the honest answer is that "usage-based" gets used loosely. Here's the split, with the billable unit each vendor meters on:

Vendor	Pricing model	Billable unit	Can you count it yourself?
My AskAI	Usage-based (per ticket)	Helpdesk chat: every 2 AI replies = 1 credit (~$0.10/ticket). Email: first reply = 1 credit, follow-ups 0.5 (~$0.15/ticket).	Yes — every AI reply shows in your helpdesk export.
Salesforce Agentforce	Usage-based (per conversation)	$2 per conversation the agent engages with.	Mostly — the conversation count is visible.
Aissist	Usage-based (per interaction), capped per resolution	$0.09 per interaction or $0.60 per resolution, whichever is lower.	Partly — what counts as "one interaction" depends on the vendor's instrumentation.
Intercom Fin	Outcome-based (per resolution)	$0.99 per resolved conversation or Procedure handoff.	No — "resolved" is a 24-hour-no-reply heuristic Fin scores.
Zendesk AI (Autoresolve)	Outcome-based (per autoresolve)	An autoresolve that stays closed for 72 hours.	No — a vendor-scored quiet period.
Gorgias Automate	Outcome-based (per automation)	An automation completed with no customer reply.	No — vendor-tagged.

The rates aren't the interesting part of that table. The second column is. The top three meter on a unit you can count in your own data; the bottom three meter on a result the vendor decides counts.

Both get marketed as "you pay for what you get", but they're different models, and the difference shows up on your invoice. Per-resolution pricing (Fin, Zendesk, Gorgias) is the one most often mistaken for usage-based, and it's really outcome-based.

We've linked each vendor's own pricing page so you can check the rates yourself: Fin's pricing, Zendesk's outcome-based pricing post, Aissist's pricing, and Metronome's writeup of Agentforce's $2 per conversation.

Is usage-based pricing good or bad? The honest trade-offs

⚡

TL;DR: Usage-based pricing is fairer when your usage is variable, since you don't pay for idle seats. It's riskier when usage spikes and you can't cap it. A good deal gives you a countable unit, volume discounts as you scale, and a spend cap or alert (the three things we'd tell you to insist on).

Usage-based pricing isn't automatically the right answer, and we're not going to pretend otherwise. So here's the two-sided version.

In its favor: your cost tracks your value, so you're not paying for idle seats in a quiet month (the line that tends to win the CFO over first). The barrier to start is low, since a small amount of usage means a small bill.

It scales with your business instead of forcing you to re-tier every time you add a head. And it lines the vendor up with you, because they earn when you actually use the thing.

Against it: the bill is harder to forecast than a flat subscription. That's the real objection, and it's behind almost every community thread on the topic, from "usage based pricing or subscriptions? what's better?" to "usage-based vs flat monthly rate, stuck on this".

A usage spike becomes a bill spike. The failure mode even has a name (bill shock): the genre of stories where a company wakes up to an invoice an order of magnitude bigger than last month's.

So what does a good usage-based deal look like? Three things make it forecastable: a unit you can count, volume tiers so you know the rate at each band, and a spend cap or alert so the bill can't run away from you. With those in place, a usage-based bill is often more predictable than a per-seat subscription, because you're modeling it off a number you already track.

In AI customer service specifically, here's the rough band for what a fair per-unit rate looks like:

Tier	Per-ticket / per-unit rate	What it usually means
Good value	$0.05 to $0.15 / ticket	Volume-tier usage-based AI support (My AskAI is ~$0.10/ticket on the Scale plan). You pay per AI reply, countable in your export.
Mid	$0.20 to $0.50 / unit	Per-conversation or per-interaction models with a broader unit.
Premium	$0.60 to $1.50 / unit	Usually per-resolution (outcome-based) rather than per-ticket: a different model wearing usage language.
Watch for	Any per-unit rate with no cap	The unit is fine; the missing spend cap is the risk. Ask for an alert or a ceiling.

For the payback frame, a fully-loaded human-handled ticket runs $5 to $12 in B2B SaaS (Zendesk's State of Service, SQM Group benchmarks). Against that, a usage-based AI rate in the good-value band pays for itself fast.

The honest rule on whether usage-based beats a subscription: it wins when your usage is variable or low, and loses when it's high and flat. Whether it saves you money depends on your usage pattern, so treat fairness and savings as two separate questions. Our own pricing is laid out on the pricing page if you want the live numbers.

Three things buyers get wrong about usage-based pricing

⚡

TL;DR: Three traps. Usage-based doesn't have to mean an unpredictable bill (a countable unit, volume tiers, and a cap fix that). Usage-based, consumption-based, and pay-as-you-go aren't identical. And usage-based isn't always cheaper than a subscription: it's cheaper when usage is variable, dearer when it's high and flat.

In our experience walking buyers through these decisions, the same three misconceptions come up almost every time.

Three myth-busters about usage-based pricing: that it means an unpredictable bill, that usage-based equals consumption-based equals pay-as-you-go, and that it is always cheaper than a subscription.

"Usage-based pricing means an unpredictable bill"

This is the big one, and it's a fair worry. Bill shock is a real failure mode, worth taking seriously rather than waving away.

But the unpredictability comes from a plan missing its guardrails rather than from the model itself. Put three things in place and a usage-based bill becomes forecastable: a unit you can count, volume tiers, and a spend cap or alert.

For support, this is easier than it sounds, because ticket volume is one of the most predictable numbers a team has. You already forecast it to plan staffing, so a per-ticket bill rides on that same forecast.

It's worth being concrete about how we handle this at My AskAI, since it's exactly the objection. We price per ticket, and most teams already know roughly how many tickets they get a month. We show an estimated monthly cost after seven days of the trial, and the trial runs a full 30 days with no usage limit, so you can see what a real month costs before paying anything.

The instinct that a flat subscription is "safer" is worth a second look too: a flat fee only really wins when you're paying for a lot of capacity you end up not using.

"Usage-based, consumption-based, and pay-as-you-go all mean the same thing"

They're a family of related models rather than exact synonyms, and the distinctions matter when you're comparing two quotes. Pay-as-you-go is the simplest shape, a flat per-unit rate with no commitment.

Consumption-based usually implies metering a resource you draw down, like compute or storage or credits (it's the framing Orb uses). Usage-based is the umbrella term for all of them, including the tiered and hybrid shapes. Two vendors can both say "usage-based" and bill you on completely different units, which is the thing to check.

"Usage-based is always cheaper than a subscription"

Not necessarily, and I'd push back gently whenever a buyer assumes it. Usage-based wins when your usage is variable or low, since you stop paying for capacity you're not using.

A subscription can win when your usage is high and steady, where a flat negotiated rate beats the list per-unit price. We'd tell you to think of it as a fairness model first; the savings only follow if your usage is the kind that suits it.

There's a flip side that's specific to AI support, and it's the one that matters most. Under usage-based pricing, your cost per resolved ticket falls as your resolution rate climbs, because you're billed on tickets (which stay flat) while the resolutions (the value) go up.

Under outcome-based pricing, the bill rises with every new resolution. So whether it works out cheaper depends on the model as much as the rate, which is the whole argument of our breakdown of per-conversation vs per-resolution pricing, and of the next section.

Usage-based vs subscription, outcome-based, and value-based pricing

⚡

TL;DR: Here's how I'd line them up: subscription pays for access, usage-based pays for inputs you can count, outcome-based pays for results the vendor scores, and value-based sets the price by perceived value. Usage-based and outcome-based look alike on a pricing page, but one meters an input you control and the other a win the vendor defines.

Usage-based pricing only really makes sense next to the models it isn't. Here's the clean comparison (the one I end up sketching on whiteboards most weeks):

Term	Definition	Difference from usage-based pricing
Subscription / SaaS pricing	A recurring flat fee for access.	Charges for access, not consumption. Predictable, but you pay it whether you're busy or idle. Most modern vendors are hybrid: subscription plus usage.
Per-seat pricing	A subscription priced per user.	A flavor of subscription. Scales with headcount, not with what the product does.
Outcome-based pricing	Pay only when the vendor delivers a scored result, like a resolved ticket.	The foil. Outcome-based meters a win the vendor defines; usage-based meters an input you count. Under outcome-based the bill rises as the AI improves; under usage-based the cost per result falls. Full case in What is outcome-based pricing?.
Consumption-based pricing	Metering a resource you draw down (compute, storage, credits).	A near-synonym that leans on a depleting resource. Usage-based is the broader umbrella.
Pay-as-you-go	A flat per-unit rate with no commitment.	The simplest usage-based shape, not a separate model.
Value-based pricing	The buyer's perceived value sets the price, usually via discovery and a quote.	Negotiated, not metered. Usage-based is one way to operationalize value-based, using a usage unit as a proxy for value.

The live four-way choice for anyone evaluating an AI customer service vendor right now is subscription vs usage-based vs outcome-based vs value-based. Almost everything in the category is a hybrid of two of them, and in our experience the pair that trips buyers up most is usage-based and outcome-based.

How does My AskAI use usage-based pricing?

⚡

TL;DR: We charge per ticket. As resolution rate climbs from 40% to 80% (which it does, mostly from work you do), the cost per resolved ticket falls under usage-based and stays flat under outcome-based. TravelJoy went from 24% on Zendesk's AI to 80% on My AskAI: that gap would have cost about $2,000 a month extra on outcome-based pricing.

We made the call to price My AskAI per ticket (usage-based) rather than per resolution, and it's worth explaining why, because the reasoning is the whole argument for the model.

What we charge for

We charge per ticket. In a helpdesk chat channel, every two AI replies count as one credit, which works out to roughly $0.10 per ticket on the Scale plan. In email, the first reply is one credit and each follow-up is half a credit, so about $0.15 per ticket.

The unit is something you can count in your own helpdesk export. There's no 72-hour quiet period to wait out, no 24-hour-no-reply heuristic, no vendor-controlled "resolved" tag.

We pay the model bill on every reply we send, and we charge a thin margin on every reply you send. The maths is symmetrical, and you can audit it.

Why per ticket and not per resolution

Per-resolution pricing sounds safer: pay only when the AI works. But "works" is a definition the vendor sets and scores, and most of the lift in an AI's resolution rate comes from your work rather than the vendor's.

The customer does most of the work that lifts resolution rate

The things that move an AI's resolution rate from 40% to 80% in production, in our experience across rollouts, are:

Keeping the knowledge base up to date, adding new articles and fixing the stale ones.

Connecting tools and APIs: helpdesk integration, live user data, order lookups, refund flows.

Writing and tuning guidance: when to escalate, when to suggest an upgrade, what tone to use.

Setting up triage and tagging: which intents the AI handles, which always go to a human.

Running a weekly QA loop that closes the questions the AI couldn't answer (in our product, Self-Learning surfaces the candidates and the Insights to Custom Answers loop closes them).

The vendor's contribution is real (model selection, retrieval architecture, the training pipeline), but it's the smaller share. On outcome-based pricing, every additional resolution your work enabled gets billed by the vendor at the per-resolution rate. On usage-based pricing, you capture the full upside of your own work, and the cost per resolved ticket falls as your resolution rate climbs.

Two-line chart comparing cost per resolved ticket as AI resolution rate climbs from 40 percent to 80 percent. The outcome-based line stays flat at one dollar fifty per resolved ticket. The usage-based line falls from twenty-five cents to twelve cents per resolved ticket, so the customer captures the improvement upside.

(A note on what "resolved" means here, since this whole post is about honest counting: we count a conversation as resolved when the AI handled it without escalating to a human. Escalation is deliberately easy, so the customer can always reach a person).

The numbers: TravelJoy

TravelJoy moved from Zendesk's own AI, which was resolving 24% of their tickets, to My AskAI, now at 80% (it was 76% at the time of the case study). Alan Pugh, their Head of Customer Service, put it like this:

"You're beating Zendesk's AI agent 76% to 24% on AI deflection. Huge."

A lift from 24% to 76% on TravelJoy's ~2,500 monthly tickets is roughly 1,300 extra resolved tickets every month. On outcome-based pricing at Zendesk's $1.50 per autoresolve, those extra resolutions would have added around $2,000 a month to the bill, money TravelJoy would have paid for resolutions their own work made possible: connecting their website and Notion as knowledge sources, closing the questions the AI couldn't answer via Insights, writing guidance, and setting up tagging. On our usage-based pricing, that same ticket volume costs the same as it did before they switched.

The numbers: Edel Optics

Edel Optics is the cleaner version of the same story. They went from roughly 25% resolution to around 79% after adding the User Data API themselves, so the AI could see order status, returns, and refunds, which lifted resolution by around 50 points overnight.

With about 4,000 tickets a month and roughly 3,000 now resolved by the AI, that's around 2,000 extra resolved tickets a month, from one piece of engineering Edel Optics did on their side. On outcome-based pricing at $1.50 per resolution, that's roughly $3,000 a month in extra billing for work the vendor didn't do. On usage-based pricing, the same volume costs the same, and the upside is theirs.

The honest limit

Usage-based pricing has a real trade-off, and we won't pretend otherwise: you also pay for tickets the AI tried and failed on. There's no "only pay when it works" cushion.

What you get in return is predictability you control (you can model the spend in a spreadsheet off a number you already track) and alignment, because every dollar of improvement you engineer stays with you instead of inflating a per-resolution bill. As a backstop on the predictability point, we put a "60% AI resolution rate or your money back" guarantee on the pricing page.

For the full worked example, at 10,000 tickets a month and a 75% resolution rate, our Scale plan comes in around $1,299/month, versus roughly $7,425 for Intercom Fin, $11,250 for Zendesk AI, and $6,750 for Gorgias Automate. We walk through the maths in our pricing explainer; the 5x to 8x gap exists because they charge per resolution and we charge per ticket.

FAQs

What is usage-based pricing in simple terms?

Usage-based pricing is a billing model where you pay in proportion to how much you actually use a product: per API call, per gigabyte, per message, or per support ticket, rather than a fixed seat or subscription fee. The more you use, the more you pay; the less you use, the less you pay. It's the model behind AWS, Twilio, Snowflake, and most modern AI tools (it's how we bill at My AskAI too).

What is an example of usage-based pricing?

The classic examples are infrastructure businesses: AWS (per compute-hour and per gigabyte), Twilio (per message and per minute), Snowflake (per compute credit), the OpenAI API (per token), and Stripe (a percentage per transaction). In AI customer service, we price per ticket, where every two AI replies is one credit, about $0.10 a ticket. It's the same principle applied to support volume instead of compute.

What are the different usage-based pricing models?

There are four shapes worth knowing: pay-as-you-go (a flat per-unit rate, no commitment), tiered or volume pricing (the per-unit rate falls as volume rises), prepaid credits (buy a bundle up front and draw it down), and hybrid (a base subscription plus metered usage above a threshold). Hybrid is the most common modern shape; prepaid credits give you the most budget control, which is why we use them.

What's the difference between usage-based and subscription pricing?

A subscription charges a recurring flat fee for access, whether you use the product heavily or barely at all. Usage-based charges for actual consumption, so the bill tracks how much you use. Subscription is more predictable; usage-based is fairer when your usage is variable. Most modern vendors blend the two, with a base subscription plus usage on top (we sit on the usage side of that blend).

What's the difference between usage-based and outcome-based pricing?

Usage-based pricing charges per unit of input you can count yourself, like a ticket, an API call, or a token. Outcome-based pricing charges per result the vendor scores as a win, like a resolved ticket. Two practical differences matter: under usage-based you can audit the unit in your own data, and the cost per resolved ticket falls as your resolution rate climbs. Under outcome-based, the vendor controls the definition of the unit, and the cost per resolved ticket stays flat as the rate climbs, so you pay the vendor for improvements your own work enabled. We dig into it in the outcome-based pricing post.

Is usage-based the same as consumption-based or pay-as-you-go?

They're closely related, but not identical. Pay-as-you-go is the simplest usage-based shape, a flat per-unit rate with no commitment. Consumption-based usually means metering a resource you draw down, like compute or storage. Usage-based is the umbrella term for all of them, including tiered and hybrid models. When you're comparing two "usage-based" quotes, check what unit each one actually meters; we've watched buyers line up a per-ticket rate against a per-token one and realize they're not measuring the same thing at all.

Is usage-based pricing cheaper than a subscription?

It depends on how variable your usage is. Usage-based is cheaper when your usage is low or spiky, since you stop paying for idle capacity. A subscription can be cheaper when your usage is high and steady, where a flat negotiated rate beats the list per-unit price. The honest framing we'd give you: usage-based is about fairness first, and savings second. For support specifically, it tends to win because ticket volume is seasonal, so you don't want to pay peak rates in your quiet months.

How do I make a usage-based bill predictable?

Three things, really. First, make sure the unit is one you can count yourself and already forecast: for support, that's ticket volume, which you track for staffing anyway. Second, look for volume tiers so you know the rate at each band. Third, ask for a spend cap or an alert so a spike can't surprise you. At My AskAI we also show an estimated monthly cost after seven days of the trial, and the trial runs a full 30 days with no limit, so you see what a real month costs before paying.

Why are SaaS companies shifting to usage-based pricing?

Because it lines price up with value and lowers the barrier to adoption. A customer can start small and grow the bill as they grow the usage, instead of committing to a big seat license up front. For AI products specifically, the underlying cost (the model bill) is itself usage-based, so usage-based pricing passes that structure through cleanly. That's a big part of why we went this way: the trade-off vendors take on is revenue that's harder to forecast, which is why many use a hybrid base-plus-usage shape.

Which AI customer service vendors use usage-based pricing?

Genuinely usage-based, metered on a unit you can count: My AskAI charges per ticket (~$0.10), Salesforce Agentforce charges $2 per conversation, and Aissist charges per interaction. Outcome-based, metered on a vendor-scored result even though they're sometimes lumped in with usage-based: Intercom Fin at $0.99 per resolution, Zendesk Autoresolve, and Gorgias Automate. The tell is whether you can count the billable unit in your own data, or whether the vendor decides what counts.

How does My AskAI's usage-based pricing work?

We charge per ticket. In helpdesk chat, every two AI replies is one credit, about $0.10 a ticket. In email, the first reply is one credit and follow-ups are half a credit, about $0.15. The Scale plan is $499/month for 2,000 credits with $0.10 overage. You can count every billable reply in your helpdesk export, and there's a "60% AI resolution rate or your money back" guarantee as a backstop.

Does usage-based pricing punish you for growing?

Only if the unit you're billed on grows faster than the value you get from it. For AI support, the unit is tickets and the value is resolutions, and as your resolution rate climbs (mostly from your own work), your cost per resolved ticket actually falls, since you're billed on the flat ticket count while resolutions rise. Done right, usage-based rewards improvement instead of penalizing it. The thing we'd tell you to avoid is a model where the billable unit balloons with success and there's no cap.

When should you choose usage-based over outcome-based pricing?

Choose usage-based when you want to count the billable unit yourself and keep the upside of your own improvement work, which for AI customer service is most teams, since your knowledge base, API connections, and guidance do most of the lift. Outcome-based makes sense only in the narrow cases where the win is cleanly attributable to the vendor, you can audit their definition of it, and the vendor genuinely drives most of the result. In support, in our experience, those conditions rarely all hold at once.

What is Usage-Based Pricing? Definition, Examples, and How AI Vendors Bill For It