Set up your client project: claims evidence, contacts and past statements
Run one project per client. The playbook gets sharper every time the project knows more about how that client actually operates, and the same context carries into every other Flow the team runs for them. Add these once and the next crisis document starts from what the client has already approved rather than from public pages alone.
What to add
Claims and Substantiation Pack
The evidence behind the client's public claims: lifecycle assessments, certifications, nutrition data and the approved wording for each one. With this in the project, the claims audit checks published language against the real evidence instead of inferring what might sit behind it.
Crisis Contact and Approval List
Who holds each role, who can approve a public statement, who covers out of hours, and how each person is reached. The escalation matrix is built around these names and the approval paths reflect who is genuinely available at 3am.
Past Incidents and Issued Statements
What the client has faced before and the language they used publicly. Scenarios get re-scored against what has actually happened to this brand, and new statements stay consistent with positions the client has already taken.
Brand Voice Guide
How the client sounds, and what they never say. A crisis statement still has to sound like the brand, and this keeps the holding lines from reading like boilerplate issued by a different company.
Guide Juma with project info
Add a short description to each knowledge item in the project's info field so Juma knows what each file holds and when to reach for it. For example:
- Claims and Substantiation Pack: "Evidence behind every public claim. Check published wording against this before flagging a substantiation gap."
- Crisis Contact and Approval List: "Current roles, approvers and out-of-hours cover. Build the escalation matrix from these."
- Past Incidents: "What this brand has faced and said before. Use for re-scoring likelihood and keeping statements consistent."
Write the first line before you need it
Frequently Asked Questions
What does a crisis communications playbook include?
A complete playbook covers six parts: a claims exposure audit tied to the brand's own published pages, a scenario register scored on a printed likelihood and impact rubric, a four-level escalation matrix with triggers and update cadence, a first-60-minutes sheet, holding statements written per channel, and a do-not-say table giving the reason behind each forbidden line.
The two deliverables split by use. The branded PDF is the document that gets circulated, reviewed and signed off, with the register, matrix, statements and governance schedule laid out in reading order. The CSV register is the working file: one row per scenario carrying its likelihood and impact scores, risk score, default escalation level, accountable lead, escalation trigger, first actions, statement text and the source each scenario was derived from. Teams sort and filter that file at the quarterly review and re-score rows as the business changes.
How is this different from a generic crisis template?
A template gives every brand the same scenarios: contamination, cyber incident, executive misconduct. This Flow starts from what the brand has actually published, so the scenarios that matter most name the real claim, quote the wording, link the page and record the date it was checked. The register describes that brand's exposure rather than a category's.
The difference shows up in the highest-scoring rows. Generic registers rank product safety at the top by reflex. A claims-derived register often ranks a sustainability or labelling challenge above it, because the brand has published a specific figure on a specific page that it would have to defend on demand. Each holding statement then points at the claim it exists to answer, rather than leaving a bracket for someone to fill in while the clock runs.
How much time does this save compared to writing a playbook manually?
Crisis playbooks usually take an agency two to three weeks: a claims review, a risk workshop, a drafting round, then legal review. This Flow produces the claims audit, scored register, escalation matrix and the full statement set in one working session, which leaves the time for the part that actually needs people.
That part is the judgement. Which risks the client will genuinely accept, who really has authority to speak at 3am, how much candour the brand can carry in its first public line: those are decisions the client's leadership and their counsel make, and no document settles them. Every holding statement arrives marked pre-approved or counsel required precisely so the review goes where it is needed instead of across all seventeen pages. Strategy, taste, and judgment stay human, and human review on every output is the point of the approval column.
Do the holding statements need legal review before use?
Some do and the playbook says which. Each statement carries an approval status: pre-approved means it can go out once the bracketed facts are verified, counsel required means a named approver clears it first. Safety, data, securities and legal-process scenarios land in counsel required by default, because those carry statutory and disclosure consequences.
Treating every statement as equally risky is what makes real playbooks unusable, because teams either route everything to a lawyer who is asleep or route nothing. Splitting the two gives the comms lead something publishable inside the first hour for low-severity scenarios, while the statements that could create liability stop at a named person. The do-not-say table backs this up by naming the exposure behind each forbidden line, so anyone adapting a statement understands why a phrase is off the table rather than deleting a rule they do not recognise.
Does this work for B2B software companies as well as consumer brands?
Yes. The structure holds and the content changes completely. A consumer brand's register fills with product safety, supply, labelling and sustainability claims. A B2B software company's fills with security incidents, availability and uptime commitments, data processing and subprocessor claims, pricing changes and customer concentration.
The claims audit is what makes the difference, because it reads whatever that company has published. For a software business that means the uptime figure on the status page, the certifications on the trust page, the data residency promise in the security overview and the retention language in the privacy policy, each one a commitment somebody can hold them to in public. The escalation matrix changes shape too: enterprise customers often have contractual notification windows, so the matrix carries those clocks alongside the regulatory ones.