A Board-Ready Downtime Cost Model: Ranges, Not Guesses

Every board has heard that downtime is expensive. Fewer have seen a number they can actually use. The figures that circulate - thousands of dollars per minute, millions per hour - are averages across industries that share nothing with your business, and everyone in the room knows it. So the number gets nodded at and ignored.

A board downtime cost model fixes this by doing less, more honestly. It takes one important service, one disruption scenario, and a short list of assumptions the business itself supplies, and it produces a range with the math showing. Directors do not need a precise figure. They need a defensible one they can weigh against the cost of reducing the exposure.

Key takeaways

• A useful downtime cost model is built per service, per scenario, from business inputs - not borrowed from industry averages.

• Separate revenue that is delayed from revenue that is permanently lost. Most models quietly treat all of it as lost, which overstates the number and destroys credibility.

• Costs come in four buckets: lost capacity, delayed or lost revenue, recovery and catch-up costs, and contractual or regulatory effects.

• Show ranges with explicit assumptions, not a single point estimate. A range the board can interrogate beats a precise number nobody believes.

• The model exists to compare exposure against remediation cost. If it does not end in a decision, it is trivia.

Step 1: Pick one service and one scenario

Resist the urge to model "an outage." Choose a single important service - order taking, customer payments, dispatch - and a single severe but plausible scenario: the order system down for 24 hours during a normal week, or four hours at peak. Precision about the scenario is what makes the arithmetic testable.

Start with the service that has an impact tolerance already set, if one exists. The tolerance tells you where harm becomes unacceptable; the cost model tells you what approaching that line is worth.

Step 2: Establish the baseline

The model needs three baseline numbers from the business, not from IT:

• Normal throughput. Transactions, orders, or cases per hour for this service, and how it varies by time of day, week, or season.

• Value per unit. Margin or revenue per transaction, and the average downstream value of the customer doing it.

• Recovery profile. How long a realistic disruption lasts for this scenario, including the degraded period before full recovery - not just the restore time IT quotes.

If any of these numbers is a guess, say so on the page. A labeled estimate keeps its credibility; a disguised one takes the whole model down when it is challenged.

Step 3: Cost the four buckets

Work each bucket separately. Combining them too early hides the assumptions.

• Lost capacity. The cost of people and assets standing idle: staff paid but unable to work, production lines stopped, vehicles parked. Usually the easiest number to source.

• Revenue, split in two. Delayed revenue comes back when the service returns: the customer orders tomorrow instead. Permanently lost revenue does not: the customer bought elsewhere, the flight left, the trading window closed. Estimate what fraction of interrupted demand is lost versus delayed, and write the fraction down as an assumption.

• Recovery costs. Overtime, expedited shipping to clear the backlog, vendor emergency support, customer credits and apologies, the manual reconciliation afterward. These routinely rival the direct losses.

• Contractual and regulatory effects. Service-level penalties, late-delivery clauses, notification costs, and any reporting obligation the disruption triggers.

Step 4: Produce a range, with the assumptions showing

Run the model three ways: conservative, expected, and severe. Present all three with the two or three assumptions that move the answer most - usually the lost-versus-delayed fraction and the disruption duration. A board that can see "the answer is $400K to 733,000" cannot.

Step 5: Attach the decision

The model earns its place in the board pack only when it is set against the remediation options: closing the gap between the impact tolerance and tested capability costs X, and the modeled exposure is Y. That comparison - not the loss figure itself - is what directors are being asked to weigh.

A worked example (fictional)

A distributor models its order-promise service against a scenario: the warehouse management system down for one business day. Baseline: 1,200 orders a day, $95 average margin per order. The team assumes 60% of interrupted orders are delayed and 40% lost, flags the split as the key assumption, and costs idle warehouse labor, weekend catch-up overtime, and expedited freight separately. The range lands at $55K to $140K for the single day.

The same page notes that tested recovery for that system is two days, not one - so the realistic scenario is double the modeled one. The remediation quote to close that recovery gap is $90K. The board is no longer arguing about whether downtime is "bad." It is comparing two specific numbers.

Frequently asked questions

What is a board downtime cost model?

It is a service-specific estimate of what a defined disruption scenario would cost, built from the business's own throughput, value, and recovery numbers, and presented as a range with explicit assumptions. Its purpose is to let directors compare disruption exposure against the cost of reducing it.

Why not just use industry cost-per-hour figures?

Because they describe other businesses. Downtime cost depends on transaction volumes, margins, seasonality, and how much demand survives a delay - all of which are specific to your service and scenario. An industry average produces a number nobody in the room believes, so it drives no decision.

How precise should the model be?

Directionally right and honestly bounded. Two or three well-sourced baseline numbers plus clearly labeled estimates beat a detailed model built on hidden guesses. If an assumption is uncertain, show a range for it and name it as the sensitivity the board should watch.

Who should build it?

The service owner and finance build it, with risk and technology supplying the scenario and recovery profile. A model built by IT alone tends to measure systems; the cost that matters attaches to the service and its customers.

Closing

Downtime cost is not a fact to be looked up. It is a small set of assumptions your business already knows, assembled honestly and shown as a range. When the range sits next to the remediation quote, the board finally has the comparison it was being asked to make all along.