SaaS Isn't Dying. The Seat Is.

Every few weeks someone tells me SaaS is over. Companies will build their own software with AI, the argument goes, and the subscription business collapses.

I understand why people say it. I don't think it's right.

The software isn't going anywhere. Your ERP, your CRM, your payroll system will still be there in five years, and someone will still be paying for them. What's going away is the way we've priced most of it: a fixed fee per person, per month, whether that person logs in daily or once a quarter.

The seat made sense when the user was a human sitting in front of a screen. That assumption is breaking, and most of the industry's billing systems were built on it.

Three things are happening at once

The "end of SaaS" story usually lumps three separate changes together. They have different causes, and they lead to different places.

Building software got cheaper. AI coding tools let an internal team build in weeks what used to take a year. That's real. But building was never the expensive part. Running software is: keeping it secure, patched, compliant and available at 2 a.m. when something breaks. Companies will build more of their own tools, mostly the thin ones. They won't rebuild their system of record.

The user is changing. More and more, the thing calling your product is an agent, not a person. An agent doesn't need your dashboard. It needs an API, a clear description of what it can do, and a price it can work with. You can't charge an agent for a seat. It doesn't have one.

The cost of serving a customer stopped being flat. Every AI feature costs money each time it runs. One customer can cost you fifty times more than another on the same plan. A fixed per-seat price quietly turns your heaviest users into your least profitable ones.

Put those together and you get the shift that's actually underway. Vendors are moving from selling access to selling capabilities: a resolved ticket, a scored lead, a thousand API calls, an hour of an agent's work.

What vendors are actually doing

You can already see this in the pricing pages of companies that sell AI to large customers.

Salesforce first priced its Agentforce agents at $2 per conversation. In May 2025 it moved to Flex Credits: $0.10 per action the agent takes, with no charge when the agent doesn't do anything. A sales agent that answers a question and books a meeting might run three to six actions. The unit went from "a conversation" to "a thing the agent did."

Zendesk went further. In August 2024 it announced outcome-based pricing for its AI agents: customers pay only when an issue is resolved without a human. Intercom charges $0.99 per resolution for its Fin agent.

Most companies are landing somewhere in between. A platform fee covers the relationship. Usage or credits cover the variable work. An outcome tier sits on top for the use cases where success is easy to agree on.

None of these models is exotic anymore. What's still hard is everything underneath them.

The price changes. The plumbing doesn't.

Changing a number on a pricing page takes an afternoon. Changing what a company can actually measure, enforce and bill takes a lot longer.

I spent five years on API monetization at Google Cloud, and before that years on API strategy at AT&T. At Google I worked with large companies on charging for the APIs they ran through our gateway. The rate plan lived in the gateway, the invoice lived in the billing system, and the product manager who owned the API filed tickets with two teams to change a price. The pricing model was rarely the hard part. The hard part was everything that had to be true for the price to hold up.

A seat-based billing system answers one question at the end of the month: how many people had access? Selling capabilities means answering harder questions, and answering some of them in real time:

• What exactly is the customer buying? An agent can't read your sales deck. It needs a catalog that describes each capability, its limits and its price in a form software can understand.
• Is this request allowed right now? If a customer has used up their credits, the next call should be stopped or slowed before it runs, not discovered on an invoice three weeks later. Every call that runs past the limit is compute you pay for and may never collect on.
• What did it cost, and what do we charge? Usage has to be counted accurately, priced against the right plan version, and turned into an invoice a finance team will accept.
• Can the customer check our math? When the bill depends on usage, the buyer wants to see where every line came from.

Billing tools are built to answer the third question. The other three usually live in separate systems owned by different teams, and that's where things break. It matters most when the buyer is a piece of software making thousands of decisions a minute.

A worked example: adding AI to a product priced by the seat

Say you run a project-management product. Customers pay $30 per user per month. Your team ships an AI agent that triages incoming requests, and a few large customers want to call it from their own agents through an API.

