How to Map a Process Before You Automate It

To map a business process, pick one process, write down its trigger, each step, who does it, what goes in and what comes out, then mark the exceptions. Time one real run and note every handoff and wait. The finished map becomes the brief for your automation.

Why map a process before automating it?

Automation copies whatever process you give it. If the process has hidden steps, unclear owners or constant exceptions, the automation will reproduce those problems faster. Mapping forces you to see the work as it really happens, which is often different from how people describe it.

You do not need special software. A document, a spreadsheet or a whiteboard photo is enough. What matters is that the map is accurate and written down.

Step 1: Pick one process with a clear start and end

Choose a single process, such as handling a new enquiry or sending an invoice reminder. Define where it begins and where it ends. If you are unsure which process to choose, use the scoring method in the guide on what to automate first. Resist mapping the whole business; a map that covers everything tends to describe nothing well.

Step 2: List the trigger, steps, owners, inputs and outputs

Write down what starts the process, then every step in order. For each step, record who does it, what information they need and what they produce. Ask the people who actually do the work, not only the person who manages it.

Keep each step to one action. Review the invoice is two actions if it means check the amount and confirm the purchase order. Splitting them shows where a rule could apply.

Step 3: Mark the exceptions

Ask what happens when things do not go to plan: missing details, a customer who replies late, a figure that looks wrong, a manager who is away. List each exception and what the person currently does. Exceptions are where most automations fail, because a tool follows the standard path unless it has been told otherwise. Some exceptions will become rules; others will stay with a person, and that is a legitimate result.

Step 4: Time one real run

Follow one actual case from trigger to finish and record the time for each step, including the gaps between steps. Use a real run rather than an estimate, because people tend to forget small interruptions. Do not invent an average from one run; treat it as a sample and, if the process varies, time a few. The aim is a baseline you can compare with after the change.

Step 5: Find the handoffs and the waits

A handoff is where work passes from one person or system to another. A wait is where nothing happens until someone acts. Both are common sources of delay and error, and both are good places to look for automation. A message that moves details between tools or a reminder that nudges a late approver often saves more than speeding up a step that is already quick.

A plain template to copy

Copy this table into a spreadsheet and add one row per step. Fill in the process name, trigger and end point above it.

How do you turn the map into an automation brief?

Once the map is complete, the brief mostly writes itself. Mark each step as keep with a person, automate, or automate with approval. Then summarise the following in a page.

The process name and goal. The trigger and the end point. The steps to automate, in order. The inputs, and where each one lives. The rules for each decision. The known exceptions and who handles them. The baseline time and error rate you recorded. The person who owns the process and signs off the result.

A brief like this lets any builder, internal or external, give you a realistic view of scope. It also supports the before, during and after checks in the business process automation checklist.

Erudience services related to this guide

Use cases related to this guide

Frequently asked questions

Do I need special software to map a process?

No. A spreadsheet, a document or a whiteboard works. The value comes from writing down the real steps, owners and exceptions, not from the tool you use.

How detailed should a process map be?

Detailed enough that a new colleague could follow it without asking questions, but not so detailed that it becomes unreadable. One action per step is a good guide.

Who should help me map the process?

The people who do the work every day. Managers often describe the intended process, while the people doing it know the workarounds and exceptions.

What if the process is different every time?

That is a sign it may not be ready to automate. Try to identify the common path and the exceptions separately, or consider automating only the stable part.

How long does mapping take?

It varies with the size of the process and how many people are involved. A small process may take a short session, while one spanning several teams will take longer. Time it once and plan accordingly.