Crisis communications: what to say before you know anything

Trust is earned by the shape of your updates, not by having the answer first.

The idea

When something breaks, people don't need you to know why yet — they need to know that you know it's happening and that they'll hear from you again soon. So you acknowledge early with only the facts you've confirmed, and you promise a ("next update at :30") rather than an ETA you might miss.

Two things quietly destroy trust: a cause you guessed at and later have to retract, and an "all clear" you give before recovery is actually verified. A false all-clear costs more than a slow one.

The outage console

clock 10:03 · incident open

You've just been paged. Login is failing for a growing number of users. Draft your first move.

clock 10:03 trust 72/100 cadences kept 0

How it works

The sequence is the discipline. Each update answers only what you can back, and every audience gets the same facts framed for what they must decide.

1. ACKNOWLEDGE (minute 1-5)
   Say only what is confirmed: "some users can't log in;
   we're investigating." No cause. No blame. No ETA.

2. COMMIT A CADENCE, not an ETA
   "Next update by 10:15" is a promise you control.
   "Fixed by 10:15" is a promise the outage controls.

3. LAYER PER AUDIENCE (same facts, different frame)
   customers  -> impact + workaround + next update time
   executives -> scope, business exposure, who's on it
   regulators -> confirmed facts, timeline, no speculation
   press      -> a single approved holding line

4. CORRECT FAST if a fact changes
   New confirmed cause replaces the old note in the open.
   A quiet walk-back reads as a cover-up.

5. HOLD THE ALL-CLEAR until recovery is VERIFIED
   Green dashboards for a stable window, then declare it —
   and only then. Relapse after "resolved" is the costliest
   message you can send.

When to use it

Situation	What the sequencing buys you
Live outage or degradation	Early acknowledgment stops the rumor vacuum from filling in for you.
Cause still unknown	A cadence keeps trust while you investigate, with nothing to retract later.
Multiple audiences at once	One confirmed-fact spine, layered per audience, keeps the story consistent.
Recovery looks close	Holding the all-clear until verified protects you from a trust-crashing relapse.

The trade-off: a cadence costs you a steady stream of "still working" updates that feel thin. That is the price of trust — and it is cheap next to one retraction.

Watch out for

Naming a cause to look decisive before it's confirmed. If it's wrong you now owe a public retraction, and the next update is disbelieved.
Promising an ETA. "Fixed by 3:00" is a clock you don't own; miss it and every future estimate is discounted.
Going quiet because "there's nothing new." Silence on a promised update is itself news — the bad kind.
Declaring "all clear" on the first green graph. Verify a stable recovery window first; a relapse after resolved is unrecoverable in one incident.
One message for everyone. Regulators need confirmed facts and a timeline; customers need impact and a workaround; blur them and you leak speculation into the wrong room.

Worked example

You're paged: checkout is failing. At 10:03 you post only "we're aware some payments are failing and are investigating; next update by 10:15." You resist blaming the 09:50 deploy even though it's your first suspect. At 10:15 you post on schedule — "confirmed elevated errors, still investigating, next update 10:30" — kept cadence, no new promise. At 10:30 engineering confirms an expired certificate, not the deploy; because you never blamed the deploy in public, there is nothing to retract. You hold the all-clear until payments run clean for fifteen minutes, then declare it resolved with a post-incident review to follow. In an interview, narrate exactly this spine — acknowledge, cadence, confirmed-only, verified all-clear — and name the one thing you deliberately didn't say.

Check yourself

Fifteen minutes into an outage you still don't know the cause, and your promised update is due. What do you post?