Why your first automation should be boring

Ask a team which process they would most like to automate and they will usually name the most painful one: the quarterly forecast that takes three people a week, the contract review nobody enjoys, the customer escalation that always needs a senior person. These are real problems. They are also, almost always, the wrong place to start.

Your first automation should be boring. Not because ambition is bad, but because the first project has a different job from every project after it. It has to work, it has to be seen to work, and it has to teach your organisation how to run automated work in production. A dull task is the best teacher.

01#What "boring" actually means

A boring task has four properties.

• →It happens often. Dozens or hundreds of times a week, not twelve times a year. Frequency is what turns small savings into large ones, and it is what gives you enough runs to find problems quickly.
• →The rules already exist. Someone can explain how it is done in a page or two: if the invoice matches the order and the amounts agree within a tolerance, approve it; otherwise send it to accounts. If the explanation keeps turning into "it depends", it isn't boring yet.
• →The inputs are predictable. The same form, the same export, the same handful of email templates. Messy inputs are not a deal-breaker, but they belong in the second project.
• →A mistake is cheap and visible. If the automation gets one wrong, a person notices within a day and fixes it in minutes. Nobody is harmed, no money leaves the building, no customer receives something strange.

Typical examples: copying data from one system into another, matching payments to invoices, routing inbound requests to the right queue, producing a weekly report that someone currently assembles by hand, chasing missing documents with a polite reminder.

None of these will impress anyone at a conference. All of them will give people back hours every week.

02#Why the dull task wins

It pays back quickly, and you can prove it

A task that runs two hundred times a week at four minutes a time is more than thirteen hours of work. You can measure it before you start, by asking people to log it for a fortnight, and you can measure it again a month after go-live. That before-and-after number is the most valuable thing your first project produces. It is the evidence that gets the second project approved without a long argument.

The painful quarterly process, by contrast, runs four times a year. Even if the automation works perfectly, you will wait months to know, and the saving will be argued about.

It teaches you how to operate automation

The first project is where you learn the unglamorous parts: where the credentials live, who gets the alert when a run fails, how exceptions reach a person, how you change a rule without breaking last week's records, what the audit trail looks like. These questions are the same whether the automation is simple or clever. Learning them on a simple task means you learn them cheaply.

Teams that start with the hard problem often discover all of these questions at once, in front of senior stakeholders, while the core logic is also still uncertain. That is how promising projects get cancelled.

It builds trust with the people who do the work

The people who currently do the task know its quirks better than anyone. On a boring task they can check the automation's output in seconds and see that it is right. Within a few weeks they stop checking every item and start checking samples. That shift, from suspicion to confidence, is earned one correct run at a time, and it transfers to the next project.

When the first automation is a black box doing something hard, the same people can't easily tell whether it is right. They keep doing the work by hand "just in case", and the saving never appears.

03#How to pick yours

Make a list of candidate tasks with the people who do them. For each, write down three numbers and one sentence:

• →how many times it happens a week,
• →roughly how long it takes each time,
• →how many systems it touches,
• →and one sentence describing what a mistake would cost.

Multiply the first two to get weekly hours. Prefer tasks that touch one or two systems, because every extra system is another login, another format and another thing that changes without warning. Strike out anything where the mistake sentence makes you wince.

Then pick the top candidate and write its rules on a single page. If you can't fit them, or if two experienced people write different pages, the task needs tidying before it needs automating. That is useful to know too: sometimes the cheapest improvement is agreeing how the work should be done.

04#What to build first

Resist the urge to automate the whole task end to end on day one. A good first version usually does the predictable eighty or ninety per cent and hands everything else to a person with a clear note explaining why. That hand-off is not a failure. It is a design decision, and it is what lets you go live in weeks rather than months.

Alongside the automation itself, build three small things:

• →A log of every item it processed and what it decided, in a form someone in operations can read.
• →An exception path with a named owner, so the items it can't handle don't pile up unseen.
• →A simple weekly summary: items handled, items handed off, failures, time saved. This is your evidence.

These cost very little on a simple task, and every later project will reuse them.

05#When to get interesting

Once the boring automation has run cleanly for a month or two, you will know things you didn't before. You will know how your systems behave under automation, how fast your team responds to exceptions, and what your people will trust. You will have a number that shows the work paid back.

That is the moment to take on the forecast, the contract review or the escalation, with monitoring already in place, an exception process that works, and a team that has seen automation help rather than hinder.

The interesting projects are still there. They will be far more likely to succeed once the dull one has paved the road.