Documenting exceptions as they happen, not after

There are two ways to document an exception: at the moment it happens, or later, when someone asks about it. The two produce completely different quality of record, even when describing the exact same decision, because the second version is a reconstruction and the first is a report.

Why timing changes what actually gets captured

In the moment, the person making the exception has full access to the specific circumstances — the exact reason, the alternatives they considered, the pressure they were under, the small details that made this particular case different from the standard rule. Writing it down then costs almost nothing, because it's simply describing what's already in front of them.

Asked to explain it later, the same person is reconstructing from memory, filtered through everything that's happened since, often under some pressure to justify a decision that's now being questioned rather than simply described. The reconstruction is usually plausible. It's rarely as accurate as the original would have been, and there's no way to know how far it's drifted without the original to compare against.

Why "after" documentation tends to happen at the worst moments

Exceptions typically get documented after the fact for one of two reasons, and both are bad timing. Either someone is questioning the decision — an audit, a review, a customer complaint — which puts the person explaining it on the defensive rather than in a neutral, descriptive frame of mind. Or enough time has passed that the exception now looks unusual enough to warrant an explanation, which means the original context has already substantially faded.

Neither situation produces a reliable record. The defensive version tends to over-justify. The delayed version tends to under-specify, because the details that made the exception clearly reasonable at the time are exactly the details most likely to have been forgotten.

What "at the time" actually requires in practice

Not a lengthy process. The entire discipline is: when you make an exception, before moving to the next task, write one or two sentences about why. This works because it attaches the documentation to an action the person is already taking, rather than asking them to remember to do it separately later.

The reason, specifically, not generally. "Customer complained about a delayed delivery, offered a partial refund to retain the relationship" is useful. "Customer service issue" is not, because it tells a future reader nothing they couldn't have guessed.

What made this different from the standard case. If the exception is genuinely warranted, there's usually a clear answer to what made this situation unusual. If there isn't a clear answer, that's worth noticing too — it might mean the "exception" is actually happening often enough to be a new standard case that hasn't been formalised yet.

Why this habit is easier to build into a workflow than into willpower

Relying on people to remember to document exceptions, unprompted, fails for the same reason most good intentions fail under deadline pressure — it competes with everything else demanding attention and loses. What works is making the documentation a required step in whatever workflow produces the exception, so it happens because the process demands it, not because someone remembered a best practice — see approval workflows people actually follow.

A required reason field on an exception approval, populated at the moment of approval, captures this automatically and consistently, for every exception, without depending on anyone's discipline holding up on a busy day.

What to change this week

Look at how exceptions currently get approved in your business — pricing overrides, non-standard terms, write-offs. If there's no required field for the reason at the point of approval, that's the single highest-leverage change available: not a new process, just a required field on the one that already exists.

Common questions

Why is documenting an exception at the time better than explaining it later?

Because at the time, the person has full, unfiltered access to the actual circumstances and reasoning. Explaining it later is a reconstruction from memory, often prompted by scrutiny or the passage of time, both of which distort the account — either through defensive over-justification or genuine forgetting of the details that made the exception reasonable.

Why does after-the-fact documentation tend to happen at bad moments?

Because exceptions usually only get explained retrospectively when something prompts the question — an audit, a complaint, a review — which puts the explainer on the defensive, or after enough time has passed that the original context has already faded, producing a vaguer and less reliable account either way.

What should an exception's documented reason actually contain?

A specific reason, not a general category — what made this case different from the standard rule, and why the exception was the right response. A vague label like "customer service issue" tells a future reader nothing useful; a specific account of the actual circumstances does.

How can a business make this habit stick without relying on individual discipline?

Build the documentation requirement into the approval workflow itself, so a reason field is required at the moment an exception is approved. This captures it consistently for every exception because the process demands it, rather than depending on someone remembering a best practice under deadline pressure.

Related: approval workflows people actually follow · a decision log is cheaper than the mistake it prevents · the customer exception nobody wrote down