How to Run a Process Efficiency Audit: A Step-by-Step Framework

"Something's not working, but I couldn't tell you exactly what" is the single most common opening line of every engagement we've ever started. It's not a lack of insight on the client's part — it's what happens when you're too close to a process to see its shape. A process efficiency audit exists to convert that vague discomfort into a specific, ranked list of fixes with numbers attached to each one.

Over fifteen years running these audits — for a FTSE 250 insurer with seventy-six process streams and for a five-person charity with one overworked ops manager — the underlying structure barely changes, even though the scale does by orders of magnitude. Here's that structure.

Step 1: Pick a boundary, not a department

The first mistake most internal audits make is scoping around an org chart rather than a process. "Audit the finance department" is too broad and, worse, artificial — most costly friction happens at the seams between departments, not inside them. Instead, define the audit around a single end-to-end process with a clear start and end point: "from client enquiry to signed contract," or "from invoice received to payment approved." A process, not a team.

Step 2: Map the process as it actually runs

Not as the handbook says it runs. This step requires watching or asking people to walk through their actual last three examples, in detail, including the workarounds nobody mentions in training. We consistently find that the documented process and the lived one have diverged — usually because someone found a shortcut months ago and it became the unofficial standard. That gap is itself useful information: it tells you where the official process is too slow or too rigid for real conditions.

Step 3: Time and count everything you can

This is the step people most often skip, and the one that turns opinion into evidence. For each stage of the mapped process, capture: how long it typically takes, how long it takes in the worst case, how often it has to be redone, and who is involved. You don't need sophisticated instrumentation — a week of honest timestamps from the team doing the work is usually enough to reveal the pattern. What you're looking for is variance as much as speed: a step that takes 2 days on average but ranges from same-day to three weeks is a bigger problem than a step that reliably takes 4 days.

Step 4: Find the constraint, not the complaints

Every team has opinions about what's broken, and they're usually about the part of the process closest to them — rarely the actual bottleneck. Once you have real timing data, look for where work piles up waiting for the next step; that queue is your constraint. Fixing anything downstream of the real constraint won't move your overall speed at all, which is why so many well-intentioned "efficiency drives" produce no measurable improvement — they optimised a part of the process that was never the limiting factor.

Fixing a step that isn't the bottleneck feels productive and changes nothing. Finding the actual constraint is the whole game.

Step 5: Cost each finding in the same units

A list of ten problems is not a plan. To prioritise honestly, translate every finding into the same currency — usually hours per month and, where possible, pounds per month. "The approval step averages 4.2 days and adds roughly 30 hours of chasing per month across the team" is a finding you can rank against other findings. "Approvals feel slow" is not.

Step 6: Separate quick wins from structural fixes

Not every finding needs the same kind of fix. Some are quick wins — a form field that's causing 40% of resubmissions could be fixed in an afternoon. Others are structural — the process fundamentally needs a different system or a different handoff design, and that's a proper project, not a tweak. A good audit output separates these clearly, because a client should be able to act on the quick wins immediately, without waiting for a larger programme to be scoped and funded.

Step 7: Write the roadmap, not just the report

The output of a good audit isn't a document that sits in a drawer — it's a prioritised sequence: do this first (cheap, fast, high impact), then this (moderate effort, moderate impact), then this (bigger investment, but here's the payback). Ranking by effort against impact, rather than listing findings in the order you discovered them, is what turns an audit into something a busy team will actually act on.

What this looks like at different scales

For a FTSE 250 client, this framework scales to weeks of stakeholder interviews across dozens of workstreams and formal statistical analysis of variance. For a charity with three staff, the same seven steps can run in a matter of days, using a whiteboard and a stopwatch rather than a data warehouse. The rigour is the same; the ceremony is not. That scalability is exactly why we built our Business Health Scan around this framework — a fixed-fee, 1–2 week version of the same discipline, sized for a business that needs the answer, not the six-month programme.