Three days before launch, a customer I'd never met posted a screenshot of our pricing error on a forum with 40,000 members. I found out at 11pm on a Sunday, from a friend's text message. My co-founder was asleep. We had no spokesperson, no holding statement, and no idea who was allowed to say anything publicly. We spent the next six hours improvising in a shared doc, and I can tell you exactly what that improvisation cost us: two enterprise deals that went quiet for a month and a support inbox that took nine days to clear.
That night is why I now treat a crisis communication plan as a piece of operational infrastructure for founders — not a document you build once for a board deck. If you're building one for your own company, the sections below are the ones I actually use, stripped of the consultant padding.
Key Takeaways
- A crisis communication plan is a pre-agreed set of decisions, not a document — who owns facts, who approves, who speaks.
- The founder should almost never be the fact-owner, the approver, and the spokesperson at once. Pick one role.
- Write your holding statement before you need it. It's the only thing you'll be able to produce under stress.
- Employees will hear about the crisis before your official message reaches them unless you designate an internal channel up front.
- Rehearse one scenario per quarter. An untested plan is a wish, not a plan.
- Keep the plan under four pages. Anything longer won't get read at 11pm.
How to build a crisis communication plan for founders who don't have a comms team
Most templates assume you have a PR department three people deep. You don't. You have a founder, maybe a head of ops, and a contractor who handles marketing two days a week. That changes the whole shape of the plan: fewer roles, tighter pre-written assets, and a hard rule that nobody improvises in public.
Why a founder-specific plan looks different from a corporate one
In a large company, the plan exists to coordinate departments. In a startup, it exists to stop the founder from ad-libbing. That's the core difference, and it drives every decision below.
When I looked at how our first incident actually unfolded, the failure wasn't a lack of goodwill. It was that three people each assumed someone else had already replied to the loudest customer. Two different answers went out within an hour. Neither was wrong, but they contradicted each other on the one detail that mattered — whether the issue affected billing. A single named owner for outgoing messages would have prevented the whole mess.
The five roles you need to assign (before anything happens)
You don't need five people. You need five roles, and one person can hold several — just not all of them.
- Fact owner. Confirms what is actually true, with timestamps. Usually an engineer or ops lead, never the person talking to press.
- Approver. Signs off on wording. This should be fast and singular — a committee will freeze you.
- Spokesperson. One face, one voice, one channel.
- Internal comms lead. Gets the message to your own team before it reaches the outside world.
- Logger. Records every statement made and when. Boring, essential, and the thing everyone skips.
Here's the specific advice I'd defend to the end: the founder should not hold the approver and spokesperson roles simultaneously. When you're the person whose reputation is on the line, your instinct is to say more than you should, faster than is wise. I learned that the hard way — my first public reply was 400 words long and created two new questions for every one it answered.
The holding statement is the only asset you'll write under pressure
Everything else can be prepared in calm conditions. The first public response cannot, which is why it needs to be pre-drafted in a fill-in-the-blank format. Three parts, and keep it short:
- What you know — confirmed facts only, with a timestamp ("as of 14:20 UTC").
- What you're doing right now — specific action, present tense.
- When you'll next update — a concrete time, and then actually hit it.
Notice what's absent: apologies you haven't verified, causes you haven't diagnosed, and timelines you can't guarantee. Getting this structure right took me an embarrassing number of attempts. The version that finally worked was under 80 words and said almost nothing — which was exactly why it worked.
Three ways to run crisis comms at startup scale
Not every company needs the same level of machinery. Here's how the realistic options stack up:
| Approach | Setup cost | Best for | Main weakness |
|---|---|---|---|
| Single-page incident card | Two hours | Teams under 10, low public profile | Breaks down the moment two channels light up at once |
| Full written plan with roles and templates | One to two days | Companies with paying customers and press exposure | Rots quietly if nobody rehearses it |
| Retained outside PR support | Ongoing monthly fee | Funded startups facing regulatory or press scrutiny | Expensive, and the agency won't know your product |
My honest take: the middle option is where nearly every seed-to-Series-A company belongs. The incident card is better than nothing but gives you false confidence. The retainer makes sense only once a single bad week could plausibly cost you a funding round.
Internal communication decides whether the plan survives contact
Your team will find out from a customer, a friend, or a news alert. Every time. The only variable you control is how long they sit with that information before hearing from you.
In our case, the gap was close to two hours, and the damage was noticeable — two people gave slightly different versions of events to their own contacts because they were genuinely trying to help. We fixed it afterwards with a simple rule: internal message goes out within 30 minutes of the fact owner confirming anything, even if the internal message only says "we know, we're on it, details by 5pm." That single rule has held up across three smaller incidents since.
How to build a crisis communication plan you'll actually test
An untested plan is a wish. Testing doesn't mean a full simulation with actors and a war room — it means a 45-minute tabletop exercise once a quarter, with the people who'd actually be involved.
Pick one scenario: a data exposure, a public complaint that goes viral, or a co-founder departure that leaks. Then walk through the five roles and see where it breaks. The first time we ran this, we discovered our designated spokesperson was on a flight with no wifi for six hours. That's the kind of gap only a rehearsal finds.
What did the rehearsal actually change?
Three things. We added a named backup spokesperson. We moved the approval step from email to a single shared channel so the timestamp was automatic. And we cut the plan from eleven pages to three, because nobody could find anything in the long version while under time pressure.
What belongs in the document itself
Keep it under four pages. If it takes longer to read than the crisis takes to escalate, it's useless.
- Role assignments with names and phone numbers, plus one backup each
- The holding statement template with fill-in blanks
- Channel list: which platforms get the official message, and in what order
- The update cadence commitment — how often you'll communicate, and where
- Escalation triggers: the specific conditions that move you from "monitor" to "respond"
- One paragraph on what you will never do: speculate on cause, blame a customer, promise a timeline you haven't confirmed
What I'd leave out: lengthy definitions of what a crisis is, generic reputation-management theory, and any page that begins with the phrase "in today's fast-moving environment." All of it gets skipped when you're panicking.
The part that doesn't fit on the page
The document is maybe 20% of the work. The other 80% is the social agreement that you'll follow it — that the engineer will tell the fact owner before telling their group chat, that the approver will respond within 15 minutes even on a weekend, that the founder will accept being edited down.
That agreement is why I now run the rehearsal even when everything is calm and nothing seems to justify the hour. The plan didn't save us on the night of the pricing screenshot. The habit of having discussed it did. And there's a strange side effect: the quarter after we started rehearsing, our team's internal communication got sharper about ordinary things too — launch dates, roadmap changes, hiring news. Turns out the discipline of saying clearly what you know and don't know is useful well beyond the bad days.
If you build only one thing this month, build the holding statement and name a fact owner. That's roughly two hours of work, and it's the two hours I wish I'd had three days before launch.