The automation audit: 12 questions before you automate anything

Before we automate anything for a client, we map the existing process by hand — every step, every decision point, every exception. It's tempting to skip straight to the workflow tool, but a surprising number of 'automation' projects turn out to be process-design projects wearing an automation costume.

The questions that matter most: How often does this process run, and how much time does it actually take today? What happens when it fails right now, and who notices? Which steps require real judgment versus just following a rule? If nobody can answer the second question confidently, that's a sign the process needs a design pass before it needs a tool.

Exceptions deserve special attention. Most processes have a clean happy path and then a long tail of edge cases handled by institutional knowledge — 'oh, if it's from that client, do it this other way.' An automation that only handles the happy path and silently mishandles the exceptions is often worse than no automation, because the failures are quieter.

Our rule of thumb: automate the parts of a process that are well-understood and repetitive, keep a human in the loop for genuine exceptions, and build in visibility so someone can see what the automation did and why. That combination is what makes automation something a team trusts enough to actually rely on.