Question
Why does per-seat pricing stick around when usage doesn't match seats
The standard argument is obvious: per-seat is predictable revenue, easy to bill, scales naturally with company size. Makes sense on paper. But I've watched this play out at two different companies now and it's weird how many products pick per-seat pricing for things where a seat is basically fiction.
We use a design tool where maybe 20% of our "seats" open it in any given month. The other 80% are there because we bought the bundle for the team and didn't want to manage revocation. The vendor knows this. They know seats sit idle. Per-seat still wins out over consumption because they'd rather have predictable ARR than actual usage metrics. Fair enough, that's capitalism. But they've also made the product harder to price fairly because now they're trapped optimizing for seat adoption instead of actual value delivery. Marketing pushes "give everyone access" which kills their LTV story.
At my last job we built something that actually should have been per-seat—collaboration tool, very seat-dependent—but we watched competitors aggressively push per-user storage buckets instead. The math worked better for them initially but they eventually switched back. Turns out usage-based models only win if your cost structure actually scales with usage. Most SaaS doesn't. You're already running the infrastructure for 10,000 seats or 1. So you default to the simplest billing model that doesn't require explaining anything to procurement.
The real problem is that per-seat is friction-free to sell, not friction-free to use. It works great until it doesn't.
2 comments
Log in to comment.
You're right that per-seat pricing persists because it solves a real sales problem, not a product one. But I'd push back slightly on the "trapped" framing—I think vendors stay with it because the alternative is actually harder than it looks.
The design tool example is the tell. Yeah, they know 80% of seats are dark. But switching to consumption pricing means they now have to answer: consumption of what exactly? Edits? Collaborators? File size? Concurrent users? Pick wrong and you've either made it cheaper for power users or you've made it incomprehensible to the buyer. Per-seat dodges this entirely. It's not elegant, but it's not ambiguous. And ambiguity kills deals with procurement more reliably than any pricing level does.
Your storage bucket example actually supports this—they switched back because usage-based models only "win" if they're simpler to explain and track than per-seat. They usually aren't. The infrastructure cost might not scale with usage, but the *support and legal surface area* absolutely does when you're tracking granular consumption data. At 3am when you're debugging why a customer's bill tripled, you'd rather be looking at "they bought 20 seats and used 15" than "they triggered 47 million API calls and we're disputing whether that includes cached reads." The per-seat model is cognitively compressible in a way usage-based rarely is.
I got burned by this exact dynamic at a previous gig. We had a log aggregation product that was nominally per-seat but our actual marginal cost was basically zero—we were already running the infrastructure, storage was cheap, the limiting factor was API rate limits and occasional database query contention. Per-seat made sense from a sales perspective because it felt fair and it was easy to explain to a CTO. Terrible from our ops perspective because we kept hitting scaling walls that had nothing to do with seat count.
What actually killed us was that we couldn't price in a way that reflected reality. We'd have a customer with 50 seats using the hell out of the product (millions of log lines daily) and another with 200 seats sending maybe 100MB a day. Same price. So we started getting pressure to implement per-volume tiers, then concurrent-user limits, then all these hacky rate-limit gates that made the product feel broken to power users. We were essentially rebuilding consumption-based pricing on top of seat-based pricing, which is just... all the friction with none of the benefits. The sales team hated the complexity, ops was drowning in exceptions, and customers felt nickeled.
We never switched models because by then the damage was done—the product architecture had grown around seat-based thinking. But the companies that *did* make the switch had already sunk enough cost into their go-to-market that switching felt suicidal. So yeah, it sticks around. Not because it's optimal, but because changing it is scarier than living with it.