How to decide what to automate first in a small team

Rank candidates for automation by frequency, stability and the cost of an error so your first build saves real hours instead of the ones you notice most.

Everything looks automatable and the list keeps growing

Somebody copies order details into a sheet every morning. Somebody else sends the same three follow-up emails by hand. Invoices are raised one at a time from a template. Every one of these is obviously automatable and the team has opinions about which to do first that correlate strongly with who finds their own task most irritating.

Irritation is a poor ranking signal. The tasks people complain about are usually short and frequent and visible. The ones that cost you money are often long and occasional and invisible because the person doing them absorbed them years ago and stopped mentioning it.

What automation costs and what it never removes

Automation does not remove exceptions. It handles the normal case and leaves you every edge case plus a new category of problem which is work that failed silently. The build cost is visible and the monitoring cost is permanent. Somebody has to notice when the automation stops and that somebody must be named before you start.

Three costs apply. The build which is configuration or scripting. The subscriptions for whatever connects your systems which are usually priced per task or per run and therefore scale with volume. And the rework when an automation does the wrong thing confidently across two hundred records before anybody checks. GST at 18% applies on the build fee and the subscriptions as services.

There is also a documentation cost that gets skipped. An undocumented automation is a mystery to the next person and the first thing they will do is rebuild it.

What you should not automate

Do not automate a process that changed in the last three months. You will encode a version that is already obsolete and the rework will exceed the build. Let the process hold still for a quarter first. Small teams routinely automate the newest process because it is the one on their mind and that is the worst candidate on the list.

Do not automate anything that runs a few times a month and takes ten minutes. Even a perfect build will not repay the construction and the monitoring attention it permanently claims. The arithmetic only works on frequency.

And do not automate a task that should be deleted. Reports nobody reads and approvals that never get refused and data entry into a system you are leaving are all candidates for removal rather than acceleration. Automating useless work makes it permanent and harder to question because somebody built it.

How to rank the candidates

List every repeating manual task with four figures beside it. Times performed per month. Minutes each time. How stable the steps have been over six months. And what a mistake costs when one happens. Multiply frequency by minutes for the hours at stake and then discount heavily anything that scored poorly on stability.

Treat error cost as a separate column rather than folding it into time saved. A task performed twice a month that produces a wrong customer invoice when it goes wrong may deserve attention ahead of a daily task that wastes twenty minutes harmlessly. Accuracy is often the stronger return and it is the one that nobody puts in the business case.

Then apply three steps in order before building anything. Eliminate what is unnecessary. Simplify what remains including cutting fields and approvals. Only then automate what survives. Most teams skip the first two and automate a process that had four redundant steps in it.

How to judge whether it worked

Number of automations running is the flattering metric and it is a liability count rather than an achievement. So is time saved calculated from the original estimate because nobody revisits that figure after the first month.

Measure the hours the team actually spends on the process now including exception handling and monitoring. Then measure the error rate before and after. If total hours fell and error rate held then the build earned its place. If hours fell and errors rose you have moved cost from the visible column to the invisible one and that trade usually loses.

The common mistake

The expensive error is building an automation with no failure alert. It runs perfectly for five weeks and then an upstream system changes a field name and it stops. Nothing breaks loudly. Orders simply stop appearing in the sheet and nobody notices for eleven days because the whole point of the automation was that nobody had to look. The recovery is manual reconstruction of everything missed and that routinely costs more than the automation saved all year.

The second error is automating paperwork that carries a compliance obligation without a review step. Automatically generated invoices and tax documents are only as correct as the rules somebody configured and the consequences of a systematic error sit with your business rather than with the tool. How the relevant rules apply to your transactions is a question for a qualified professional and it should be settled before the automation runs at volume rather than after a year of filings.

This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.