Crisis Communications: What To Do When Things Go Wrong

When systems fall over or a story blows up, speed and clarity beat perfection. Use this tested playbook to stabilise the moment, inform customers and stakeholders, and protect trust — without adding to the chaos.

TL;DR: Assign roles fast, publish a holding statement within 30–60 minutes, update on a fixed cadence, and centralise everything in one source of truth.

What a crisis looks like

A crisis is anything that significantly degrades customer experience, threatens trust or safety, or risks revenue or compliance. It rarely looks tidy and may include:

• Operational outage: logins fail, checkout errors, latency spikes, payments don’t process.
• Security/privacy concerns: suspicious access, data mis-routing, vendor breach rumours.
• PR/trust issues: viral criticism, inaccurate press, influencer claims, executive missteps.
• Partner/platform failures: cloud/provider outage that breaks your product anyway.
• Legal/regulatory events: takedown notices, compliance lapses, regulator inquiries.

Crisis “smells” the same across categories: customer tickets spike, internal channels splinter, facts are partial, and leaders pressure you for ETAs you don’t yet have. That’s normal. This playbook prevents panic from becoming the story.

How this playbook helps (why it works)

• One owner: an Incident Commander makes decisions and sets the clock — no committee drift.
• One source of truth: a status page or pinned doc keeps messages consistent everywhere.
• Severity and cadence: a shared scale (S1–S4) and timed updates stop guesswork and silence.
• Empathy first: acknowledge impact, apologise, and commit to the next concrete update.
• Channel discipline: status page → master; social/email/in-product → pointers back.
• Ready-made replies: support replies are fast, consistent, and measurable.
• Stakeholder digest: leaders get the same facts and next update time — fewer drive-bys.
• Automatic log: updates form the post-mortem record, saving hours later.
• Legal guardrails: review when data/privacy/regulated claims are involved.

When to activate

Flip this playbook on if any of the following are true:

• 5% of active users impacted

• Revenue-affecting paths broken
• Safety/privacy risk suspected
• Negative coverage is trending, or an exec asks “Should we be worried?”
• Regulatory or compliance breach flagged

If in doubt, declare S3 and escalate up or down as facts emerge.

Your first 60 minutes (at a glance)

1. Create an incident channel and name an IC.
2. Assign Comms/Tech/Support/Legal/Exec roles.
3. Set severity and cadence.
4. Publish a 4-line holding statement on the status page.
5. Mirror the link to social/support/email as needed.
6. Spin up support macros/replies and the stakeholder digest.
7. Schedule the next update time before you go back to fix things.

The first hour: step-by-step

