Founders love to ask which SaaS pricing model is winning right now. Seat-based? Usage-based? Credits? Outcome-based? Three tiers with an enterprise CTA?
That question sounds strategic, but it usually hides a messier truth: most pricing pages fail because the company is mixing up two separate decisions.
Your pricing model is how the invoice works. Your packaging is how the buyer understands what they are getting.
Those are not the same thing.
A per-seat model is a licensing decision. Usage-based pricing is a licensing decision. Flat-rate pricing is a licensing decision. Tiered editions are a packaging decision: which capabilities, limits, support levels, integrations, security controls, and promises belong together. You can run tiered editions on seats, usage, flat fees, credits, or a hybrid of all of the above.[1]
The distinction matters because the buyer is not evaluating your pricing architecture. They are asking three simpler questions:
- Do I understand what I am buying?
- Will the bill grow in a way that feels fair?
- Can I defend this purchase internally without becoming your pricing translator?
If the answer to any of those is no, your model is not sophisticated. It is just expensive to explain.
The model is the meter. The package is the promise.
A pricing model tells the customer what variable moves the bill. Seats. API calls. contacts. messages. resolutions. storage. credits. invoices processed. agents deployed.
A package tells the customer what kind of customer they are becoming. Starter. Growth. Business. Enterprise. Developer. Team. Scale.
When teams confuse the two, they create tiers that are really just arbitrary fences around a metric. That is how you get plans where the feature buyers need is in the wrong edition, the usage allowance is too small for serious evaluation, and the sales team immediately starts discounting around the page.
The better order is:
- Pick the value metric that grows with customer value.
- Decide where the vendor needs margin protection.
- Build packages around buyer maturity and procurement legibility.
- Add guardrails so variable spend does not feel like a trap.
This is why most B2B SaaS eventually becomes hybrid. Per-seat works when value scales with headcount. Usage-based works when consumption is a good proxy for value and does not punish adoption. Tiered editions help procurement compare options quickly. The strongest pages combine these without making the customer do algebra.[1]
Hybrid pricing is not a trend. It is a compromise with reality.
Look at the market and the pattern is obvious. Slack prices per user inside tiered plans. Twilio is closer to pure usage. Basecamp has long been a flat-rate counterexample. Microsoft Copilot combines a per-user base with additional usage capacity, while Atlassian blends subscription, bundled AI entitlements, and consumption overages. Zendesk and Salesforce Agentforce are pushing AI pricing toward per-conversation or per-resolution units.[2]
These are not random experiments. They are responses to different value curves.
If the product becomes more valuable as more people collaborate, seats can work. If value comes from transactions, automation volume, or infrastructure consumed, usage is more natural. If the buyer needs predictable budgeting, a subscription floor helps. If the vendor faces real variable costs, overages or credits protect gross margin.
The problem is that hybrid pricing can be designed from the vendor spreadsheet instead of the buyer conversation.
That is when you see:
- A subscription fee that does not clearly buy anything.
- A usage meter that customers cannot forecast.
- Credits that obscure rather than simplify cost.
- Editions named by internal roadmap history, not customer maturity.
- Add-ons that feel like ransom notes for expected functionality.
Hybrid is not automatically clearer than seat-based pricing. It is just more honest about the fact that value and cost rarely scale on one clean axis.
AI made the second half of pricing impossible to ignore.
Before AI, many SaaS companies could tolerate fuzzy alignment between price and cost. A customer might use a lot of product, but the marginal cost was often low enough that the model survived.
AI changed that. Two customers on the same plan can create wildly different cost profiles. One sends short prompts to a small model. Another runs long agentic workflows, retries failed steps, calls tools, stores context, and escalates difficult tasks to more expensive reasoning models. The revenue line may look identical. The gross margin does not.[5]
That is why pricing now has two jobs.
The first job is commercial: decide whether the customer buys access, seats, credits, usage, outcomes, or a bundle.
The second job is operational: decide what the customer can do next based on entitlements, wallet balance, accumulated charges, contract terms, and margin exposure.[5]
Most founders still obsess over the first job. The painful surprises live in the second.
Usage pricing moves risk. Under a fixed subscription, the vendor absorbs consumption risk. Under usage-based pricing, more risk moves to the buyer, who now has to forecast spend from API calls, tokens, model mix, agent steps, or some other volatile unit.[5] That is not inherently unfair. It becomes unfair when the only moment the buyer understands the bill is after the product has already spent the money.
Zylo’s 2026 SaaS Management Index, cited by Lago, found that organizations spent an average of $1.2 million on AI-native applications, up 108% year over year, and that 78% of IT leaders reported unexpected charges tied to consumption-based or AI pricing.[5]
That number should scare anyone selling AI software. Surprise is not a monetization strategy. It is churn with a delay.
The customer does not call it packaging. They call it weird.
Pricing people like me use polite language: friction, opacity, misaligned incentives, poor metric fit.
Customers are less diplomatic. In one Hacker News discussion about SaaS convenience, a commenter put it plainly: when pricing gets weird, people start asking what they are really paying for.[8]
That reaction matters. It is easy for SaaS teams to dismiss online complaint threads as noise, but they reveal a real psychological threshold. Buyers will tolerate a premium when the product is essential, convenient, trusted, and easy to justify. They become hostile when the bill feels detached from perceived value.
This is especially dangerous for AI products because the value story is often still forming. If the customer cannot tell whether they are paying for intelligence, compute, automation, seats, workflow completion, or vendor margin anxiety, they will assume the worst.
A pricing page should not make the buyer feel like they are entering a casino.
A practical framework for the next pricing redesign
When I help a team reprice, I try to separate four decisions that founders often collapse into one workshop.
1. Choose the value metric before choosing the page layout.
A good value metric grows as the customer gets more value, is understandable before purchase, is measurable after purchase, and does not discourage the behavior you want.
Seats are simple, but they can suppress adoption if the product gets more valuable when more people participate. Usage is elegant when consumption maps to value, but it can make customers ration the product. Outcomes are powerful when the result is auditable, but dangerous when attribution is fuzzy.
A strong B2B SaaS strategy starts by identifying the value metric that scales with delivered value, rather than pricing around the cost of building the feature.[2]
2. Build editions around buyer maturity, not feature inventory.
Most tiering mistakes come from treating the product roadmap as the package architecture.
A better tier should answer: what is different about this buyer?
- Do they have more users?
- More risk?
- More workflow complexity?
- More compliance requirements?
- More integration needs?
- More internal stakeholders?
- More need for predictability?
That is why security, admin controls, audit logs, support commitments, governance, and custom contracts often belong in higher editions. Not because they are nice-to-have features, but because they match a more complex buying environment.
Keep the number of tiers small. Three to five editions is usually enough to create choice without forcing the buyer into a comparison spreadsheet.[4]
3. Put shock absorbers around every variable charge.
If usage is part of the model, design the emotional experience of usage.
That means:
- Included allowances that match normal early adoption.
- Clear overage rates.
- Spend alerts before the customer crosses a threshold.
- Hard caps or soft caps where appropriate.
- Admin controls for who can trigger expensive actions.
- Forecasting tools for finance and operations teams.
- Plain-language invoices that map charges back to business activity.
The goal is not to hide cost. The goal is to make cost feel governable.
AI-native companies especially need this because the product can spend money before the invoice exists.[5] If your customer needs a forensic analyst to understand last month’s model usage, you have not built pricing infrastructure. You have built resentment infrastructure.
4. Localize willingness to pay, not just currency.
Global pricing is another place where companies confuse mechanics with strategy. Translating dollars into euros or rupees is not localization. It is formatting.
Willingness to pay for the same software can vary by 20-40% between markets, and checkout expectations differ by region. Tax-inclusive pricing may feel normal in Europe while tax-exclusive pricing is expected in the US.[7]
If you sell internationally, your packaging still needs one coherent value story, but your price points, payment methods, tax treatment, and procurement assumptions may need local adaptation.
5. Make billing flexibility a product requirement.
Pricing strategy dies when billing systems cannot support it.
If you are early, this sounds boring. It is not. Billing constraints become pricing constraints faster than founders expect. If your next 12 months may include seats, usage, hybrid contracts, proration, mid-cycle upgrades, credits, localized checkout, or AI metering, your billing infrastructure needs to support that before the sales team starts inventing workarounds.[7]
The wrong billing setup turns every pricing experiment into an engineering project. That makes the company slower, and slow pricing teams leave money on the table.
The 10x rule is useful, but incomplete.
Value-based pricing is still the north star. If a customer pays $10,000, they should believe they are getting a multiple of that in saved time, reduced risk, new revenue, or avoided headcount. Many founders use the 10x rule as a heuristic: deliver at least ten times what you charge.[4]
But value-based pricing does not remove the need for a good metric. It just tells you where the ceiling might be.
A customer may believe your product is worth $100,000 a year and still reject your pricing if the meter is unpredictable, the package hides essential controls, or the expansion path punishes success.
That is why I like to ask four questions in order:
- What value do we create?
- Who recognizes that value?
- What unit makes that value measurable and fair?
- What package makes the buying decision obvious?
Most pricing debates start at question three. Most of the answers live in questions one and two.
Your pricing page should pass the one-meeting test.
The one-meeting test is simple: can a champion explain your pricing to their CFO, procurement lead, or department head in one meeting without bringing you in?
If not, the issue is not just conversion. It is sales velocity, trust, and expansion.
A pricing page that passes the test usually has:
- A clear base promise for each edition.
- One primary value metric.
- A visible included allowance if usage exists.
- Predictable expansion rules.
- Enterprise controls packaged where enterprise buyers expect them.
- Minimal add-ons, reserved for genuinely optional value.
- Plain descriptions instead of pricing jargon.
A pricing page that fails the test often has multiple meters, hidden limits, vague credits, too many plan differences, and an enterprise tier that is basically a junk drawer.
The work is never finished.
No pricing model is permanent. Markets move, AI costs shift, customer segments mature, competitors reset anchors, and your own product changes. Several pricing guides now emphasize regular review and a willingness to adjust as evidence comes in.[4]
I would go further: pricing should have a cadence.
Every six months, review:
- Win-loss notes by segment.
- Discounting patterns.
- Gross margin by customer cohort.
- Expansion and contraction behavior.
- Usage distribution and outliers.
- Support tickets about billing confusion.
- Sales calls where price explanation consumed too much time.
- Customers whose value received is clearly above or below their spend.
Do not reprice every six months. But inspect every six months.
Because the goal is not to find the perfect pricing model. The goal is to keep your model, packages, costs, and buyer expectations in tension without letting any one of them snap.
Hybrid pricing is where most B2B SaaS is headed, especially with AI in the product. But hybrid only works when the floor is understandable, the meter is fair, and the promise is worth defending.
If the customer can tell what they are buying, why the price grows, and how to control the bill, complexity becomes acceptable.
If they cannot, even your most elegant model will feel like weird pricing.
References
- SaaS Pricing Models Compared: Why Most B2B Goes Hybrid — https://softwarepricing.com/blog/saas-pricing-models
- SaaS Pricing Models: The Complete Guide for Businesses — https://vinzotechblog.com/saas-pricing-models
- The Ultimate Guide to SaaS Pricing Strategies and Models | SBO — https://sbo.financial/blog/startups/saas-pricing-strategies-models
- The AI pricing shift nobody priced correctly | Lago — https://getlago.com/blog/the-second-half-of-pricing
- How to evaluate a Merchant of Record in 2026 | Paddle — https://www.paddle.com/resources/how-to-evaluate-a-merchant-of-record
- The bread paradox: why convenience always wins, and why SaaS isn’t doomed | Hacker News — https://news.ycombinator.com/item?id=48896672
Leave a Reply