The work is not the building

People expect the difficulty to be in the software. It is not.

The difficulty is describing the process precisely enough that a robot can follow it — including every exception nobody wrote down.

A person doing a task handles odd cases automatically. The file that arrives late. The record with a blank field. The month the archive contained two files instead of one.

None of that is in the written procedure, because the person absorbed it and stopped noticing.

Most of the project is discovering those cases.

Step 1 — Watch it being done

Sit with the person who does it. Watch several times.

Write down:

• Every step, in order
• Every decision, and what determines it
• Every exception, and what they do about it
• What “done” looks like
• What they do when something goes wrong

The exceptions are the valuable part. Ask directly: “when does this not go smoothly?” and “what was the last thing that surprised you?”

Watch more than one person if several do it. They will be doing it differently, and you need to decide which way is correct before automating either.

Step 2 — Decide what to automate

Not the whole process, usually.

A process might be twelve steps, of which nine are mechanical and three need judgement.

Automate the nine. Leave the three. The robot prepares; a person decides.

That is often a better outcome than full automation — faster to build, more reliable, and judgement stays where it belongs.

And check each step for a better method. Does this step need a browser, or is there a direct URL? Does this need screen automation, or is there an API? Every step you can do without a screen is a step that will not break when a layout changes.

Step 3 — Build it

Activities on a canvas, in sequence.

Two practices that matter more than any technique:

Name things clearly. Not “Click1” or “HTTP Request3”. “Download the daily archive”. “Find the newest CSV”. Somebody else has to read this.

Log at each meaningful step. When it fails at three in the morning, the log is what tells you where.

And structure it in stages — download, extract, validate, send — rather than one long sequence. Each stage can then have its own error handling, and a failure tells you which stage rather than just that something went wrong.

Step 4 — Selectors, if you need them

Only relevant where screen automation is genuinely required.

A selector is how the automation finds an element on screen. It is where RPA breaks.

Fragile: relies on position, or on a value that changes each session — “the third button”, or a generated ID.

Stable: uses something meaningful and unchanging — a name, an automation ID, a label.

Spend time on selectors. It is the difference between surviving an application update and breaking the following week.

And accept that some will break anyway. A vendor redesign can change everything. That is the nature of the technique, which is the argument for using as little of it as possible.

Step 5 — Error handling

The part that separates a working automation from a liability.

Wrap each stage in try-catch, so you know which one failed.

Log the error message and the stack trace. For an unattended job, that is all anyone will have.

Re-throw the error so the job is marked failed. This is the one people get wrong. An automation that catches an error and exits successfully records a false success — nobody is alerted, and the work silently did not happen.

Decide what happens next. Skip this item and continue? Stop the whole run? It depends on the process, so decide deliberately rather than accepting a default.

Notify a person. Not a log file nobody opens.

Step 6 — Test properly

Not with clean data. With real data, including the awkward cases.

Test these specifically:

• The source is unavailable
• The download returns an error page instead of a file
• The archive is empty
• The archive contains two files instead of one
• A required field is missing
• The target system is unavailable
• It runs while a previous run is still going

Then run it alongside the manual process for a couple of weeks and compare.

This is the step shortened when a project runs late, and it is the one that should not be.

Step 7 — Deploy and hand over

Attended first, if possible. A person triggers it and sees the result.

Move to unattended once it has proven stable, and only with monitoring in place.

Hand over properly:

• What it does and why
• Who owns it
• What to do when it fails
• Which system changes might break it

Without that handover you have built a black box that works until it does not, and then nobody can fix it.

What makes projects fail

Automating an undocumented process. Halfway through, you discover it is not what anyone described.

Automating a bad process. It runs faster in the same wrong direction. Fix the process first.

Swallowing errors. Silent failure for weeks.

No owner. Something changes, it breaks, nobody fixes it.

No baseline. Nobody measured the manual version, so nobody can say whether it helped.

Measuring it

Before you start, record:

Time per run. How long the manual version takes.

Frequency. How many times a month.

Error rate. How often the manual process goes wrong.

Afterwards, compare — including the time spent maintaining the automation. That last part is what people leave out, and it is the difference between a real saving and an apparent one.

The short version

Building is the easy part. Documenting the process, including the exceptions, is where the work is.

Automate the mechanical steps and leave the judgement. Use the least fragile method available for each step.

Structure it in stages with error handling per stage, and re-throw so failures are visible.

And give it an owner before it goes live. An automation nobody maintains breaks quietly.