Per-seat pricing charges a fixed rate per user, flat-rate pricing charges one fixed price per tier regardless of usage, and usage-based pricing charges for what customers consume. The right model depends on how customers get value: predictable team tools suit per-seat or flat-rate, while variable-consumption products suit usage-based. Many SaaS products now combine models.
What the Three Pricing Models Are
Every subscription price answers one question: what exactly is the customer paying for? The three dominant answers in SaaS are seats, tiers, or consumption.
Flat-rate pricing charges one fixed price per tier — every customer on "Standard" pays the same each month regardless of usage. It is the simplest model to explain, sell, and bill.
Per-seat pricing multiplies a fixed rate by the number of users or licenses, so revenue grows automatically as the customer's team grows.
Usage-based pricing charges for measured consumption — API calls, tokens, storage — with the bill reflecting what was consumed.
These are the same four building blocks that Stripe's subscription documentation uses to frame pricing design — flat rate, per-seat, tiered, and usage-based — and most real-world price lists are combinations of them rather than pure examples of one.
Flat-Rate Pricing: How It Works
Flat-rate pricing is the model most people picture when they hear "subscription": a fixed price, billed on a fixed cycle. Stripe's documentation illustrates it with two tiers — Standard at $20 per month and Pro at $50 per month — each a single fixed charge regardless of how many people use the account or how intensively they use it.
Why companies choose it:
- Predictable. Customers know the bill in advance; vendors forecast with simple multiplication.
- Frictionless checkout. One price, one decision — no seat-counting or usage estimates before signup.
- Cheap to operate. Billing logic is trivial: charge the plan price each cycle.
Where it strains:
- Heavy users are subsidized. A 200-user account pays the same as a 2-user one, capping value capture from your best accounts.
- Price rises are blunt. Moving the tier price hits every customer at once, inviting churn at the price-sensitive end.
- No automatic expansion. Growth only comes from plan upgrades you sell deliberately.
Flat-rate fits products where usage intensity varies little — simple tools and SMB products where the lightest and heaviest users look alike.
Per-Seat Pricing: How It Works
Per-seat pricing multiplies a unit price by a quantity. Using the same numbers as the flat-rate example, a $20-per-seat Standard plan costs a 12-person team $240 per month, while a $50-per-seat Pro plan costs the same team $600 per month. The "seat" is usually a named user, but some products define it as a license, a workspace, or an active contributor.
It dominates B2B collaboration software because price tracks adoption: when a team grows from 10 to 40 people, revenue follows without renegotiation.
Why companies choose it:
- Natural expansion. Every new hire is a potential new seat; land-and-expand happens almost by default.
- Easy to forecast. Seats are countable, so finance teams can model growth from headcount.
- Value alignment. Where each user gets direct value — CRM, project tools — seats track value closely.
Where it strains:
- Seat-sharing. Customers minimize seats via shared logins, and every unused seat becomes a cancellation argument.
- Punishes adoption. Per-user charges discourage inviting the whole company, slowing network effects.
- Blurry definitions. "Active user" vs. "viewer" vs. "guest" creates disputes and demands careful metering.
A common refinement: licensed seats (a fixed quantity purchased) vs. metered seats (counted from active users). Licensed is simpler to bill; metered is fairer but needs reliable tracking.
Usage-Based Pricing: How It Works
Usage-based pricing charges for a measured quantity of consumption. Stripe's documentation describes three common shapes, using token usage as the example: fixed fee with overage ($100 per month covers 100 tokens, then $2 per token beyond that), pay as you go ($2 per token, no base fee), and credit burndown (the customer prepays $100 and draws it down at $2 per token).
Under the hood it is an event pipeline: the product emits usage events, a metering system aggregates them per period, and a rating engine turns the aggregate into a charge — detailed in our usage-based billing guide.
Why companies choose it:
- Low entry barrier. Customers start with tiny bills, removing pricing friction from trials.
- Tight value alignment. Heavy users pay more because they consume more.
- Automatic upside. When usage 10x's, revenue follows without a pricing conversation.
Where it strains:
- Unpredictable bills. Both sides need guardrails: spend alerts, caps, committed-use discounts.
- Revenue volatility. Forecasting is harder when bills depend on behavior, not contracted seats.
- Metering is engineering. Accurate, auditable metering is a real system to build and maintain, not a toggle.
The Math: Comparing Cost Curves
Using the example rates from Stripe's documentation, here is what three customer sizes would pay per month:
| Customer size | Flat-rate | Per-seat ($20) | Graduated tiers | Usage ($100 base + $2/token) |
|---|---|---|---|---|
| 5 users / 50 tokens | $20 | $100 | $75 | $100 |
| 15 users / 200 tokens | $20 | $300 | $210 | $300 |
| 30 users / 500 tokens | $20 | $600 | $370 | $900 |
Three patterns stand out. Flat-rate is cheapest everywhere — which is why it leaves expansion revenue on the table. Per-seat and usage scale similarly here but respond to different growth: headcount vs. consumption. Graduated tiers soften the curve, which is why enterprises prefer them.
Run this exercise with your own numbers before choosing: the crossover points determine which model helps or hurts at your deal size. Our billing-volume pricing guide applies the same comparison to the fees platforms charge you.
Tiered and Hybrid Variants
Pure models are rare in practice. The two most common refinements:
Tiered pricing varies the unit rate by quantity. Volume-based tiers apply one rate set by the total: 18 seats at the 11–20 tier costs 18 × $12 = $216. Graduated tiers price each band separately: (10 × $15) + (8 × $12) = $246. Volume-based is simpler; graduated avoids the cliff where one extra seat reprices everything.
Hybrid pricing combines models. The most common shapes:
- Base fee + usage overage — a predictable floor with consumption-based upside (the $100-for-100-tokens example).
- Per-seat + usage — seats cover platform access while metered consumption covers variable cost (common in AI and data products).
- Flat tiers with usage caps — each tier includes a usage allowance, with overage beyond it.
Hybrids blend subscription predictability with metering's value alignment, at the cost of more complex billing and harder invoices.
Trade-Offs at a Glance
| Dimension | Flat-rate | Per-seat | Usage-based |
|---|---|---|---|
| Bill predictability | Highest | High | Lowest |
| Expansion revenue | Manual upsell only | Automatic with headcount | Automatic with consumption |
| Billing complexity | Trivial | Low–moderate | High (metering required) |
| Customer friction | Lowest at signup | Seat management overhead | Bill-shock risk |
| Best when value comes from | Access to the product | Each team member | Each unit consumed |
| Risk | Under-monetized power users | Seat minimization | Revenue volatility |
No model wins on every row. The right choice is the one whose strengths match how your customers actually derive value — and whose weaknesses you can mitigate with product and billing design.
Which Model Fits Your Product
A practical way to decide:
- Map value to a metric. One more user → per-seat; one more API call or token → usage; roughly equal value per customer → flat-rate.
- Check your costs. Near-zero marginal cost means free choice; real infrastructure cost per token or gigabyte argues for usage-based or a hybrid.
- Consider the buyer. Enterprise finance teams prefer budgetable per-seat or flat contracts; product-led buyers prefer usage they can start small with.
- Prototype the invoice. Draft it for your smallest, median, and largest customer. If any would confuse or anger that customer, add guardrails or rethink.
Models can evolve: many start flat-rate, add per-seat upmarket, then add usage as consumption becomes the value driver. Changing later is a migration project — version your catalog from day one so early customers can be grandfathered.
How Billing Platforms Implement Each Model
Modern billing platforms support all three models, but depth varies. Stripe Billing handles flat-rate, per-seat, and tiered natively; its documentation points to Metronome for complex usage-based configurations. Chargebee, Recurly, and Zoho Billing likewise support all four catalog shapes, with advanced metering concentrated in higher tiers.
Two notes. First, "usage-based support" ranges from simple metered quantities to full event pipelines with prepaid credits and multi-dimensional rating — verify the depth in the vendor's own docs. Second, the vendor's fee for their platform is separate from your pricing to your customers: billing-layer fees are typically a percentage of billing volume, as our buyer's checklist explains.
- Flat-rate is simplest and most predictable, but it under-monetizes heavy users and offers no automatic expansion.
- Per-seat ties revenue to team adoption, making it the default for B2B collaboration tools — but it invites seat-sharing and punishes broad rollouts.
- Usage-based aligns price with consumption and lowers the entry barrier, at the cost of bill unpredictability and real metering engineering.
- Tiered and hybrid variants (volume vs. graduated tiers, base + overage) exist to soften each model's sharp edges.
- Run the math with your own customer sizes before choosing: crossover points determine which model helps or hurts at your typical deal size.
- Verify platform support for your chosen model in the vendor's documentation — "usage-based" means very different depths of metering across platforms.
FAQs
Can I switch pricing models later?
Yes, but treat it as a migration project. Existing customers usually need grandfathering or a transition plan, your billing catalog needs versioning, and invoices, proration, and dunning flows all need re-testing. It is far easier to pick a model with headroom — for example, per-seat with tiered discounts — than to re-platform pricing mid-growth.
Which pricing model maximizes revenue?
There is no universal winner; it depends on the distribution of value across your customer base. Usage-based tends to capture the most from power users, per-seat captures team growth, and flat-rate captures simplicity-loving buyers who would otherwise not convert. The honest answer comes from modeling your own customer data, not from industry averages.
Is per-seat pricing dying?
No, but it is being blended. Pure per-seat is under pressure in AI products where one user can drive enormous compute cost, which is why per-seat-plus-usage hybrids are spreading. For collaboration software where each seat represents a human getting value, per-seat remains the standard.
How do I bill a hybrid model without confusing customers?
Separate the invoice into clear lines — one for the base or seats, one for usage — and show the usage calculation (units × rate) on the invoice itself. Publish the metering rules in your pricing page or docs so the usage line is auditable. Confusion usually comes from hidden metering, not from the hybrid structure itself.
Should I offer annual discounts on usage-based plans?
Annual commitments work better than annual discounts for usage: the customer commits to a minimum spend (often with a discounted overage rate) rather than prepaying a fixed amount. This preserves the value-alignment of usage pricing while giving both sides predictability. Check how your billing platform models committed-use contracts before promising them on a pricing page.
Conclusion
Per-seat, flat-rate, and usage-based pricing are tools, not rivals: per-seat monetizes adoption, flat-rate monetizes access, usage monetizes consumption. The strongest price lists combine them — a predictable base plus a variable component that captures value as customers grow. Pick the model tracking how customers get value, verify your platform implements it deeply enough, and model the math at real customer sizes first.