SaaS Strategy
AI Didn't Kill Seat-Based Pricing. It Turned the Seat Into Packaging.
By Nishant Kadian ยท Jun 21, 2026
For the better part of a decade, every SaaS pricing conversation I've sat in started the same way: how many seats. Sales reps counted heads, finance modeled ARR off headcount, procurement signed contracts shaped around how many people would log in. That conversation is getting quieter. What's replacing it isn't usage-based pricing in the clean, textbook sense everyone's writing about right now. It's something messier: seats that still exist on the invoice, while the real cost driver moves underneath them.
Agentforce: From $2 a Conversation to a Credit-Stuffed Seat
Salesforce is the clearest example, and it's worth walking through because the company didn't get this wrong. It ran into a problem nobody had solved yet. Agentforce launched in late 2024 priced at $2 per conversation. On paper, simple. In practice, almost nobody could agree on what counted as one conversation. A multi-turn exchange, a mid-thread handoff to a human, an agent that ran eight backend actions to answer one question, none of it metered cleanly. Early adoption was slow, because buyers couldn't model a bill they couldn't predict. By May 2025, Salesforce moved to Flex Credits: $0.10 per action, sold in blocks of 100,000 for $500. That fixed the metering problem. It didn't fix the procurement problem, credits are hard to forecast before you've run an agent in production for a few months, and enterprise buyers don't love walking into a renewal with a number they can't predict.
So Salesforce brought seats back. Per-user Agentforce licenses now run roughly $125 to $550 a month, and the top tier bundles in a fixed allotment of AI and data credits. To a buyer, that reads like a familiar Salesforce seat. Underneath it, you're not really paying for a person, you're pre-paying for a chunk of agent consumption, wrapped in language procurement already knows how to approve. One Salesforce engineer reported seeing roughly a 10% seat reduction across 90 enterprise accounts, because agents are now doing work that used to require a person logged in. The seat count is shrinking. The seat label isn't.
Intercom: The Seat Stays, the Bill Doesn't
Intercom tells a quieter version of the same story. Seats are still the entry point, $29 to $139 per agent depending on plan. Fin, its AI agent, is billed separately at $0.99 per resolved conversation, on top of whatever seats you're already paying for. At low volume, that's a rounding error. At real support volume, independent cost breakdowns have put Fin's resolution fees at the majority of the total bill, in one published example, close to 80%. The seat is still the thing you click "buy" on. It's no longer the thing driving the number on the invoice.
Lovable: No Seat to Begin With
Then there's Lovable, which never bothered with the wrapper. It's priced entirely on build credits, shared across an entire workspace regardless of how many people are logged in. A team of two and a team of twenty pay the same if they burn the same credits. There's no seat to dress up, because there was never a seat to begin with.
Same Shift, Three Different Disguises
The three aren't running the same playbook, and that's the point. Salesforce kept the seat as the default purchase order and tucked consumption inside it. Intercom kept the seat as the floor and stacked consumption visibly on top of it. Lovable skipped the seat entirely and let credits be the only unit anyone buys. None of these choices is wrong, they're just answering a different question about how much pricing transparency a buyer can absorb at the point of purchase.
Three companies, three different starting points, the same underlying shift: credits, tokens, and actions are what's actually metering cost now. Seats are increasingly just the packaging customers are used to buying.
That's the part most "seats are dying" takes miss. Seat-based pricing isn't actually dying. It's being used as packaging for a cost structure that's shifted underneath it. Vendors keep the familiar per-user unit on the price page because buyers trust it and procurement can model it without a forecasting exercise, while the real meter, credits, tokens, agent actions, runs behind it. Most buyers don't notice until the bill arrives.
Voice and CPaaS Got Here First
This isn't new, by the way. Voice and CPaaS companies, Exotel, Acefone, Ameyo, the kind of platforms I've worked alongside for years, have priced their voicebot and streaming products on usage since before "AI pricing" was a category anyone wrote about. Nobody called it a trend. It was just how you price something that runs unpredictably and scales by event, not by login. What's changed is that this logic has moved from the edge of the SaaS stack into the core of it, because AI agents broke the assumption seat pricing was built on: that cost scales with how many humans are using the product. It doesn't anymore. It scales with how much work the product is doing, with or without a human attached.
How to Price an AI Agent Without Lying About the Cost
If you're building an AI agent pricing model right now, the seat-versus-usage debate is the wrong question to spend time on. The real question is which one is actually metering your cost, and whether your pricing page admits it. If your AI feature's marginal cost scales with usage, and for almost anything built on inference, it does, a flat per-seat price will eventually underprice your heaviest users or overprice your lightest. Keep the seat as the buyable unit if your buyers need that predictability; Salesforce and Intercom both made that bet deliberately. But name the consumption unit precisely. "Per resolution" tells a buyer something concrete. "Per credit" or "per token" tells them nothing until they've burned through a month of usage and reverse-engineered what a credit actually buys. Don't let the seat lie about where the cost is coming from, and don't let the credit hide behind a unit nobody can picture. That's the mistake worth avoiding, not which model you choose, but pretending your pricing page reflects a cost structure it doesn't.