Process Mapping Before an Automation Project

Process mapping is the step most automation projects skip, and the one whose absence derails them. The temptation is easy to understand: everyone already knows which process is slow, the tool has already been chosen, and spending two weeks drawing boxes and arrows feels like time stolen from real work.

The trouble is that an automation does exactly what it was told. If the description is incomplete, you do not get a faster process. You get the wrong process running faster, with fewer people watching it.

Three people, five versions of the same process

Ask three colleagues to describe how expense approval works in your company. You will get three different answers, and probably none of them matches what actually happens. Celonis, whose business is reconstructing processes from the traces they leave in systems, puts it plainly in its analysis of process discovery: ask three people how a process works and you get five different answers.

This is not carelessness. Each person knows their own stretch of the process well, plus a little before and a little after. Nobody holds the whole thing in their head — and the whole thing is precisely what the automation will execute.

Mapping is the exercise of putting those stretches into one drawing and forcing the versions to confront each other. Half the value shows up in the room, when two people discover they run the same check twice, or that nobody performs a check both assumed the other was doing.

What a map actually has to contain

A map that is useful for automation is not a tidy flowchart. It is the answer to five questions, step by step:

What triggers the process? An email, a submitted form, a time of day, a new row in a spreadsheet. If you cannot name the trigger precisely, there is no automation to build.
Who does it, and in which system? The name of the role and the name of the application. "Sales confirms it in the CRM" works. "It gets validated" is worthless.
What data goes in and comes out? Concrete fields: tax number, order reference, expected delivery date. This list decides whether two systems can talk to each other at all.
Where is there a decision? Every branch, with the criterion spelled out. "Above £5,000 it needs director approval."
How long does it take and how often does it happen? Without those two numbers there is no way to prioritise, and no way to prove later that it was worth doing.

None of this requires software. A sheet with those five columns, filled in during a two-hour meeting with the people who run the process, is already a better map than most of what companies keep filed away as PDFs.

The exceptions are the real map

Ask a team to describe a process and what you get is the happy path: the sequence that unfolds when nothing goes wrong. Everyone can recite it, and it is usually the part that causes the least trouble.

The cost sits everywhere else. In real processes a minority of cases generates the majority of variants, and those variants eat the hours, because each one makes somebody stop and think.

Here is an example, with illustrative numbers and the arithmetic in plain sight. A 30-person company receives 60 quote requests a month. On the happy path each request takes about 12 minutes: read the email, check the customer history in the CRM, fill in the template, send. That is 12 hours a month.

But roughly one request in five involves a configurable product and requires a trip to production to confirm lead times. That detour adds some 35 minutes. Twelve requests times 35 minutes is another seven hours. The real process costs close to 19 hours a month, not 12.

Automate only the happy path and you solve 12 of those 19 hours. The remaining seven end up worse than before: they lose their recognised route and get handled case by case, with no record and no clear owner.

The map is what lets you run this calculation before spending the budget rather than after. It is the same reasoning we applied when working out how much manual processes actually cost, only step by step instead of treating the process as a single block.

Which notation to use, and when a table is enough

For most SMEs, the five-column table plus a swimlane diagram — one lane per department — solves the problem. The strength of lanes is that they make handoffs visible, and it is between lanes that work sits waiting for somebody to notice it.

When the process crosses several systems and will be implemented by people who were not in the room, it is worth moving up to BPMN, the notation maintained by the Object Management Group and now the de facto standard for business process diagrams. BPMN distinguishes things that genuinely change the implementation: a timer event is not a message event, and an exclusive decision is not a parallel split.

One warning about BPMN: the full specification runs to more than a hundred elements and almost nobody needs them. Five or six symbols — start, task, decision, end and error event — cover practically everything an SME will automate in its first year.

The map also exists to say no

Not every mapped process should be automated. The value of the map is that it lets you make that call with arguments instead of enthusiasm.

Three signs it is better to stop:

The process changes every quarter. Automating an unstable rule is buying permanent maintenance.
Low volume, high variability. Fifteen cases a month, all different, rarely pay for the workflow that would handle them.
The map exposed steps that should not exist. Here the answer is to remove, not to automate. A deleted step costs nothing to maintain.

That last point is the most common and the most wasted. Often the biggest gain from a mapping exercise is not the automation that follows. It is the field nobody has read in two years that stops being filled in.

From map to workflow

A good map converts almost directly into implementation. Triggers become trigger nodes, decisions become conditional branches, and the systems you named become connections — n8n's official catalogue currently lists more than two thousand integrations, so the question is rarely whether something can be connected.

What the map gives you and intuition does not are the exceptions. Every error branch you identified on paper corresponds to a behaviour somebody has to decide inside the workflow: retry, carry on, or stop and alert a human. The n8n documentation on error handling describes the two levels where this is set: on the individual node and on the workflow as a whole, through a dedicated error workflow that starts with an Error Trigger node.

Without a map, nobody remembers those branches while building. They remember them in production, when a supplier sends a PDF with no order number and the workflow fails silently for three days.

After the map comes the design phase, which has rules of its own — we wrote about how to design a workflow your team will actually use.

Where to start next week

Pick one process. Just one. Ideally one that happens at least 20 times a month and involves two departments, because handoffs between teams are where time hides.

Book two hours with the people who run it, not with the people who manage it. Draw the happy path in 20 minutes and spend the rest of the time asking "and when does it not happen like that?". Record every answer as a separate branch.

At the end, add up the times and see what share of the total cost sits on the happy path and what share sits in the exceptions. If you are not sure which processes are good candidates, our list of 20 business processes worth automating helps you choose the first one.

The question that closes a process mapping exercise is not "can we automate this?". It is a less comfortable one: now that we have seen the process drawn out, do we still want it exactly like this?