Tiered Pricing: A Practical Guide for SaaS

You have a few competitor pricing pages open and a three-column layout half copied into your draft. Most guides treat naming Starter, Pro and Team, then filling in the checkmarks, as the hard part.

But the columns don't decide what a customer pays. Tiered pricing also covers per-unit rates that change as usage grows, and the same band table can produce two very different invoices for the same usage.

Confuse those two calculations and the mistake shows up after launch, when a customer crosses a band and their bill drops in a way you never priced for.

Starter can also quietly take sales from Pro, or a later plan change can leave you rebuilding how you charge.

This guide walks through which kind of tiering you are setting up, how the bill is calculated, and what it takes to charge buyers worldwide for those plans.

Which kind of tiered pricing are you setting up?

Tiered pricing can mean the plans buyers choose from or the rates you use to calculate their bill. Those are two separate decisions.

• Packaging tiers give buyers different features, limits or allowances when they choose Pro over Starter. Starter might include core features and fewer API calls, while Pro adds advanced features and more calls.
• Billing tiers change the per-call price as a customer’s usage grows. Graduated billing applies each band’s rate to calls within it, while volume billing applies the reached band’s rate to all calls.

A bigger allowance doesn’t automatically mean tiered billing. If Starter and Pro include different amounts of API usage but charge the same rate for every extra call, you have tiered packages with one overage rate.

Likewise, charging per seat tells you what you’re counting, but not whether each seat gets cheaper or more expensive as the team grows.

You can use both together by offering a Pro plan with advanced features and billing its API calls through quantity bands. The plan sets access and allowances, while the bands determine the usage charge.

Separate those choices before you set prices. Plans with different features or allowances are packaging, while a unit price that changes with quantity needs band-based billing. If neither applies, one flat price or one usage rate does the job.

How is a tiered bill calculated?

Use the band table below to bill 60 units in two different ways. Neither total includes flat fees or tax.

Graduated pricing

At 60 units, you fill each band in turn. Each unit is billed at the rate for the band it falls into:

• First 10 units × $20 = $200.
• Next 20 units × $10 = $200.
• Remaining 30 units × $5 = $150.

The total is $550, and the lower rate only applies to units that fall in the cheaper band.

Volume pricing

60 falls in the $5 band, so every unit bills at $5. That gives you 60 × $5 = $300.

The same table and quantity produce a $550 bill with graduated pricing and a $300 bill with volume pricing. Volume pricing costs this customer $250 less, which means you give up that revenue by choosing it.

What happens when a customer crosses a tier?

With volume pricing, 30 units cost 30 × $10 = $300, but at 31 units the bill drops to 31 × $5 = $155. With graduated pricing, it rises from $400 to $405 instead.

Under volume pricing, every quantity from 16 to 30 costs more than 31 units. Even 16 × $10 = $160 is more than $155, so customers have a reason to pad their usage.

Check the totals on both sides of each boundary. If more usage produces a smaller bill, switch to graduated pricing or adjust the band rates so totals keep rising.

Moving into a new band changes the rate, not the plan. Switching plans mid-cycle needs rules for when access changes and how proration adjusts the charge for unused time in the billing period.

Which tiered pricing structure fits your product?

Use feature tiers when customers need different capabilities, seats when value grows with team size, and usage or credits when it grows with consumption.

Feature-based tiers

A team may need permissions and admin controls even if it uses less of the product than an individual. Those controls give teams a reason to upgrade that has nothing to do with usage.

Your entry plan should let an individual do enough to see the value, such as completing the main task. The higher plan adds the controls a team needs. Check that your feature list follows that split.

Per-seat tiers

Seats fit collaboration products where adding participants makes the product more useful. Before publishing your price, decide whether guests, read-only viewers and inactive accounts count as seats, because those rules determine what lands on the invoice.

An AI user’s compute consumption can change while the seat count stays the same. If cost per active user grows faster than seat revenue, add metered usage or credits.

Usage, credit and hybrid tiers

Usage pricing charges for tokens, API calls or generations. With postpaid billing, you collect after paying the serving cost, so a failed charge leaves that compute unpaid. Prepaid credits collect before the customer consumes them.

