Why per-seat pricing won over usage-based, even when it makes no sense

I'd push back on the inevitability here. We ditched usage-based at my last place too, but not because per-seat won—because we built the wrong usage-based model. We were charging per API call like it was 2010. What actually worked was metered billing on the thing that mattered: data processed per month, with a simple committed spend tier option. Customers could pick "I want to process 500GB/month for $X" and not think about it, or pay as they go if they were small. The Finance horror story in your post—"we didn't make those API calls intentionally"—that's a billing model failure, not a usage-based pricing failure. Bad instrumentation, bad communication about what triggers charges, bad dashboards showing real-time spend. We fixed that and suddenly it wasn't a nightmare to forecast or explain. Sales cycles didn't get longer because we weren't debating usage projections anymore; we were just asking "how much data do you actually move?" The per-seat rationalizing is real though. What I noticed is companies switch to per-seat not because it's theoretically cleaner but because building a *good* usage-based system is work. You need observability. You need customer dashboards that don't lie. You need support ready to explain what they're actually paying for. Per-seat looks simpler until you're three years in and your highest-paying customer is 90% dormant seats, which is its own kind of awkward.

I'd push back on one thing: you're treating "simplicity" and "fairness" as separate dimensions when they might actually be inverses of each other in a specific way. Per-seat pricing isn't just simpler—it's simpler *because* it outsources the fairness problem to the customer. They have to figure out who sits where, who actually needs access, whether to rotate credentials. That's not the vendor being lazy; that's the vendor saying "you manage your own compliance with this deal." Usage-based fails operationally not because it's inherently harder, but because you built it wrong. If you'd shipped with hard caps, no surprise bills ever, and billing was just "you used this, here's the cost, next month reset," then finance could forecast and sales wouldn't be negotiating. Instead you went soft-threshold, which creates the exact uncertainty you're complaining about. The nightmare wasn't the model—it was the implementation. And yeah, maybe that's always the trap with usage-based: the temptation to be clever about it (progressive tiers, burst pricing, overage handling) until it collapses under its own terms. The real question your post skips: did per-seat actually solve the problem, or did it just move it? Because now your power users are subsidizing lurkers, and eventually someone notices and either demands a lower tier or stops paying altogether. You got forecasting clarity for a quarter; you didn't get a sustainable model. You just got a model where the wrongness is somebody else's problem to discover in year two.

You're describing what happens when the coordination problem beats the pricing problem. The usage-based model is actually harder to operate—not just to explain, but to instrument, bill, and dispute. Every anomaly becomes a support ticket. Every customer query about their bill requires you to have bulletproof logging and to have *thought about* what constitutes a legitimate charge, which you haven't, because you were too busy building the product. Per-seat is just... settled. Both sides know what they're paying for, even if it's a fiction (access, seats, whatever you call it). The fiction is stable. Usage-based requires continuous negotiation because the meter is always running and customers can see it, which means they'll question it, which means you need policies you don't have. I watched our old monitoring platform do the same thing. Started usage-based on data ingestion volume. Six months in we were having monthly calls with customers about "why did our metric cardinality spike" and "can you grandfather us on that price tier." Switched to per-instance, billing went from a source of friction to background noise. We probably left money on the table—the heavy users could've paid more—but we also stopped burning engineering and support cycles explaining why their costs went up. The certainty was worth more than the precision.

The rationalization you're pointing at is real, but I'd push back slightly on the framing. Per-seat didn't win because it's simpler—it won because it transfers risk. You're right that it's predictable for the customer, but that predictability is bought by making the vendor absorb the variance. If I'm paying per seat, I know my bill. You know my bill too, but you've just committed to serving me whether I use the thing once or three hundred times a month. That's a bet you're making, and you only take it if you believe the math works out across your customer base. Usage-based is unstable the other way: the customer's bill becomes the vendor's problem to explain. So it's not really that per-seat is simpler. It's that it moves the operational chaos—the forecasting, the variance, the "wait why is this so high"—from the sales floor to the infrastructure team. Someone's still eating the unpredictability. We just decided it'd be the company, not the customer. That's often the right call! Customers hate surprises. But calling it fairer or more sensible is doing real work to hide that someone made a bet and got lucky (or didn't). The interesting case is when that bet breaks. Slack, Docker, Figma—they've all run into moments where per-seat pricing on heavy power users becomes obviously untenable. Then you see things get weird: enterprise tiers, concurrent-user models, weird hybrid schemes. Because now the vendor is *losing* the bet on certain customer shapes. So we're not actually discovering that per-seat is wise. We're just discovering the shapes where it still works.