SaaS Pricing Models: What Actually Works in B2B Software

TL;DR — Most SaaS pricing model comparisons list options like a menu: per-seat, usage-based, tiered, freemium. Pick one. The problem is that choosing a pricing model is the wrong starting point. The model is downstream of three harder decisions: what metric you charge on (licensing), how you structure what’s included (packaging), and what price points hold up in real deals (pricing). Companies that start with the model end up retrofitting everything else to justify the choice they already made.

---

The Model Is Not the Decision

Every SaaS pricing guide starts the same way: here are six models, here’s a comparison table, pick the one that fits. This framing is wrong, and it’s why so many B2B software companies end up with pricing that doesn’t survive contact with procurement.

The model — per-seat, usage-based, flat-rate — is a delivery mechanism. (Tiered packaging is often listed here too, but that’s a packaging structure, not a pricing model — more on this below.) It describes how the invoice looks. It doesn’t describe what you’re charging for, why the buyer should accept it, or whether the price captures the value the software delivers.

A per-seat model tells you the billing structure. It doesn’t tell you whether “seat” is the right metric for how customers measure ROI. A usage-based model tells you consumption drives the bill. It doesn’t tell you whether the usage metric you’ve chosen encourages adoption or suppresses it.

Starting with the model is like choosing the container before you know what you’re shipping. The decisions that actually determine whether pricing works — what value metric to charge on, how to package capabilities into offerings that match how different customer groups use the product, and what price levels hold up across your deal population — all precede the model choice.

What the Transaction Data Shows About Model Selection

When companies say “we chose per-seat pricing,” what usually happened is someone on the product team looked at what competitors charge, picked a similar structure, and set a number. No analysis of how customers actually extract value from the product. No examination of what happens to deal velocity at different price points. No understanding of how the metric they chose behaves when a customer’s usage grows tenfold.

The problems surface later. In our competitive intelligence work, we studied a competitor of one of our customers that meters dozens of features in their packaging by count — dashboards, reports, automations, workflows, each capped at different limits per edition. A seller at the company told us how he actually closes deals: he gives the buyer the upper edition discounted to the previous edition’s price. The packaging is so complex that the fastest path to a closed deal is to skip the packaging conversation entirely. The model was designed to create upsell paths. What it actually created was a system so difficult to navigate that sales bypasses it.

This is what happens when the model drives the architecture instead of the other way around.

Per-Seat Pricing: Simple Until It Isn’t

Per-seat is the default for B2B SaaS. Simple to explain, simple to invoice, simple to compare across vendors. But simple for the vendor doesn’t mean right for the buyer.

Per-seat pricing assumes that every seat extracts equal value. In practice, software usage is skewed — not normally distributed around the mean. Across the B2B software categories we’ve analyzed, a small number of power users drive the majority of value delivery, while a substantial portion of seat licenses see minimal engagement. The buyer who runs transactions in the software all day and the buyer who logs in once a month to pull a report are paying the same price for dramatically different value.

This creates a predictable problem at renewal. The economic buyer — usually a CFO or VP of Finance — looks at utilization data and asks a reasonable question: why are we paying for 200 seats when 40 people use it daily? The answer is usually that 200 people need access, but only 40 derive daily operational value. Per-seat pricing makes the 160 look like waste. A metric tied to the actual value delivered — transactions processed, reports generated, decisions supported — would make the same 200-person deployment look fully justified.

Per-seat works when the product’s value genuinely scales with the number of people using it — collaboration tools, communication platforms, project management. It breaks when the product’s value scales with the work being done, not the headcount doing it.

Usage-Based Pricing: The Metric Matters More Than the Model

Usage-based pricing sounds like the natural evolution: charge for what customers use. But “usage” is a category, not a metric. The specific thing you count — and where it sits on the spectrum from raw activity to business outcome — determines whether usage-based pricing captures value or suppresses it.

A mobile app analytics company charged per event tracked. Customers responded rationally: they didn’t instrument all their in-app events, even though comprehensive instrumentation was the core value of the technology. The per-event price made full deployment feel expensive relative to the insight each marginal event delivered. The pricing architecture prevented customers from using the product the way it was designed to be used.

