AI or plain automation? When to use which.
The question I get most this year isn't "can this be automated?" but "shouldn't we use AI for this?". Most of the time, the answer is no. Here's how I decide.
Last month I sat down with someone who sells car parts online. His process was as clear as it gets: orders from the shop have to land in the invoicing software, the invoice has to go to the customer, stock has to go down. His question was whether we'd do this "with AI". I said no, and I think he was a bit disappointed.
Not because AI isn't good. Because there was nothing for it to do there. The order arrives with every field filled in, the prices sit in a table, the rule is the same every time. Plain automation has done this for ten years, costs next to nothing per run, and never fails in any way other than the one you programmed.
What "plain automation" means
A rule. If X happens, do Y. New order → invoice. 07:00 → report. New row in the sheet → email. The tools differ (n8n, Make, a script, an API), but the idea is the same: the program does exactly what you told it, in the same order, every time.
Its strength is also its limit: it needs tidy data. If the invoice arrives as a crooked scanned PDF, the rule doesn't know where the total is. If the customer's email says "the one from last week, with the wheels", the rule doesn't know which order that is.
What AI adds
Exactly that: it reads messy things. A language model can pull the supplier, number and total out of a PDF it has never seen before. It can work out that "the one with the wheels" is order #1042. It can write a reply in Hungarian if the customer wrote in Hungarian. And it can make a rough judgement: is this a complaint or a question?
The price: it isn't one hundred percent predictable. The same email, sent twice, can get two slightly different replies. Sometimes it's wrong with confidence. And it costs something per call. Little, but not zero.
| Plain automation | AI | |
|---|---|---|
| Input | Tables, forms, APIs | PDFs, emails, photos, free text, voice |
| Output | Identical every time | Almost identical, sometimes surprising |
| When it fails | Stops or raises an error | Answers confidently, possibly wrong |
| Cost per run | Practically zero | Small, but not zero |
| Building it | Rules written once | Instructions, tests on real data, safety nets |
| Good for | Processes with tidy data | Reading, sorting, summarising, proposing |
My rule
I've settled on a simple rule that I apply at every audit:
- Is the data tidy and the rule clear? Plain automation. No debate.
- Is the input messy (PDFs, emails, photos, free text, voice)? AI for the reading part, rules for the rest.
- Does a person need help, not replacing (replies, summaries, sorting, proposals)? AI prepares, the person approves.
- Does the decision have consequences (money, tax, an upset customer)? AI can propose, but it doesn't sign. Rule-based validation, then a human.
What it looks like in practice
Most of my projects are a mix, and in all of them AI sits at the edges, not in the middle.
Supplier invoices. They arrive by email, as PDFs, in ten different layouts. AI reads: supplier, number, date, total. Then plain automation takes over: checks the tax ID against the supplier list, checks the total against the order, renames the file, drops it in the month's folder, writes the row in the register. If the AI isn't sure (and it says when it isn't), the invoice goes to a "to check" folder, not into the books.
Supplier feeds. CSV, XML, the same columns every night. Zero AI. It would be more expensive and less reliable.
Customer emails. This is where AI genuinely shines: it sorts, finds the order, writes the reply. But the reply only leaves once someone in the company presses "send". Complaints never get an automatic reply. An upset customer wants a human.
What I don't do with AI
I don't let a model decide on its own about amounts that end up in the books or at the tax office. I don't send customer data to tools I haven't checked. I don't put AI into a process just so I can say it has AI. And I don't promise that a model "understands" your business; it understands the text you give it, that's all.
The right question
Not "should we use AI?" but "where is the data messy, and where does a person lose time reading?". That's where it's worth it. Everywhere else, a good rule, written once, beats any model.
Not sure which case your business is? That's exactly what we find out in a free 30-minute audit. I'll tell you honestly, even if the answer is "you don't need AI".
Read next
Where AI goes wrong, and how to build around it.
A language model fails differently from a program. It doesn't stall, it doesn't throw an error: it answers nicely, confidently, and sometimes wrongly. The four safety nets I put in every time.
ReadWhat AI actually costs inside an automation.
The good news: the AI part is almost free. The less good news: the AI part isn't what's expensive. Where the money goes, and how I work it out for a client.
ReadAI and your company's data: what leaves the building and what doesn't.
"If I add AI, do my data end up in America?" Good question. The short answer: it depends how you build it, and you get to choose. Three options and five questions for anyone selling you AI.
ReadTen tasks: five without AI, five with.
A short list from real projects, so you can see the difference at a glance. And the pattern that repeats across all ten.
Read