Clean up
The discussion guide
A one-page, printable list of questions you read aloud in the blameless review meeting — seven sections, three to five spoken questions each, framed around the system rather than any person.
Run the meeting a few days after the incident — not immediately — with the incident responders plus stakeholders from any impacted service. The guide covers How Did We Get Here, Impact, Detection, Response, Recovery, Learnings, and Future Actions, and it builds the ground rules into itself: every commitment leaves as a task with an owner, a due date, and a way to confirm it's done. "Improve communication" is not an action item.
Same conversation: paste the prompt as a new message in the conversation that built your BC/DR plan — it already has your business summary, role mapping, and severity scale. Brand-new conversation? You can attach your BC/DR plan to the conversation for context.
Using everything from this conversation — the business summary, role mapping, P1-P4 severity scale, and BC/DR plan — build us a Post-Mortem Meeting Discussion Guide.
This is not a report template. It's the list of questions we'll actually ask out loud in the room to run a blameless post-incident review. Base the structure on Atlassian's incident postmortem framework (https://www.atlassian.com/incident-management/postmortem/templates), but make it easier to use live in a meeting: fewer fields, plain language, real questions instead of fill-in-the-blank prompts.
Organize it into these seven sections, each with 3-5 discussion questions:
1. **How Did We Get Here** — what led up to the incident, what changed right before it started
2. **Impact** — what broke, who felt it (customers, internal teams), how long, tied to our P1-P4 scale
3. **Detection** — how we found out, how long that took, whether we could have caught it sooner
4. **Response** — what we did once we knew, using our role mapping from earlier, what worked and what didn't
5. **Recovery** — how we confirmed it was actually fixed, using the "what restored means" definitions from our BC/DR plan where they exist
6. **Learnings** — root cause (push for at least one "why" past the first answer, but don't require a full Five Whys write-up), what surprised us
7. **Future Actions** — turn every commitment into a task with an owner, a due date, and a plain-language way to confirm it's actually done. "Improve communication" is not an action item; "add a customer-notification step to the release checklist, owned by [role], done when it's in the checklist template" is.
Build these ground rules into the guide itself, not just as a description of it:
- Frame every question around the system or process, not a person. Include a short "if you hear blame, rewrite it" reference the facilitator can glance at mid-meeting — 4-5 pairs, e.g. "X forgot to..." → "The process didn't require confirmation that...", "Nobody owned it" → "Ownership was implicit rather than assigned." Base these on our own role mapping and systems, not generic examples.
- Note at the top that this meeting happens a few days after the incident, not immediately, and should include incident responders plus stakeholders from any impacted service.
Where our earlier context doesn't give you enough to phrase a question specifically to us — for example, don't ask about a status page if we don't have one — write it generically instead of guessing at systems we don't have.
Format it as a single page I could print and hand out in the meeting: headers and a short question list per section, not paragraphs. Add a one-line footer crediting Atlassian's postmortem framework as the source of inspiration, with the link. What the prompt asks for
The structure is based on Atlassian's excellent incident postmortem template, but adapted to your use. It also writes a short "if you hear blame, rewrite it" reference into the guide — phrased around your own roles and systems — so the facilitator can glance at it mid-meeting.
Where your context doesn't cover something, the AI writes the question generically instead of guessing at systems you don't have.