How to map a workflow before you automate it

An automation does not improve a process. It runs the process faster, including the parts that were never worth running. That is why the second month of an automation is usually worse than the first: the work still arrives, it just arrives without anyone looking at it.

The step that gets skipped is the boring one. Before you pick a tool, write down what actually happens today. Not the version in the onboarding doc, and not the version someone describes when you ask. The version that runs on a Tuesday when two of the inputs are late.

Why automation fails on work nobody has written down

A process that lives in someone's head is not one process. It is a family of related processes, and the person running it switches between them based on judgement they have never had to explain. When you automate, you have to pick one member of that family. If you pick the version people described to you, you have almost certainly picked the version that runs least often.

The exceptions are the whole problem. A monthly report might follow the documented path nine times out of ten, and the tenth time a source is missing, so the person running it substitutes last month's figure and adds a note. That substitution is not in any document. Automate around it and the tenth run produces a report with a hole in it, which somebody downstream will treat as real.

Mapping first does not remove the exceptions. It makes them visible early enough to decide what the automation should do when it meets one: stop and ask, carry on with a flag, or refuse to run at all. Those are three different products, and choosing between them after you have built one is expensive.

Write it as a sequence of states

Skip the flowchart. Write a numbered list where each entry names what arrives, what happens to it, and what leaves. If you cannot name the input and the output of a step, you have not found the real step yet.

1. Name the trigger. What has to be true for this work to start? A date, a form submission, an email from a specific person. If the honest answer is "when someone remembers", write that down, because it is the first thing worth fixing and it needs no software.
2. List each step with its input and output. One line each. "Input: list of twelve competitor URLs. Action: pull the page text. Output: twelve text files." Vague verbs like review, process or handle are a signal that a step is actually several steps.
3. Mark every point where the work changes hands. Between people, between tools, between a tool and a spreadsheet someone maintains. These are the handoffs, and they matter more than the steps.
4. Write down what makes each step stop. Missing input, ambiguous input, an input in the wrong format, a judgement call. This becomes the exception list, and it is the part of the map worth the most.
5. Name the consumer of the final output. A person, a decision, a document. If nobody can name one, you have found something to delete rather than automate.

Then run the process once with the list in front of you and correct it as you go. Every map is wrong on its first pass, usually in the same way: two or three small steps that are so habitual nobody thinks to mention them.

Count the handoffs, because that is where the time goes

Take any process that takes three days end to end and add up the time somebody is actively working on it. It is rarely more than a couple of hours. The rest is queue: work sitting in an inbox, a file waiting for a review, a request waiting for a reply from someone in another timezone.

Automating a step makes the work faster. Removing a handoff makes the process faster. They are not the same size of win.

So measure both, separately. For each step, note the working time, meaning hands actually on it. For each handoff, note the waiting time. Two runs of the process is enough to see the pattern, and the pattern is usually that one handoff accounts for more elapsed time than every step combined.

Handoffs also fail differently from steps. A slow step is annoying and visible. A handoff fails silently, because the work is nobody's while it waits. The classic version is a review step where the reviewer was never told they were the reviewer.

Some handoffs disappear for free once you can see them. If a file moves from person A to person B only so B can rename it and put it somewhere, the handoff exists because of a folder permission, not because of the work.

Score what to automate before you build

Once the map exists, most steps are obviously not worth automating and a few are obviously worth it. The argument is only ever about the middle. Three properties settle it faster than a discussion does.

Frequency sets the payback. A step that runs twice a year has to be genuinely painful before a day of building pays for itself, and it will have rotted by the next time you need it.

Variation sets the difficulty. A step that does the same thing to the same shape of input every time is cheap to automate. A step whose rules change with the input needs either much more work or a human in the loop, and pretending otherwise is how automations end up producing confident nonsense.

Blast radius sets the risk. If a step going wrong means an internal file is malformed, you will notice and fix it. If it means a client receives the wrong figure, the automation needs verification built in from the first version.

A worked example

A marketer produces a monthly competitor brief covering twelve companies. Before mapping, the process was described as "check their sites and write it up", and it took most of two days. The map told a different story.

1. Trigger. The first Monday of the month, when a recurring reminder fires. Reliable, so nothing to fix here.
2. Collect. Open twelve sites, copy the pricing and product pages into a document. Forty minutes of working time, and two of the twelve block selection, which meant a detour every month that had never been written down.
3. Handoff. Send the document to a colleague for a sanity check on which pages had changed. Fifteen minutes of work, two days of waiting. This single handoff was most of the elapsed time.
4. Compare. Read against last month, note what moved. An hour of genuine judgement, and the only part of the process that produced anything a reader valued.
5. Write and send. Ninety minutes, going to two named people who both read it.

The collect step scored high frequency, low variation and a small blast radius, so it was the obvious first target. A browser based extractor turned forty minutes into about five, and it handled the two awkward sites without the detour. Our Website Content Extractor was built for exactly this shape of step.

The handoff was the larger win and needed no tooling. The colleague was reviewing something they had no context on, which is why it always sat for two days. Dropping the review and adding a diff against last month's file to the compare step removed two days of elapsed time and cost nothing.

Note the order. If the collect step had been automated without mapping first, the brief would still have taken two and a half days, and the automation would have looked like a failure.

Record a baseline you can actually compare against

Time two or three runs before you change anything, and write down four numbers: elapsed time from trigger to delivery, working time by step, how often the process hit an exception, and how often the output needed correcting after delivery.

That last number is the one people skip, and it is the one that catches a bad automation. Throughput can improve while quality quietly falls, and without a correction count you will find out from whoever consumes the output rather than from your own numbers.

Two runs is enough. This is not a measurement exercise, it is a sanity check so that in six weeks you can answer the question honestly.

Keeping the map alive

A map goes stale the moment the process changes, and a stale map is worse than none because people trust it. Two habits keep it usable. Re-read it whenever the process surprises you, since a surprise means reality moved. And keep it in the same place as the work rather than in a documentation folder nobody opens.

The map is also what makes the next automation cheap. The first one takes a week largely because you are learning the process while building. The second takes a day, because the hard part is already written down.

The part that actually saves the time

Mapping is unglamorous and it is where the money is. Most processes that feel slow are not slow because any step is slow. They are slow because the work spends days in a queue, and no tool fixes a queue you have not noticed.

Write the list. Time two runs. Then pick the step with the highest frequency, the lowest variation and the smallest blast radius, and automate that one. The map will tell you which step that is in about an hour, which is quicker than finding out by building the wrong thing.