The Seat Compression Spiral: When Success Destroys Your Own Revenue

If your software reduces the number of people a customer needs, and you charge per person, then delivering value costs you revenue. That is the seat compression spiral, and it is the clearest articulation of why the pricing model that built modern software is being abandoned. Pure per-seat pricing fell to roughly 15% of the SaaS market in a year.

The trap, stated plainly

Per-seat pricing was the best pricing model in software history because it tracked value almost perfectly. More people using the product meant more value delivered, and more revenue.

AI breaks the link in the worst possible direction. A product that lets ten people do the work of twenty is worth more to the customer and generates half the revenue.

The vendor's incentives invert. A per-seat vendor benefits from customers hiring, and is damaged by the exact outcome its marketing promises. Sales teams end up quietly hoping the product does not work too well, which is not a sustainable position for anyone.

This is not a hypothetical. It is why the enterprise software pricing conversation changed shape entirely inside about eighteen months.

What the market actually did

The destination is not pure consumption. Hybrid models reached roughly 37% of the market and correlate with the strongest net revenue retention, which suggests buyers want predictability and vendors want upside, and hybrid gives each side part of what it wants.

The pace of change is the other finding. Published research counted more than 1,800 pricing changes across the largest software and AI companies in a single year, most of them iterative rather than structural. Companies are experimenting continuously rather than making one decision.

Why this took eighteen months rather than five years

Pricing models normally change slowly because changing them is risky and the pressure is gradual. This one moved fast for a specific reason.

The pressure did not build gradually. It arrived with the first customer who deployed an agent successfully and then asked, at renewal, why they were paying for forty licences when twenty-five people now did the work.

That conversation happened across the industry at roughly the same time, because the capability arrived at roughly the same time. A gradual problem would have produced gradual change. A synchronised one produced a scramble.

The four ways out

Consumption

Charge for what the software does rather than who can access it. It solves the compression problem completely and creates a new one, because buyers cannot forecast the bill and finance teams cannot approve what they cannot forecast.

Outcome based

Charge per resolved ticket, per processed document or per completed task. It aligns perfectly with buyer value and requires a shared, auditable definition of success. Most contracts leave that definition to the vendor's own telemetry, which is where the disputes come from.

Platform fee plus usage

A base charge for access with variable usage on top. Predictable enough for procurement, elastic enough to capture growth, and complex enough that the pricing page needs a worked example. This is where most of the market has settled.

Change the value metric

Keep a simple per-unit model and change the unit to something that grows with customer success rather than headcount. Records under management, transactions processed, endpoints monitored. This is the cleanest exit where a suitable unit exists, and no such unit exists for many products.

Choosing between them

Two questions narrow it quickly.

First, does your product have a natural unit that grows when the customer succeeds? If yes, changing the value metric is the simplest exit and it preserves the predictability buyers value.

Second, can you and the customer agree on what counts as a completed outcome, in writing, before signing? If yes, outcome pricing is available. If the honest answer is that the definition would be contested, it is not, regardless of how attractive the model looks.

If neither applies, hybrid is the default and the reason it dominates. It is nobody's ideal model and it fails least often.

There is a third question worth asking before any of this, which is whether your product actually reduces headcount at all. Plenty of software increases what a team can do without changing its size, and those products are not in the trap and should not reprice as though they were.

The order to do this in

Step 2 is the one companies skip and the one that prevents most of the damage. Modelling the new pricing against last year's actual invoices tells you exactly which accounts will object and by how much, before anyone has to have that conversation.

What this means if you are buying

Every one of these transitions moves risk from the vendor to you, and most buyers accept it without negotiating the terms that matter.

The three worth asking for are a committed tier with defined overage pricing, a cap or notice period on unit price changes, and a written definition of the billable unit that does not rely solely on vendor telemetry.

None is unreasonable and vendors grant them more readily than buyers expect, particularly during a pricing transition when retention matters more than optimisation. The wider dynamic behind these costs is examined in the analysis of AI margins.

How to migrate without causing churn

Changing pricing on existing customers is where this most often goes wrong, and the failure mode is predictable.

A migration that increases cost at current usage reads as a price rise regardless of the strategic logic behind it. Customers do not evaluate your pricing model. They compare this year's invoice to last year's.

The approaches that work share one property: the new model is neutral or better at the customer's current usage, and captures upside only as usage grows. Grandfathering existing terms, offering a choice for a period, or capping the first year at the previous spend all achieve that.

The approach that fails is a repricing that increases cost immediately and justifies it by explaining the vendor's economics. Customers are not obliged to care about your margin structure, and telling them about it rarely helps.

The pattern across successful migrations

Companies that changed pricing without losing customers share one behaviour. They treated it as a product change requiring a rollout rather than a commercial decision requiring an announcement.

That means a pilot group, a feedback loop, a documented rollback position and an internal owner accountable for retention through the transition. Pricing changes handled by a pricing committee and communicated by email produce churn that no model design prevents.

Signs you are already in the spiral

Four symptoms, and they appear well before the revenue does.

Renewals where the customer requests fewer seats while describing the product positively. Sales conversations where the buyer's stated goal is doing more with the same team. Account managers avoiding usage-efficiency conversations. And a customer success function quietly measured on seat retention rather than outcomes.

That last one is the clearest tell. If your customer success team is incentivised on something the customer is actively trying to reduce, the misalignment is already structural and no messaging fixes it.

Where this argument is weak

Three problems.

Seat compression assumes AI actually reduces headcount, and the evidence for that at scale is thin. Most enterprises report absorbing productivity gains as higher output rather than fewer people, which would make the whole trap theoretical for now.

The market share figures also describe new and changed pricing rather than installed base. A great deal of software revenue still sits on per-seat contracts signed years ago and renewing unchanged.

And hybrid dominating may reflect indecision rather than optimisation. A model that combines two approaches is also the model you pick when you cannot commit to either, and correlation with retention does not establish that the pricing caused it.

Frequently asked questions

Where to start this week

If you sell software, answer one question in writing.

If your best customer used your product perfectly and reduced their team by 30%, what happens to your revenue from that account? If the answer is that it falls, you are in the trap, and the size of the fall tells you how urgent the exit is.

If you buy software, run the same question in reverse. A vendor whose revenue falls when you succeed has an incentive misaligned with yours, and that shows up eventually in what they build and how hard they push adoption.

Then ask them directly. A vendor that has thought about seat compression will have a clear answer about how their pricing evolves as your team gets more efficient. One that has not will change the subject, and that tells you what to expect at the renewal after next.

Related reading