What should I document when a process has exceptions that are hard to remember?
Quick answer
For each exception, record the situation that triggers it, how to recognize it, what to do first, what not to assume, and who to ask for a decision. Include where relevant information can be found and what details to provide when escalating. Keep routine steps separate from exceptions, use plain language, and date the note so someone can check whether it is still current.
The question, the details, the next step.
Our process is straightforward most of the time, but people forget what to do when an unusual case comes up. What should I capture?
Make a small exceptions and escalation note alongside the main process—not a long catalog of every imaginable scenario. For each exception, help the reader answer five questions: What situation am I seeing? What clues identify it? What should I do immediately? What should I avoid deciding on my own? Who can clarify or approve the next step?
Also record where the person can find the relevant record or reference, and what information to include when asking for help. Separate the exception from the normal path so a reader can quickly tell whether the standard instructions still apply. If no one has confirmed the right response, label it as unresolved rather than presenting a guess as a rule.
How do I describe an exception so a colleague can recognize it without knowing the history?
Describe observable clues, not just a label like “special case” or “urgent.” State what differs from the usual process and what detail makes that difference matter. Avoid relying on a person’s memory of an earlier incident; the note should make sense to someone encountering the situation for the first time.
For example, suppose a team’s ordinary request includes all required fields. An illustrative exception might be: “One required field is missing, and the requester cannot confirm it.” That is more useful than “incomplete request,” because it tells the reader what to check. Then give a safe holding action—such as pausing the handoff and asking the designated owner—only if that action is actually appropriate for your process. Confirm your team’s actions and roles before publishing the note.
What belongs in the escalation part? I want people to know when to stop, but not make the guide cumbersome.
Write a clear pause point and a clear route to guidance. Name the role or team to contact, using a placeholder until your organization confirms the owner. Explain what to send: the relevant record identifier, the observed mismatch, what has already been checked, and the decision needed. Do not ask people to include sensitive information unless your approved process calls for it.
A useful distinction is: “If X is true, continue with the standard step. If Y is true or you cannot tell, pause and ask [role/team].” Don’t invent a deadline, approval authority, or backup contact. If the owner is unavailable and the next step is unclear, say where to find the approved fallback—or mark the gap for the process owner to resolve before relying on the note.
Can you give me a copyable template and show what a completed entry might look like?
Use this compact format, then have the process owner check that the examples, actions, and escalation route match the actual work.
Exception note template
- Process and version/date: [name] — [date]
- Exception name: [short, recognizable label]
- Recognize it when: [observable clues]
- Difference from the normal path: [what does not fit]
- First safe action: [confirmed action, or “pause and ask”]
- Do not assume or do: [decision that needs guidance]
- Ask: [role/team and approved route]
- Include in the question: [record reference, observed facts, checks made, decision needed]
- Owner and review date: [role] — [date]
Illustrative entry—replace with your team’s confirmed process:
- Exception name: Required request detail is missing
- Recognize it when: A required field is blank and the requester cannot confirm it.
- Difference from normal path: The request is not ready for the usual handoff.
- First safe action: Pause the handoff; do not fill in the missing detail by inference.
- Ask: [designated process owner/team] via [approved route].
- Include: [request reference], which field is blank, what was checked, and what decision is needed.
Keep the entry short enough to scan. Review it when the process changes or a real exception reveals that the wording is unclear. This template helps organize guidance; it cannot establish your organization’s rules or decide an unresolved case.
A practical checklist
Separate the normal process from exception instructions.
Describe recognizable clues and what differs from the usual path.
State a confirmed first action and what the reader should not infer.
Name the verified role or route for guidance; use placeholders until confirmed.
List the facts needed for a useful escalation, without requesting unnecessary sensitive details.
Add an owner and review date, and mark unresolved guidance clearly.
A few more useful answers
Should I document every unusual situation?
Start with exceptions that recur, create confusion, or require a decision beyond the standard steps. Record other cases when they reveal a meaningful gap, rather than trying to predict every possibility.
What if nobody knows the right response yet?
Label the case as unresolved, record the known facts, and identify who must decide or clarify the process. Don’t turn an unconfirmed workaround into an instruction.
How often should the note be reviewed?
Assign an owner and a review date, and revisit the note when the process or escalation route changes. The right review interval depends on how often that work changes.