May AI SOLUTIONS

Common questions · Tools

How do I know whether a task in my business is worth automating?

A short test you can run yourself before spending anything: how to time the task honestly, and how to spot the ones nobody ever mentions.

Three ring binders stacked on a desk, each crammed past its capacity with loose paper so the covers no longer close.

Everybody has a candidate. The thing somebody grumbles about every week. The spreadsheet with a name like FINAL_v4_USE_THIS. The Monday morning that disappears into the same job it disappeared into last Monday.

Whether it is worth doing anything about is a question you can answer yourself, before you talk to anybody, in about a week of paying attention. Here is the test I use.

Step one: time it honestly

Not from memory. Memory is unreliable in both directions, and predictably so.

Tasks that feel worse than they are: anything annoying, anything interrupting, anything that requires a person to switch off what they were doing. Being interrupted eleven times feels like a lost afternoon and is often forty minutes. It is a real cost — but it is a cost of interruption, not of duration, and the fix might be batching rather than software.

Tasks that are worse than they feel: anything routine enough to have stopped being noticed. Nobody mentions it because it is simply Tuesday. These are the expensive ones, and they are almost never the ones the owner nominates.

So: for one normal week, write down the start and stop time every time somebody does the thing. Not an estimate at the end of the week — the actual times, as they happen. Take the total and multiply by fifty.

That number is what you are deciding about. It is frequently double or half what anyone guessed.

Step two: check it is actually repeated

Automating something that happens once a quarter is nearly always a mistake, however irritating it is. The work to remove it costs more than living with it, and worse, nobody remembers how the tool works by the time it runs again.

The sweet spot is weekly or more often. Daily is better. Something that happens several times a day, even briefly, adds up faster than almost anything else on the list.

Step three: write the rules on one page

Sit down and describe the task as instructions for somebody who has never done it. What comes in. What you do to it. What comes out. What you do when it is not the normal case.

This step does more work than any other, for two reasons.

If you can write it down, it can be built, and the page you have just written is most of the specification.

If you cannot — if every rule sprouts three exceptions, if the honest answer to “how do you decide?” is “you get a feel for it” — then it is not ready. That is not a failure. It is you finding out, for free, something a supplier would otherwise have charged you to discover halfway through.

Sometimes the exceptions are the whole job, and the right move is to fix the process rather than encode the mess.

Step four: ask what it costs when it goes wrong

Time is only half of it. The other half is error.

A task that takes twenty minutes a week but catches billing mistakes, missed appointments or stock discrepancies is worth more than its twenty minutes, because when it is skipped — and under pressure it is always the checking that gets skipped — the mistakes go through.

Ask: what has this task caught in the last year, and what would it have cost if nobody had been doing it? For checking work, that number is often larger than the labour.

Step five: the four questions that settle it

If it has got this far, four things decide whether it is worth building:

Is the input consistent? A spreadsheet with the same columns every week, an email in the same format, a report from a system that always looks the same. Consistent input is easy. Input that arrives as a photograph of a piece of paper, differently each time, is a much larger job.

Does it need judgement, or just rules? “Flag anything more than five per cent over the agreed price” is a rule. “Decide whether this customer is worth keeping” is judgement.

Will the person doing it now actually use the replacement? This is the one that quietly kills more tools than anything technical. If it takes six clicks, or lives somewhere they do not already go, or requires a login they will forget, they will go back to the spreadsheet. Any tool has to be less work than the thing it replaces on the very first day, not once everyone gets used to it.

Would you still want it in two years? If the process is about to change, or the software underneath it is being replaced, wait.

The ones that are almost always worth it

Patterns I would say yes to nearly every time:

  • Somebody retyping data from one system into another
  • A report assembled by hand to the same layout every week
  • Checking one document against another — invoices against a price list, deliveries against orders
  • Anything currently guarded by one person’s memory, where the risk is that they leave

The ones that are almost never worth it

  • Anything that happens less than monthly
  • Anything where the rules genuinely change every time
  • Anything that duplicates mature software you already pay for
  • Anything a formula in a spreadsheet already fixes
  • Anything nobody has actually asked for

That last one matters more than it sounds. A tool built because it was possible, rather than because someone was suffering, does not get used.

Doing the test properly is most of the value

Here is the part I would emphasise: run steps one to three and you will know the answer yourself. You will have a real number for the cost, a real answer on frequency, and a page describing the work. At that point you can decide, and you can also tell whether anyone quoting you has understood the job.

Plenty of the time the conclusion is no, or not yet, or fix the process first. Reaching that conclusion in a week for free is a good outcome.

When I am asked to look at one of these, the first thing I do is sit with whoever does it now and watch them do it — the real thing, at their desk, at their speed. What people do and what they describe themselves doing are reliably different, and the gap is usually where the tool actually belongs.

The short version

Time it for a real week. Check it repeats at least weekly. Write the rules on one page. Ask what it costs when it goes wrong. Then check the input is consistent, the rules are rules rather than judgement, and the person doing it will actually use the replacement.

If you have run that and want a second opinion on what you found, tell me what the task is — including your page of rules if you wrote one. I will tell you honestly whether it is worth building, and I will say so when it is not.

If this is the question you came with and you would rather just ask a person, that is what the form is for. I read them myself.

Tell me what you need