We have to be accurate, right? Because "Tiered pricing" is one phrase doing the work of at least four different billing models that we support.

They look identical (sometimes) on a pricing page but they're rather different in practice.

This guide breaks down the four, with the invoice math, which companies use them, and the trade-offs involved.

What is tiered pricing?

Tiered pricing is any model where the rate changes depending on how much a customer buys or uses.

More usage = different price.

That's the whole idea, and it's where I stop agreeing with it too. Because how does the price change is a rather important question. For example:

1. Does the customer pay the new rate only on the units inside each tier?

2. Does the customer pay the new rate on the whole volume?

3. Is there a flat fee for landing somewhere in a band?

Each answer lands you somewhere else with real money in between.

Here's the map before we go deep:

Feature-based tiers

Feature-based tiers are the pricing page you've seen a thousand times with three columns, ascending prices, more checkmarks as you go right. The thing that changes between tiers is the package, not a usage rate, e.g., which features you get, what the limits are, whether you get SSO and a real SLA.

I really like Vercel's version here. Hobby is $0 for personal projects. Pro is $20 per developer seat, and that seat comes with $20 of usage credit, 1 TB of fast data transfer, and 10 million edge requests included. Enterprise is custom, and the thing you're actually buying there is SAML, audit logs, and a support contract, not a better per-unit rate.

Vercel's Pro plan already mixes two models with feature packaging on the outside, usage metering underneath (the $20 credit, then overages bit).

We've often said that hybrid is the default now, not the exception. Pure feature tiers with no metering are getting rare, because the cost of serving a customer stopped being flat the moment inference entered the bill.

So feature-based tiers are a packaging decision.

Now let's talk about metered usage…

Progressive tiered pricing

Progressive tiered pricing applies each tier's rate only to the units that fall inside that tier. The customer fills tier one at tier one's price, fills tier two at tier two's price, and the invoice is the sum of those slices. This is the model most people mean when they say "volume discount".

This is how it looks like in Solvimon:

Twilio prices conversations this way, with volume discounts on higher MAUs. You don't get the cheap rate retroactively on everything. You get it on the units past the threshold.

Another example (indicative, not real Twilio prices): API calls priced per 1,000:

A customer making 250,000 calls pays:

• First 100k: 100 units x $2.00 = $200

• Next 150k: 150 units x $1.50 = $225

• Total: $425

Because every additional call costs something, it never costs more to use more. That predictability is why progressive tiered is the safe default for metered products, and why it's what we call "progressive tiered pricing".

Here, the customer can reason about their own bill, which matters more than people think when the buyer is now sometimes an agent doing a cost estimate before it commits.

Top-tiered (volume) pricing

Top-tiered pricing takes the customer's entire volume and prices all of it at the rate of whichever tier they land in. The whole amount decides the one rate.

Here, a customer making 250,000 calls lands in tier 2, so every one of those 250k calls is priced at $1.50:

• 250 units x $1.50 = $375

Same usage, same table, $50 cheaper than progressive.

Watch the boundary at 100k though because it can really get weird here:

• 99,000 calls, all at the tier-1 rate: 99 x $2.00 = $198

• 101,000 calls, all at the tier-2 rate: 101 x $1.50 = $151.50

The customer who used more paid less.

This is how it looks like in Solvimon:

Top-tiered pricing creates cliffs where crossing a threshold drops the whole bill, and savvy customers will sit just past a boundary on purpose. Used well, that's a deliberate incentive to consolidate volume with you.

ElevenLabs' "extra minutes" follows this pattern

This is far from my favourite to use but it has its place, mostly in committed-use contracts and wholesale deals where the whole-volume rate is the negotiation.

Stairstep pricing

Stairstep pricing drops the per-unit idea entirely. The customer pays one flat fee for landing anywhere inside a band. Use a little or a lot within the band, same price. Cross into the next band, new flat price.

Again, ElevenLabs runs textbook stairstep. The plans are bands of monthly credits, each at a fixed price, and your bill is the band you're in, not the credits you actually burned:

A customer who uses 60,000 credits is on Creator and pays $22. A customer who uses 99,000 credits is also on Creator and also pays $22. The exact usage inside the band is invisible to the invoice.

