A report arrives with the same missing column for the third week. A customer request is approved outside the usual route. A recurring handoff needs a workaround because one input was late. Each incident looks small, so people solve it and move on. Then the same friction returns. An exception log gives teams a practical way to record departures from normal work, fix the immediate problem, and spot repeated patterns without building another heavyweight reporting system.
The purpose is not to catch colleagues making mistakes. It is to distinguish a one-off interruption from a recurring weakness in a process. A useful log makes the next response faster and gives the team evidence for a proportionate improvement.
What belongs in an exception log?
An exception is a specific event in which actual work differs from an agreed standard, expected input, deadline, rule, or workflow. For example, a purchase request arrives without the required cost centre; a weekly export contains an unexpected duplicate; or a document reaches an approver without the necessary supporting evidence.
Not every inconvenience deserves an entry. Log an issue when it needs a workaround, changes a commitment, creates material rework, introduces risk, or has happened repeatedly. Keep routine questions and harmless variations out of the log. Otherwise, the record becomes noise and people stop using it.
Separate this from a decision log. A decision log preserves why a team chose a course of action. An exception log captures what departed from the normal process and how the team responded. One exception may eventually lead to a decision, but the records answer different questions.
Use seven fields, not a complicated incident form
Start with a shared table, spreadsheet, or task-list view. The simplest useful record contains seven fields. Choose plain-language labels and make only the essential fields mandatory at the point of capture.
- Date and workflow: when the exception occurred and which recurring activity it affected.
- Expected versus actual: the normal requirement and the observed deviation, stated without assigning blame.
- Immediate impact: the delay, rework, customer effect, or control risk, including a quantity when known.
- Containment: what was done to keep work moving safely in this instance.
- Owner: one person responsible for following up, not necessarily the person who caused or discovered it.
- Status and next review: open, contained, investigating, resolved, or monitoring, with a specific check date.
- Repeat signal: a short category or related-record identifier to make similar events easy to group.
Keep the record brief enough to create in about two minutes. If root-cause analysis is needed later, add a linked note. Do not ask someone handling a live deadline to complete a long investigation before recording the basic facts.
A worked example: the recurring missing attachment
Suppose a sales team forwards signed order forms to operations every afternoon. Twice this month, the required pricing appendix was missing. Operations had to request it, and fulfilment preparation was delayed. A vague entry such as “Sales keeps forgetting attachments” is neither neutral nor useful.
A better entry reads: “October 8; sales-to-operations order handoff. Expected: signed order form plus current pricing appendix by 3 p.m. Actual: appendix absent on order 4821. Impact: preparation paused for 45 minutes. Containment: operations requested the appendix and held fulfilment changes pending verification. Owner: sales operations lead. Status: monitoring; review October 15. Repeat category: incomplete order handoff; related event September 29.”
That description gives the next person a starting point and avoids guessing about intent. It also makes the repeated failure visible. If the problem persists, the team can check whether the handoff instructions, template, responsibility, or timing need to change.
Capture facts first and explanations second
When an exception happens, record what someone could verify: the missing input, affected work item, time detected, and immediate consequence. Avoid writing “careless” or “always late” in the event description. Those are judgments, and they make the record less trustworthy.
If the impact is still unknown, write “impact being assessed” and assign the follow-up. A guessed financial amount or invented delay is worse than an honest blank. Attach a link to the relevant work item only when colleagues have permission to open it, and avoid copying sensitive customer details into a broadly shared log.
Use a short final check before calling an incident contained. Confirm the workaround did not introduce a second problem, the current version is correct, and the receiving person can proceed. The checklist in How to Do a Final Quality Check Before You Send Work provides a useful structure for that verification.
Set an escalation threshold before the next incident
An exception log should not become a substitute for action. Agree in advance when a team member can apply a standard workaround and when the issue requires approval. A low-impact missing field might be corrected by the request owner; a change to contract terms, privacy handling, safety requirements, or customer commitments may require a named approver.
Write escalation rules in terms people can recognize: “Escalate if the customer deadline changes, a required control must be bypassed, the workaround affects more than one department, or the same category occurs three times in 30 days.” These are example thresholds, not universal standards; adjust them to your actual operational risk.
For decisions that require authorization, use the five-line method in How to Create an Approval Path Before Work Gets Stuck. The log can then link to the approved exception rather than allowing a temporary workaround to become an unexamined permanent rule.
Review patterns weekly, not every incident in a meeting
A log creates value when somebody reviews it. Reserve ten minutes during an existing weekly operations check-in, or conduct the review asynchronously. Sort open items first, then group the past month’s entries by repeat category. Ask which exception has caused the most avoidable rework, not simply which category has the largest number of rows.
Look for concentration: the same missing input from several requesters, repeated last-minute approvals, one confusing instruction, or a recurring timing mismatch between teams. Three similar incidents might indicate a process issue; three unrelated incidents do not necessarily call for the same fix.
For each meaningful pattern, choose one response: clarify an instruction, change a template, adjust a deadline, name a handoff owner, add a small validation check, or accept a documented variation. Assign one owner and a review date. If no change is justified, record the reason and keep monitoring rather than manufacturing a project.
Fix the process and check whether the fix worked
Imagine the missing-appendix problem occurs four times in six weeks. The team learns that a saved email template lists the order form but not the appendix. The owner updates the template, adds a checkbox beside the upload action, and tells operations what will change.
The test is not whether the new template exists. It is whether the next set of handoffs arrives complete. Review a defined sample, such as the following ten eligible orders, and record how many required a follow-up. Compare that with the earlier period, while noting differences in workload. If exceptions continue, revisit the assumption rather than declaring the problem solved.
When different people cover the same process, include exception handling in the handoff. The framework in How to Hand Off a Task Without Losing Context helps clarify the expected outcome, current state, next action, constraints, and escalation point.
Keep the log separate from a general task backlog
An exception is an observation; an improvement task is a commitment to change something. Linking them is useful, but mixing every task into the log obscures trends. Keep the exception entry as evidence, create an ordinary task for the approved fix, and link the two. Close the task when implemented, then mark the exception as resolved only after checking the result.
Changing priorities can also produce legitimate exceptions. If a manager deliberately moves a deadline, record the updated commitment in the project plan; only log an exception if the change violates a required process or creates a recurring problem. The guidance in What to Do When Work Priorities Keep Changing can help communicate the trade-off without turning every change into an incident.
A 15-minute launch checklist
- Choose one recurring workflow with visible rework, such as approvals, reporting, or order handoffs.
- Write the normal expectation in one sentence so people can identify a genuine deviation.
- Create the seven fields and select a single owner for the log’s upkeep.
- Enter two or three recent, verified examples rather than inventing historical data.
- Agree on one escalation rule and one weekly review point.
- After two weeks, remove fields nobody uses and inspect whether repeat categories are actionable.
Tell the team what the log is for: preventing repeated interruptions and clarifying safe responses, not measuring individual blame. Limit access to people who need it. If employees believe every entry is a performance accusation, they will stop reporting the exceptions that matter most.
The standard of success is less repeated rework
An exception log does not need sophisticated software, a long policy, or a daily meeting. It needs clear criteria, factual entries, responsible follow-up, and a short review habit. The best signal of success is not a growing number of records. It is fewer repeated surprises, faster containment when something does go wrong, and more reliable work for the people downstream.