An IoT platform selling to chemical plants saw the same pattern. Customers instrumented a fraction of the sensors on the plant floor, even though full coverage was safer and operationally smarter. It was only after a spill that they came all in.

In both cases, the model was “usage-based.” The problem wasn’t the model — it was the metric. Peer-reviewed behavioral economics research documents what practitioners call the pain of paying: when the price is visibly tied to each unit of consumption, buyers ration usage to manage the bill. The metric that makes sense to the vendor (events tracked, sensors instrumented) creates friction for the buyer at the point of value delivery.

The job of the metric is to get customers to come all in — every user, every event, every sensor, every workflow deployed. When they ration instead, the metric needs to move further from raw consumption toward something the buyer can budget around without suppressing adoption.

Tiered Packaging: The Industry Calls It a Model, but It Isn’t

“Tiered pricing” is one of the most misunderstood terms in B2B software. It gets listed alongside per-seat and usage-based as a pricing model, but it’s not — it’s a packaging structure. “Good / Better / Best” describes how capabilities are bundled into offerings, not what drives the price or what metric you charge on. The definition got munged over time because so many comparison guides list it alongside actual pricing models, and the conflation stuck.

The distinction matters because it changes where the work happens. Per-seat and usage-based are licensing decisions (what metric you charge on). Tiered packaging is a packaging decision (what capabilities go together). You can have tiered packaging with per-seat pricing, or tiered packaging with usage-based pricing, or tiered packaging with flat-rate pricing. The tier structure and the pricing model are independent choices — treating them as the same decision is how companies end up with packaging that doesn’t match how customers buy.

The most common mistake is building editions around average usage. One client designed packages around “t-shirt sizing” — the typical customer buys 2 of product A and 10 of product B. The problem? No one actually bought the average. The average t-shirt size fit no one. The editions created a choice architecture where every customer felt like they were either overpaying for capabilities they didn’t need or missing capabilities they did.

Effective tiered packaging starts with customer groups — clusters of customers who derive value from the product in similar ways, regardless of company size or industry vertical. The distinction from traditional customer segments (small/medium/large, by vertical) matters: segments don’t predict how customers actually use the product. Groups do.

When you build editions around customer groups, each edition maps to a recognizable use case. The buyer sees their situation reflected in the packaging and can choose without needing a sales conversation to explain which edition fits. This is the structural advantage of good packaging: it reduces the evaluation burden. Complex packaging — too many editions, too many add-ons, too many conditions — signals negotiation complexity and contract risk. Procurement teams flag it because it means more legal review and more potential for invoice surprises.

Flat-Rate Pricing: Simpler Than It Appears

Flat-rate pricing — one price, unlimited access — is often dismissed as unsophisticated for B2B. But it has a structural advantage that’s underappreciated: it eliminates the pain of paying entirely. The buyer pays once (or monthly), and every subsequent use of the product is free at the margin. There’s no mental accounting per transaction, no usage rationing, no “should I use this feature if it costs me more?”

The trade-off is that flat-rate pricing can’t capture expansion revenue from growing usage. A customer processing 100 transactions and a customer processing 10,000 pay the same price. If the product’s value scales with usage volume, flat-rate leaves money on the table for the vendor and creates a disproportionate deal for the heavy user.

Flat-rate works best for products where the primary value is access rather than volume — reference databases, compliance tools, design systems. It fails for products where the top 10% of users drive 80% of the value and a usage-aligned metric would capture that differential.

Freemium: It Touches All Three Layers

Freemium sits across licensing, packaging, and pricing simultaneously — which is why it’s harder than most companies realize. The decision to offer a free edition involves all three layers of the architecture — it determines how you fill the top of the funnel. The pricing architecture for the paid editions still needs the same licensing, packaging, and pricing work as any other B2B software product.

The critical question isn’t whether to offer freemium. It’s where the free-to-paid boundary sits. — a decision that PLG companies specifically struggle with because nobody owns it. The capabilities that cross that boundary define what buyers perceive as the product’s value — everything below the line is “expected,” everything above is “worth paying for.” Set the boundary too high and free users never convert. Set it too low and the free product doesn’t demonstrate enough value to create conversion pressure.

This requires understanding how different customer groups experience the product, which features drive the moment that justifies payment, and what usage patterns predict conversion. For the full treatment, see Freemium SaaS: When It Works and When It Doesn’t.

