A lot of SaaS founders are asking the same question right now: should we keep charging per seat, or move to usage-based pricing?
It sounds like a choice between two different business models. But I think we’re starting in the wrong place. A seat and a unit of usage are simply two ways to count what customers pay for. Before choosing how to count, we need to decide what we’re actually selling.
[Image: the same product priced two ways, per seat (counting the people who log in) and per result (counting the work done).]
Start with what the customer buys
Every pricing decision has three parts: what you charge for, how much you charge and when the customer pays. I explain that distinction in “Seven things a customer can pay for (opens in a new tab).”
Take a typical SaaS product. The customer pays to use software they don’t own. You host it, maintain it, fix problems and keep improving it. That’s access.
Charging per seat simply means you count that access one user at a time. Charging per API call, transaction or gigabyte means you count it differently. Neither method tells us, on its own, what value the customer is buying.
That’s why I’d settle the question of what we sell first. Then I’d choose the right way to measure it.
Why charging per seat is getting harder
For years, the logic was straightforward. More people used the software, so customers usually got more value and paid for more seats.
AI changes that relationship. Say an AI agent now answers questions that once needed five employees to log in. Your software may be doing more useful work than ever, but the customer needs fewer seats. Your product improves while your revenue falls.
Intercom offers a useful example. It still charges for its helpdesk based on seats, but its Fin AI agent has a separate charge of $0.99 per outcome. An outcome counts when Fin resolves a conversation or completes a defined task. If it doesn’t resolve the issue, there’s no outcome charge.1
Notice what Intercom is counting. Not the number of messages. Not the number of tokens. It charges for a result. The helpdesk is still access, measured in seats. Fin is an outcome, measured in resolutions.
Of course, that creates another problem: who decides the result happened? Intercom can count an “assumed resolution” when someone receives an answer and leaves without asking for more help.1 But did that person get what they needed, or did they just give up? When you charge for results, you also need clear rules for measuring them.
“Usage-based” can mean very different things
When someone suggests usage-based pricing, my first question is: usage of what? The answer changes what you’re selling and who takes the risk if the product doesn’t deliver value.
| What you count | What you’re charging for | Who takes the risk |
|---|---|---|
| Seats or logins | Access | The customer |
| Compute time or storage | Access | The customer |
| AI tokens or API calls | Effort: the machine does work | Mostly the customer |
| Delivered reports or documents | Output: something tangible is delivered | Both sides |
| Resolved tickets or closed deals | Outcome: a result happens | Mostly the seller |
Here’s the practical difference. Charge per token and your customer pays for the AI’s work, even if it produces a long, unhelpful answer. Charge per resolved ticket and you earn the fee only when the issue is resolved. That’s a much bigger commitment.
It also changes how buyers judge your price. With tokens, they compare your rate with other token prices. With resolved tickets, they compare your fee with the value of getting those tickets off their team’s workload.
Ask these three questions instead
- What are we selling? Is the customer paying for access, work performed, a finished deliverable or a result? A product can sell more than one of these.
- What should we count? Pick a measure that increases as the customer gets more value. Make sure both sides can check the number and agree on it.
- Could we charge for a result? If AI now performs a task rather than helping a person do it, is there a clear, measurable result we can price?
I’m not saying seats have to go. If people log in every day and the software helps them do their jobs, charging per person can still make sense.
But when the software starts doing the job for them, counting the people who log in may no longer reflect the value it delivers. That part of the product needs a different measure.
The point
I wouldn’t start a pricing discussion with “per-seat or usage-based?” I’d start with “What does this product actually do for the customer, and what are they paying us to deliver?”
Keep seats where they make sense. When AI produces a measurable result, consider charging for that result. Choose the unit after you’ve made that decision, not before.
Here’s the question I’d leave any SaaS founder with: if your AI does more of the work today, does your pricing reflect that, or are you still charging for the people it no longer needs?
Source
1 Intercom, Fin AI Agent outcomes, accessed 19 October 2026.