AI or automation? What to automate first

That covers most of what an owner needs to know about AI for small business. The rest of this piece shows how to apply it to your own list of jobs.

Does this task need AI, or just automation?

Ask whether you could write the task down as instructions that a new starter could follow without asking you anything. If you could, it is a rules task and plain automation will do it. If the instructions end with "use your judgement", AI might help.

Some rules tasks: send a reminder when an invoice is seven days overdue. Copy a new web enquiry into the CRM. Post an alert when stock of an item drops below a set level. Each one has a trigger, a condition and an action. A workflow tool such as Zapier or Make, or a short script, handles these for a monthly subscription. When one of them fails, it fails in ways you can predict.

Some judgement tasks: read a customer email and decide whether it is a complaint. Pull the total, the VAT and the supplier name from invoices that arrive in many different layouts. Summarise a long site survey into the points a director needs. No complete rulebook exists for these tasks. A language model is useful for this kind of work.

In practice, the difference that matters is reliability. Automation gives the same output for the same input. AI gives a likely output. That output is usually right, but it can be wrong and still sound completely confident. That is fine when someone checks it. It is not fine when nobody does.

Most real tasks are a judgement step wrapped in rules. Handling a supplier invoice means receive it, read it, match it, approve it and pay it. Only the "read" step needs AI. So split the task, automate the rules parts first, and use AI only on the step that needs it. When AI workflow automation works well, this is usually its shape: a mostly boring pipeline with one clever step in the middle.

I think many businesses reach for AI because everyone is talking about it, when half of what they need is a trigger and an action. Build the boring half first. You will find out quickly whether the clever half is worth paying for.

Which tasks should a small business automate first?

Start with the tasks that happen often, take real time and cost you when they go wrong. Score each task on those three things and begin with the highest-scoring rules task.

Here is the scoring I'd use. List every task your team repeats. Then score each one from 1 to 3 on each question:

• How often does it happen? 1 means monthly or less, 2 means weekly, 3 means daily or more.
• How long does it take each time? 1 means under 5 minutes, 2 means 5 to 30 minutes, 3 means over 30 minutes.
• What happens when it goes wrong? 1 means a minor annoyance, 2 means rework or an unhappy customer, 3 means lost money or a compliance problem.

Multiply the three scores together. The maximum is 27. Then mark each task R for rules or J for judgement, using the test above.

An illustrative list for a small firm might look like this. The scores show how to fill in the table. They are not measurements.

Task	How often	Time	Errors	Score	R or J
Re-keying web enquiries into the CRM	3	2	2	12	R
Chasing overdue invoices	2	2	3	12	R
Sorting the shared inbox	3	2	2	12	J
Year-end stock take	1	3	3	9	R
Monthly management report	1	3	2	6	R

Start with the top R. Rules tasks are cheaper to build and easier to check. Take on the top J after you have seen what the first project involved.

Two cautions. First, do not automate a process that is already broken. If nobody agrees how refunds get approved, software will only make the disagreement happen faster. Fix the process on paper first. Second, rare tasks with high stakes, such as the year-end stock take, score low for good reason. Leave them with people and a good checklist.

Why start with the data you already have?

The data you already hold shows what the task really involves, and it is the data any automation or AI will run on. Starting a new data project before you have proved anything is the slowest way to begin.

Most SMEs hold more data than they use. Your inbox, CRM, booking system, accounting software and a few spreadsheets together record who asked for what, when they asked, and what happened next. That record tells you how often a task really occurs. Your scores above may have been a guess.

Look for three things:

• Data that someone types twice. If an order goes into the booking system and then into a spreadsheet, removing that retyping is the easiest data automation you will ever build.
• Data locked in documents, such as PDFs, scanned forms and email attachments. Automated data extraction turns these into rows you can search and report on. This is one of the places where AI is clearly worth the cost.
• Data nobody looks at, such as enquiry timestamps, response times and lost quotes. This data often shows where you are losing time and money.

If your data is spread across systems that do not talk to each other, your first project may be joining them up. That is less exciting than AI, but it makes everything after it cheaper. We write about this kind of work on our operational efficiency page.

What does this look like in a real business?

Below are two projects from our own work and one hypothetical example. I have described the Naitiv projects only as far as their published case studies go.

Brooklyn Travel: leads that arrived after 5pm

At Brooklyn Travel, the job was capturing the leads that arrived after 5pm. Visitors who spoke to the sales team converted, but after 5pm nobody was there to answer their questions, and by morning they were gone. We helped deliver a prototype in one month. It answers visitors' questions, qualifies each enquiry and passes the full conversation to the sales team.

This is a good example of where to look first. Out-of-hours enquiries happen often, and missing one has a clear cost, because the customer books with whoever answered first. Logging and acknowledging an enquiry is a rules task. Working out what a customer wants from a loosely worded message needs judgement. In the Brooklyn Travel build, the AI assistant does the judgement part: it answers questions and gathers the requirements. Passing the lead and the conversation to the sales team is the rules part. Lead capture is growth work as much as efficiency work, so we also cover it on our page about growth.

The Wild Company: data extraction

For The Wild Company, the project was data extraction. The result on the case study is commercial land analysis in under half an hour. Before, each commercial review took days. It lived in messy spreadsheets and in the heads of experienced team members. The tool brings the site requirements, supply and demand data and valuation knowledge together, and every figure includes its workings.

This is the "data locked in documents" case from the section above. The information the analysis needed already existed. The work was getting it out and into a form someone could use quickly.

A hypothetical example: supplier invoices at a trades firm

This example is hypothetical. It describes how I would approach the problem, not a project we have delivered. It has no results because there are none.

Picture a 15-person plumbing and heating firm. The office manager spends part of every day on supplier invoices. They arrive by email as PDFs from a dozen merchants, and each merchant uses its own layout.

Split the task into steps. Routing the invoice emails into one folder is a rules step. Reading the supplier, date, total and VAT from each PDF needs judgement because the layouts vary, so an AI extraction step fits there. Matching each invoice to a purchase order is a rules step again. Any invoice that does not match, or where the extraction is unsure, goes to the office manager.

The office manager stops typing and starts checking. The only invoices left with her are the ones that need a decision.

Why keep a person on the exceptions?

AI will sometimes be wrong, and plain automation breaks when its input changes. Having a person handle the exceptions is what makes either one safe to run.

Design the exception route before you launch, rather than waiting for the first mistake. Decide what counts as an exception: a failed match, a missing field, or an AI output below a confidence level you set. Decide who receives each exception and how quickly they should deal with it.

Then count the exceptions every week. If the number falls, you can widen what the system handles. If the number jumps, something has changed upstream. Perhaps a supplier redesigned its invoice. Either way, you find out within days, not at year-end.

I would rather run a system that sends a fair share of cases to a person and gets the rest right than one that attempts everything and is quietly wrong on a few. The second system feels more efficient until someone finds the errors.

When should you get outside help?

If your top task is a rules task and an off-the-shelf tool already does it, set the tool up yourself. You do not need a studio to connect a web form to a CRM. Buy first.

Bring in help when the task depends on your own data or on a workflow no product is built for. The same applies when a judgement step needs testing on real cases. That is the work we do at Naitiv. We start with a business consultant and build a fast prototype on your real data. We also publish what our builds cost, so you can judge before you talk to us.

What should you do this week?

Spend an hour listing the ten tasks your team repeats most. Score each one and mark it R or J. Then look at the top rules task. If a standard tool already does that job, set the tool up. If it doesn't, or if the top of your list is a judgement task, a first conversation with us works through three things: your scored list, the data behind the top task, and whether to buy or build.