Per-seat pricing is a tax on growing teams

Picture this: your company hires three people this quarter. Congratulations. You now owe an extra ~$1,800 a year to your ticketing vendor. Not because they did anything. Not because the software is more useful with five people instead of two. Just because more humans exist in your org chart.

This is per-seat pricing, and it's the dominant pricing model in B2B SaaS, and it's a tax on you for the crime of having a team.

Why per-seat exists

Per-seat pricing isn't about value delivery. It's about predictable revenue growth for the vendor. If a vendor charges $12 per user per month, and your company grows from 50 to 100 people, their revenue doubled without them doing anything. From their perspective this is a perfect business model.

From your perspective, you're paying twice as much for software that works exactly as well as it did before.

What it actually costs you

Let's look at typical ticketing prices (in 2026):

ServiceNow: ~$100/user/mo at small team rates
Zendesk: $55/user/mo for "Suite Team"
Freshservice: $19/user/mo for "Starter" (and good luck staying on starter)
Jira Service Management: $20/user/mo

A 50-person IT team on Zendesk: $33,000 per year. For a tool that, charitably, you use to track tickets.

A 200-person team on the same: $132,000 per year.

You hire one IT analyst and instantly owe Zendesk another $660 a year, forever, even though the IT analyst is the one using the software to do their job.

The "but it scales" defense

The vendor will tell you per-seat is fair because they're providing more value as you grow. This is nonsense for ticketing software specifically. The product is not getting smarter, more capable, or more useful as your headcount grows. You're paying more because your headcount grew. That's it.

There are categories where per-seat genuinely scales with value — Salesforce, for example, where more salespeople using it really does generate more leads and revenue. Ticketing is not that category. Ticketing is overhead. Paying more overhead because you have more employees is exactly backwards.

The dirty secret of seat-based ticketing

Most teams I've worked on do this thing where they keep a single "shared" login that three or four people use to triage tickets, just to avoid paying for extra seats. Everyone knows this is happening. The vendor knows this is happening. The vendor doesn't care because they're still capturing $X from the licensed seats, and the shared login is technically violating ToS but they're never going to enforce it.

This is a comically bad outcome:

The vendor isn't getting full revenue
The customer is violating ToS
Audit logs are useless because three humans are one user
And everyone agreed this was the system in advance

It only happens because the pricing model is misaligned with how the work actually gets done.

What we charge

One-time payment. No per-user. No subscription. Same price whether you have 5 users or 5,000.

If you add five new hires, your IT software bill doesn't change. Crazy concept, we know.

💡

This is also why we ship as PHP source you host yourself. There's no central licensing server. There's nothing checking how many users you have. You bought it, it's yours, the end.

The pushback we've gotten

When we tell people we don't do per-seat, the most common response is "but how do you scale revenue?"

The answer: by selling Ticket Foundry to more companies, not by punishing existing customers for growing. Wild idea but here we are.

If we wanted to capture more revenue from individual companies, the right thing to do would be to ship more useful features and charge for major upgrades. That's the same way Microsoft Office worked for thirty years before SaaS happened.

Per-seat pricing got popular because it's easy to model in a finance spreadsheet, not because it's fair to customers. We're betting that enough IT leaders are sick of paying the per-employee tax that there's a real business in just... not doing that.

We'll see if we're right.