AI automation for small business: what works, and what doesn't

Which tasks are actually worth automating?

The tasks worth automating share three properties: they are repetitive, they happen often, and they follow rules a person in the business could write down if asked. All three matter, and the third is the one most often missing.

In practice that usually means drafting quotes and proposals from a price book and past jobs; reading inbound documents like invoices, purchase orders and forms and filing them into a finance system; sorting and answering routine customer enquiries from your own documentation; and assembling one set of numbers from several systems on a schedule.

The common thread is that a competent new employee could be taught to do them from a written procedure. If you could not write that procedure, automation will not rescue you — it will encode the confusion faster.

What does not work?

Anything requiring judgement that the business has not made explicit. If two experienced people in your company would handle the same case differently and both be right, that is judgement, and automating it produces confident nonsense.

Low-volume work is the other category. An automation has a build cost and a maintenance cost. A task that happens twice a month rarely repays either, however irritating it is.

Then there is the genuinely common failure: automating a process that should have been deleted. Plenty of recurring work exists because a system could not do something in 2015. Automating it preserves a workaround permanently. The first question is always whether the task should exist at all.

How do you know if it is actually paying?

Measure the time before you start, and measure it again afterwards. This sounds obvious and is skipped almost every time.

The honest calculation includes the maintenance. Automations break when the things they connect change, and something always changes. An automation saving two hours a week but costing three hours a month to keep running is a worse deal than it looks and needs to be counted that way.

It is worth agreeing in advance what result would cause you to switch it off. Projects without a stopping condition tend not to stop.

What about accuracy? Won't it make things up?

It will, if you let it operate unsupervised on work that needs judgement. The design answer is to be deliberate about which mode each task runs in.

For rule-following work with a checkable output — extracting figures from an invoice, matching a line item to a price book — the output can be verified automatically and the automation can run on its own.

For anything customer-facing or consequential, the automation drafts and a person approves. That is slower than full automation and considerably better than being wrong at scale. Treating the approval step as a failure of ambition is how businesses end up apologising to customers.

Testing against your real data before anything goes live is not optional. A demonstration on sample data tells you almost nothing about how it behaves on the messy reality of your own records.

Do you have to replace your systems first?

Usually not, and being told you do is worth questioning. Modern automation works against the accounts and data you already have.

Sometimes a system genuinely cannot support it — no API, no export, no way in. Then the honest answer is either that this task is not the one to automate, or that the system belongs on a replacement list for its own reasons. Building a fragile workaround around software that cannot support it usually costs more than the manual work it replaced.

Replacing working systems in order to enable automation is a large project wearing a small project's clothes.

Where should a business start?

With the four or five tasks that eat the most predictable amount of someone's week, listed honestly, then narrowed to the one that is most repetitive and least dependent on judgement.

Start narrow enough that failure is cheap. A first automation should be a piece of work with a fixed scope and a fixed date, not a programme. Either it pays for itself quickly, or it tells you something useful about your data and your processes at low cost.

The second automation is much easier than the first, because by then the arguments about who owns which data have already been had.