The Automatisation Process: Five Steps From Manual Task to Running System

Most automation projects fail in the same order: someone picks an exciting process instead of a boring one, builds the complete version before proving the simple one, and then nobody owns it when the source system changes.

The automatisation process that actually works is five steps, and the first two are where the outcome is decided:

1. Select — pick the process on frequency and stability, not on how painful it feels
2. Map — write down what actually happens, including the exceptions
3. Build small — two steps in production beats twelve on a whiteboard
4. Instrument — logging, alerting, and a manual fallback before you trust it
5. Own — a named person, or it rots

Here's what each step looks like in practice, plus the scoring method for step one and the failure signature for each.

Step 1: Select the right process

The instinct is to automate whatever is most annoying. That's usually wrong — the most annoying processes tend to be annoying because they're full of judgment and exceptions, which is exactly what automates badly.

Score candidates on four axes instead:

A process that scores well on all four is worth automating even if it only takes ten minutes, because ten minutes daily is a working week per year. A process that fails two or more is worth fixing before automating — and often fixing is the whole answer.

The trap worth naming: a process that exists only because two teams don't share a system. Automating it makes the underlying breakage permanent and much harder to see. Ask why the process exists before you ask how to automate it.

Step 2: Map what actually happens

Not what the documentation says. What people do.

Sit with whoever runs the process and watch one real execution. You are looking for three things the process owner will not volunteer:

• The undocumented steps. The spreadsheet they keep on the side. The colleague they message to check something.
• The decision points. Every place they choose. Each one is either a rule you can encode or a human checkpoint you must keep.
• The exceptions. Ask "when does this go wrong?" and then "what did you do last time?" This is the single most valuable question in the whole process, and it's the one that never makes it into a requirements doc.

Write it as a sequence with the exceptions attached. If the process is going to be handed to a provider or rebuilt later, BPMN makes that map portable between tools instead of trapping it in a screenshot.

Failure signature for this step: the automation works perfectly in testing and breaks in week one. That means the exceptions weren't mapped — real inputs are messier than the sample you were given.

Step 3: Build the smallest version

Two steps. In production. This week.

Not the full flow with branches and error paths — the first two steps of it, running on real data, with a human doing the rest. Then add the third step.

This is unpopular advice because the complete design is more satisfying to build, but the reason is arithmetic. A twelve-step flow built before anything ran has twelve places to be wrong at once and no information about which one is failing. A flow grown two steps at a time is never more than one change away from its last working state.

Which platform matters less than people expect:

• Zapier — the fastest path when both apps are supported
• n8n — self-hostable with a code fallback, for control or data residency
• Power Automate — the obvious pick inside Microsoft 365, with desktop RPA for systems that have no API
• UiPath — when you must drive legacy software through its interface

Our comparison in workflow AI covers how these differ on billing units, which matters more than feature lists once something runs at volume.

Step 4: Instrument before you trust it

The difference between a demo and a process automation system is what happens when it fails at 3am on a Sunday.

Four things, none optional:

• A log of every run, success or failure, with enough detail to reconstruct what happened
• An alert on failure that reaches a person, not a channel nobody reads
• A retry policy that distinguishes "the API was briefly down" from "the data is wrong" — retrying the second forever is how bills explode
• A documented manual fallback, because the process still has to run on the day the automation doesn't

The failure mode this prevents is the worst one in automation: a job that silently stopped working three weeks ago, while everyone downstream kept trusting its output. A loud failure is a minor problem. A quiet one is a data integrity incident.

Step 5: Give it an owner

Every automation needs a named person who notices when it breaks and knows enough to fix or escalate it. Not a team. A person.

The reason is that automations decay for reasons outside themselves: an API changes, a field gets renamed, a credential expires, someone restructures a folder. None of these are bugs in your flow, and all of them break it. Without an owner, the first failure becomes permanent, and the process quietly reverts to manual — usually without anyone deciding that.

Budget this as ongoing cost, not project cost. A reasonable rule is that a portfolio of automations needs roughly a day a month of somebody's attention per dozen flows. If nobody has that day, build fewer flows.

Putting it together

The whole process, compressed:

1. Score candidates on frequency, variability, judgment, and error cost — automate the boring winner
2. Watch one real run and write down the exceptions
3. Ship two steps to production, then grow it
4. Add logging, alerting, retry rules, and a manual fallback before trusting it
5. Name an owner and budget their time

For a catalogue of what other teams start with, examples of automation covers common first candidates, and automating business processes goes deeper on the organizational side.

One honest note on where people actually stall. It's rarely step one or two — it's the gap between "I found a workflow that does this" and "it's running on my machine." Dependencies, credentials, and environment setup kill more automation attempts than bad process design does. Taku mirrors an AI workflow someone already got working into your own desktop workspace and runs it there, instead of asking you to reproduce their setup first. The free app library is a quick way to see whether your process already has a published shape. Taku is in Beta, and the Mac app is available now.

FAQ

What is the automatisation process?

The sequence for turning manual work into a running system: select a suitable process, map what actually happens, build the smallest working version, instrument it for failure, and assign an owner. Selection and mapping decide most of the outcome.

How do I choose which process to automate first?

Score on frequency, variability, judgment required, and cost of error. High frequency, low variability, low judgment, and cheap visible errors make the best first candidate — even if it isn't the most irritating task.

What is a process automation system?

The full setup around an automated process: the workflow itself plus logging, alerting, retry rules, a manual fallback, and a named owner. A flow without those is a script, not a system.

Why do automation projects fail?

Usually three reasons: the exceptions were never mapped, the complete version was built before a simple one was proven, and nobody owned it when an upstream system changed.

How long does it take to automate a process?

The first working two-step version should take days, not weeks. If a proposal puts the first production deliverable more than a month out, that's a warning sign rather than thoroughness.

Key points

• Selection beats execution — pick on frequency and stability, not on irritation.
• Map the exceptions by watching a real run, not by reading documentation.
• Ship two steps to production before designing twelve.
• Silent failure is the dangerous one; instrument for it before you trust the flow.
• Automations decay from outside causes, so budget ongoing ownership time.