Auto-refill buys more credits when the balance falls to a set threshold, so customers can keep using the product.

A hybrid plan might charge a base monthly subscription with a generation allowance, then one rate for each extra generation. If you offer quantity discounts on that extra usage, use the graduated or volume calculation described above.

A feature plan can also charge per seat for team size and meter usage for consumption. Each charge covers a different source of value.

How to design your pricing tiers

Borrow a price from another pricing page and you can end up cutting allowances to protect margin or adding features to justify the charge. Neither tells you whether the package fits your customers.

I would keep the price column blank until you know who each tier serves, what you count, what it includes and caps, and what it costs to serve. Set the price once you know what you’re asking customers to pay for.

1. Map each customer group to a tier

“Small business” and “enterprise” describe customer size, not the job the customer needs to finish. A small team with an advanced use case may need a different package from a department rolling out the core product across an organization.

You don’t need a large research study to find those differences. Start with the records you already keep and look for recurring jobs and requirements:

• Signup records show what customers say they came to do. Group similar intended uses together.
• Support conversations reveal requirements. Prioritize requests that block the job, and keep optional improvements as evidence for features, messaging or add-ons.
• Current usage shows how customers actually work. Look for individual, team-wide and organization-wide patterns.

Compare those groups by the outcome they need and the requirements for getting there. Customers doing the same job with the same requirements belong in the same package.

For each proposed tier, write one sentence that says who buys it, what prompts the purchase and what they need to accomplish. Two neighbouring tiers might read:

• Starter serves people adopting the product to complete the core job independently.
• Team serves groups moving from individual work to a shared workflow so they can complete that job together.

Those descriptions give each package a distinct reason to buy. They also give you a way to check feature requests before adding more plans.

Different priorities don’t necessarily call for another pricing column. If customers need the same package but value different benefits, change the messaging instead.

An optional requirement shared across several groups belongs in an add-on. That lets customers upgrade when they need the broader package, rather than move to a higher plan for one extra capability.

I would remove any draft tier whose customer description fits the tier beside it without changing a word. Merge those two into one package.

2. Pick the unit you charge for

Your invoice unit doesn’t have to match your infrastructure bill, so you might charge for a resolved case while tracking tokens and storage internally. Customers pay for an outcome they understand, and you track the resources it takes to deliver it.

Whether you charge per seat, project, API call or credit, pick a unit customers can estimate and your product can count reliably. Check it against these requirements:

• Customers understand it. They can explain what counts without learning how your infrastructure works.
• Customers can forecast it. Their expected activity gives them a reasonable estimate of the bill.
• Your product can measure it. The count shown to the customer matches the count used for billing.

A credit balance means little to a customer unless you show which actions spend credits and how many each action uses. A pack description could read “500 credits, enough for 50 image generations at 10 credits each.”

Put that conversion next to every pack price and record the resource cost of each credit-spending action, so you can check whether the allowance is affordable.

Before setting allowances, define exactly what counts, including whether failed API requests count and when a case qualifies as resolved. Those definitions tell customers what they’re paying for.

If you count only successful requests, write the charging rule as “completed API calls”. Keep it separate from the included allowance, so you can change plan limits later without changing what counts as a billable action.

3. Allocate features and limits

Build each package around the workflow its customer needs to finish. If the plan promises reporting customers can share outside your app, report creation and export belong together.

Charging another upgrade for export leaves that package unable to finish the job you sold it for. Include both features or narrow the promise to what customers can actually do.

Go through your draft comparison table and check each plan against these requirements:

• Complete the promised job using only the features in that plan, without asking support to unlock anything.
• Check that every included feature works without a dependency reserved for the next plan.
• Compare the allowance with the attempts needed to produce a usable result.

For an illustrative generation allowance, customers who make three attempts per usable result need 3 × 20 = 60 generations to produce 20 results a month. Use current usage to get the attempts-per-result figure before setting the cap.

An allowance that runs out before customers finish a workflow can hurt trial-to-paid conversion, while one that covers the workflow leaves room for upgrades when their volume grows.

A higher tier earns its price by offering more capacity or a capability that its customer group needs. A longer feature list alone doesn’t explain why someone should upgrade.

