When work departs from a standard process, a note saying “handled” or a signature added later may not show why the change happened, who approved it, or whether its impact was addressed. An exception log links verified facts, decisions, evidence, and follow-up so the team can reconstruct the event and decide whether the process needs to change.
What should count as a process exception?
Treat an exception as a departure from an adopted rule needing a decision trail. Confirm the rule: if a checklist requires second-person review but an outage delays it, the work departed from the rule. If the process permits an alternative and its conditions are met, record it in the normal workflow.
Assess what changed and could affect customers, inventory, delivery, funds, or information: a skipped check, changed approval, exceeded tolerance, or unverified data may alter risk. If a blank field is contradicted by original records showing completion, correct it under applicable rules and preserve history; if completion cannot be proved, record an exception pending clarification. State the requirement, action, difference, and decision basis.
Use low, medium, and high severity to set response speed: promptly fill a low-impact gap; have a manager decide whether to pause, redo, or notify for medium impact; contain and escalate high risks involving safety, funds, sensitive data, or expansion. Record rule version, ratification status, and closure authority. If a supplier shuts down before a deadline and purchasing rules require two quotes, log why an alternative was used and who authorized it. Log unauthorized purchases too, including the period and later response.
How should timing and impact be recorded?
Separate occurrence, discovery, and entry times. Record event ID, process/version, handler role, required step, actual action, difference, cause status, affected items, current risk, interim measures, evidence location, and open questions.
Write observable facts first; label assumptions. A blank review field is a fact; verbal approval without a supporting record remains unconfirmed. Identify affected orders, documents, customers, data, or batches and count from traceable sources. If scope is uncertain, state what was checked and remains unknown. Preserve timestamps, source locations, and originals; make corrections readable, with editor and reason. For external impact, record who decided whether to notify, when, and why; notices should distinguish confirmed facts from open questions.
This hypothetical summary uses illustrative numbers:
| Field | Example entry |
|---|---|
| Occurrence and discovery | A second-person review was found incomplete before Tuesday’s shipment |
| Impact scope | 1 order; 8 checklist fields awaiting reconciliation; not yet shipped |
| Immediate action | Hold release; preserve the checklist and system timestamps |
| To confirm | Outage times and whether other orders were affected |
The table summarizes; it does not replace evidence links. Add findings and reviewer to the same event; if scope grows, update affected items and preserve earlier versions and timestamps.
Who should confirm temporary approval?
Use the existing authority matrix to choose an approver based on risk and scope, not convenience. Amounts, customer commitments, data access, and quality release may belong to different roles; obtain each required confirmation. Check authority, conflicts, and any authorized substitute.
Record approver, time, decision, affected item, prerequisites, deadline, limits, and basis. “Manager agreed” is not reconstructable. Set limits in advance—for example, delay one batch but do not change price or data use. A limit breach needs renewed review; silence is not approval.
For urgent verbal approval, note its time and substance in a message or duty log, then complete formal records under internal rules; keep approval and record times distinct. Later ratification is not advance approval. If an authorized approver is unavailable or risk exceeds authority, pause, protect customers and assets, and escalate; act first only under a documented emergency procedure.
For a batch needing a second-person check, the handler cannot approve their own work. If a manager authorizes a substitute, record role, data scope, deadline, and release conditions. Approval assigns a decision; it does not erase the deviation or prove later controls worked.
How should corrective actions be assigned?
Give each action one owner, due time, collaborators, dependencies, completion evidence, and acceptance owner. Separate containment, restoration, verification, and recurrence reduction; split multi-step work into individually checkable tasks.
Set deadlines by risk and process timing. Mark actions as release blockers when work cannot safely proceed. For other actions, state due date and delay risk. The task owner supplies evidence, such as a record, recheck list, response, or system change; the acceptance owner checks it against a predefined standard and records state and change time.
At handover, assign a new owner and confirm evidence and due time. For unfinished or overdue work, record interim controls, next review, escalation role, and reassessed risk; do not quietly move deadlines.
If two checklist fields were missed before shipment, hold release, assign a duty manager, have another person recheck both and log the time, then have the process owner verify the full checklist. Release only after all three steps have evidence and pass acceptance. If incorrect information reached a customer, assign contact, correction, delivery confirmation, and next step if unanswered. Address form, permission, or handover causes; training alone is not a universal fix.
How can recurring exceptions reveal a common cause?
Do not group similar titles or blame the most frequent name. Compare process step, trigger, timing, system or supplier, impact, approval, and actions; test for a shared mechanism.
Ask which conditions and control failures prevented or delayed detection, and why the process did not prompt action. Check documents, timestamps, handovers, or interviews; one person’s recollection is incomplete evidence. If facts are missing, state the hypothesis and evidence needed before changing the process. Separate unrelated cases and note classification changes.
For example, shipping reviews may recur. If delays occur only at shift change and alerts go to off-duty staff, handover or alert design may be a common cause. Check other shifts and alert records; missed notifications, permissions, or workload may also contribute. If supported, target it—perhaps with a receiving handover role or changed alert recipients—and track recurrence under the same conditions.
A trend log can track counts, recurring mechanisms, impact, and overdue actions. State source, date range, and classification method. Small samples describe observations, not rates; process changes can weaken comparisons. Record decisions, no-action reasons, open risks, recurring mechanisms, and next-review conditions. If no cause is supported, keep cases separate.
When should a process be revised?
An isolated equipment failure may need repair and practice of a workable contingency, not process revision. Review recurring or impractical steps, unclear approval limits, late controls, memory-dependent recovery, or a process/system mismatch.
The process owner should compare intended controls with actual conditions, locating causes in rules, forms, permissions, tools, training, or resources. Propose the smallest change that addresses the cause. If no revision is needed, record why. Plan the target failure, affected roles, approval, pilot/test, success criteria, effective date, old-version retirement, and rollback.
Before piloting, walk through a case: can handlers follow the steps, approvers fulfill their roles, and reviewers inspect evidence? Afterward, check whether exceptions declined and whether delays or new risks appeared; adopt, adjust, or roll back. If reviewers lack time or access for a cross-check, provide a pause-and-escalate path.
At launch, mark version and date, notify affected roles, update forms and instructions, brief staff, and prevent mixed versions. Link the exception ID to the revision decision and verification result.
Choose a recent deviation; record its occurrence time, approval scope, action owner, and evidence location, then decide whether revision is needed. Learn more about Chan & Chung on the English website.