Something went wrong, a customer noticed, and someone spent the afternoon on damage control: an apology, a refund, a fix pushed through by whoever was closest to the problem. By evening the ticket is closed and everyone is relieved it's over.
It isn't over. The process that produced the mistake is exactly as undocumented as it was yesterday morning. The only thing that changed is that one specific instance of it got patched. The next person to touch that process, next week or next quarter, starts from the same gap.
The fix and the documentation are two different jobs
Under pressure, both get treated as one job, and the documentation part loses. That's understandable: the fix is urgent and visible, and writing down what actually happened feels like it can wait until things are calmer. Things are never calmer. A week later the details are fuzzy, the person who found the workaround has moved on to the next fire, and the write-up never happens.
The moment right after an incident is, counterintuitively, the best time to document the process, not the worst. Everyone involved still remembers the exact sequence, the specific step that had no written answer, and the workaround that actually worked. That detail decays fast. In a week it's gone.
What to capture before the memory fades
- The exact step where the process broke. Not the general area, the specific point: which person or system was supposed to catch this and didn't.
- What the process assumed would never happen. Almost every incident traces back to a case nobody wrote a rule for, because it seemed unlikely. It just happened.
- Who actually fixed it, and how. The workaround someone improvised under pressure is usually the first draft of the real fix. Write it down before it's forgotten as "we sorted it."
- What the customer was told, word for word. If it needs following up or contradicts what they'll be told later, this is the only record.
- Who else could hit the same gap. If one account manager improvised a fix, the other four are still exposed to the exact same undocumented step.
Ask why it happened, not just what happened
A ticket log records what happened: the customer's order shipped to the wrong address. That's the symptom. The useful question is why the process allowed it: was there no step that verified the address against the account on file, or did that step exist and get skipped under a rush order?
Keep asking why until the answer is a process or a missing check, not a person. "Someone forgot to verify the address" is not a root cause, it's where most teams stop. The real question is why forgetting was possible: was there no step, no prompt, no second check? A cause you can't design a fix around isn't a root cause yet.
Write the fix into the process, not into someone's memory
A fix that lives as "we all know to double-check that now" survives until the person who said it moves teams. A fix that gets written into the actual procedure, as a step with a name attached, survives the next reorg.
That means the output of this isn't a postmortem doc that gets read once and archived. It's an edit to the process itself: a new step, a new decision branch for the case that wasn't covered, or a new escalation path for exactly this situation. If there was no written process at all before the incident, that's the actual finding, and the postmortem is the fastest cover you'll ever get to write one.
Decide who owns the fix, not just who reported the bug
An incident with no named owner for the follow-up gets a apology and nothing else. Someone specific needs to own updating the process, with a date, and someone else needs to confirm it actually happened rather than assuming it did because it was mentioned in a meeting.
The confirmation step is the one that gets skipped. A corrective action that was agreed verbally and never checked is indistinguishable, three months later, from one that was never agreed at all.
Where Sendabrief fits
The fastest way to lose this window is to schedule a formal review for next week. By then the detail is gone. If the incident already got talked through on a call, paste the transcript or upload the recording and get a structured draft of the fixed process out of it in minutes, roles, the new step, and the decision branch for the case that wasn't covered. If it's fresher in someone's head than it is on a recording, they can describe it out loud and get the same result.
Either way the draft goes through review before it replaces the old process, so what ends up live has been checked, not just typed up under pressure.