Our pricing page charges per seat: a flat rate per logged-in user, regardless of how much or how little that user actually touches the product. We'd like to explain, honestly, why we chose this over usage-based pricing, because the reason has very little to do with the explanations usually given on pricing pages.
The stated reason
"Per-seat pricing is simple and predictable." This is true, and it's also true for us far more than it's true for you. A per-seat number lets our finance team forecast next quarter's revenue from a headcount spreadsheet, with no modeling of actual product usage required. The simplicity being sold as a customer benefit is, first and most directly, an internal planning convenience.
The real reason: seats rarely go down
A customer who buys 50 seats and only actively uses 30 of them is, from a revenue perspective, exactly as valuable as a customer using all 50. Usage-based pricing would let that gap show up as a bill that shrinks to match reality. Per-seat pricing freezes the number at whatever the org chart looked like the day procurement signed, and decreasing it requires someone to proactively notice, raise the issue, and request a downgrade — friction that overwhelmingly favors the vendor, because almost nobody does this paperwork voluntarily.
Why "per seat" discourages the behavior that would shrink revenue
If pricing were usage-based, a customer optimizing their own costs would be incentivized to consolidate activity — fewer people doing more, less waste. Under per-seat pricing, the same optimization doesn't touch the bill at all, because the bill is keyed to headcount, not activity. We have no commercial incentive to help a customer notice that fifteen of their fifty seats haven't logged in in four months, and in practice, we don't build tools that would surface it.
The seat that never gets removed
Someone leaves the company. Offboarding IT revokes their email and their Slack. Their seat in our product, somewhere lower on the offboarding checklist, often survives for months, quietly billed, because removing a seat requires a specific action in a specific admin panel that offboarding doesn't always include. This isn't fraud. It's just friction, working exactly as friction works — in the direction of whoever benefits from nothing changing.
Why usage-based pricing is harder for us, not just for you
Usage-based pricing requires us to build real, granular tracking of what "usage" means, defend that definition against customers who'll reasonably argue a given month was unusually heavy, and accept genuine month-to-month revenue volatility that makes our own forecasting harder. Per-seat pricing offloads nearly all of that complexity onto a single number that's cheap for us to bill against and expensive for you to audit, and "expensive to audit" is doing a lot of the actual commercial work here.
What we're not saying
We're not saying per-seat pricing is predatory — for a product genuinely used daily by everyone with a seat, it's a perfectly fair, simple model that actually tracks value well. We're saying the pricing page's stated rationale — simplicity, predictability — undersells the asymmetry: the model is simple and predictable mostly for us, and the friction it introduces around downgrading happens to flow almost entirely in the direction of more revenue, not less.
Our recommendation
If you're the buyer: audit your seat count every renewal cycle, specifically, on a calendar reminder, because nobody on the vendor side is going to flag the fifteen inactive seats for you. If you're the seller: a model built on genuine customer trust survives an honest seat audit. One built on friction only survives because the audit doesn't happen.
If your own per-seat bill hasn't been audited since before your last reorg, email us at contact@b2bsaas.guru. We'll help you count the inactive seats. We'd rather you didn't, but we'll help.