What seats were actually measuring

Seat pricing made sense for twenty years because it was a reasonable proxy for value. One sales rep used the CRM. One designer used the design tool. One support agent used the helpdesk. You could literally count your customers by the number of logins. More humans, more seats, more ARR. Beautifully linear.

Dropbox's growth charts from 2012 to 2019 look like a textbook. Revenue tracked headcount. Headcount tracked growth. Nobody questioned it because nobody had a reason to.

Then three things broke the logic at once.

• Agents don't log in. Work that used to require a licensed user now runs through an API, and the agent doesn't have a browser tab.
• Ten people with AI can do what a hundred people did before, so headcount stops scaling with output. Seat count per customer flattens or shrinks even when usage goes up.
• Every AI feature that makes your product more useful reduces the number of humans needed to get the same work done. Seat expansion becomes self-defeating. Your best product improvements shrink your own revenue base.

This is the structure of AI-era software, not a set of edge cases.

Where the value went

Seat pricing didn't die in one day, but the margin migrated.

One enterprise customer with five seats might drive more inference cost than a mid-market account with fifty but your pricing didn't account for it and your billing system doesn't know that. That also means your pricing doesn't reflect it and your sales rep can't quote it in a sales led motion.

The CFO who approved $59/seat/month for 200 seats last year is looking at an AI tools budget line that keeps growing without a corresponding headcount reduction. That conversation gets harder every quarter.

Hybrid pricing is a holding pattern

I see tons of companies respond by adding usage components to their seat plans, like seats plus credits plus overage. I think this is temporary even if it's the hot new thing for 2026.

Hybrid pricing is what disruption looks like from the inside and you can see it in product telemetry across the industry: seat count per customer is flat or shrinking while compute cost per customer rises - and AI adoption cuts user logins and increases workload volume simultaneously.

Worth doing, sure, but you should know what you're buying.

The billing system is the real constraint

Here's the part that doesn't get enough attention.

When billing can only model seats, reps can only sell seats. Not because reps are lazy, but because the system literally cannot express what the deal needs to be.

It becomes a spreadsheet, a Slack thread, a manual invoice, and a promise that someone will sort it out later.

So reps either push the deal desk to approve something the system can't handle, or they sell what the system can quote and leave AI value off the invoice entirely. The first creates operational debt. The second leaves revenue on the table.

The bottleneck is never the sales team. It's not the product. It's the revenue architecture.

What replaces it

The destination is per-work pricing. Not per-seat. Not per-token. Per-work.

Three archetypes are already operating in the market:

The line connecting all three: value tracks work done, not humans doing it.

• Lovable Dropped seats entirely and moved to credits only.
• Salesforce Launched Agentforce as a separate product — different buying motion, fundamentally different value proposition from Sales Cloud.
• Intercom Priced Fin per resolution, not per agent.

These aren't experiments. They're signals. Bain puts it at 65% of SaaS companies with AI features having already moved away from pure seat pricing. The other 35% are mostly considering it.

The messy part is transition. Your existing customers are on seat-based contracts with annual terms. Migrating them means renegotiating every deal, or at least communicating changes well ahead. Customers on favorable per-seat rates won't want to switch. You'll run both models simultaneously for years.

That's fine, but your billing infrastructure has to support it. Two models, same customer, same period, same invoice. Most billing v1 stacks can't do that without significant engineering work that has nothing to do with your product.

What you should be asking yourself now

Before you finalize your next pricing page, ask one question: what does your AI agent actually deliver?

I trust it's not how many tokens it consumes, how many users it serves. It's more about what unit of work it completes. That's what you should bill for, and you can't price for what you can't measure.

I consult people daily who are still finding that answer. You too deserve a model built on real visibility into what the product delivers, which is harder to copy than a number on a pricing page. That's your moat.