The prompt
Score 10 of 10, Excellent
Use it when Something went wrong, such as a missed shipment, a payment run error or an outage, and you need a factual review that leads to fixes rather than blame.
- {{audience}}
- {{owner}}
- {{incident_notes}}
- {{impact}}
- {{actions_taken}}
Full prompt and why it works
Prompt
Write a blameless incident review of the event below, for {{audience}}. The purpose is to understand how our process allowed this to happen and to agree on changes, so that it is less likely to happen again. It is a draft for {{owner}} to review with the people involved before it is shared. What happened (timeline notes, messages, logs): """ {{incident_notes}} """ Impact as known so far: {{impact}} Actions already taken: {{actions_taken}} Use these headings: 1. Summary: three sentences on what happened, the impact and the current status. 2. Timeline: a table with the columns Time, What happened, Source, built only from the notes, oldest first. 3. Contributing factors: the conditions in the process, tools, information or workload that made the outcome possible. Write them as "The process allowed..." or "There was no check for...", not as a person's mistake. For example, "The order export ran before the stock sync finished, and nothing checked the order of the two jobs" rather than "The analyst ran the export too early." 4. What went well: things that limited the impact. 5. Actions: a table with the columns Action, Type (prevent, detect or respond), Owner, Due date. Use owners and dates from the notes; otherwise write "to assign". 6. Open questions. Keep it under 800 words. Use roles, not names, throughout. Do not assign blame, speculate about anyone's competence or intent, or describe anyone as careless. Do not add causes, numbers or impact that the notes do not support. The review should be something the people involved would agree is fair and accurate. If the notes conflict about when something happened, or it is unclear whether something contributed to the problem, say so under Open questions instead of choosing a version.
Variables
- {{audience}}
- Who will read the review, for example "the operations team and the head of operations".
- {{owner}}
- Who owns the review, for example "the operations manager".
- {{incident_notes}}
- Everything you have: timeline notes, chat messages, emails, system logs, with times where possible.
- {{impact}}
- Who or what was affected and how, as far as you know.
- {{actions_taken}}
- What has already been done to fix or contain it.
Why it works
- What to avoid. Contributing factors are written as gaps in the process, never as someone's mistake, which is what makes people willing to report the next incident.
- An example. A paired example shows the difference between a process factor and blame.
- If unsure. Conflicting times and unproven causes go to Open questions instead of being settled by the model.