---
title: "Process automation step by step: 5 stages | JustAutomate"
description: "How to map and automate one process: a week of watching instead of an interview, counted exceptions, five metrics read before the change, a parallel run."
url: "https://justautomate.ai/en/guides/process-automation-step-by-step/"
lang: en
---

Where to start

# Process automation step by step from the map of one process to production

A process that exists only in people's heads cannot be automated. Below is the method we run in our workshops: a week of watching instead of an interview, exceptions counted one by one, five metrics read before anything changes, an explicit split of work between the automation and the person, and a parallel run next to the old process. At the end, a checklist to clear before anyone starts building.

10 minutes read

- 5 dayshow long we watch the process before the first map is drawn; what people say about it we collect after the measurement, not before
- 5 metricsthe numbers written down before the change and read again after it, so there is something to compare against
- 2 to 6 weekshow long it takes us from workshop to a working solution, depending on how many systems sit on the path
- 30 and 90 dayswhen we measure the process after go-live, on the same metrics we used before the start

Short answer

## How do you automate a process step by step?

Start with one process and with watching it, not with a tool. Sit next to the person who does the work and write down what actually happens: which system they open first, where they retype data from one screen to another, who they ask, what they wait for. An interview gives you the procedure. Watching gives you the process.

Then measure it for a week on five numbers: time for one run, runs per month, corrections, time from event to result, and how many people touch a single case. Only with those numbers in hand do you design the target version, and write down in plain words what the automation takes over and what stays with a person.

Run the new process alongside the old one, not instead of it. For two weeks both paths handle the same work and you compare the results. Before you start, agree who gets the alert when the automation stops. At 30 and at 90 days you read the same five numbers you took before the change.

## The method in five steps, in this order

The order is not cosmetic. Each step collects the information without which the next one is guesswork. The usual shape of failure: the tool picked in week one, the process understood in week four, when half the budget is gone.

