The difficulty of measuring the cost of e-mail downtime

Many organizations use ROI analysis to make decisions about the deployment of new technologies or to compare alternatives when planning to deploy a new system. For example, when considering the value of a technology that allows online collaborative sessions as a replacement for in-person meetings, ROI analysis works quite nicely because most of the relevant costs and other factors can be quantified - the cost of the collaborative technology, travel, employee salaries, and other factors can all be determined fairly easily.

However, it is much more difficult to apply ROI analysis to the cost of preventing e-mail downtime, simply because in many cases e-mail downtime carries with it so many unknowns. For example, if you knew that for every hour of e-mail downtime you would lose $10,000 in revenue, you could easily carry out an ROI analysis to justify the cost of a capability that would eliminate downtime. However, e-mail downtime has a large number of unknown costs that are extremely difficult, if not impossible, to quantify.

During a downtime, for example, 5,000 users might send e-mail to your company and receive bounceback messages. What does that cost your organization? Some of those e-mail senders might assume your company has gone out of business, some might assume you don't manage your e-mail servers well enough to avoid downtime, some might ignore the bounceback altogether, while some might contact your competitors after not hearing from the employees they contacted. Was there a time-sensitive, high value order in an e-mail that was bounced back during the downtime? For many organizations that don't necessarily receive a regular stream of orders via e-mail, there is virtually no way to quantify what the impact of downtime will be on an organization.

The bottom line, in my opinion, is that e-mail is one of those "utility-like" technologies for which it is very difficult to justify the cost of reliability-inducing capabilities, but for which these technologies must be deployed. Even though you cannot accurately determine the cost of e-mail downtime in many cases, you must make e-mail reliable because of the potentially significant cost that such downtime can carry with it.