Why Per-Seat Pricing Breaks Small Support Teams

Per-seat pricing is the default for almost every support tool. It sounds fair: you pay for what you use. More people using the tool, more you pay.

In practice, for small teams, it creates three problems that nobody talks about in the sales call.

Problem 1: You pay for people who barely use it

Support software is rarely used equally across a team.

A 5-person startup might have one person who handles 80% of customer email and four people who occasionally jump in when volume spikes or the primary person is on vacation. Under per-seat pricing, you pay for five seats to cover four people who each send maybe ten emails a month.

That occasional coverage is exactly when you most need the tool to work. But paying five seats for a problem that could be solved by one primary user and occasional access doesn't feel proportionate.

The math:

• Help Scout Standard: $25/seat × 5 = $125/month — for one heavy user and four occasional ones
• Flat-rate alternative: $9.99/month flat — same inbox, same features, unlimited agents

The difference is $115/month, or $1,380/year, for the same four occasional check-ins.

Problem 2: Pricing punishes exactly the moment you're growing

Per-seat pricing creates a perverse incentive at the worst possible time.

When a team goes from 3 to 6 people, support volume typically grows — but so does the team's ability to handle it collaboratively. More people means you need more of the tool, not less. But more of the tool means a bigger bill.

What this looks like in practice:

A founder is growing their team. Before hiring a second customer success person, they have to justify adding a seat. The question "is this person worth $25/month extra in tooling costs?" is irrelevant — they're being hired for other reasons — but it's now a line item that shows up in the budget review.

More likely, the new hire ends up using a shared login, or checking email over someone's shoulder, or not using the shared inbox at all. The tool gets less useful because adding seats costs money.

Flat-rate pricing doesn't do this. You hire a 7th person, they get access, the bill doesn't move.

Problem 3: The model assumes usage that small teams don't have

Per-seat pricing was designed for large support organizations. At scale, it makes sense: 50 agents each sending hundreds of replies a day is meaningfully different from 10 agents doing the same.

For a small team sending 30 emails a day across 4 people, the infrastructure cost per message is not proportional to the number of humans accessing it. The per-seat model is pricing you at enterprise unit economics for startup volume.

The implicit assumption of per-seat pricing: every seat is actively used, full-time, all month. That assumption is true for a Salesforce deployment at a Fortune 500 company. It's almost never true for a 5-person SaaS startup.

What flat-rate pricing actually means

Flat-rate pricing charges a fixed monthly fee based on tier (usually email volume, storage, or feature access) — not on how many people have accounts.

For small teams, this means:

• Everyone gets access. No second-guessing about whether to add a seat.
• Growth doesn't affect the bill. Hire your third co-founder, give them inbox access, pay nothing extra.
• Occasional users are free. The developer who handles one technical support email a week doesn't cost $25/month extra.

Smailor uses this model. €9.99/month covers unlimited agents. A 15-person team and a 3-person team pay the same amount, and both get the same features. The price increases at higher tiers based on storage and AI usage, not headcount.

The counter-argument (and why it doesn't hold)

The standard defense of per-seat pricing: "You only pay for what you use."

This is true in the sense that a 1-person team pays less than a 100-person team. But it conflates value received with number of accounts created. A 5-person team shares one inbox — the value of that inbox doesn't increase linearly with the number of people peeking at it.

The better metric would be emails handled, or conversations resolved, or active sessions. Those would actually correlate with value. But "seats" is easy to count and easy to invoice, so it became the default.

How to evaluate support tool pricing properly

When comparing shared inbox tools, ignore the headline seat price. Instead:

1. Calculate total cost at your actual team size.
If you're 8 people, multiply by 8. That's the real number.

2. Project forward 12 months.
If you'll be 12 people by end of year, use 12. Support software compounds: the bigger the team, the more you rely on it.

3. Check what's included in each tier.
Some per-seat tools bundle AI, knowledge base, and chat. Some flat-rate tools don't. Make sure you're comparing equivalent feature sets.

4. Verify free tier permanence.
"Free" tiers that expire after 14 or 30 days aren't really free — they're trials. Look for whether the free tier has a genuine long-term use case or is designed to funnel you to paid.

Per-seat pricing isn't wrong. For large organizations with predictable headcount and enterprise budgets, it aligns incentives reasonably well. For a 4-person startup where everyone sometimes handles email, it's just an expensive way to pay for a shared inbox.

Smailor is €9.99/month flat — any number of agents, your domain, no trial clock.