This is the same sequence we run on a [process workshop](https://justautomate.ai/en/services/process-workshop/), and you can walk it yourself if you have someone in the company who can watch another person work for a week without fixing it along the way.

1. ### Watching
A week at the desk of the person who runs the process. You write down systems, clicks, waiting, and the questions they ask other people, not how it is supposed to work.
2. ### Exceptions and measurement
You add to the map every situation that fell off the main path, and measure the process on five numbers. Exceptions get counted separately: how many times a month each one shows up.
3. ### Target version
You draw the process after the change and write an owner next to every fragment: the automation or a person. A fragment with no owner does not go into the build.
4. ### Parallel run
The automation starts next to the old process: first in preview mode with nothing written, then writing for real. For two weeks both paths handle the same work and you compare the results.
5. ### Switch and measure
You turn the old process off only once every difference has an explanation. At 30 and at 90 days you read the same five numbers and set them against the measurement from before the change.

## Why watch a process instead of asking about it?

Asked about a process, a person describes the procedure: how it is supposed to work. Watched, they show you the process: three tabs side by side, a file on the desktop called „final\_v4”, a phone call to a colleague to check which price is current.

The gap is measurable. The time people report does not include hunting for the file, waiting for someone's answer, or fixing their own mistake, and those three are exactly what automation lifts most easily. So we measure instead of asking.

- Which system gets opened first, and why that one
- Every place where data is retyped by hand from one screen to another
- Every wait: for an answer, for an export, for the day to close
- Every question asked of another person, together with what it was for
- Files outside the systems: spreadsheets on the desktop, notes, chat messages

**Note.** The observer does not correct and does not advise. One „you could do that faster” changes the process you came to measure, and the measurement starts again.

## What has to be in the map of one process?

A process map is not a flowchart for the wall. It is six things, without which nothing can be built, written so that someone outside the department can follow them.

The same hole shows up in every company: nobody can say in one sentence what starts the process and how you know it finished correctly. An automation needs something to fire it, and it needs to be told when its job is done.

| Element of the map  | The question it answers                                            | Where you check it                                                     |
| ------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------- |
| Trigger             | What starts the process and at what time of day it usually happens | system log, inbox, team calendar                                       |
| Systems on the path | Which tools get opened and in what order                           | watching, the user's list of access rights                             |
| Input data          | Where the data comes from and in what format it arrives            | 20 sample documents from the last month                                |
| Decisions           | Who decides mid-process, and on what basis                         | a conversation with the decision maker, after the watching, not before |
| Result              | What has to be produced and how you know it is correct             | a definition of the finished result, written in one sentence           |
| Owner               | Who answers for the process when something goes wrong              | how the team actually splits work, not the org chart                   |

The third column matters more than the second. „We know how it works” with no place to verify it is a declaration, not a map.

## Why do exceptions eat most of the time?

The main path of a process is boring and fast. Time disappears into the exceptions: an order with no VAT number, an invoice in a foreign currency, a customer writing to a salesperson's private address, a document sent in as a phone photo.

Exceptions are missing from the written process, because nobody thinks of them as the process. They are „those situations”. So the workshop question is put differently: not „how does this work”, but „when did it last fail and what did you do then”.

A counted exception can be handled, or deliberately left to a person. A skipped exception comes back a month later as a phone call: the automation did something, and nobody knows what, or to whom.

- Incomplete data: no number, no address, an empty field in the form
- A format other than usual: a scan instead of a file, another language, another currency
- A duplicate: the same request arrived through two channels on the same day
- An urgent case someone pushes through outside the queue and outside the system
- An unusual customer: own price list, own payment terms, own contact person

**Note.** Count how many times a month each exception happens. The once-a-quarter one stays with a person, and you write that into the map. Handling a rare exception can cost more than the whole main path.

## How do you measure the process before and after the change?

The before measurement cannot be recovered later. Once the automation is live, nobody can reconstruct how long the retyping really took, because nobody does it any more. What is left is a story, and a story compares to nothing.

You take five numbers, the same ones before and after. A metric that cannot be read out of a system without asking someone to fill in a spreadsheet drops off the list on day one. How to turn these numbers into money is in our guide to [automation ROI](https://justautomate.ai/en/guides/automation-roi/).

| Metric                    | Where you read it                                        | What breaks this measurement                  |
| ------------------------- | -------------------------------------------------------- | --------------------------------------------- |
| Time for one run          | a stopwatch during the watching, not a declaration       | timing only the easy cases                    |
| Runs per month            | system log, document list, order history                 | seasonality, so take at least 3 months back   |
| Corrections and rework    | credit notes, resends, complaints                        | fixes made quietly, with no trace in a system |
| Time from event to result | the entry timestamp and the exit timestamp in the system | weekends and holidays counted as working days |
| People touching one case  | the watching and the process map                         | leaving out the people who only approve       |

You read the same five rows at 30 and at 90 days after go-live. Change the definition of even one metric along the way and the comparison stops meaning anything.

## The line: what stays with a person

The target version of a process is not „the same thing, only faster”. It is a new split of work, written out fragment by fragment. A fragment with no owner stays in the company as a hole that someone plugs by hand a month later, with no trace in any system.

The rule we apply: the automation takes what is repeatable and checkable, the person keeps what costs money or a relationship when it goes wrong. An AI agent will draft the reply and point at the source, but sending it to a strategic client should be a person's move.

- Automation: moving data between systems, in both directions
- Automation: watching deadlines, reminders, retrying failed operations
- Automation: assembling a report from several sources and counting the same thing every time
- Person: a cost decision, a discount, an exception to the rule, the conversation after a mistake
- Person: the first handling of an unusual case nobody has seen before

**Note.** Write down what the automation does NOT do as well. The sentence „the system does not issue credit notes” saves an hour of explaining six months later why a correction never went out.

## Who gets the signal when the automation stops?

The automation will stop. Not because it is badly built, but because a vendor changes an interface, a token expires, or a file arrives in a format nobody planned for. The question is whether you find out in 15 minutes or on Friday, from the customer.

Before go-live you settle three things: what happens to the job that failed, who gets the alert, and after how long the case goes to a person. Without that, monitoring is a screen nobody looks at.

The parallel run is the cheapest insurance in the whole implementation. For two weeks the automation handles the same work as the person, and you compare the results day by day. Only then does the old process go dark. That is how every deployment runs at our [AI automation agency](https://justautomate.ai/en/ai-automation-agency/).

- Automatic retry: 3 attempts, then the job lands in an error queue
- One alert channel for the team, a Slack channel for example, not one person's inbox
- A named person in the documentation: who reacts on working days, who reacts outside them
- Response time written as a number, 4 working hours for example, not „quickly”
- A manual path that always works: how to do this step without the automation

**Note.** An alert to one person's inbox goes on holiday with them. An alert to a team channel is seen by someone else, so it reaches whoever happens to be at a desk.

Common mistakes

## Five mistakes that break a process implementation

- An interview instead of watching
You get the procedure and build the automation on it. The exceptions that were eating the time surface in production and come back as phone calls.
- The tool picked before the process map
The process gets bent to fit what the tool can do, rather than the other way round. It ends in a workaround nobody but its author can maintain.
- No measurement before the change
At 90 days there is nothing to compare the result against. The effect stays a story, and at the next budget round nobody buys it.
- Going live instead of the old process, with no parallel run
The first case nobody planned for stops the department, because the manual path disappeared on the same day the automation started.
- An alert with no owner
The automation sits idle for 3 days, because the notification went to the inbox of someone on holiday. The customer finds out first, the team finds out from the customer.

Checklist

## Checklist before the first line of configuration

If any line is a no, do not start building.

- One process picked, described in one sentence, with one owner
- A week of watching behind you, notes written up the same day
- Exceptions listed and counted: how many times a month each one happens
- Five metrics measured before the change, each with the place it is read from
- The target version drawn, every fragment owned by the automation or by a person
- Settled: what happens on an error, who gets the alert, how fast they react, and how to do the step by hand
- The parallel run dates and the 30-day and 90-day measurement dates already in the calendar

Sources

## Sources

1. [n8n documentation: building flows, error handling and retrying jobs](https://docs.n8n.io/)
2. [Make help centre: scenario execution history and what to do after an error](https://www.make.com/en/help)
3. [Zapier help centre: monitoring and replaying failed tasks](https://zapier.com/help)
4. [JustAutomate, automation ROI: the formula and a worked payback example](https://justautomate.ai/en/guides/automation-roi/)

Let us map one process

## A workshop ends with a map and a measurement, not a deck

On a free 30-minute consultation we pick one of your processes with you and say plainly whether it can be mapped in a week. The process workshop costs EUR 3,500 net per week and ends with a process map, a counted list of exceptions, the measurement from before the change, and a 30-day plan you can execute without us. We take at most two implementations at a time.

[Book a free consultation](https://justautomate.ai/en/contact/)

## Frequently asked questions

Where do you start when automating a process in a company?

With picking one process and with a week of watching it, not with a tool. Sit next to the person who runs it and write down what actually happens. You choose the tool only once you have a map, counted exceptions and a measurement from before the change.

How long does it take to implement one process?

From workshop to a working solution usually takes us 2 to 6 weeks, depending on how many systems sit on the path and whether they have an API. The process workshop costs EUR 3,500 net per week; the build is quoted after the workshop, because anything earlier would be guesswork.

How long should you measure a process before the change?

A week minimum, so 5 working days, and across all the cases, the hard ones included. Take the number of runs from a wider window: at least 3 months back, so seasonality does not skew the average. A shorter measurement mostly shows you the good days.

What do you do when there are more exceptions than main path?

Count them and sort by frequency. You automate the weekly ones and deliberately leave the rest to a person, written into the map. A process where exceptions dominate needs its rules cleaned up first, and only then an automation on top.

How long do you keep the old process next to the new one?

Usually two weeks: the first in preview mode with nothing written, the second writing for real, with both paths handling the same work. You turn the old process off only once every difference has an explanation. The manual path goes into the documentation and stays there for good.

How much does it cost to run a process like this every month?

Platform licences per the vendor price list, AI model usage at EUR 0.005 to 0.07 per query paid to the provider directly, plus time for fixes when one of the systems changes its interface. Support after go-live is optional here and agreed separately.

## Related

- [What can be automated in your business](https://justautomate.ai/en/guides/what-can-be-automated-in-business/)
- [Automation ROI](https://justautomate.ai/en/guides/automation-roi/)
- [How to measure automation ROI](https://justautomate.ai/en/guides/how-to-measure-automation-roi/)
- [How to implement an AI agent](https://justautomate.ai/en/guides/how-to-implement-ai-agent/)
- [Process workshop](https://justautomate.ai/en/services/process-workshop/)
- [AI automation agency](https://justautomate.ai/en/ai-automation-agency/)

---

**JustAutomate** · contact: contact@justautomate.ai · form: https://justautomate.ai/en/contact/