What to automate first, and how to choose without guessing

Three tests a first candidate has to pass

Every business has a long list of work it would happily hand to a machine. The list is not the problem. Choosing badly on the first attempt is, because the first build decides whether anybody in the company believes the second one is worth paying for.

Two out of three is not a pass. A frequent, well described task whose failures are invisible will erode trust quietly, and a task that fails safely but happens twice a month will never repay the build.

• Frequency. It happens many times a week, not many times a quarter. A build has a fixed cost in mapping, connecting and testing that does not shrink because the task is small, so volume is what pays it back.
• Describability. The person doing it today could write the rules on one page without writing it depends. If the honest answer to how do we do this is that it varies by who is on shift, you have found a documentation job wearing an automation costume.
• Cheap, visible failure. When it goes wrong somebody notices the same day, and undoing it is a small piece of work. Tasks that fail silently, or fail expensively, belong later, once the team trusts the system.

Why the first reply usually wins

Run those three tests across an ordinary business and the same candidate keeps surfacing: the first response to an incoming enquiry. It happens constantly, the rules are boring and writable, and a wrong answer is visible immediately and correctable by a human stepping in.

It also sits on top of the one loss that never appears in any report. A quote you sent and lost gets discussed at the next meeting. An enquiry that arrived at nine at night, got answered at eleven the following morning and had already gone elsewhere leaves no trace anywhere. Businesses in this market describe exactly that pattern with WhatsApp messages that sat unanswered while everyone was busy.

There is a second reason to start here. Time to first response is a number anyone can read, it moves within days, and nobody needs a dashboard to believe it. That matters more than it sounds, because your second build is funded by whether people believed the first one.

• Acknowledging an enquiry and capturing the details into one place, whatever channel it arrived on
• Answering the same handful of questions that turn up every week in slightly different words
• Chasing a quote that has gone quiet, on a schedule nobody has to remember
• Assembling the report somebody rebuilds by hand every Monday morning
• Moving a record from one system into another so two teams stop keeping separate versions of the truth

Build the shortlist in one ordinary week

You do not need a consultant to produce the list, and the list already in your head is usually wrong, because the loudest annoyance in a business is rarely the most expensive one.

For one week, ask everybody who touches the operation to keep a note. Every time they do something repetitive they write down what it was, roughly how long it took, and what set it off. Paper is fine. The point is the count, not the precision.

At the end of the week, group the notes into tasks and count them. Two things usually surprise people. Something nobody ever complains about turns out to happen more often than anything else, and something everybody complains about turns out to happen rarely and hurt each time, which makes it a process problem rather than an automation candidate.

Score the shortlist on paper

For each surviving candidate, write down five things in a row and compare the rows instead of arguing about the candidates.

The winning row is usually not the one with the biggest total. It is the one with a high count, a one page rule set and a cheap failure. A task with an enormous total and no describable rules is a trap: the build is long, the exceptions never stop arriving, and the result gets argued about for months.

Keep the losing rows. They become your second and third builds, and by then you will have a real number for what a build costs in your business rather than somebody's quote.

• Times per week, counted rather than estimated
• Minutes per instance, including the interruption around it rather than only the typing
• Whether the rules fit on one page, answered yes or no with no third option offered
• How many systems it touches, and whether any of them has no way for software to connect
• What happens when it goes wrong, in one sentence, and how long that would take anyone to notice

Signs you picked the wrong one, while it is still cheap

A bad first choice announces itself in the first fortnight if you are watching for it, and moving on from it quickly costs far less than finishing it out of pride.

None of those is a reason to abandon automation. They are reasons to move to the next row on your sheet and come back to this one when the process has an owner and a written description.

• The mapping conversation keeps producing new exceptions, and each one is described as rare by a different person
• Nobody can name who decides what a correct outcome looks like
• The rules change while the build is happening, for reasons that have nothing to do with the build
• Every test case has to be checked by the one person who understands the process, and they are never free
• The saving only exists if somebody stops doing something, and nobody has agreed what they will do instead

The candidate to skip even though it looks perfect

One candidate passes the first two tests easily, wins on volume, and should still not be first: anything that moves money without a person looking. Payment runs, refunds, payouts, invoice approvals. High frequency, clear rules, an obvious saving, and a failure that is expensive and slow to notice.

Build it later, once the team has watched a smaller system behave for a few months and there is a review step people actually use rather than click through. The technology is not the obstacle here. Trust is, and trust gets earned on work where a mistake costs an apology instead of a reconciliation.

Two more to leave for now. Anything where a bank, an auditor or a regulator requires a named person to sign, because the preparation can be automated but the signature cannot. And anything owned by one person who is never available to explain it, because what you will build is their guess rather than the process.

Who catches the exceptions the first build creates

A first reply automation creates a new job on day one, and it is worth staffing before it goes live rather than afterwards. Everything it cannot answer hands it to a person, and where nobody owns that queue the automation has moved the silence rather than removed it. Any price outside the published list, any complaint and any commitment wait for human approval. The candidate to skip, anything that moves money without a person looking, is the same rule written as a shortlist criterion.

Choose the first candidate on the three tests and then insist on one thing about the build whichever one won. The accounts, the workflow definition, the message templates and the record of what it did sit under your own logins, so you own the system and can read it on the day the mistake announces itself in the first fortnight. That is what makes moving on from a bad first choice cheap, which is this article's own advice.

The three tests are also the test for keeping it in-house. High frequency, rules that fit on one page, and a mistake that shows up within a day and costs little to undo, is exactly the shape a capable person inside the business can build. Where they exist and will still be there next year, the first one should be theirs. Haad owns growth and client solutions at Wobble and takes the conversation that ends in that answer often enough for it to be worth writing here. Wobble works from Karachi, bills month to month, across 25 engagements in six countries.

Common questions

What should I automate first in my business?

The task that happens most often, whose rules fit on one page, and whose failures are visible the same day and cheap to reverse. In most businesses that is the first reply to an incoming enquiry, because it repeats constantly, the rules are dull enough to write down, and a wrong answer can be corrected by a person before it does damage.

How do I know if a task is worth automating?

Count it for a week rather than estimating it. Multiply the count by an honest time per instance, including the interruption around it, and compare that against what a build and its maintenance would cost. If the task happens a handful of times a month, the arithmetic will usually say no, and a checklist will serve you better than a system.

Should I start with the task that annoys me most?

Only if it also passes the frequency test. The most irritating task in a business is often one that happens rarely and hurts a lot each time, which usually means the process itself needs fixing rather than encoding. Automating a painful monthly job feels satisfying and pays back slowly.

How many workflows should we automate at once?

One. Not because more is technically hard, but because the first build is how your team learns what these systems need from them, and how you learn what a build actually costs in your business. Finish it, watch it run for a few weeks, then start the second with real numbers instead of assumptions.

What if our process is not written down?

Then writing it down is the first piece of work, and it is worth doing whether or not anything gets automated afterwards. Undocumented processes get automated as one person's version of them, and every other version surfaces later as a change request. Sit with the person who does the work and write the page they would hand to a replacement.

How long should a first automation take to prove itself?

You should see the operational number move within the first few weeks, which is why a candidate with a readable measure is worth preferring. Time to first response, the count of enquiries that got no reply, the number of records rekeyed by hand. If nothing observable has changed after a month of real use, the problem is usually the choice of task rather than the build.