Guide

AI automation in a small business: where it pays and where it does not

Not every task should be automated, and the most expensive projects are the ones where nobody did the sums first. A sober look at what actually works.

Published on 2 min read

Most conversations about AI in a small business start with the technology and end without a result. The more useful ones start with a list of activities somebody does every week that nobody in the business would describe as core work.

That list is the actual starting point. Everything else follows from it, including the answer to whether this is worth doing at all.

What automates well

Three properties make a task a good candidate.

It repeats. Not occasionally, but measurably often: daily, or several times a week. A task that comes up four times a year almost never pays back, however tedious it is.

It follows a rule, even if the rule is written down nowhere. If you can explain it to a new colleague in ten minutes, it can be described. If you have to say “you get a feel for it after two years”, it cannot.

A mistake is visible and cheap. A misfiled email gets noticed and corrected. A wrongly triggered payment does not. The first suits automation; the second needs a checking step or stays manual.

What automates badly

Anything where the judgement is the work. A client conversation that decides whether a job is a fit. A complaint that turns on whether somebody is right. A quote that needs experience.

Then anything rare that fails expensively. And anything where describing the task costs more effort than doing it. Almost everyone underestimates that last one: writing a process down precisely enough for a machine to follow is work, and it all lands at the front.

The sums that come before the project

You do not need a study, you need four numbers.

  1. How often does the task come up, per week?
  2. How long does it take, honestly measured rather than estimated?
  3. What does the time of the person doing it cost?
  4. What does setting it up cost, and what does it cost to run?

Number 2 is where nearly everybody is wrong. Measure it for a week before doing the arithmetic. If the numbers still work afterwards, you have a project. If they do not, you have spent an hour and avoided a bad decision.

Where small businesses actually start

In practice it is almost always the same three places. Enquiries that have to be sorted and answered. Data that moves from one system to another because the two do not talk. And documents somebody retypes the same details out of, over and over.

What is striking is that two of those three are not AI problems at all, they are integration problems. That is no accident. Before automation pays off, the systems you are automating between have to be connected in the first place.

So our first question in these projects is never which model to use. It is which systems you run today, and what happens between them by hand.

Common questions

Do we need a large volume of data for this?
For most sensible small-business applications, no. It is rarely about training a model and usually about connecting an existing one to your workflow. What you need is a clearly described process, not a dataset.
How quickly do you see an effect?
That depends on the task, on how clearly the process is already described and on how many systems have to be connected first, so we do not put a figure on it before we have looked. What we can say is the shape to aim for: with a single well-chosen task the saved time appears as soon as it runs and can be counted, and a project that only adds up over a much longer stretch is usually scoped too large.
Does this replace staff?
Not in the kind of work this suits. What gets automated is the work nobody enjoys and nobody misses: entering the same thing twice, retyping data from one system into another, writing standard replies. That frees time for the work you hired the person to do.
Why do these projects fail?
Almost always because the process was not clean beforehand. Automation does not make an unclear process clearer, it makes it unclear faster. That is why the first step is always writing it down, not building.