All insights

    Pricing Strategy

    SaaS Pricing Models: A Complete Guide to Choosing the Right One

    Every major SaaS pricing model compared: flat rate, per seat, tiered, usage-based, hybrid and outcome-based. What each one rewards, where it breaks, and how to pick the value metric your price should sit on.

    September 13, 202612 min readBy Cristian Varga
    SaaS Pricing Models: A Complete Guide to Choosing the Right One

    A SaaS pricing model is the structure that decides what a customer pays for. Not the number, the unit. Per user, per workflow, per resolved ticket, per percentage of savings. Get the unit right and price increases feel fair, expansion happens without a sales call, and margin holds as the product scales. Get it wrong and no amount of price testing saves you.

    This guide compares the six models that matter, what each one rewards, where each one breaks, and how to choose between them. It is written for SaaS and AI products where cost of delivery moves with usage, because that is where most inherited pricing structures are now failing.

    Start with the value metric, not the price

    Before the model, one decision: what is the thing you charge for. This is the value metric, and it should satisfy three tests.

    • It grows as the customer gets more value. If a customer doubles the good outcome they get, the metric roughly doubles.
    • The customer can predict it. A metric nobody can forecast becomes a procurement objection and a churn risk.
    • It tracks your cost of delivery. Especially for AI products, where tokens, compute and tool calls scale with work done rather than with logins.

    Most pricing failures are metric failures wearing a price tag. Seats do not grow with value in a product where an agent does the work. Storage does not grow with value in a product whose value is decision quality. Fix the metric first; the model follows from it.

    Model 1: Flat rate

    One product, one price, everything included.

    Works when: the product does one job, buyers are homogeneous, and simplicity is a competitive advantage. Excellent for early self-serve products where the priority is learning fast rather than extracting maximum revenue.

    Breaks when: your customer base spreads out. A single price leaves money on the table with your largest accounts and prices out the smallest. There is also no expansion path: revenue only grows by adding logos.

    Model 2: Per-seat (per user)

    Price multiplied by the number of users.

    Works when: value genuinely accrues per person using the software. Collaboration tools, CRMs, design tools. Buyers understand it instantly and finance teams can forecast it.

    Breaks when: the work stops being done by people. This is the central problem in AI products right now. An agent resolves tickets without occupying a seat, so the customer's value goes up while your seat count goes flat or down. Seat pricing also creates a perverse incentive: customers share logins and restrict rollout precisely to avoid paying you more, which suppresses the adoption you need for retention.

    If your product replaces work rather than assisting workers, per-seat is a structural cap on your revenue, not a pricing preference.

    Model 3: Tiered packaging

    Two to four named packages with different feature sets and limits.

    Works when: you have identified genuinely different segments with different needs, and you can name the one feature or limit that separates them. Tiering is how you serve a self-serve buyer and an enterprise buyer with one product without discounting your way through every deal.

    Breaks when: the tiers are invented rather than observed. Three columns built from a whiteboard exercise produce a middle tier nobody wants and an enterprise tier that exists only to make the middle look reasonable. Good tiers are built on evidence about what each segment values and what each will pay, which is exactly what willingness-to-pay research produces.

    Tiering is also a packaging decision, not a model on its own: each tier still needs a unit underneath it.

    Model 4: Usage-based (consumption) pricing

    The customer pays for what the system does: API calls, workflow runs, documents processed, messages sent, gigabytes stored.

    Works when: usage correlates with value and your cost. Revenue expands automatically with adoption, small customers can start cheap, and there is no negotiation required for a customer to grow. For AI products it has the additional virtue of putting revenue on the same axis as inference cost.

    Breaks when: bills become unpredictable. Consumption pricing without caps, alerts and committed floors generates surprise invoices, procurement resistance, and customers who deliberately throttle usage. It also decouples price from outcome: a customer paying per run cares about minimising runs, which is not the behaviour you want.

    Guardrails make it work: a platform floor, transparent metering, usage alerts, volume tiers, and an annual commitment with overage rather than pure pay-as-you-go. See the usage trap for how this goes wrong in practice.

    Model 5: Hybrid (platform plus usage)

    A fixed platform fee covering access and baseline volume, plus a usage or outcome component above it.

    Works when: no single metric can carry the whole structure, which is most serious AI products. The floor covers your delivery cost and gives finance a predictable line item; the variable component captures upside as the customer grows. It is the default recommendation for the majority of AI-native products we work on.

    Breaks when: it becomes complicated. Two components is a model; five is a spreadsheet the buyer cannot evaluate. Keep it to one floor and one variable unit, both stated in one sentence.

    Model 6: Outcome-based pricing

    The customer pays for a result: per resolved ticket, per qualified lead, per approved claim, or a share of measured savings.

    Works when: the result is measurable in a system both sides trust, you can agree a baseline before you start, and you have a floor to cover cost when volume dips. It is the most defensible model for agents, because it prices the work rather than the access.

    Breaks when: attribution is contested or your cost per outcome is unmodelled. Margin dies in the tail: the small share of cases that loop, retry and escalate. Full detail in the outcome-based pricing guide.

    Comparing the models

    • Simplest to buy: flat rate, then per seat, then tiered.
    • Best expansion without a sales call: usage-based and hybrid.
    • Best alignment with delivered value: outcome-based, then usage-based.
    • Best margin protection under variable AI cost: hybrid, then outcome-based with a floor.
    • Highest risk for AI products: per seat, because the unit no longer moves with the work.

    How to choose, in five questions

    1. Where does the work happen? If a person does it, seats can still work. If an agent does it, price the work.
    2. What does your cost track? Whatever drives your delivery cost should appear somewhere in your price, or margin erodes with success.
    3. What can the customer forecast? If they cannot predict the invoice within about ten percent, add a floor, caps or tiers.
    4. What grows when the customer wins? That is your value metric candidate. Test it against the previous three answers.
    5. What will the market actually pay? Not a guess. Research it.

    Setting the number once the model is chosen

    The model tells you what to charge for. Two research methods tell you how much.

    The Van Westendorp Price Sensitivity Meter uses four questions to establish the range of prices your market finds credible, bounded below by "so cheap I doubt it works" and above by "more than I would ever pay". It gives you guardrails, not an answer.

    Gabor-Granger then tests specific price points inside that range and produces a demand curve and a revenue curve, so you can see which price maximises revenue and what you give up by going one step lower.

    Run in sequence, they turn a pricing argument into a decision with evidence behind it. Skip them and you are negotiating with your own assumptions.

    Migrating from one model to another

    Do not reprice everyone at once. Launch the new model on new business plus one willing segment. Run both structures side by side for a quarter and compare revenue per account and gross margin per account, not logo count. Grandfather existing contracts to renewal, then migrate each with a clear before-and-after showing what changes and why. Give a long notice period and a transition ceiling for the accounts that would see the biggest jump.

    Two rules make migrations survivable. Nobody should find out about a pricing change from an invoice. And every affected customer should be able to see, in one line, what they now pay for.

    The short version

    Pick the unit that grows with customer value and with your cost. Put a floor under it so delivery is always covered. Use tiers for packaging, not as a substitute for a metric. Research the number rather than guessing it. And if the work in your product is done by agents rather than people, get off seats before your market does it for you.

    If you want this decided on your own product and numbers, see how the C.O.R.E. engagement works.

    #saas pricing models#saas pricing strategy#software pricing models#value metric#usage-based pricing
    From research to practice

    See how we apply empirical pricing research in practice: Explore the C.O.R.E. roadmap & 78-artifact catalog

    Explore the C.O.R.E. roadmap

    Have a pricing problem worth solving?

    Book a 45-minute strategy session and leave with a sharper view of your monetization gaps.

    Book a Strategy Call