Map one workflow before you automate it.
Ask three people on the same team how an invoice gets paid and you will usually get three different answers. Each one is true for the part of the process that person touches. The trouble starts when someone tries to automate the process from one of those answers, and the automation runs straight into the other two.
The version in people's heads is the wrong starting point.
Most processes were never designed. They grew. Someone set up a shared inbox, someone else added a spreadsheet to track it, and a few years later there is a step where a coordinator forwards certain emails to a manager because of a problem that happened once. None of that is written anywhere, and the person who does it every day may not think of it as a step at all.
When a team decides to automate that process, the brief tends to come from whoever has the clearest picture of the happy path. A request comes in, it gets reviewed, it gets approved, it goes out. The automation is built to do exactly that, and it works for the cases that look like the description. Everything else (the late paperwork, the request missing a field, the client who always emails the director directly) lands in a pile no one expected.
We see this pattern often enough in our work with teams that we now ask for a map before anyone opens an automation tool. One page, one workflow, written with the people who do the work.
What a one-page map has to show.
A useful map is plainer than people expect. It doesn't need swim lanes, a diagramming tool or a consultant's notation. It needs the actual steps in order, who does each one, and what they need in hand to do it. A list down the left side of a sheet of paper is enough.
Two things matter more than the steps themselves. The first is handoffs, the moments when the work moves from one person, inbox or system to another. Handoffs are where things wait, get lost and get re-keyed by hand. The second is exceptions, which most first drafts leave out entirely. For every step, someone should answer the question "what happens when this doesn't go the normal way?" The answers are usually where the real time goes.
The happy path is the part of a process that already works; the exceptions are where your team spends its afternoons.
Picture a town clerk's office handling permit applications. The written procedure might list five steps. A morning spent mapping it with the two people at the counter could turn up a sixth step where incomplete forms get photocopied and mailed back, a seventh where the fee gets checked against an older schedule for certain neighborhoods, and a standing habit of calling the applicant when the address doesn't match the parcel record. Any automation built from the five-step version would handle the easy applications and drop the hard ones without telling anyone.
How to run the mapping session.
Pick one workflow, small enough to finish in an hour and annoying enough that people care about fixing it. Intake forms, purchase approvals, onboarding a new hire and the weekly report are all good candidates. Avoid anything that spans the whole organization on the first try.
Get the people who do the work in the room, with the manager who signs off on it if possible. Then walk one real recent example from start to finish. A real example works better than a hypothetical because people remember what actually happened to it, including the parts they would leave out of a general description. Once that one is mapped, ask about the last few that went wrong and add the branches they took.
Write as people talk. If someone says "then I check it against the old list," write that down and ask which list, where it lives and why it's still in use. The point of the session is to get the unwritten steps onto paper, so resist the urge to tidy them up while you're still collecting them.
Reading the map before you build.
A finished map usually changes the plan. Sometimes it shows that the slow part of the process is a decision that only one person can make, and no software will speed that up. Sometimes it shows two steps that exist only because a system from years ago couldn't talk to another one, and they can simply be dropped. Teams often get their first real win by deleting a step.
Where automation still makes sense, the map tells you where it fits. Look for steps that are repetitive, rule-based and fed by information that arrives in a predictable shape, such as copying fields from a form into a record or drafting a standard reply. Leave the judgment calls and the messy exceptions with people at first, and decide what the automation should do when it meets one. Handing the exception to a named person with a short note is a perfectly good answer.
The map also gives you something to test against later. When the automation is running, you can walk the same real examples through it and see whether each branch still ends up somewhere sensible.
A workflow-mapping worksheet
Fill one in per workflow, on a single page, with the people who do the work.
- Name the workflow and its trigger: what starts it, and how often it happens in a normal week.
- List every step in order, with who does it and which system or document they use.
- Mark each handoff, and note how the work moves (email, shared folder, verbal, a form).
- For each step, write what happens when it doesn't go normally, and who handles that case.
- Note where work waits, and for roughly how long, in the team's own words.
- Circle any step that exists only because of an old tool, rule or one-time problem.
- Mark the steps that are repetitive and rule-based, and the ones that need judgment.
- Pick one recent case that went badly and trace it through the map to check nothing is missing.
- Write down who owns the process today and who will own any automation built on it.