This is how it looks like in Solvimon:

Stairstep is simple to forecast and simple to sell, which is why most subscription SaaS lives here. The cost is the dead zone. A customer using 31,000 credits jumps a whole band to pay for capacity they won't touch, and a customer creeping toward 100,000 has every reason to throttle their own usage to avoid the next step. You're either leaving the band's headroom on the table or pushing customers to use your product less. Keep the bands narrow (a 20 to 30 percent jump between steps) and that tension stays manageable.

How to choose

Unsatisfying, but pick the model that matches how your cost behaves and how your customer reasons about value.

• If your cost-to-serve is roughly flat per customer and the differences are about features and support, feature-based tiers carry it.

• If you have a real marginal cost per unit (inference, storage, messages, compute) and you want a bill the customer can predict, progressive tiered is the default.

• If your strategy is to reward consolidation and you can stomach boundary cliffs, top-tiered does that, usually inside a contract.

• If you're selling capacity in chunks and forecasting matters more than precision, stairstep is the cleanest.

Most real pricing is two or three of these stacked in a hybrid system:

1. A flat platform fee

2. + included usage

3. + progressive overage tiers

4. + a feature gate on the enterprise plan.

Do make sure your system supports all of these together (many don't) - or come talk to us at Solvimon!

The advantages and the costs

The case for tiered pricing in any form: you segment without running four separate products, you give customers a path to grow their spend as they grow their usage, and you shape perceived value by what sits in each tier. That's why it became the default.

The costs are operational, and they're the same costs every time. Multiple tiers mean more states to bill correctly, more edge cases at boundaries, more proration when someone moves mid-cycle. Too many tiers and customers can't choose (less of a problem in sales-led motions, where a human walks them through it). And every tier model encodes assumptions about usage that stop being true the moment your product changes. Which it will.

That last one is the real tax. Pricing isn't a thing you set. It's a thing you keep editing, e.g., the volume-tier breakpoint you guessed at launch, the overage rate you need to test against churn, the new credit type your AI feature needs. Vercel ships pricing and packaging changes constantly. The question isn't whether you'll change your tiers. It's how long a change takes once you decide.

Implementing tiered pricing in Solvimon

Solvimon supports all four models as native pricing methods, not as workarounds. Flat and fixed, progressive tiered, top-tiered (volume), and stairstep are each a configurable price on a plan, and pricing rules and combined usage volumes let you stack them on one subscription.

Feature-based packaging comes from plans, features, and entitlements layered on top.

Because Solvimon can also operate headless, you can build this with our MCP server by simply describing what you want.

FAQ

What's the difference between progressive tiered and top-tiered pricing?

Progressive tiered prices each tier's units at that tier's rate and sums them, so a customer's bill is a stack of slices. Top-tiered takes the whole volume and prices all of it at the single rate of the tier the total lands in. Same tier table, different invoice, and top-tiered creates boundary cliffs where using slightly more can cost less.

Is stairstep pricing the same as a subscription?

Close. Stairstep charges one flat fee for landing anywhere inside a usage band, which is how most subscription plans work. The defining trait is that exact usage inside the band doesn't change the price, unlike progressive or top-tiered pricing, which both still scale with units.

Are feature-based tiers a usage-based model?

No. Feature-based tiers change the package (features, limits, support), not a per-unit rate. They're a packaging decision. They're often combined with a usage model underneath, e.g., a Pro plan with included usage and then metered overages, which is the common hybrid today.

Which tiered pricing model is best for an AI product?

It depends on cost behavior. If you have a real marginal cost per unit (inference, tokens, minutes), progressive tiered gives customers a predictable bill that scales with use. Many AI products combine a stairstep base plan (included credits) with progressive overage tiers, so they get clean forecasting plus fair scaling.

How often will I need to change my tiers?

More often than you expect. Breakpoints, overage rates, and new credit types all get revised as the product and the market move. The constraint that actually hurts is how long a change takes to ship, which is a function of whether your billing system requires a human in a dashboard or exposes pricing as something you can edit programmatically.

Related reading from our docs

• Progressive tiered pricing

• Top-tiered pricing

• Stairstep pricing

• Flat and fixed pricing

• Pricing rules

• Combining usage volumes