Cross-posted from the Fluidify blog.
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.
Why per-seat pricing exists
Look at what actually scales with an added seat: a row in a database, a few more notifications a month. None of that costs meaningfully more per user at real scale. Per-seat pricing tracks something else: how many people are at the company buying the software, a proxy for budget, not for load on the vendor's systems.
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 a design tool doesn't.
What it distorts
Rationing rotation membership: If adding someone to the rotation costs a license, who's on call stops being purely operational and becomes partly financial. A bad axis to make a staffing decision on.
Seat-count negotiation replacing policy design: Procurement conversations center on the per-seat price instead of whether the escalation policy and schedule design are actually right for the team.
Shadow responders: A senior engineer gets paged through someone else's account, or an unofficial channel exists for escalations that never touch the licensed tool. A symptom of pricing fighting the operational need.
The gap grows with the thing you're trying to do, not shrink: As a team scales, the case for a bigger rotation gets stronger exactly as the bill makes it more expensive.
What actually scales with team size, and what doesn't
Alert volume scales with the number of services, not headcount. Incident count scales with system complexity. None of what a vendor's infrastructure actually handles scales in lockstep with rotation headcount. What does scale with headcount is ability to pay, a legitimate business reason to price this way, a separate question from whether it's the right way to price this specific job.
Alternative models
Flat-rate regardless of team size, usage-based on incident volume, or free/self-hosted with the cost shifted to infrastructure and engineering time. Each has tradeoffs. None are free of distortion, they just distort a different variable than headcount.
FAQ
Is per-seat pricing inherently unfair? Not inherently. The question is whether it fits the specific job, and for a tool whose whole purpose is keeping the right people reachable, charging more for having more people reachable is a strange incentive.
Does a bigger rotation actually cost the vendor more? Marginally, but not proportionally to what per-seat pricing typically charges.
What should a buyer evaluate instead of the per-seat price? Whether the pricing model changes how you'd design the rotation if the tool were free.
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.
Top comments (0)