Key takeaways
- Per-seat pricing in on-call and incident tools tracks headcount, not infrastructure cost or usage. The marginal cost of one more responder on a schedule is close to zero for the vendor, the price increase isn't a cost passthrough.
- It exists because headcount is a convenient, hard-to-game proxy for company size and ability to pay, not because it reflects what the vendor spends to serve one more seat.
- The real distortion isn't the bill itself, it's the decisions it forces on buyers: rationing who goes on a rotation, negotiating seat counts instead of designing the escalation policy around who should actually be reachable.
Why per-seat pricing exists
Look at what actually scales with an added seat in an on-call tool: a row in a database, a few more notifications a month, maybe a slightly larger support burden. None of that costs meaningfully more per user at any real scale. If pricing tracked marginal cost, on-call tools would be priced close to flat, or per-incident, or per-notification, something that scales with what the vendor's infrastructure actually does.
Per-seat pricing tracks something else: how many people are at the company buying the software. That's a proxy for budget, not for load on the vendor's systems. It's a value-capture mechanism, not a cost-recovery one, and there's nothing unusual about that in SaaS generally. What's specific to incident tooling is how directly the "seat" maps to something operationally meaningful: whether a real person, at 3 a.m., is reachable to fix a real problem. Charging for that access changes the buyer's incentive around it in a way that charging per seat for, say, a design tool, doesn't.
What it distorts
Rationing rotation membership: If adding someone to the on-call rotation costs a license, the decision of who's on call stops being purely operational (who understands the system, who's actually available) and becomes partly financial (can we justify another seat this quarter). That's a bad axis to make a staffing decision on, and it's specific to how the tool is priced, not to the actual work of being on call. It compounds the same way the tooling problem in alert fatigue does: a structural incentive nobody examines during a routine budget cycle.
Seat-count negotiation replacing policy design: Procurement conversations about incident tooling often center on getting the per-seat price down or negotiating a volume discount, rather than on whether the escalation policy and schedule design are actually right for the team. The pricing model pulls attention toward the bill and away from the thing the bill is nominally paying for.
Shadow responders: Teams under real pressure sometimes work around seat limits: a senior engineer gets paged through someone else's account, or an unofficial channel exists for escalations that never touch the licensed tool. That's a symptom of a pricing model fighting the actual operational need, not a training problem.
The gap grows with the thing you're trying to do, not shrink: As a team scales, the operational argument for a bigger rotation (more coverage, better follow-the-sun, lower burnout per person) gets stronger exactly as the per-seat bill makes a bigger rotation more expensive. The incentive runs backwards from what good on-call practice wants.
What actually scales with team size, and what doesn't
Alert volume scales with the number of services and their reliability, not headcount directly. Incident count scales with system complexity and change velocity. Escalation depth scales with how the team is organized, not with the schedule tool. None of the things a vendor's infrastructure actually has to handle scale in lockstep with the number of people on a rotation.
What does scale with headcount, roughly, is ability to pay, which is exactly what a proxy metric for value-based pricing wants. That's a legitimate business reason to price this way. It's a separate question from whether it's the right way to price the specific job of keeping the right person reachable when something breaks.
Alternative models
A few pricing shapes track the actual job more directly: flat-rate regardless of team size, usage-based on incident or notification volume, or free/self-hosted with the cost shifted to infrastructure and engineering time instead of a subscription. Each has its own tradeoffs (flat-rate vendors still need to price for their biggest customers somewhere; usage-based pricing can get unpredictable during a bad month; self-hosting has a real operational cost even without a license fee). None of them are free of distortion, they just distort a different variable than headcount.
FAQ
Is per-seat pricing inherently unfair? Not inherently, it's a legitimate value-based pricing choice many software categories use successfully. The question worth asking is whether it fits the specific job, and for a tool whose whole purpose is "make sure enough of the right people are reachable," charging more precisely for having more of the right people reachable is a strange incentive to build in.
Does a bigger rotation actually cost the vendor more to support? Marginally, in support tickets and infrastructure load, yes, but not proportionally to what per-seat pricing typically charges. The infrastructure cost of one more user on a schedule is a rounding error compared to the price increase.
What should a buyer actually evaluate instead of just the per-seat price? Whether the pricing model changes how you'd design the rotation if the tool were free. If the honest answer is "we'd add three more people to on-call," the current pricing is actively shaping a worse operational setup than the team would otherwise choose.
For what it's worth: this is a big part of why we built FluidifyAI Regen without per-seat pricing on the self-hosted tier, the goal was removing this specific distortion, not just being cheaper.