Observation checklist
Watch the work, then capture what the diagram missed.
| Observe | Capture | Why it matters |
|---|---|---|
| Trigger | What actually starts the work | Reveals work that begins outside the documented system |
| Handoff | What context moves and what is reconstructed | Shows where delay and repetition enter |
| Exception | What makes the normal path stop | Names the review or recovery route a build needs |
| Owner | Who can decide what happens next | Prevents an unowned queue after launch |
What audits find
Use these four checks to find what the documented workflow misses.
Load-bearing shortcuts
Steps that were skipped and never added back.
When a workflow was originally designed, it included a step that turned out to be slow, redundant, or unclear. The team stopped doing it. The shortcut became permanent. The official process still shows the step, but nobody does it.
Some shortcuts are safe to formalise, the step was unnecessary. Others are load-bearing in ways that are not obvious: skipping them works 90 percent of the time and breaks silently in the other 10. The audit identifies which is which before a new system inherits either assumption.
Informal handoffs
Context that moves between people but never enters a system.
A deal moves from sales to delivery. The formal handoff is a CRM stage change. The actual handoff is a fifteen-minute conversation where the sales rep explains three things about the client that are not in any field. The delivery team needs those three things. The system does not have them.
Informal handoffs are the most common source of context loss in operational systems. The audit makes them visible: what information is being transferred informally, who transfers it, and what happens when the person who usually holds that knowledge is unavailable.
Inconsistency between people
The same role handled differently by different people.
Two people doing the same job use different tools, apply different criteria, or make different decisions at the same step. The workflow looks consistent at the process level. At the execution level it is not.
Inconsistency matters for system design because a system built around one person's interpretation will not work for the other. The audit surfaces these inconsistencies, not to judge which approach is correct, but to force the design decision that was previously being made implicitly by each person individually.
Exception accumulation
Unusual cases that have become routine handling.
Every workflow has exceptions. What the audit usually finds is that the exceptions have multiplied over time into a parallel workflow of their own, a collection of special cases that each has a person who knows how to handle it, an informal trigger that tells them when it applies, and an outcome that is never recorded in the main system.
These informal exception processes are often more important to the team's actual output than the official workflow. A system that does not account for them will not replace the workflow. It will exist alongside it, adding overhead without solving the core problem.
The audit before the build
Skip the audit and you build a system for the workflow that was designed, not the one that exists.
The spec describes what someone intended; the audit describes what is actually happening. Skip it and you build for the documented workflow while the team keeps working around everything it does not cover.
