Every engagement I take on starts the same way: I map the work. Not the org chart, not the aspirational process — the actual flow of work activity through the business as it currently operates.
This step is almost always uncomfortable for clients. Documenting reality means confronting the gap between how the business is supposed to work and how it actually works. That gap is usually larger than expected.
Three questions to ask about every process
The first question is: where does work slow down? This is usually obvious once you’re looking for it. Jobs sitting in someone’s inbox. Approval processes that involve unnecessary steps. Information that lives in one person’s head and has to be requested every time it’s needed.
The second question is: where do errors happen? Not catastrophic failures, but the quiet recurring errors — the wrong information on an invoice, the missed callback, the order that goes out slightly wrong. These point directly to process gaps.
The third question is: what tasks are being done manually that follow a predictable pattern? These are your automation candidates. Manual doesn’t mean human judgment — it means repetitive, rule-based activity that a machine could handle reliably.
The build trap
The build trap is when the solution is assumed before the problem is understood. “We need a CRM” before you’ve established what customer information you actually need to track and why. “We need an app” before you’ve mapped the workflow the app would support.
Systems built without diagnosis tend to solve the symptoms of a problem rather than its root cause. They require more ongoing maintenance because they weren’t designed for the actual context. And they often get abandoned because the people who were supposed to use them never trusted them.
Diagnosis isn’t slow. A half-day working session with the right business owner can surface more useful information than weeks of requirements gathering. But it has to come before the build.