The Death of Per-Seat SaaS: Why AI Is Forcing a Shift to Outcome-Based Billing
For most of the last fifteen years, SaaS pricing followed a fairly simple rule: charge for the number of people using the software.
The logic was easy to understand. A company hired more employees, bought more seats. A team grew from 20 people to 50, and the software bill grew with it.
That model worked extremely well for companies such as Salesforce, Jira, Slack, and Zendesk. The more people inside an organization who depended on the product, the more recurring revenue the software company generated.
AI is starting to challenge that logic.
The interesting part isn't simply that AI makes software more powerful. It's that AI can now do some of the work that previously required a human employee to sit inside the software.
Imagine a customer-support platform that can resolve thousands of conversations automatically. A company might eventually need fewer support agents because the AI is handling a large part of the workload.
Under a traditional per-seat contract, that's an awkward situation for the software vendor.
The customer becomes more productive, but the vendor could potentially sell fewer seats.
That's the pricing problem I think founders need to pay much more attention to.
Recent analysis from Bain & Company has also highlighted the tension between effort, usage, and outcomes in AI pricing. Other SaaS-focused analysts have similarly been examining what happens to traditional seat-based economics as software starts performing more work autonomously.
So I want to look at what is actually changing, the pricing models emerging around AI, and what founders should consider before changing their own monetization strategy.
1. The Productivity Paradox: Why Seats Start to Make Less Sense
For me, the biggest issue with per-seat pricing comes down to incentives.
The traditional SaaS model looks something like this:
More Human Employees
↓
More Software Seats
↓
Higher Vendor RevenueThat made sense when the human employee was doing most of the work.
But an AI-enabled product can change the relationship:
More AI Automation
↓
Fewer Human Tasks
↓
Potentially Fewer SeatsThat's where the old model starts to feel uncomfortable.
When software was mainly a workflow tool, charging by users was relatively intuitive. Humans were the ones creating tickets, updating CRM records, moving Kanban cards, writing notes, and reviewing dashboards.
In an increasingly agentic software environment, some of that work is being performed by the software itself.
So the question changes from:
"How many people use the product?"
to:
"How much useful work does the product actually perform?"
Consider a customer-support system resolving thousands of inquiries every day. If only a small number of human supervisors log in to review the results, charging primarily for those human logins doesn't necessarily capture the economic value being created by the system.
That doesn't mean every SaaS company needs to abandon seat pricing.
It does mean founders need to question whether seats are still the right unit of value for an AI-heavy product.
2. Three Pricing Models I See Emerging Beyond the Seat
The shift I'm seeing is essentially from charging for access toward charging for usage, work, or outcomes.
Model 1: Outcome-Based Pricing
The simplest version is:
The customer pays when the software achieves a defined outcome.
A good example is Intercom's Fin AI Agent, which uses outcome-oriented pricing for AI-powered customer support.
Instead of thinking purely in terms of how many support employees have access to the system, the pricing model can be connected to successful AI resolutions.
That creates a very different incentive structure.
If the AI successfully resolves a customer's issue, the vendor earns revenue.
If the AI can't resolve the problem and the conversation needs to be handled by a human, the economics can be different.
From the customer's perspective, this can make the software cost easier to justify because the payment is connected to something the business actually cares about.
But there's a catch for founders.
You need a very clear definition of an outcome.
What exactly counts as a successful resolution?
Does a customer clicking a button mean the issue was solved?
What happens if the customer returns two hours later?
What if the AI gives an incorrect answer but the customer doesn't immediately complain?
The more your pricing depends on outcomes, the more carefully you need to define and measure those outcomes.
Model 2: Work-Unit or Task-Based Pricing
Not every AI workflow has a clean binary outcome.
Think about:
- Contract analysis
- Data reconciliation
- Code generation
- Research
- Document processing
- Incident triage
- Lead enrichment
In these cases, startups can charge for a defined unit of work.
That unit might be called a credit, task, run, document, workflow execution, or something else.
For example:
1 Contract Parsed → $X
1 Incident Triaged → $X
1 Document Processed → $X
1 Workflow Executed → $XThe exact unit depends on the product.
I like this model because it moves the pricing conversation away from headcount without necessarily making the customer's bill completely unpredictable.
A company can estimate how many tasks it expects to process and budget accordingly.
The important part is making sure the work unit actually corresponds to something the customer understands.
If a "credit" is an arbitrary internal unit that has no relationship to customer value, pricing can quickly become confusing.
3. The Hybrid Model: Platform Fee + AI Usage
I don't think pure usage-based pricing will make sense for every SaaS business either.
AI workloads can fluctuate significantly.
One month a customer might process a relatively small amount of work. The next month, usage could increase dramatically.
That's why a hybrid structure can be attractive:
Monthly Invoice
=
Platform Fee
+
AI / Work UsageThe platform fee can cover things such as:
- Infrastructure
- Security
- Administration
- SSO
- Data storage
- User management
- Core software access
The usage component then captures the additional value created as the customer runs more automated workloads.
This gives the vendor a predictable recurring revenue base while still allowing revenue to grow when customers increase their use of AI-driven workflows.
For enterprise software in particular, I think this model deserves serious consideration because procurement teams usually want some degree of budget predictability.
4. AI Changes the Financial Metrics Too
Changing the pricing model isn't just a billing decision.
It changes the economics underneath the business.
A. Gross Margin Becomes Much More Important
Traditional SaaS businesses benefited from extremely low marginal delivery costs.
Once AI inference becomes part of the product, that assumption becomes less straightforward.
Every request can consume:
- Model tokens
- GPU compute
- API costs
- Storage
- Retrieval infrastructure
- Tool calls
- Additional processing
A customer who barely uses the product might be highly profitable.
Another customer running thousands of complex AI workflows could have a completely different cost profile.
That's why I would closely monitor gross margin after model inference costs rather than looking only at the headline subscription price.
The basic question is simple:
How much does it actually cost me to deliver the AI work I'm selling?
If I charge $1 for a task that costs me $1.20 to execute, increasing usage isn't necessarily good news.
B. NRR Can Grow Differently
Traditional SaaS companies often expand revenue when customers add more employees and therefore purchase more seats.
AI changes another part of that equation.
A customer might keep the same number of employees while dramatically increasing the amount of work processed through the software.
For example:
Year 1:
10 employees
10,000 automated tasks
Year 2:
10 employees
50,000 automated tasksThe customer didn't hire five times as many people.
But the amount of work flowing through the software increased substantially.
That creates a different path for expansion revenue.
The challenge is making sure the pricing model captures that additional value without making customers feel as though they're being punished for using the product more efficiently.
5. How I Would Approach the Transition
If I were building a SaaS product today that already uses per-seat pricing, I wouldn't immediately throw the existing model away.
I'd transition carefully.
Step 1: Don't Kill Per-Seat Pricing Overnight
If customers already understand your pricing, suddenly replacing it can create unnecessary friction.
A more gradual approach could be:
Human Seats
+
AI Usage / Work UnitsThe human seats cover collaboration and administration.
The AI component captures automated work.
That gives existing customers time to understand the new pricing structure instead of forcing them into an entirely different billing model overnight.
Step 2: Connect Pricing to a Metric the Customer Understands
I would avoid inventing complicated AI-specific billing units unless there is a good reason to do so.
Instead, I'd ask:
What business metric does my customer already understand?
For example:
| Product | Potential Pricing Metric |
|---|---|
| Customer support | Resolved conversations |
| Sales software | Qualified meetings |
| Accounting | Reconciled transactions |
| Document AI | Documents processed |
| DevOps | Incidents handled |
| Recruiting | Candidates screened |
The exact metric will depend on the product.
The principle is what matters:
Make the relationship between payment and value easy to understand.
Step 3: Give Customers Spending Controls
This becomes particularly important when autonomous systems are involved.
A human employee generally doesn't suddenly execute 50,000 software actions overnight without anyone noticing.
An automated agent potentially can.
That's why I'd want customers to have:
- Monthly usage limits
- Budget caps
- Usage alerts
- Per-workflow limits
- Approval requirements for expensive actions
- Clear usage dashboards
Nobody wants to discover that an autonomous workflow generated a surprisingly large invoice at the end of the month.
Predictability will remain important even if the pricing unit changes.
The Bigger Question: What Are Customers Actually Buying?
This is where I think the AI pricing conversation gets interesting.
Traditional SaaS largely sold software access.
You paid for the right to use a system.
AI increasingly allows software companies to sell completed work.
That's a fundamentally different proposition.
Instead of:
"Pay $50 per user so your employees can use our software."
the conversation can become:
"Pay us when our system completes this piece of work for you."
That doesn't automatically make outcome-based pricing better.
Some products will still make perfect sense with per-seat pricing. Collaboration software, for example, can remain tightly connected to the number of people using it.
But when the product itself begins performing meaningful amounts of labor, the pricing model may need to evolve with it.
Final Thoughts
I wouldn't describe this as the immediate "death" of per-seat SaaS.
I see it more as a change in what the software industry considers a unit of value.
For years, the number of users was a convenient proxy for value.
AI makes that proxy less reliable for certain categories of software.
If one employee can now supervise an AI system that performs work previously handled by an entire team, charging purely according to the number of employees may no longer capture what the customer is actually buying.
That creates an opportunity for startups to experiment with:
Outcome-based pricing
Work-unit pricing
Usage-based pricing
Hybrid platform + usage models
Human seats + autonomous work units
But there is an important warning here.
Outcome-based pricing only works when the outcome is measurable.
If customers cannot understand what they're paying for, the pricing model becomes a source of frustration rather than a competitive advantage.
So if I were designing an AI-native SaaS business today, I would start with one question:
What measurable piece of work does my software actually complete for the customer?
Once I can answer that clearly, the pricing model becomes much easier to design.
Disclaimer
Financial and business information published by JioAi is provided for general informational and educational purposes only. It should not be considered personalized investment, financial, or business advice. Readers should conduct their own research and consider their individual circumstances before making financial or business decisions.