Business email comparison: a side-by-side buyer guide

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. Another counts a mailbox. One quotes storage per person; another pools it and counts the archive separately. One publishes an availability commitment that pays a credit; another publishes a number with no obligation attached. Put those side by side in a grid and the grid will be tidy, symmetrical, and wrong. The work that makes a comparison useful is the work of converting everything into your own units first.

What to take away

• Before comparing anything, define your own unit for each column. A comparison in the vendors' units compares marketing, not offers.
• Decide the category boundary early: a mail service and a bundle that contains mail are not competitors in any comparable sense.
• Weight each row by how often you touch it, not by how impressive it sounds.
• Finish by writing what would have to be true for the runner up to win. If nothing would, you were not comparing.

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 standard definitions of cloud service models are a fair reference for deciding whether two things are even the same kind of purchase.

Column	Define it as	The trap in the vendors' version
A user	An address you need to exist, whoever or whatever reads it	Some count only humans, some count every address, and the difference can be most of your bill
Storage	Total gigabytes your organization will hold in three years	Per person and pooled are different products; a per person figure tells you nothing about a heavy user
Retention	The period you are obliged or intend to keep mail	Default retention and maximum retention are different numbers, and only one is included
Availability	What the provider owes you when it is missed	A percentage with no remedy attached is a statement of intent
Support	Who answers, in what time, on the tier you will buy	Published response times often apply to a tier above the one being quoted
Administration	The specific controls you listed as required	Feature names differ across offers for the same capability, and differ for different capabilities under the same name
Export	Formats, and whether you can run it yourself	An export that requires a support request is a different thing from a button

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 one component of an office bundle answer different questions. The bundle may be cheaper for mail alone and commit you to a set of other decisions. The bundled-with-hosting option ties your mail to your website's fate. The dedicated service does one job and leaves the rest to you. The hosting arrangements page sets out what each costs you operationally.

So decide first which of these you are buying, and compare within that group. If you genuinely want to compare across groups, add a row for what else the bundle replaces and price that honestly: a suite that includes mail, storage, and meetings is only cheaper if you would otherwise buy all three. This is the same discipline that applies when comparing whole office bundles, where the weakest component decides the value of the package.

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.

• Daily contact: the mail client on the devices people actually use, search quality on a full mailbox, calendar across the team, how shared addresses work.
• Monthly contact: adding and removing people, resetting a second factor, releasing a message from quarantine, checking a log.
• Yearly contact: renewal, capacity increases, the annual access review.
• Once, and then never again unless it fails: migration in, and migration out.

Features in the first group are worth arguing about. Features in the fourth group are worth checking exist and 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 of it on the first because it feels subjective. Daily friction is not subjective; it is just 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, the cloud security principles give you a set of questions any provider should be able to answer 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.

Three techniques help more than another round of research:

• Separate vetoes from preferences. A veto is a requirement whose absence ends the discussion. Everyone gets very few. Preferences are traded; vetoes are not.
• Score independently, then compare scores. Group scoring converges on whoever speaks first. Individual scores expose where the real disagreement is, which is usually one row rather than the whole grid.
• Write the case for the option you are rejecting. If nobody can write a decent one, the comparison was decorative and the decision had already been made.

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.