The Server Died at 9:12. The First Useful Update Landed at 11:40.

An outage has four audiences and they want completely different things.

The status page wants one sentence. The engineers want a bridge and a place to post findings. The 42 people who can't open their files want to know whether to go and make a coffee. And the person paying the invoice wants to know what it costs and what decision is sitting with them.

What usually goes out is one email, written by whoever noticed first, aimed at nobody in particular. Then the phone starts.

So we added Write the Outage Comms Pack for Every Audience at Once to the library. You feed it the facts once and it writes all four versions.

A worked example

Say you run IT for a 42-person accountancy practice. At 09:12 on a Tuesday the host carrying the file server and the practice management database falls over after a firmware update. Microsoft 365 is on a different platform, so email and Teams still work.

You give the prompt the facts: what is down, who is affected, when it started, how you found out, what you are doing, the workaround, and that the next update goes out at 10:00.

Back comes four pieces of writing.

The status page line is two sentences with no internal hostnames in it. Something like: file and practice management access has been unavailable since 09:12, email and Teams are working as normal, next update at 10:00.

The engineer message names who owns the bridge, where findings get posted, and tells the service desk to stop replying to users individually so the story stays consistent.

The user email opens with what they can and cannot do. Stop retrying the mapped drive. Work in Teams on anything already open. Log nothing new, we know. Next update at 10:00.

The note to the practice owner is the one that earns its keep. It says 42 people cannot reach client files, the VAT deadline on Thursday is at risk if this runs past lunchtime, here is what we are doing, and here is the one decision we need from you by 11:00 about authorising an out-of-hours restore.

Each version carries the same facts. None of them carry a guess about cause.

Where the value sits

Two places.

The first is call volume. A user email that answers "what do I do for the next 48 minutes" kills most of the inbound. Every call you avoid is an engineer staying on the fix.

The second is the decision. Most outages reach a fork where somebody with budget has to choose between waiting and spending. If that person hears about the fork at 11:40, you have lost two and a half hours of their options. The prompt forces a decision ask into the exec version every time, with a deadline on it.

It also ends with a short list of phrases to avoid while the incident is live. Speculating on root cause and blaming the hardware vendor both read fine at 09:30 and look terrible in the post-incident review when the firmware turns out to be ours.

How to use it

1. Paste the prompt into whichever model you use. Fill in the bracketed inputs with facts you can prove at that moment. Leave the gaps as gaps.
2. Set a real next-update time before you send anything. Every version repeats it, so pick one you can hit even if nothing has changed by then.
3. Run it again at each update window. Same inputs, new facts, four fresh versions.

When the incident closes, the next job is the write-up. Write a Post-Incident Review That Avoids the Blame Game turns your messy timeline notes into something you can send the client without anyone getting defensive about it. And a month later, Turn a Month of Tickets Into an IT Report Clients Read puts the incident in context next to everything else you handled.

Three prompts, one bad Tuesday, handled properly.