A process audit gives a team a shared account of how work actually moves. The useful output is a map supported by real examples, a short list of failure points, and decisions the owner can make. A diagram of the intended process is a starting point for observation.
Collect recent runs
Use ordinary records from the same process, with sensitive details removed where possible. Include a straightforward completion, an item that required rework, and an exception. For each, record the event that started it, the people or systems involved, and the evidence that it finished. Ask where the records are incomplete.
Walk the handoffs with operators
Review one run with the people who actually receive and send it. Mark the inputs they need, the evidence they leave, and the reasons work is sent back. Distinguish active effort from elapsed waiting. A small manual workaround can explain why a process looks reliable in reporting while operators still spend time correcting it.
Prepare a findings readout
For each finding, show one observed example, its effect, and the owner who can confirm it. Mark assumptions explicitly. Group ideas into process changes, small technical fixes, and candidates that need feasibility work. End with a decision on what to measure or test first, with a named owner and a follow-up date.
Example
Trace a purchase request through a team inbox and record time waiting for approval.
What to do next
Leave the audit with an agreed current-state map and a prioritized short list supported by observed runs.