Hybrid Models: Where Most B2B Software Actually Ends Up

In practice, most B2B software companies don’t use a single pricing model. They end up with hybrids: per-seat for the base license, usage-based for consumption above a threshold, packaged into editions for different customer groups, and negotiated enterprise pricing for the largest accounts.

This is fine — hybrid models reflect the reality that different customer segments buy differently. But hybrid models are also where pricing complexity compounds. Each layer (seat count × usage edition × add-on bundle × enterprise discount) creates another dimension of negotiation surface. Sales teams learn to game the seams — pushing customers into the edition that’s easiest to discount rather than the one that best fits their usage.

The discipline required for hybrid models is maintaining legibility. The buyer should be able to predict their bill at 2x, 5x, and 10x their current scale without needing a spreadsheet. If pricing legibility breaks at scale, expansion revenue suffers — not because the buyer doesn’t want to grow, but because they can’t forecast what growth will cost.

What Should Actually Drive the Decision

The comparison table — per-seat vs. usage-based vs. flat-rate (with “tiered” incorrectly listed as a fourth option) — is the wrong tool. Each model has scenarios where it works and scenarios where it fails. The variables that determine which scenarios you’re in:

How does the buyer measure ROI from your product? If they measure in seats productive, per-seat works. If they measure in outcomes delivered, the model should align to outcomes. If they measure in cost avoided, flat-rate with clear feature differentiation works. The answer comes from customer research — what metric appears in their internal business case for purchasing your software?

What happens to your revenue when usage moves 10x — in either direction? Everyone models the upside: if per-seat pricing stays flat because headcount doesn’t change, you’ve capped your expansion revenue. If usage-based pricing makes the buyer hesitate before deploying to a new team, you’ve capped their adoption. But nobody asks the harder question: what happens when usage drops 10x? A market correction, a budget freeze, a customer consolidation — usage-based revenue collapses in lockstep. Per-seat revenue holds until the contract renews. Flat-rate holds regardless. The right model isn’t just the one that captures upside — it’s the one that survives downside without destroying your revenue base overnight.

Can procurement evaluate your pricing in one meeting? If explaining the pricing requires a custom quote builder, a slide deck, and a 45-minute call, the packaging is too complex. Complexity creates evaluation burden. Enterprise buyers compare your pricing against everything else at that price point in their budget — not against your competitors. One buyer we interviewed told us his mental comparable for a security software purchase wasn’t another security vendor — it was Microsoft Office, because it happened to sit at a similar price point. Pricing that’s hard to evaluate loses to pricing that’s easy to evaluate, regardless of which is actually cheaper.

Does your transaction data support the model? Most SaaS pricing model decisions are made without looking at deal data. Win rates, discount depth, deal velocity, renewal rates — all vary by pricing structure. Companies with enough deal volume to analyze should let the data inform the model choice. Peer-reviewed research on pricing methodology documents that hypothetical methods (surveys, conjoint studies) systematically overstate what buyers will pay — the gap between stated willingness and actual payment behavior is roughly 2x. Transaction data from real deals doesn’t have this bias.

The Licensing, Packaging, and Pricing Sequence

The model choice becomes straightforward when you’ve done the upstream work:

Licensing — what metric you charge on. Is it seats? Transactions? API calls? A composite measure? The metric should map to how the buyer measures value from your software. This is the value metric decision — the single highest-leverage pricing choice a software company makes.

Packaging — how capabilities are structured into offerings. Which features go in which edition? What drives the upgrade path? How do customer groups map to packages? Good packaging reduces evaluation burden and makes the buyer’s choice obvious.

Pricing — what price levels hold up in real deals. Not what surveys say buyers would pay. Not what competitors charge. What actually closes at acceptable velocity with acceptable discount depth across your deal population.

The model — per-seat, usage-based, flat-rate, or a hybrid — describes how these three decisions get delivered to the buyer. (Tiered packaging is a separate axis that sits on top of any model.) It’s the container. The contents are what matter.

Enterprise SaaS pricing that holds up over time starts with the metric, builds the packaging around customer groups, prices from deal data, and then selects the model that delivers all three legibly. For the full framework on how licensing, packaging, and pricing work as an integrated architecture, that’s the deeper read.

FAQs