How to run a business email comparison in your own units

A comparison table is a claim that two things can be measured on the same scale. In this category that claim is usually false, and the table hides the fact rather than admitting it.

One offer counts a user as a person, while another counts a mailbox. One quotes storage per person, while another pools storage and counts the archive separately. One publishes an availability commitment that pays a credit, while another publishes a number with no obligation attached.

In a business email comparison, put them side by side and the grid will be tidy, symmetrical, and wrong. The work of a useful comparison is converting everything into your own units first.

What to take away

Convert everything into your units first

Take a blank page and define the following for your own organization. Then fill each candidate's answer in your units, not theirs. Where an offer uses a term loosely, the cloud service model definitions in NIST SP 800-145, the National Institute of Standards and Technology's reference on cloud computing, are a fair guide for deciding whether two things are even the same kind of purchase.

Filling this in is slow the first time and fast afterward. It is also the step that most often changes the answer, because two offers that looked close in their own units frequently stop looking close in yours.

Fix the category boundary before you start

Half the confusion in this category comes from comparing things that are not the same kind of thing.

A dedicated mail service, mail bundled with web hosting, and mail as part of an office bundle answer different questions. The bundle may cost less for mail alone and commits you to other decisions. The hosting bundle ties your mail to your website's fate.

In practice the field splits three ways: the mail half of an office bundle such as Microsoft 365 or Google Workspace, a standalone mail service such as Zoho Mail, Fastmail, or Proton Mail, and mail that arrives with hosting, as with GoDaddy or Rackspace.

Our hosting arrangements guide sets out what each arrangement costs you operationally.

Decide first which group you are buying, then compare within it.

To compare across groups, add a row for what else the bundle replaces and price it honestly. A suite with mail, storage, and meetings is cheaper only if you would otherwise buy all three. The same discipline applies to whole office bundles, where the weakest component sets the package's value.

Weight rows by contact, not by impressiveness

Once the units are yours, the remaining question is what matters. The reliable method is to weight each row by how often someone in your organization will encounter it.

Features you touch daily are worth arguing about. Those you touch monthly are worth a look; those you touch yearly or once are worth confirming exist, then leaving alone.

The common error is spending the comparison on the last group because it is the most interesting to read about, and none on the first because it feels subjective. Daily friction is not subjective; it is harder to measure, which is what a trial is for.

One row deserves a firmer standard than a sales answer. For availability, resilience, and separation between customers, ask for written answers to a fixed set of questions. The cloud security principles published by the UK's National Cyber Security Centre are one such set, and any provider should be able to answer them without a specialist in the room.

Where comparisons go wrong

Comparing documentation instead of products. A well written help site is pleasant and is evidence about the help site.

Treating a long feature list as capability. The relevant question is whether the four things you named as required are present on the tier you can afford, which is a much shorter question.

Letting the demo set the criteria. Write the criteria first, in your own words, and change them only for a reason you can state out loud.

Scoring on the interface you saw for twenty minutes. Unfamiliar is not the same as bad, and the effect wears off in a week. Score on tasks completed, not on first impressions.

Ignoring the seams. Mail touches identity, storage, calendars, and every system that sends on your behalf. An offer that scores well alone and connects poorly to what you already run is the worse choice, which is why the integration surface belongs in the grid rather than in a footnote.

Comparing the price of the tier in the table rather than the tier that contains what you need. This is the single most common distortion, and it usually reverses the ranking.

When the people disagree

Comparisons are rarely settled by data alone, because the people involved value different things. The finance view, the administrator view, and the view of whoever answers the shared inbox are all legitimate and will not agree.

More research rarely settles it. What helps is assigning each view to the rows where it will actually be felt, naming who makes the call if the rows still tie, and writing down what evidence would reopen the question.

Then record the reasoning in a few sentences: what you chose, what you gave up, and what would make you revisit. At renewal that note turns a rerun of the whole exercise into a short check of whether the reasons still hold. Keep it beside your cost model so that the numbers and the reasoning stay together.

Common questions

How many candidates should be in the grid?

Two or three. A grid with eight columns is a research exercise, not a decision. Use disqualifying requirements to cut the field before the comparison starts, so the comparison itself is between things that could all genuinely work.

Is a published comparison from a third party useful at all?

For discovering that an option exists, yes. For deciding, no, because the author does not know your unit definitions, your address count, or what you already run. Treat outside comparisons as a source of candidates and questions rather than of conclusions.

What if two candidates end up genuinely equal?

Then they are equal, and the honest conclusion is that either would work. Break the tie on the easier exit, then stop. Time spent separating two adequate options is time not spent on the decisions where the options are not adequate.

Should price be in the grid at all?

Yes, but as the last column and in your units, including the addresses that are not people and the tier that contains your requirements. Price entered early anchors every other judgment in the table.