What Does a "Seat" Even Mean Any More?

For thirty years, software vendors had a reliable answer to the question "how do we charge for this?" Count the users. One login, one seat, one monthly fee. It was simple, it was auditable, and it scaled roughly in line with how much value the customer was getting.

That logic is quietly falling apart. And most vendors have not noticed yet.

Why per-seat pricing worked in the first place

The model made intuitive sense in a world where software was operated by humans. If you bought a CRM licence for ten salespeople, ten people were doing ten people's worth of work. The number of seats was a reasonable proxy for the value flowing through the system.

The same was true for project management tools, email platforms, design software, spreadsheets. Every active user was a human, doing something, producing something. Scale the team, add seats. Shrink the team, remove them. The pricing moved in step with the operation.

Vendors loved it because it created a natural expansion motion. Your customer hires more people? Revenue goes up automatically. No renegotiation needed.

The assumption that is now breaking

Per-seat pricing rests on a hidden assumption: that the number of logins is a reasonable stand-in for the amount of work getting done. When every actor in the system is human, that assumption holds.

It stops holding the moment agents enter the picture.

Consider a solo consultant who uses an AI agent to monitor competitors, draft proposals, handle initial client triage, and process invoices. That is one human login. But the output is the kind of output that might once have taken a small team to produce. Should the vendor charge one seat? Or five? Neither answer is obviously right.

Now scale that up. A ten-person operations team, augmented with a fleet of agents that handle routine processing, flag exceptions, and prepare reports. The number of human seats might stay flat or even fall. The value extracted from the platform goes up significantly. Under per-seat pricing, the vendor captures none of that upside.

This is not a hypothetical. It is already happening in companies that are serious about AI adoption.

The vendors who are feeling it first

The tension is most visible in categories where AI displacement of human tasks is furthest along: customer support software, document processing, data entry and enrichment, legal research, basic financial analysis.

Support platforms built their entire business on charging per agent seat. A company with fifty support staff paid for fifty seats. Now the same company runs twenty human agents alongside AI agents that handle the majority of tier-one tickets. Their seat count drops. Their support volume stays the same. The vendor loses revenue while the customer gets the same or better outcome.

Intercom and Zendesk have moved furthest toward outcome pricing: Intercom's Fin charges per resolved outcome at $0.99, and Zendesk offers per-automated-resolution pricing in a similar range. Salesforce tried the same direction with Agentforce, launched in 2024 at $2 per conversation, but has since partly reverted toward seat-anchored enterprise agreements under customer and procurement pressure. That reversal is itself instructive: it is not that buyers do not want value-based pricing in principle, it is that their procurement and finance processes were built around headcounts and resist the shift. All three are patching the model rather than replacing it, and the Salesforce pullback shows how hard that patching is in practice.

What the alternatives look like

A few pricing models are emerging as plausible replacements, each with their own trade-offs.

Outcome-based pricing charges for results rather than access. A support platform might charge per resolved ticket. A document platform charges per processed contract. The vendor earns more when the customer gets more value. The problem is that "outcome" is often hard to define and even harder to verify at scale. Who decides when a ticket is genuinely resolved?

Usage-based pricing charges for consumption: API calls, tokens processed, documents run through the system. This is already common in infrastructure (AWS charges per compute-hour, Twilio per message sent). It is increasingly showing up in AI tooling. The downside is unpredictability. Customers hate bills that spike unexpectedly, and finance teams resist tools they cannot budget for reliably.

Capability tiers sell access to different levels of power rather than headcount. You pay for what the platform can do, not for how many people are doing it. This works well for platforms where the core differentiator is the intelligence itself. It maps poorly onto tools that are genuinely multi-user in their collaboration features.

Hybrid models combine a base platform fee (covering access and collaboration for human users) with a usage or outcome layer for agent-driven work. This is probably where most B2B software ends up, at least in the medium term. It keeps the simplicity of seats for the human layer while capturing value from the AI layer.

The honest problem with all of them

None of these models is clean. Outcome-based pricing requires agreement on what an outcome is. Usage-based pricing creates anxiety. Hybrid models are complex to explain and complex to audit.

Per-seat was sticky partly because it was so easy to understand. You have ten people, you pay for ten seats. Any replacement model has to clear a higher bar in terms of trust and transparency, because the customer can no longer verify the bill just by counting heads.

There is also a procurement problem. Enterprise buying processes were built around seat counts. Legal, finance and IT security teams know how to evaluate a "per user per month" proposal. They are much less comfortable with "per outcome" or "per 1,000 API calls". Changing the pricing model often means changing the buying process too, which is a slow, institutional shift.

What buyers should be doing right now

If you are evaluating or renewing software contracts, the per-seat question is worth pressing on explicitly. Ask the vendor how they think about pricing as your AI usage grows. If you deploy agents that interact with their platform, how does that affect your bill? If they have not thought about it, that is useful information.

Some vendors will try to count agent interactions as additional seats. Others will ignore them entirely (for now). A few are genuinely building pricing that accounts for the new reality. Knowing which camp your vendor is in matters for long-term cost planning.

It is also worth thinking about your own internal accounting. If a single employee plus an AI setup is producing the output of three people, the value of that employee to your business has gone up considerably. How you pay for their tools should probably reflect that, even if the vendors have not caught up yet.

A short history of how we ended up pricing software per seat (optional, click to expand)

Per-seat licensing did not emerge from a grand theory of pricing. It emerged from a very practical problem: how do you stop people copying software?

In the early days of commercial software, the industry tried all sorts of approaches. Dongles (physical keys that plugged into your computer). Product activation codes. Feature-limited shareware. None of it was elegant, and all of it was annoying.

The enterprise licensing model that emerged in the 1980s and 1990s solved the problem differently. Instead of locking the software itself, vendors licensed it to organisations by the number of authorised users. You agreed contractually to limit usage to a defined number of people. Audits enforced the cap. This made billing predictable and enforcement manageable without requiring technological DRM.

When SaaS arrived in the late 1990s and early 2000s, it inherited the per-seat model almost by default. Salesforce and its contemporaries moved software to the cloud, but kept the user-count logic intact. A seat became a login rather than a licence key, but the underlying structure was unchanged.

The model proved extraordinarily durable. It survived the mobile revolution (per-seat became per-device where needed), the API economy (developers were often excluded from seat counts or given separate developer tiers), and the freemium era (free seats up to a limit, paid above it). The unit economics were so well understood by both vendors and buyers that it became the default without anyone explicitly choosing it.

The AI shift is the first genuine challenge to that default in thirty years. It is not that per-seat is wrong, exactly. It is that it was always a proxy for value, and the proxy has stopped tracking what it was supposed to measure.

How AI with Ash can support you

If you are building AI into your operation and trying to work out what that means for your software costs, contracts or procurement strategy, it helps to have someone who has thought about this from both sides. I work with businesses to design AI workflows that actually fit the way they operate, and that includes thinking through the commercial implications, not just the technical ones.

Book a call and we can talk through what makes sense for your situation specifically.