Automating processes with AI starts with describing every step

What does it mean to map a process before automating it?

It means writing down, in order, every action a person takes to complete a task: what they open, what they copy, what they check, what they decide and who they notify. It is the starting point for any AI automation, whether with an assistant, an agent or a tool like n8n or Power Automate. It defines what can be automated and what will stay in people’s hands.

An analyst explains how she puts together the weekly report: “I pull the data from the system, move it to the spreadsheet and send it.” Three steps, she assures you! But when she does it with someone next to her taking notes, seventeen show up, the real ones… She exports two files because one comes out incomplete. She deletes a few test rows that someone loads, though nobody knows who. She manually fixes the names of two clients. She compares the total with last month’s to see if it “looks about right”. And when it doesn’t, she messages someone in another department before sending anything. Sound familiar?

The three steps are the process everyone agrees on. The seventeen are the real process, the way she actually does it. Any automation works on the second one!

What is known but never said

We know more than we can tell. Whoever performs a task every day handles it with accumulated judgment. They spot the odd data point, fill in what is missing and know who to ask. That judgment goes unnoticed precisely because it works.

A person tolerates ambiguity and resolves it on the fly. An automation does exactly what it was told. If the step “delete the test rows” was never written down, the flow will process them as if they were real data, and it will do so silently.

Mapping means putting that knowledge into words, at a level of detail where someone else could do the task without having to ask anything.

How to map a process, in practice

1. Do it live. The person who performs the task does it once, in real time, while someone takes notes. From memory, half the steps get lost.
2. Give each step a verb and an object. “Download the order list from the system” is a step. “Manage orders” is a summary.
3. Flag the decisions. These are the moments when the person looks at something and chooses a path.
4. Note the exceptions. What happens when the data is missing, wrong or late.
5. Record the source and the destination. Where each piece of data comes from and where each result goes.

With the complete list, the next step is to draw it: a simple diagram of boxes, arrows and decisions, done on paper before opening any tool.

What will stay in people’s hands?

With the process in plain sight, the second question comes up: which parts will remain human after automating. There is always a part left. Approving an amount, validating an exception that has no rule, agreeing on something with another department or taking responsibility for what gets sent are tasks that stay in a person’s hands.

Defining that part from the start changes three things:

• The design. The automation is built around those points, with pauses where a person reviews and confirms before moving on.
• Expectations. The result is an AI-assisted process, with people in the places where judgment is needed. A flow that promises to do everything and fails at the first exception loses the team’s trust, and a flow nobody trusts stops being used.
• Adoption. Whoever performs the task sees clearly which part they will stop doing and where they are still essential. That clarity lowers resistance more than any presentation.

That part also shrinks over time. As the team gains experience, some decisions that depend on judgment today become rules, and rules can be automated.

Why should the team map it themselves?

When someone from outside does the mapping, the understanding of the process leaves with that person. When the person who performs the task does it, the team gains two things: an automation that reflects the process as it is actually done, and a fresh look at their own work. They usually spot unnecessary steps, repeated checks and data that could arrive another way. Often the process improves before the first action is automated.

That is why, in Booster AI programs, mapping the manual process and defining which parts stay in people’s hands is the first thing we train, before any tool. The judgment, not the recipe: whoever knows how to map one of their own tasks can do it with any other, and with whatever tool the company chooses.

Before choosing a technology, the useful question is how many steps the task really has and which of them need a person. A team that can answer that about its own work has already started automating.

Questions and takeaways

What does it mean to map a process in order to automate it with AI?
It means listing, in order and with concrete verbs, every action a person takes to complete a task, including the decisions, the exceptions, and where the data comes from and goes. It is the input every automation needs.

Which parts of a process remain human after it is automated?
The ones that need judgment, such as approvals, exceptions with no rule, agreements with other departments or responsibility for the result. They are defined before building, because the automation is designed around those points.

Which processes should you automate with AI first?
The ones that repeat often, are already mapped step by step, and have clear rules and few parts that depend on a person. A process nobody has written down yet needs to be mapped first.

Who should map the process?
The person who performs it every day, together with someone who asks questions and takes notes. That way, the knowledge of the process and the judgment to improve it stay with the team.