Write the reason to upgrade beside every difference in your comparison table. If an extra feature or larger limit doesn’t connect to the higher tier’s customer needs, leave it out.

4. Check the cost to serve each tier

A plan can work at average usage and lose money when a customer uses the full allowance. That allowance is part of what you sell, so its full cost needs to be in your calculation.

For a generation allowance, multiply the tokens or compute used per generation by the applicable model or cloud provider rate, then multiply by the full included allowance. Add support effort and payment fees to calculate what serving that customer costs.

For credits, calculate the cost of the full balance as if every credit went toward the action with the highest delivery cost per credit consumed. Actions can cost different amounts to deliver even when they spend the same number of credits.

If that workload loses money at the proposed pack price, raise that action’s credit price or reduce the pack size.

A tier can cover its own compute without covering its share of the business, so keep two cost views:

• Direct variable costs measure the cost one more customer adds.
• Fully allocated costs also include a share of common business expenses, using a stated allocation basis.

Record the assumptions beside each estimate:

• Workload mix, including which activities consume the allowance and the resources each requires.
• Supplier rates used to turn that consumption into a cost.
• Support and shared-cost allocation, including how you assigned each amount to the tier.

Those records let you reproduce the calculation rather than rebuild it from memory. Run it again whenever a provider changes its rates.

5. Set prices and plan upgrade and downgrade paths

Your cost estimate sets the floor, while the package’s value to its customer group gives you a reason to charge above it. Check each price gap against what the higher package adds and what it costs to serve at full allowance.

Change one thing per test, such as the price, allowance or plan description, and log the full package offered at each price. Track the share of new buyers choosing Pro alongside their trial-to-paid conversion to distinguish a more attractive offer from one that gets interest without converting.

For an upgrade, you need to make two decisions:

• Access timing determines whether added features become available immediately or at renewal.
• Charge timing determines whether you charge for the remaining period now or apply the higher price at renewal.

Proration adjusts the charge for the time spent on the new plan within the billing period. Moving from a $20 plan to a $50 plan halfway through the month, for example, means about $15 due now, calculated as the $30 difference × half the period, then $50 at renewal.

Show both the charge and when access changes before the customer confirms.

For downgrades, I would default to the next renewal so customers keep what they paid for until the period ends. Explain what happens to stored work separately from their permission to view, edit, create or run it.

Use a message such as “Your existing projects remain viewable. Creating new projects is paused while you exceed Starter’s project limit.” Clear terms help prevent “why did I lose my projects” tickets and stop downgrades from turning into cancellations.

Grandfathering means current subscribers keep their old price. Editing a product’s price in Creem leaves existing subscribers on their previous price unless you move them.

If you decide to move them, publish the renewal date when the new price takes effect and tell those subscribers before that renewal.

What does a three-tier lineup look like?

GitLab’s lineup is a useful reference because each plan speaks to a different buyer:

1. Free is for one person working on their own projects.
2. Premium serves a scaling organization that wants better productivity and collaboration.
3. Ultimate is built for enterprises that have to meet security and compliance requirements.

Each higher plan gives that buyer a reason to pay more, not just a more expensive label.

Compare that with small, medium and large versions of the same feature list. If quantity is the only difference, buyers pick the lowest-priced plan that covers their volume.

If quantity is all that separates your plans, use usage bands within one plan instead of adding columns. The bill grows with use, and the lineup stays short.

Three plans are a starting point. Before you publish, check whether you can name a third customer group whose needs the other two plans don’t cover. If you can’t, two tiers or a flat price is enough.

A filler plan gives customers who need the same package two near-identical columns to compare. That hesitation can lower pricing-page conversion, so merge it into the plan serving the same customers. Keep only the columns that meet a need the other plans don’t cover.

Where do tiered pricing models go wrong?

Tiers go wrong when customers have no reason to upgrade, charges don’t track costs, or buyers can’t tell what a plan or price change means for them.

1. Too many plans serve the same buyer

Extra columns confuse buyers when they don’t cover a need the other plans miss, so merge any plan whose buyer you cannot describe separately.

2. Starter eats Pro sales