You can't fold it into the seat price, because your heaviest customers would eat your margin. You can't drop seats either. They're most of your revenue, and every contract is written around them. So you end up running three prices at once:

• Seats stay where they are.
• Each plan includes a monthly pool of AI credits. One triage costs 1 credit. A full project plan written by the agent costs 20.
• API and MCP access for outside agents is sold separately, per call, with its own limits. (MCP is the emerging standard for how agents find and call tools.)

Here's what has to happen every time the agent runs:

1. Something checks whether this customer has credits left, in milliseconds, because a person or an agent is waiting. You also need to decide in advance what happens if that check is ever unavailable: let the call through, or stop it.
2. The call runs, usage is recorded, and the balance goes down.
3. At 80% used, the account admin gets a warning. At 100%, the customer is cut off, slowed down, or billed for overage, depending on their contract. Contracts will differ.
4. At month end, one invoice: seats, credits used, overage, API calls and tax, with every line traceable to the usage behind it.

Then next quarter you ship another AI feature, and sales wants to try a different credit price with new customers. This is the part that hurts most. When pricing lives in code, every pricing change becomes a sprint. And now every new feature arrives with a price attached, so pricing work lands on every release.

Where the work sits. The top row has to be right in milliseconds; the bottom row has to be right weeks later. If they disagree about what the customer bought, you give away compute or send a bill that gets disputed.

Look at where the work sits. Steps 1 to 3 happen at the gateway, live, on every request. Step 4 happens in billing, weeks later. Pricing changes fall in between, and usually no one owns them. If those pieces disagree about what the customer bought, you either give away compute or send a bill the customer disputes.

That gap is where most teams find out their stack was built for seats.

Outcome pricing: who decides what "success" means?

Outcome pricing is the most appealing model on paper. The customer pays only when the work actually worked. It's also where I see the most risk, because the hard question isn't technical. It's who gets to decide what counts as an outcome.

Look at how one public example works. Intercom counts a resolution when the customer confirms the answer helped, or when the customer leaves the conversation without asking for more help. That second case is reasonable, and it's also exactly what a skeptical CFO will question. Did the customer leave because the problem was solved, or because they gave up?

I don't think the answer is a smarter algorithm guessing at success. I think it's this:

1. The seller and the buyer define the outcome together, in writing. For example: a ticket is resolved if it's closed, no human was brought in, and it wasn't reopened within 72 hours.
2. The product sends the raw events. Ticket closed. Ticket escalated. Ticket reopened.
3. The platform checks those events against the agreed rule. It waits out the 72 hours, then confirms the outcome or cancels it.
4. The buyer can see the rule and the evidence behind every charge, and dispute any single one.

Same rule, two tickets. Neither side guesses: the outcome is decided by events both sides can see, against a rule both sides signed.

When the buyer can see the rule, the invoice stops being an argument.

This is harder to build than counting API calls. Every ticket has to be tracked over time, late events have to be handled, and a confirmed outcome sometimes has to be reversed. But it's the only version of outcome pricing I'd want to sign as a buyer.

What we're building at Aforo

This is why I started Aforo. We're building the layer between what a company sells and what it gets paid for: what's in the catalog, who is allowed to use what, and a bill that proves it. It works alongside the gateways, payment processors and accounting systems companies already run, so pricing can change as fast as the product does.

Aforo already bills on outcomes today. What we're working on now is taking it all the way to the model I described above: a rule both sides agree on, a waiting period before anything is billed, and evidence the buyer can check.

If your team keeps getting pricing tickets, or you're working out how to charge for something used by software instead of people, I'd like to compare notes. Write to me at jay@aforo.ai.

SaaS will be fine. The seat won't.

— Jay

Sources: Salesforce: Agentforce Flex Credits · Zendesk: outcome-based pricing for AI agents · Intercom: Fin AI Agent resolutions