biza.email
Sign inStart free
Back to all posts
·4 min read

Why we don't charge per seat for business email

Per-seat pricing is a hangover from Microsoft Office. Email doesn't behave the way per-seat priced things behave. Here's the short version of why we picked a different model.

pricingcompanyopinion

Every business email provider charges per user per month. Google Workspace, Microsoft 365, Fastmail, Zoho, Proton, the smaller hosts — same shape. Some charge $1/seat, some charge $12. The thing they have in common is the unit.

We don't. Biza Email is $50 per year, flat, for unlimited mailboxes on your domain. This is a short essay about why — written because customers ask, and because the answer is more interesting than "we wanted to be cheaper".

Per-seat pricing is a hangover from Office

The reason every business app is priced per seat is that Microsoft Office, in the late 1990s, was priced per seat — and then Office became Office 365, which carried mailbox hosting along with the document apps, and the per-seat pricing carried with it. Then Google Workspace, then everyone else.

It works for productivity suites because each person genuinely consumes their own copy of Word, their own copy of Excel, their own copy of PowerPoint, their own Drive quota. The pricing matches the consumption.

Email, by itself, is not seat-shaped. Per-seat email is the bundle's pricing model surviving past the bundle.

Email is collection-shaped, not seat-shaped

When you actually look at how teams use email:

  • A support@ address has 0 owners, or 3, depending on the day. It's not anyone's seat.
  • A careers@ address sits dormant for 11 months and is on fire for one.
  • Aliases per person — alice+stripe@, alice+linear@, alice+gym@ — are a hygiene tool, not new seats.
  • Ex-employees' mailboxes need to be retained for months or years.
  • Contractors and short-term collaborators want company-domain addresses too.

What scales with usage isn't seats, it's storage — and even there, the storage of a typical mailbox is so small (a few GB for normal use; tens of GB for archival users) that flat plans handle the variance fine.

When we costed out the actual marginal cost of an additional mailbox on a team that already has mail flowing, the answer was: tiny. Almost all the cost is the team's first mailbox (DNS, deliverability monitoring, the existence of the domain on the host). Subsequent mailboxes are rounding error.

So we priced accordingly.

The incentive alignment

There's a more uncomfortable reason per-seat exists: per-seat hosts make more money when customers create fewer mailboxes. The vendor's commercial interest is in keeping seat counts low while still being useful enough to keep the contract.

This produces customer behaviours that are bad for the customer:

  • "We can't add a legal@ address because that's another seat."
  • "Don't create a temp@ for that contractor — they can use Gmail."
  • "We need to delete this leaver's mailbox today even though their replacement isn't onboarded yet, because we're paying for it."

None of these are tragic individually. Together they nudge teams toward worse architecture and worse customer experience.

Flat-rate flips this. Our incentive is the opposite: we want you to add the mailboxes you should add. The role addresses you avoid creating are not a saving for us. The flat plan removes the conversation entirely — you build the email setup that fits your operations, not the one that fits your pricing tier.

What we lose

Honest accounting cuts both ways. Flat pricing has real downsides for the host:

  • Adverse selection. A team that runs 200 mailboxes for a 50-person company pays the same as a team running 50. We absorb the cost difference. This works because the vast majority of teams don't have that ratio — but a few do.
  • Predictability for us. Per-seat revenue scales with your customer's headcount, which is roughly a leading indicator. Flat revenue is just the plan rate × customer count. No expansion revenue per existing customer.
  • The simple comparison gets confused. "Why is Zoho $1 and Biza $50?" Because Zoho is $1 per user per month, which is $300 per year for 25 mailboxes. Customers do this math eventually; they don't always do it at the moment of comparison.

We accepted these because the alternative — building per-seat tiers into the product, then convincing customers to upgrade, then sales-motion-ing the friction — is a worse company to run.

What we kept

Storage is metered separately. The base plan includes 50 GB of pooled storage shared across all mailboxes; if your team needs more, you add capacity in tiers. This isn't a hidden per-seat fee — it's billing for the one thing that genuinely scales with usage rather than headcount.

Storage tiers being optional and transparent (you see the line item, you can opt in) is the closest thing we offer to "pricing scaling with usage". It scales with actual usage, not proxy-for-usage.

Why we still might be wrong

We're operating on the bet that flat pricing is structurally better aligned with how teams want to think about email, not just cheaper. We could be wrong about how broadly that resonates. Some teams genuinely prefer per-seat — it makes budgeting per cost-centre easier, makes departmental chargebacks straightforward, lets procurement do its standard motions.

We accept that we're not the right vendor for those teams. We're the right vendor for the team that's spent the last hour calculating whether they can afford to add a partnerships@ mailbox. The answer should be yes. Our pricing makes it yes.


The math behind this, with concrete numbers for teams at 5 / 25 / 100 people, is in the real cost of per-seat email.