Starter eats into Pro sales when Pro’s intended buyer can do the whole job on Starter, so watch the share of new customers choosing Pro. Give Pro a higher usage allowance or a team feature that its buyer needs and Starter’s buyer doesn’t.

3. The entry plan blocks the core task

Customers can’t see the product’s value if the entry plan stops them completing its core task. Keep that task usable and tie upgrades to expanded needs, so customers can see the value before deciding to pay more.

4. Seats leave compute uncapped

Seats don’t cap compute, so a seat-priced AI plan needs a usage cap, meter or credits once heavy users start eating into its margin.

5. Checkout adds unexplained tax

A tax-exclusive plan price won’t match the tax-inclusive checkout total. Put “Tax added at checkout” or “Tax included” beside the price and keep the purchase flow consistent.

6. New prices leave renewal terms unclear

Before announcing new prices, decide which current prices stay and say when the new renewal prices apply. Leaving those terms unclear can increase churn at renewal.

How do you know your tiers are working?

Moving subscribers from a retired plan onto Pro can make upgrades look strong without showing demand for Pro’s added value. If those subscribers leave soon after, check why they moved and what they told support before changing the offer.

I would call a tier healthy when buyers choose it, keep paying and pay more than they cost to serve. Check that against these measures:

• Customer counts and conversion by tier show which packages buyers select. You don’t need an even split across plans.
• Upgrade and downgrade rates become useful when you tag each move with its reason, such as increased usage or a new capability.
• Customer churn and revenue churn should be read together per tier. Losing many small accounts and losing one large account call for different fixes.
• Failed renewals sit beside churn by tier, so payment failures are not read as rejection of the plan.
• Plan-related support tickets expose confusing limits, charges and switches. Use recurring questions to revise the pricing copy or confirmation message customers misunderstood.
• Margin per tier tests your original cost assumptions against actual usage and support costs. Adjust the package if customers consistently cost more to serve than expected.

Group subscribers by the plan lineup they signed up under and the terms that applied when they switched plans, then compare the groups at the same number of months after signup. That keeps older prices from muddying the numbers for the new lineup.

What it takes to charge tiered plans worldwide

A successful checkout proves you can take a payment. Charging tiered plans worldwide also means making sure every invoice matches what you sold and a legal seller answers for the tax on it.

Before launch, take a test customer through a full billing cycle on each plan:

• Subscriptions and seats produce the expected renewal invoice for the billing cycle and billable quantity.
• Usage invoices show the included allowance used and bill only the overage.
• Credit balances drop by the amount consumed and rise by the amount bought.
• Plan switches apply your chosen effective date and proration, with access changing when promised.
• Failed renewals enter dunning, payment-recovery attempts such as automatic retries, while customers retain the access you chose for the unpaid period.

The same Pro plan sold to buyers in two countries can have different tax lines on the invoices. The plan name does not change that, so test the tax treatment alongside the subscription charge.

A processor moves the money and leaves you as the seller. I would consider handing that role to a merchant of record when someone on the team first has to register for VAT or sales tax and file a return.

Before you choose a provider, ask it:

• Whose name appears as the seller on the buyer’s invoice?
• Who answers a chargeback?
• Which transactions and jurisdictions does it cover?
• Who collects and remits the tax?
• Who handles refunds and payouts?

Charging your tiers worldwide with Creem as the seller of record

Once you have set the tiers and checked that band totals increase at every boundary, the remaining decision is who sells those plans.

If your buyers are in one country and your team already files its own sales tax, a processor may be enough. If you sell subscriptions, seats, usage or credits across countries, compare merchants of record on the billing models they support as well as their role as the seller.

Creem handles subscriptions, seat billing, usage meters and prepaid credit wallets with auto-refill. It is also the seller on every sale, issuing invoices and collecting and remitting tax for buyers in 190+ countries.

Those billing models share the same account, so you can add a meter or credit pack to a tier without wiring in another billing tool.

The rate is 3.9% + 40¢ per successful transaction, charged on the order total including tax, and it covers tax compliance and invoices. A $100.00 sale with no tax leaves $95.70 before payout fees.

When your tiers are ready to sell, try Creem and start account onboarding, so the transaction tax on those plans sits with us instead of your team.