The short answer: choose the smallest structure that explains your offer without forcing unlike customers into the same deal. A flat rate works when buyers want roughly the same product and create similar value and cost. Package tiers work when real customer segments need different entitlements. Quantity tiers work when the price per unit should change as volume grows. You can combine them, but every extra rule creates another question the buyer must answer.
Founders often treat flat rate and tiered pricing as opposite choices. Billing systems use those words more precisely, and the distinction matters.
Stripe defines flat rate as a customer choosing a service tier and paying a fixed amount. That means a company can offer Basic, Starter, and Enterprise plans while each plan still uses flat-rate billing. In Stripe's billing definition, tiered pricing means the unit cost changes with quantity or usage.[1][2]
So there are two decisions hiding inside one question:
- Do you need one package or several packages for different customer segments?
- Within a package, should the price stay fixed or change with quantity?
Separating those decisions prevents a pricing page with three plans, five usage bands, exceptions for every large account, and no obvious choice.
The four structures founders usually mean
| Structure | What changes the bill? | Best fit | Main risk |
|---|---|---|---|
| One flat package | Nothing inside the billing period | One clear job, narrow customer range, predictable delivery | Light and heavy accounts pay the same |
| Multiple flat-rate packages | The plan the buyer selects | Distinct segments need different limits, features, or support | Arbitrary feature gates confuse buyers |
| Volume tiers | Total quantity determines one unit price for the whole quantity | Unit economics or discount expectations change at scale | A threshold can create a surprising price jump |
| Graduated tiers | Each quantity band has its own unit price | Higher volume should receive a lower marginal rate | The invoice takes more work to explain |
Chargebee makes a similar distinction. Its flat-fee model has a fixed recurring charge with no quantity. Its tiered model prices successive quantity ranges, while its volume model applies the rate from the customer's total-quantity range.[5]
This guide covers package structure and tier calculation. If you are deciding whether to charge by seats or usage, use the seat-based vs usage-based pricing guide. If you are deciding whether to display prices at all, use the public pricing vs contact sales guide.
Choose a flat rate when simplicity matches the product
A flat rate is not the beginner option. It is the honest option when one price covers a repeatable scope and the customer base is not split into materially different groups.
Start with one flat package when:
- most customers buy the product for the same job;
- account size does not create a large difference in value or delivery cost;
- buyers struggle to forecast a usage unit;
- the sales team keeps recommending the same configuration;
- a second package would exist only to make the first one look cheaper.
Flat pricing gives the buyer a short explanation. They know what the product costs and what the package includes. The buyer gets a predictable bill, and the company has fewer calculations to explain.
Flat rate can still support monthly and annual options. Stripe's setup documentation shows multiple flat-rate products, each with separate monthly and yearly prices.[2] Billing interval is a separate choice from package structure.
Add package tiers when customer segments are real
Package tiers should describe customer differences that already exist. They should not invent differences to fill a pricing table.
Stripe's packaging guide says tiers should map to real customer segments with real needs. It also separates pricing from packaging. Pricing defines the unit and levels. Packaging bundles features, limits, and entitlements into plans.[4]
Add package tiers when at least two groups differ in ways the buyer can recognize:
- one group needs governance, security, or procurement support;
- one group needs a higher limit because its workflow is larger;
- one group needs collaboration while another works alone;
- one group needs service or implementation that the lower segment does not;
- the product has a clear progression from first use to wider deployment.
A tier earns its place when the buyer can finish this sentence: "We need this plan because..." If the answer is a list of small feature differences, the packages may reflect your roadmap rather than the customer's buying logic.
Write one sentence for the buyer, job, limit, service level, and upgrade trigger of each plan. If two plans have the same buyer and job, merge them or make the boundary concrete.
Use quantity tiers when the unit price should change with scale
Quantity tiers answer a different question. They decide how the unit price behaves when volume grows.
Stripe recommends tiered billing when quantity or usage needs non-linear pricing. It supports both volume and graduated calculations, and either model can include a flat amount.[3]
Volume pricing
With volume pricing, the customer reaches a quantity band and that band's unit rate applies to the full quantity. This works when scale justifies a different rate across the whole account. The tradeoff is the threshold. A buyer may see an abrupt change when one extra unit moves the account into another band.
Graduated pricing
With graduated pricing, the first units keep the first-tier rate and only the next units receive the next-tier rate. The total changes more smoothly, but buyers need a clear calculation example.
Stairstep packages
Chargebee also documents stairstep pricing. A quantity range receives a flat amount instead of a per-unit rate.[5] This can work when buyers think in capacity bands, but usage inside a band does not need its own line-item calculation.
Use a quantity tier only when the boundary changes something real, such as unit economics, capacity, service, or the buyer's expected discount. A neat round number is not enough.
A five-question pricing structure test
- Is there one customer job or several? One job across a narrow customer band points to a flat package. Distinct jobs or requirements point to package tiers.
- Does quantity change value or cost? If not, quantity tiers add billing complexity without a commercial reason.
- Can the buyer predict the plan? A qualified buyer should identify the likely package and estimate the bill without a private spreadsheet.
- Is there a visible upgrade trigger? The customer should know what new need, limit, or service moves them upward.
- Can the team explain the invoice? Sales, finance, product, and customer success should use the same calculation and vocabulary.
| Observed condition | Start with | Reason |
|---|---|---|
| Same buyer, same job, similar account cost | One flat package | The simple explanation matches the product |
| Distinct segments need different entitlements or service | Multiple flat-rate packages | Each plan represents a real buying situation |
| Higher total volume earns one account-wide rate | Volume tiers | One rate applies to the reached scale band |
| Only incremental units should become cheaper | Graduated tiers | Each band keeps its own unit rate |
| Platform access has fixed value and quantity adds more | Flat fee plus tiers | The base and variable parts have separate jobs |
| The team cannot state why a boundary exists | Remove the boundary | The buyer should not pay for internal indecision |
Measure whether the structure helps buyers move
A pricing page can convert well while sending customers into the wrong plan. Measure the path after the initial purchase.
Stripe recommends tracking plan distribution, time to upgrade, expansion MRR, churn by plan, and self-serve upgrade rate.[4] Add the operational evidence your team sees directly:
- how often buyers ask which plan fits;
- how often sales overrides the published package;
- downgrades shortly after purchase;
- discount requests at quantity thresholds;
- billing disputes by plan and calculation method;
- gross margin and support load by package.
Test a new structure on a defined cohort before moving the full customer base. Replay current accounts through the proposed model. Look at the smallest, typical, and largest accounts. Then inspect the boundary cases where one unit or one feature changes the bill.
- current package and calculated bill;
- proposed package and calculated bill;
- reason for every package or quantity boundary;
- buyer-visible upgrade trigger;
- grandfathering or migration rule;
- invoice example for the boundary cases;
- owner for pricing questions and exceptions.
Your pricing model creates a buyer-education job
Every extra plan, feature gate, quantity band, and billing rule creates another question before a buyer can say yes. Complexity may be justified, but it must be teachable.
Publish the plan definitions, upgrade triggers, calculation examples, and common boundary cases in the same words your sales team uses. The product, pricing page, contract, invoice, and onboarding material should not translate the model five different ways.
Use the technical expertise into buyer education guide to build that explanation. If the package also changes how prospects evaluate the product, compare a free trial with a sales demo. If pricing still needs the founder in every conversation, review the sales transfer test.
Sources
- Stripe Documentation, Recurring pricing models, accessed October 19, 2026.
- Stripe Documentation, Set up flat rate pricing, accessed October 19, 2026.
- Stripe Documentation, Set up tiered pricing, accessed October 19, 2026.
- Stripe, SaaS pricing and packaging strategy, updated April 7, 2026.
- Chargebee Documentation, Pricing models for plans, addons and charges, accessed October 19, 2026.