Map the process before you pick the tool

Most automation projects start with a tool. Someone has seen a demo of n8n or Make, or the team already pays for Zapier, and the question becomes what to connect to what. It feels like progress, because something gets built quickly.

The trouble is that the tool then decides the shape of the process. Steps that don’t fit the platform get dropped or worked around. Exceptions that happen once a week, the ones that cost the most time, are left for a person to catch. Six months later the business is running two processes: the automated one and the one people do around it.

So we start somewhere else.

Watch the work, not the diagram

Every business has a diagram of how something is supposed to happen. It is rarely how it happens. The useful version comes from sitting with the people who do the work and following one real case from start to finish: an order, an invoice, a new hire, a support request.

We ask four questions as we go:

• What actually happens? Every step, including the ones nobody thinks of as steps, like checking a spreadsheet before replying.
• Where does it get stuck? The waiting, the chasing, the copy and paste between two systems.
• What repeats? Work that follows the same rules every time is the safest to automate.
• Where does a person have to decide? Judgment calls are not failures of the process. They are part of it, and they need a place in whatever we build.

Write the logic down before anyone builds it

Once the process is mapped, we write its rules in plain language. Which system owns each record. What triggers each step. What happens when the data is missing, late or wrong. Who is told when something fails.

This document is short, and it does most of the work. It is what the client signs off, what the build is checked against and what the next person reads when the process changes. It is also where the tool choice becomes obvious, because by now the requirements are on the page.

Then choose the tool

With the logic written, the choice is usually simple. A workflow that branches a lot and that the team wants to see laid out suits Make. One that needs to run on your own servers, or carry real volume without the bill growing with it, suits n8n. Mainstream apps that the team will look after themselves suit Zapier. Some parts need custom code, and that is fine too.

Often the answer is a mix, and sometimes it is no new tool at all. Mapping a process regularly shows that the biggest saving is a change to how the work is done, not software.

Why it is worth the time

Mapping takes a few hours of the people closest to the work. In return, the system we build matches the process the business actually runs, the exceptions have somewhere to go, and the rules are written down for whoever changes them next.

Automation won’t fix a broken process. It makes the mess move faster. The map is how we find out which kind we are looking at.