TL;DR: Crisis communication prompts fall into four jobs: holding statements while facts are still being confirmed, an escalation ladder defining who reviews what before anything goes out, internal alerts to keep employees informed, and post-incident statements once facts are settled. 20 prompts below cover all four. None of them replace legal review — get sign-off from actual counsel before anything customer-facing or public goes out, and treat nothing on this page as legal advice.
Crisis communication is the one category of business writing where speed and accuracy are both non-negotiable at the same time, and that combination is what makes a blank page dangerous. An incident happens, facts are incomplete, someone needs a statement out within the hour, and a comms lead facing a blank document under that pressure is exactly when a rushed sentence creates a second, self-inflicted problem on top of the first one.
The 20 crisis communication prompts below exist to remove the blank page, not to remove the judgment. Every prompt drafts structure and language around facts you actually supply, what happened, what you know, what you don't yet, and every prompt is built around one non-negotiable rule that applies before anything on this page reaches a customer, a regulator, or the public: get a human review, and for anything with legal or safety exposure, get your actual legal counsel's sign-off, before it goes out. This page is not legal advice, and nothing drafted here should be treated as a substitute for that review.
The stakes of getting this wrong run in both directions, which is part of what makes crisis communication genuinely hard. Say too little, too slowly, and the silence itself becomes a story, read as either not knowing what's happening or not caring enough to say so. Say too much, too fast, before facts are confirmed, and an early guess about cause or scope can become the thing you have to walk back publicly a day later, which usually does more damage than the original incident. The structure below is built to thread that gap: fast enough to avoid the silence problem, disciplined enough to avoid the walk-back problem.
| Stage | The real risk | Where a prompt earns its keep |
|---|---|---|
| Holding statement | Silence or speculation while facts are unclear | An honest "we know this much, not yet that" structure |
| Escalation ladder | No one knows who reviews what before it ships | A defined chain: facts owner, legal, final sign-off |
| Internal alert | Employees learn from social media before their own company | Fast, honest internal-first communication |
| Post-incident | A generic apology that sounds like it was written by no one | A specific, accountable statement once facts are settled |
Read that table before the prompts. The order below follows an actual incident timeline: acknowledge fast, get the review chain right, keep your own people informed, then close it out once the facts are settled.
None of the four stages is optional, and skipping straight to the post-incident statement because "we'll just explain everything once we know" is the single most common mistake this page is built to prevent. Every hour a company stays silent while an incident is visibly unfolding is an hour the story gets written by someone else, a customer on social media, a journalist working from incomplete information, a competitor happy to let the ambiguity sit. A short, honest holding statement doesn't need all the facts. It needs to exist, quickly, and to say plainly what it doesn't yet know.
How do you write a holding statement before you know all the facts?
By saying exactly what you know, what you don't yet, and when you'll update, without speculating about cause or promising a timeline you're not sure you can hit.
A holding statement is the single highest-leverage piece of writing in a crisis, precisely because it goes out while the pressure to say something is highest and the confidence in any specific explanation is lowest. Getting the structure right here, honest about the gap between what's confirmed and what's still being investigated, sets the tone for every statement that follows. Getting it wrong, either through silence or through an early guess dressed up as a fact, creates a credibility problem that follows the rest of the response.
1. Initial holding statement
Draft a holding statement for this situation: "[WHAT'S HAPPENING, AS
CONFIRMED SO FAR]"
State only what's confirmed. Explicitly say what's still being
investigated rather than speculating. Include when we'll provide an
update. Do not assign cause or blame unless it's already confirmed and
I've told you so.
2. "We're aware and investigating" short version
Write a short, immediate acknowledgment (under 50 words) that we're aware
of "[ISSUE]" and investigating. This is the first thing to go out, before
we have real details — it needs to say we're on it without stating
anything unconfirmed.
3. Timeline-of-updates commitment
We've committed to updating on this cadence: "[E.G., EVERY 2 HOURS, EVERY
BUSINESS DAY]"
Draft a sentence for the holding statement stating this update commitment
clearly, so people know when to expect more information rather than
refreshing constantly.
4. Scope-of-impact statement, honestly bounded
Here's what we currently know about who or what is affected: "[KNOWN
SCOPE, INCLUDING WHAT'S STILL UNKNOWN]"
Draft a sentence describing the known scope of impact, explicitly noting
what's still being confirmed. Do not state a number of affected users or
systems unless I've actually given you a confirmed number.
A holding statement that follows this pattern buys the time an incident response team actually needs to get the facts right, without the vacuum that silence creates. It is deliberately unsatisfying to read, because it commits to almost nothing beyond acknowledgment and a promised update. That restraint is the entire point: a statement that says less than it knows is recoverable if new facts emerge; a statement that says more than it knows rarely is.
5. Draft-review readiness checklist
Before this statement goes out, check it against this list and flag any
issue: does it assign cause or blame that isn't confirmed, does it
promise a timeline we might not hit, does it state a number we haven't
verified, does it speculate about anything.
Statement: "[PASTE DRAFT]"
List any issue found, quoting the specific sentence.
How do you build an escalation ladder before you need one?
By defining, in advance, who owns the facts, who reviews for legal exposure, and who has final sign-off, so the review chain is a checklist during an actual incident, not a conversation you're inventing under pressure.
The absence of a defined ladder rarely feels like a problem until the exact moment it becomes one: an incident hits, three people each believe they have the authority to approve the statement, none of them has actually cleared it with legal, and the pressure to say something fast overrides the pause that should have happened first. Building this ladder calmly, in advance, is the single biggest predictor of whether a company's first public statement is fast and safe, or fast and reckless, regardless of who's actually on shift when the real incident hits.
6. Escalation ladder draft
Help me draft an escalation ladder for crisis communications at our
company. Here's our team structure: "[LIST ROLES: WHO OWNS FACTS, LEGAL
CONTACT, FINAL SIGN-OFF AUTHORITY, SPOKESPERSON]"
Structure as: severity level, who's notified, who reviews, who approves
before anything goes out publicly. Use only the roles I've given you —
don't assume a role structure I haven't described.
7. Severity-level definitions
Help me define severity levels for incidents at our company, using these
rough examples of past incidents and how serious each was: "[LIST PAST
INCIDENTS AND THEIR ROUGH SEVERITY]"
Draft 3-4 severity tiers with a one-line definition each, based on the
pattern in these examples, not a generic industry template.
8. Internal notification message for the response team
Draft an internal alert to notify the incident response team that
something has happened: "[WHAT'S HAPPENING, WHO NEEDS TO KNOW]"
Direct and urgent without being alarmist. State what's known, what's
needed from each person, and where updates will be posted.
9. Legal-review request note
Draft a short note to send to legal counsel along with a statement,
asking for review before it goes out: "[CONTEXT: WHAT HAPPENED, WHAT
THE STATEMENT SAYS, HOW URGENT THIS IS]"
Clear and specific about what needs review and by when. This is a request
for review, not a request to skip it — make clear the statement is not
going out until legal signs off.
10. Sign-off tracking note
Help me draft a simple sign-off tracker format for a crisis statement:
who needs to approve (facts owner, legal, final approver), and a column
for status. Just the structure — I'll fill in actual names.
How do you keep employees informed before they hear it elsewhere?
By treating internal communication as its own urgent priority, since an employee who learns about a company incident from social media or a customer before hearing it internally loses trust fast, independent of how the incident itself resolves.
Employees are frequently the last to know about their own company's incident, and the ones most likely to be asked about it directly, by a customer, a friend, or a stranger who saw it online. An employee caught flat-footed by a question they've never heard internally either says something wrong or says nothing at all, and both outcomes look worse to the person asking than an honest "here's what we know so far" would. Internal communication isn't a courtesy step here; it's protection for the people most exposed to the outside world's questions.
11. All-hands internal alert
Draft an internal message to all employees about this situation: "[WHAT'S
HAPPENING, WHAT'S CONFIRMED, WHAT EMPLOYEES SHOULD DO OR NOT DO]"
Honest and direct. Include what employees should say if a customer or
reporter asks them about it (usually: direct them to the official channel,
don't speculate). Do not include anything not yet confirmed for public
release if this needs to stay internal-only — flag that distinction
clearly at the top.
12. "What to say if asked" guidance for frontline staff
Draft short guidance for frontline/customer-facing staff on what to say if
a customer asks about "[SITUATION]" before an official statement is out.
Should be: acknowledge we're aware, don't speculate, direct them to
"[OFFICIAL CHANNEL]". Keep it to a few sentences staff can actually
remember under pressure.
13. Leadership talking points for internal Q&A
Draft talking points for a leader fielding employee questions about
"[SITUATION]" in an all-hands or team meeting. Here's what's confirmed:
"[FACTS]"
Structure as likely questions with honest, confirmed answers. Where the
honest answer is "we don't know yet," write that plainly rather than a
softer non-answer.
14. Internal update as facts develop
Here's what's changed since the last internal update: "[NEW
INFORMATION]"
Draft a short follow-up internal message noting what's new, referencing
the earlier message rather than restating everything from scratch.
15. Post-mortem announcement to the team
Once the incident is resolved, draft a message to the team announcing
that a post-mortem is happening and inviting honest input: "[WHEN, WHO'S
LEADING IT]"
Frame it as blameless and focused on what the process can catch next
time, not on assigning individual fault.
How do you write the follow-up statement once facts are settled?
By being specific about what happened and what's changing, since a generic apology that could describe any incident at any company reads as exactly that: generic, and unconvincing.
The temptation at this stage is to reach for language that sounds appropriately serious without committing to any specific claim, "we take this very seriously" and "we're taking steps to prevent this in the future" without saying which steps. That language protects nothing and reassures no one, because it could describe literally any company's response to literally any incident. Specificity is what makes an apology or a post-incident statement actually land: naming the real harm, naming the real fix, and being willing to be held to both.
16. Full post-incident statement
Draft a post-incident statement now that facts are confirmed: "[WHAT
HAPPENED, ROOT CAUSE IF KNOWN, IMPACT, WHAT WE'RE DOING ABOUT IT]"
Specific and accountable, not vague. State what happened plainly, take
ownership where it's ours to take, and be concrete about the fix — not
"we're taking this seriously" with no specifics. Use only facts I've
given you.
17. Apology statement, specific not generic
Draft an apology for "[SPECIFIC HARM CAUSED]". Avoid a generic
"we apologize for any inconvenience" — name the specific harm and what
we're doing to make it right, using only what I've told you.
18. Remediation commitment statement
Here's what we're actually committing to do as a result of this incident:
"[REAL, SPECIFIC COMMITMENTS — REFUNDS, FIXES, PROCESS CHANGES]"
Draft a statement of these commitments, specific and concrete. Do not
add a commitment I haven't listed, even one that sounds reasonable.
19. FAQ for affected customers
Draft an FAQ for customers affected by "[INCIDENT]", based on these known
facts and confirmed next steps: "[FACTS AND NEXT STEPS]"
Cover the questions an affected customer would actually ask: what
happened, am I affected, what do I do, will this happen again. Use only
confirmed information — mark anything still being determined as
"we'll update this by [DATE]" rather than guessing.
20. Post-mortem summary for external publication
If we're publishing an external post-mortem, help me draft it from these
internal findings: "[ROOT CAUSE, TIMELINE, WHAT'S CHANGING]"
Technical enough to be credible, plain enough for a non-technical reader
to follow the timeline and the fix. Use only the findings I've given you
— do not add technical detail that sounds plausible but wasn't confirmed.
The short version
Crisis communication rewards two things that are hard to do at the same time under pressure: speed and honesty. The 20 prompts above are built to give you the speed — a fast, structured first draft instead of a blank page — while the constraint running through every one of them protects the honesty: draft only from facts you actually have, flag what's still unknown, and never let a plausible-sounding sentence stand in for a confirmed one.
None of this replaces your incident response process, your legal counsel, or the judgment of the people closest to what actually happened. What it replaces is the wasted time between "something happened" and "we have a defensible first statement," and the risk of a rushed, unreviewed sentence becoming a second incident on top of the first. For the broader discipline of writing to clients and stakeholders under normal, non-crisis conditions, see our guide to client communication prompts, and for the narrower, everyday version of handling an upset customer without an incident behind it, 20 AI prompts for escalations and difficult customers covers that ground directly.
The single best investment a comms team can make before any of this is ever needed is running through the escalation ladder and the holding-statement structure once, calmly, as a tabletop exercise, rather than for the first time during an actual incident. A ladder that exists only on paper and has never been tested against a hypothetical scenario tends to reveal its gaps at the worst possible moment. Ten minutes reviewing who owns what, once a quarter, costs almost nothing and pays for itself completely the first time it's actually needed.