How to Map a Process Before You Automate It

Every process has two versions: the one you'd describe if asked, and the one that actually happens. They differ most in exactly the places that break automation — the exception someone handles without thinking, the step that only applies to certain clients, the thing that gets skipped when it's busy.

Mapping is the act of writing down the second version.

Map by doing, not by remembering

Reconstruction from memory smooths over the fiddly parts. Your description will be the clean version, which is the one that doesn't work.

Run the process and write each step as you complete it. If someone else runs it, sit with them and write while they work — and resist correcting them mid-flow, because how they actually do it is the data.

Do this two or three times. The second run surfaces steps you skipped writing down; the third surfaces the variations.

Four things per step

For each step, capture:

| | Question | Why it matters | |---|---|---| | Trigger | What causes this to start? | A step with no trigger cannot be automated — nothing can fire it | | Actor | Who or what does it? | Identifies handoffs | | System | Where does it happen? | Determines what tools must integrate | | Output | What exists afterwards? | Becomes the next step's trigger |

The trigger and output are the important pair. One step's output should be the next step's trigger. Where that chain breaks, you've found a gap where work waits for someone to remember.

A worked line:

STEP 4  Send the intake form
  Trigger:  Agreement signed (from step 3)
  Actor:    Account manager
  System:   Email + form tool
  Output:   Form sent, logged against the client record
  Time:     5 min
  Waits:    Client completes it — typically 1-4 days

That Waits line is worth adding wherever the process stalls on someone else. Waiting time is usually most of the elapsed duration and none of the effort, and it's frequently the thing actually worth fixing.

The exceptions are the map

The happy path takes ten minutes to write. The exceptions take the rest of the session and they're where the value is.

For each step, ask:

• What happens if this input is missing or wrong?
• What if the person is away?
• What if the client doesn't respond?
• Has this ever gone wrong? What happened?
• Is there a type of customer this works differently for?

An automation built on the happy path breaks the first time reality varies, and it breaks in the worst way — by continuing confidently.

Write exceptions inline, where they occur:

STEP 4  Send the intake form
  - If no response in 3 working days: automated reminder
  - If no response in 7: account manager calls
  - If the client is enterprise: legal review before sending (adds 2-5 days)

Mark every handoff

A handoff is any point where work passes between people, or between a person and a system.

Circle them all. They're where things stall, where context gets lost, and where the same question gets asked twice. In most processes, the handoffs contain nearly all the delay even though they contain almost none of the work.

They're also the highest-value automation targets — a handoff that fires automatically removes a wait, and removing waits shortens elapsed time far more than speeding up individual steps.

Delete before you automate

The most valuable output of mapping is usually not the map. It's the list of steps that turn out to be unnecessary.

Ask of every step:

• Why does this exist? If the answer is "we've always done it," investigate.
• Who uses the output? If nobody can name a consumer, it may be producing nothing.
• What breaks if we stop? Sometimes genuinely nothing.
• Is this checking work that another step already checked?

Duplicate approvals, reports nobody reads, and forms whose data is never used are extremely common. The cheapest automation is a step that no longer exists — and deleting is free while automating is not.

Expect to remove a meaningful fraction of steps. Do that first, then re-map, then automate what's left.

Then mark what to automate

Go through the finished map and label each step:

• AUTO — rule-based, stable, no judgement
• ASSIST — a person decides, a tool prepares the option
• HUMAN — judgement, relationship, or genuinely rare

The ASSIST category is the underused one. Plenty of steps aren't fully automatable but can be reduced to a review — a draft prepared, a figure calculated, an exception flagged. That converts twenty minutes into two without removing the judgement.

Keep it current

A map that's a year old is a historical document. Attach it to the SOP and let whoever runs the process update both — the same rule applies: the person who runs it edits it, without needing approval.

The mistakes

1. Mapping from memory. You'll write the clean version.
2. Only the happy path. The automation breaks on the first variation.
3. Skipping triggers. A step with no trigger can't be fired by anything.
4. Ignoring waits. They're most of the elapsed time.
5. Automating before deleting. You've made a pointless step permanent.
6. Mapping alone. The person who runs it knows things you don't.

What to do next

Take the top candidate from your automation shortlist and map it the next time you run it — writing as you go, exceptions included. Then before building anything, go through and delete every step you can't justify.