A working guide to SaaS pricing for leadership teams: the six decisions in the order they should be made, the pricing models and metrics to choose from, and how usage-based and AI pricing change the picture.
SaaS pricing goes wrong most often when a company changes the price level to fix a problem that sits in the metric or the packaging. Raising the price of a per-seat plan does not help if customers are consolidating seats. Adding a fourth tier does not help if nobody upgrades from the second. A sound SaaS pricing strategy makes six decisions, and each one constrains the next:
Decision 1
Value metric.
The unit the price scales with: seats, users, usage, or outcomes.
Decision 2
Pricing model.
How the metric turns into a bill: flat, per unit, tiered, usage, or a hybrid.
Decision 3
Packaging.
Which capabilities, limits, and service levels sit in which plan, and what sits outside as an add-on.
Decision 4
Price levels.
The numbers, set against the value delivered to each segment and the alternatives buyers consider.
Decision 5
Discount rules.
What sales can give, in what form, with whose approval.
Decision 6
Price changes.
How and when prices move for new and existing customers.
Most companies inherit the first three and spend their energy on the fourth. The sections below take them in turn.
Pricing metrics are the foundation of software pricing, because they decide whether revenue grows with the value customers get. A good value metric passes four tests: customers understand it, it rises as they get more value, you can measure it reliably, and it is hard to game by sharing logins or batching work.
| Product type | Common metric | Better fit when |
|---|---|---|
| Collaboration and workflow tools | Seats or active users | Value is per person and headcount grows with the customer |
| Data and analytics platforms | Data volume, queries, or records | Value grows with how much the customer analyzes, not who logs in |
| Developer and API products | Calls, transactions, or compute | Consumption is measurable and tracks the customer’s own revenue |
| Vertical software for a trade | Locations, assets, or jobs | The customer’s business is counted in sites, vehicles, or work orders |
| Payments and financial software | Transaction value or count | Value is proportional to money moved |
| AI agents and automation | Tasks completed or outcomes | The software replaces work rather than supporting a user |
The last row is where many B2B SaaS pricing models are under strain. When an AI capability does work a user used to do, a seat-based price falls as the product succeeds. That is the single strongest reason software companies are revisiting their metric now.
Once the metric is chosen, the model decides how it becomes an invoice. Each of the common SaaS pricing models has a situation it suits and a way it fails.
| Model | Suits | Breaks when | What billing must do |
|---|---|---|---|
| Flat rate | One product, one buyer type | Small customers overpay and large ones get a bargain | Very little |
| Per seat or per user | Value per person, predictable budgets | Customers share logins, or automation reduces the number of users | Count seats; handle true-ups |
| Tiered | Segments that need clearly different capability | The fences leak, so large customers buy the lower tier | Map features and limits to plans |
| Usage based | Consumption that tracks value | Buyers cannot forecast their bill, so procurement resists | Meter usage accurately; invoice in arrears |
| Hybrid: platform fee plus usage | Most mid-market and enterprise B2B software | The fee dwarfs usage, or is so small that revenue turns volatile | Both of the above |
| Credits or prepaid units | Variable consumption with budget control | Unused credits expire and customers feel cheated at renewal | Track balances and burn rates |
| Outcome based | Measurable, attributable results | The outcome depends on factors outside the product | Agree the measurement and audit it |
In practice, most B2B SaaS pricing ends up hybrid: a subscription fee that gives the buyer a number to budget, and a usage or capacity component that lets revenue follow adoption.
A usage based pricing model aligns price with value better than almost any other, and it is also the model buyers find hardest to approve. The finance team at the customer wants to know what it will spend next year. The design problem is to keep the alignment and remove the surprise.
The standard answer is a platform fee that includes an allowance, with a published overage rate above it. The worked example shows how that bill behaves across three customers of different sizes.
Illustrative examplePlatform fee of $2,000 a month including 50,000 API calls, then $0.03 per additional call.
| Customer | Calls in the month | Monthly bill | Effective price per 1,000 calls |
|---|---|---|---|
| A | 30,000 | $2,000 | $66.67 |
| B | 80,000 | $2,900 | $36.25 |
| C | 250,000 | $8,000 | $32.00 |
Three properties are worth noticing. The smallest customer pays the full fee and uses less than its allowance, so the fee protects revenue at the low end. The effective unit price falls as usage grows, which gives large customers a volume discount without anyone negotiating one. And the bill for customer C is four times the bill for customer A, which is roughly how differently the two customers value the product.
Buyer concerns about unpredictable bills are handled with design choices, not discounts: annual commitments that lower the overage rate, spending alerts at defined thresholds, soft caps that require approval before overage is charged, and quarterly true-ups instead of monthly surprises.
AI changes SaaS pricing in two ways at once. It changes the value, because AI capabilities often do work rather than support it. And it changes the cost, because inference is a real variable cost per use, which traditional software did not have. An AI pricing strategy has to handle both.
The cost side is easy to underestimate. Illustrative example: an AI feature costs $0.40 in compute per task. A light user running 50 tasks a month costs $20. A heavy user running 2,000 tasks costs $800. If the feature is bundled into a plan priced at $150 per seat per month, the heavy user is served at a loss and the light user subsidizes nothing, because both pay the same.
The common AI pricing models answer this in different ways. We work through them as a sequence of questions:
Does the feature cost meaningfully more to serve as usage rises? If not, include it in the plans where it defends the price and helps sell the upgrade.
Is usage concentrated in a minority of customers? If yes, include an allowance in the plan and charge beyond it, so the heavy minority carries its own compute cost.
Is the AI capability a distinct job with its own buyer? If yes, it may deserve its own product and price, not an add-on to the existing plans.
Can the result be measured and attributed? If yes, an outcome price per resolved ticket, processed document, or qualified lead becomes possible, and it tracks value most closely of all.
Would customers compare the price with the human work it replaces? If yes, price against that reference, with the saving made visible, rather than against other software.
Applied to the example above: 200 tasks per seat are included, a cost of $80, and extra tasks are sold in packs of 1,000 for $900. Each pack costs $400 to serve, a gross margin of 56%.
The two failure modes are opposite. Giving AI away in every plan erodes margin as adoption grows. Charging for it separately before customers trust it slows adoption until a competitor includes it.
API products are the purest case of usage based pricing, and the same principles apply with more precision. An API pricing strategy defines the unit (calls, tokens, records, compute time), a free or low entry allowance that lets developers build before a buyer is involved, volume bands that reward commitment, and rate limits that separate plans. The mistake to avoid is pricing the API as an afterthought of the main product, so that a customer can rebuild the product’s value through the API for a fraction of the subscription.
Packaging decides what sits in each plan. In SaaS pricing and packaging work, the plans are only as good as the reason to move between them. That reason can be a capability, a usage ceiling, or a support commitment, and it has to be one the next customer segment genuinely values. Plans with no such reason between them get compared on price alone, and the gap between them gets discounted away.
Three packaging rules hold across most software products. Keep plans to the number the sales team can explain in a sentence each, usually three plus an enterprise option. Put security and administration features (single sign-on, audit logs, advanced permissions) in the higher plans, because the buyers who need them are the buyers with bigger budgets. And sell capabilities that only some customers need as add-ons, rather than forcing them into a plan everyone pays for. The principles of fences and tier design are covered in detail on our pricing and packaging page, and the SaaS pricing and packaging article goes further on plan design.
B2B SaaS pricing differs from consumer subscription pricing in who buys and how. A buying committee evaluates the product, procurement negotiates the terms, and the contract often runs for several years. That brings pricing mechanics that consumer apps never meet:
Multi-year terms.
A discount for a longer commitment is reasonable; an undocumented one that compounds with others is not. Each should be measured as effective annual price over the term.
Ramp deals.
Prices that start low and step up as the customer rolls out the product. They help land large accounts, and they need an end date written into the contract.
True-ups.
Annual reconciliation of seats or usage against the contract, which is where expansion revenue is either captured or forgiven. Set the true-up rate in the contract, not at reconciliation.
Price protection.
Caps on renewal increases requested by procurement. A cap tied to an index is defensible; a flat cap of zero for three years is a discount in disguise.
Enterprise software pricing adds one more layer: the top plan is usually quoted, not published. That gives sales flexibility, and it needs a price book behind it, with floors and approval rules, so that quoted prices for similar customers stay consistent. Discount structures and how to govern them are covered in our B2B pricing guide.
Pricing rarely fails all at once. These are the signals in the data that one of the six decisions has drifted:
Each of these has a specific cause, and each points to a different one of the six decisions.
If one of the signals above looks familiar, bring us the numbers behind it. Within one call we can usually say which of the six decisions has drifted and what it would take to correct.
Tiered subscriptions priced per seat have been the default for years. For mid-market and enterprise software, a hybrid of a platform fee and a usage or capacity component is increasingly common, because it keeps the predictability of a subscription while letting revenue follow adoption.
Review price levels once a year and the metric and packaging whenever the product changes materially: a major new capability, an AI feature with real running cost, a move upmarket, or an acquisition that brings a second price list.
No. It suits products where consumption is measurable, varies widely between customers, and tracks the value they receive. Where usage is flat across customers, or buyers need a fixed annual budget, a subscription with capacity tiers usually works better.
Against the work they replace, not against other software. A per-task or per-outcome price that sits clearly below the cost of doing the work manually is easier for a buyer to approve than a seat price that has no link to the labor saved.
The model is the mechanism: flat, per seat, tiered, usage, or hybrid. The strategy is the full set of choices around it, including the metric, the packaging, the price levels, the discount rules, and how prices change over time.
When the decision affects most of your ARR, when internal teams disagree about the direction, or when the change needs research and a migration plan that nobody inside has the time to run. Our SaaS pricing consultant page describes how we run those engagements.