1. Declare the incident. Create a single Slack channel (e.g., #incident-YYYYMMDD) and pin this doc. Name an Incident Commander (IC) immediately.

2. Assign core roles (people, not teams).

   • Incident Commander (IC): owns decisions and timeline
   • Comms Lead: crafts and publishes updates
   • Tech/Operations Lead: facts and ETA
   • Customer Support Lead: macros and inbox
   • Legal/PR Advisor: risk review
   • Exec Sponsor: shields roadblocks (One person per role; no co-owners.)

3. Set severity (S1–S4).

   • S1: Full outage / data risk / national press likely
   • S2: Major feature degraded / wide customer impact
   • S3: Minor feature / limited cohort
   • S4: Cosmetic / no customer impact

4. Agree the update cadence.

   • S1: every 30–60 min
   • S2: every 60–120 min
   • S3+: as resolved, with at least daily recap

5. Draft a 4-line holding statement (publish within 30–60 min). Use the template below. Publish to the status page first, then link it everywhere else.

6. Open a single source of truth. Status page (preferred) or pinned Google Doc. Every update mirrors to Support macros, social, and email if needed.

Next 3 hours: contain and communicate

1. Facts only, then ETA. Comms Lead posts what’s confirmed (symptoms, affected customers, current work) and avoids speculation. IC sets the next update time — even if the ETA is unknown.

2. Choose channels intentionally.

   • Status page: master timeline
   • In-product banner: when most users are logged in
   • Email: S1 outages / security / compliance
   • Social: brief updates + link to status page
   • Support macros: consistent 1:1 replies

3. Spin up support at scale. Create 2–3 macros: initial notice, ongoing updates, resolution/apology. Tag tickets to measure impact.

4. Stakeholder digest (internal). Hourly note in #leadership with current impact, actions, next update time, and asks (e.g., approve credit policy).

Resolution and the 72-hour window

1. Post a clear resolution update. What changed, when it stabilised, what to expect next.
2. Customer follow-up (if S1/S2). Email recap, any credits, and how you’ll prevent recurrence.
3. Public post-mortem (when appropriate). Within 72 hours: timeline, root cause, fixes, and what you’re changing. Keep it human and specific.

Legal note: For anything involving personal data, regulated industries, or active investigations, have Legal review every external message.

Ready-to-use snippets

1. 4-line holding statement (status page / social)

We’re investigating an issue affecting [service/feature] beginning [time, timezone]. Customers may experience [symptom in plain English]. Our team is working to restore service; next update by [time]. Track updates here: [status page link].

2. Customer email (outage)

Subject: Quick update on today’s service disruption

Hi [first name], today at [time, timezone] we began experiencing an issue affecting [feature]. You may have seen [symptom]. We’re on it and will update our status page every [cadence] here: [link]. We’re sorry for the disruption — this isn’t the experience we aim to deliver. We’ll follow up with a full recap once things are stable. — [Company] Support

3. Customer email (PR / trust issue)

Subject: We’re addressing [issue]

Hi [first name], you may have seen discussion about [issue]. Here’s what we know now: [short facts]. We’re taking [actions] and will share updates at [link] by [time]. We understand your concerns and are committed to [principle: transparency/safety/fairness]. If you have questions, reply to this email — we’re listening. — [Leader name], [Title]

4. Support replies (copy-paste)

• Initial: We’re investigating an issue affecting [feature] since [time]. Live updates: [status link]. Sorry for the disruption.
• Ongoing: Still working to restore service. No ETA yet; next update by [time]: [link]. Thanks for your patience.
• Resolved: Service was restored at [time]. Root cause: [short phrase]. Steps we’re taking: [1–2 items]. Details: [post-mortem link].

5. Social post (X/LinkedIn)

We’re investigating an issue affecting [feature] since [time, TZ]. Updates every [cadence] here [status link]. Sorry for the disruption — we’ll keep this thread current.

FAQs to prepare (answer once, re-use everywhere)

Is my data safe? State what you know. If investigating, say so and commit to updates.

What caused this? Share confirmed facts only. Avoid blame until root cause is verified.

How long will it take? Give the next update time, not speculative ETAs.

Will there be compensation? Share policy criteria (severity, duration, customer tier) and when you’ll decide.

Who can I talk to? Provide a contact route for press/regulators and a normal support route for customers.

What “good” looks like (principles)

• One source of truth → link everything back to the status page.
• Time-boxed updates → even “no change” is an update.
• Plain English → describe symptoms, not systems.
• Empathy and ownership → apologise without deflecting.
• Document while you work → capture timeline for the post-mortem.

Post-incident review (60 minutes, within 1 week)

1. Timeline recap (5 min)
2. Impact review: customers, ops, revenue (10 min)
3. Root cause(s) using 5-Whys (15 min)
4. Fixes and owners: immediate, short-term, long-term (20 min)
5. Comms review: what we’ll change next time (10 min)

Publish notes with owners. Schedule follow-ups now.

Crises are messy by definition — you won’t have every fact and that’s okay. Your job is to protect customers and trust while stabilising operations. Do that by publishing what you know, what you don’t know yet, and when you’ll update next. Keep all roads pointing back to one source of truth, write in plain English, and show empathy and ownership. Silence and speculation do more damage than a concise, imperfect update on a reliable cadence.

The second job is to turn pain into process. When the dust settles, capture the timeline, publish a simple post-mortem, and update this runbook. Run a short tabletop drill quarterly so the team can practise roles, responses, and status-page updates without pressure. Finally, keep a pre-approved library (holding statements, responses, credit policy) in your wiki so you can move in minutes, not hours, the next time.

Use our Notion template