SaaS Pricing: Charge for Seats or Usage?
Imagine a team choosing a price for its new software product. One customer wants a small group to use it all day; another wants to give occasional access to a large department. A single monthly fee treats those customers alike. A charge for every seat treats the department as the heavier user, even if its people rarely sign in. A charge for activity could reverse the result. Before anyone debates whether the price should be $50 or $500, the team has to decide what the customer is actually buying.
That is the job of a pricing model: it defines the dimension used to calculate the charge. For software, common choices include one flat fee, a fee per seat, charges tied to usage, and tiers. These patterns answer different questions about who pays more as an account grows; none tells you the right dollar amount by itself. Stripe’s guide to SaaS pricing models describes the main structures, but a useful choice begins with the buyer’s situation, not a model name.
My starting judgment is simple. Charge for a unit that buyers can recognize, that tends to grow when they get more from the product, and that the seller can count without arguments. Then decide what is included, when the bill arrives, and what happens at a threshold. If those details cannot be explained with a sample invoice, the model is not ready to publish.
Find the unit that should make the bill grow
The first decision is what changes the charge. A seat is a named or otherwise defined user. A usage unit could be a request, a minute, a stream, or some other counted action. A flat fee makes the account itself the billable unit for the stated period. Those definitions matter because each one rewards and penalizes different behavior. With per-seat pricing, adding people raises the bill. With usage pricing, more counted activity raises it. With a flat fee, neither change raises it until the customer moves to another package or contract.
For software used chiefly through collaboration, I would begin by testing seats. A team can usually understand why wider access means a higher charge. Yet a seat is a poor proxy if a few users can consume far more service than many light users. For a product whose consumption is closely tied to the service delivered, I would test a usage unit instead. The trade-off is that the final bill can move from period to period, so the buyer needs a way to estimate it. Stripe’s pricing and packaging guidance frames the choice around the unit customers pay for and the way their use and value change.
Do not choose a unit merely because the billing system can count it. A seller may be able to count logins, but logins might be a strange basis for charging if the useful work happens after sign-in. The better question is whether a buyer could look at a bill and say, “Yes, that count represents what we used.” If the answer depends on an internal definition, such as an unexplained weighted score, the seller has created an explanation problem. If buyers must change normal use simply to keep a count down, the unit may also work against adoption.
The seller has a separate concern: whether the unit reflects the cost of serving a growing account. A flat account fee may be easy to buy but hard to live with if one customer’s consumption rises far beyond the others’. A pure usage charge can track that burden more closely, but it can make revenue and the customer’s budget less predictable. Those are reasons to compare likely account patterns before committing to a model. They do not establish a universal winner. Without information about actual use, delivery cost, and what buyers regard as valuable, the model choice remains conditional.
Match the structure to the way customers use the product
A flat rate works when the offer is consistent enough that one charge can cover the expected range of customers. The invoice is easy to read: one stated amount for access during one stated period. I would favor it for a narrowly defined offer with modest variation in use, especially when a prospective buyer wants a known bill. The cost is that a light customer and a heavy customer pay the same amount. If the gap between them becomes large, the seller either accepts that difference or creates separate packages.
Per-seat pricing makes sense when wider participation is the principal reason an account gets more value. A collaboration product is a plausible candidate: adding another person is both a recognizable purchasing event and a clear addition to the invoice. I would specify what counts as a paid seat before putting a number on the pricing page. Is an invited user charged immediately? Does an inactive account still count? Who can remove a seat, and when does the change affect the bill? Those are offer decisions, but leaving them open makes a simple model feel arbitrary. A fixed monthly fee per seat also does not capture unusually heavy consumption by a small team.
Usage-based pricing is the stronger starting point when the customer can identify a consumed service unit and more consumption usually means more service delivered. It is particularly compelling where a seat count would say little about the work the product performs. Its weakness is bill uncertainty. A buyer needs the measurement period, the unit definition, and a way to understand what happens if use rises sharply. The seller needs a reliable way to record the usage being charged. Stripe’s usage-pricing documentation shows that different unit and tier calculations can produce different usage charges.
A combined model is often the sensible answer when there is both continuing access and variable consumption. A base charge can pay for the package, while a separate component rises with usage or seats. I would choose that route when a pure flat fee would ignore substantial variation, but a pure usage bill would make the base service difficult to price and budget. The price of the compromise is a longer explanation and an invoice with two moving parts. Stripe’s packaging guidance describes a base fee plus usage as a hybrid structure; the combination still requires a clear rule for each component.
Consider an illustrative offer: $200 per month includes access and the first 1,000 counted events; each event above 1,000 costs $0.04. A customer with 1,300 events owes $200 plus 300 × $0.04, or $212, before any separately stated taxes or adjustments. At 700 events, the charge is $200. The example illustrates a flat fee with overage, a structure Stripe documents. The actual rates, included allowance, and definition of an event are choices for the seller; the model alone supplies none of them.
Keep package tiers separate from quantity tiers
“Tiered pricing” can mean two different things in an ordinary pricing discussion. A set of plans may offer different features or limits: one package includes a basic capability, while another includes more. That is a packaging decision. A quantity tier changes how the charge is calculated when a measured count crosses a boundary. One offer may use both. For example, a plan could determine which features a buyer can use, while a quantity rule calculates charges for events within that plan. Stripe describes pricing and packaging as linked choices: the billable unit and price work alongside the features, limits, and entitlements in each package.
Package tiers are most useful when they correspond to different needs, rather than being a collection of arbitrary fences. If a small team needs the same functions as a large team but fewer seats, a seat charge may express the difference more directly than locking basic functions into an expensive plan. If a customer needs a distinct capability, a higher package can make that difference explicit. The seller should be able to finish the sentence “This plan is for a buyer who needs…” without referring only to the price. A package boundary does not, however, reveal what the buyer will pay for it. That amount still needs its own judgment.
Quantity tiers demand even more precise wording. Under graduated tiers, units in each band are charged at that band’s rate. Under volume tiers, the total count selects a rate that applies to the whole count. These are different calculations, even if the thresholds and displayed unit rates look identical. Stripe’s tiered-pricing documentation sets out both methods. A page that says only “$10 for the first 100, then $8” leaves a buyer guessing whether the lower rate applies only to later units or to every unit.
Here is an illustrative calculation, with no base fee or other charges. Suppose units 1 through 100 cost $10 each and the stated rate from unit 101 is $8. At 100 units, both methods charge $1,000. At 101 units, graduated pricing charges 100 × $10 plus 1 × $8, or $1,008. Volume pricing charges all 101 units at $8, or $808. At 120 units, the totals are $1,160 under graduated pricing and $960 under volume pricing. The same two rates produce different bills because the rule for applying them differs.
The volume example has a striking boundary: buying one more unit reduces the total from $1,000 to $808. That may be an intentional discount, but the seller should know it is there and a buyer should not discover it only on an invoice. Graduated tiers avoid that particular drop because earlier units keep their original rates. They also take a few more words to explain. I would ordinarily prefer graduated tiers when smooth changes in the total bill matter; I would use volume tiers when repricing the whole quantity at a threshold is deliberate and plainly disclosed. Neither method determines whether $10 and $8 are sensible rates.
Decide when the price is known and when it is collected
The billing interval is another decision that can be mistaken for the model. A subscription can have a recurring price tied to a defined interval. An account might be charged monthly or on another interval while still using a flat, seat, or usage rule for the amount. Stripe’s recurring-pricing documentation describes subscription pricing models; the interval belongs in the offer because it tells the buyer how often the charge is assessed. It does not make a per-seat model into a flat rate, or turn a usage charge into a seat charge.
An interval also affects commitment and cash timing. A monthly charge gives the buyer frequent opportunities to reassess spending, while a longer commitment may require more confidence in the product before purchase. This is why a headline price without its interval is incomplete. “$30 per seat” does not say whether the count is assessed each month, whether the stated amount is monthly, or when a newly added seat starts to incur a charge. Those details are especially important when the seat count can change during the period.
For metered use, distinguish the time when consumption happens from the time the buyer learns the final amount. If the offer charges for activity during a month, the exact usage component cannot be known before the month closes unless it is capped or otherwise constrained. A seller can still make it understandable: show the current count, explain the next threshold, and state when the measured charge appears on an invoice. For a base fee plus overage, say whether the base covers the coming period while overage reflects the completed one. The buyer needs enough detail to reconcile both parts of the bill.
Price the chosen unit without hiding the trade-offs
Once the billing unit and calculation are clear, the seller can decide the amount. This is a separate commercial choice. A seat price that is easy to calculate can still be too high for the value a buyer sees or too low for the cost of serving the account. Likewise, an included usage allowance can make an overage plan feel generous or restrictive without changing the underlying structure. The supplied models show how charges can be formed; they do not reveal a buyer’s willingness to pay for a particular product.
I would compare several realistic customer profiles before publishing a number. Take a small account, a growing account, and a heavy account. Write each one’s likely seat count or consumption for the same period, then calculate the bill under the candidate models. This is a design exercise, not a claim about what customers actually do. If the model asks a small but active customer to pay far more than a large but inactive customer, ask whether that is the intended relationship. If one extra unit creates a sudden jump or drop, decide whether the threshold is defensible. If the seller cannot explain a difference in bills in terms a buyer recognizes, the design needs revision.
Next, place the package beside the calculation. List the features and limits available at each price and show which rule triggers an upgrade or overage. The question is whether customers can tell what they gain by paying more and what they lose by staying where they are. A feature gate can make sense for a capability that serves a different need. It is a poor substitute for a usage rule when the real difference is simply how much of the same service the customer consumes. Stripe’s packaging discussion separates plan entitlements from the unit and rate used to calculate charges.
Before committing, I would put the terms on a sample invoice and ask someone unfamiliar with the pricing work to reproduce the total. The invoice should show the billing period, base fee if any, starting and ending seat count or measured usage, included allowance, the rate for each billable band, and the amount due. If the total needs a private spreadsheet to explain it, the offer may be too complicated for the intended buyer. The sample also exposes missing rules: rounding, partial periods, changes to seats, and what happens when usage is zero. Those rules have to be specified for the particular offer, even though the headline model name never mentions them.
The final call depends on the pattern of value and consumption. I would choose a flat fee for a tightly defined offer whose buyers want a stable bill; seats when broader team participation is the main change; usage when a countable service unit drives the work delivered; and a base plus usage when both access and variable consumption matter. I would use graduated quantity tiers by default if I wanted lower rates for later units without repricing earlier ones. The choice can change when actual customer use, costs, or buying behavior contradicts those assumptions. A pricing model is useful when it makes that relationship visible on the bill, not merely when its name sounds familiar.