Most business automation does not need AI at all, and the part that genuinely does is much narrower than the sales pitch suggests. Plain rules handle the bulk of it. They cost almost nothing to run, they finish in milliseconds, and they do exactly the same thing every single time. AI earns its place in one specific band of work, and knowing where that band sits is the difference between an automation that pays for itself and one you quietly switch off in March.
We build both kinds, so this is not a purist argument against putting AI in your business. It is an argument for putting it where it actually helps, because the alternative is paying per API call for something an if statement was already doing properly.
What plain rules already handle
A rule is a set of instructions that runs the same way every time. When an invoice lands in the inbox, save the attachment, rename it, drop it in the right folder, notify the bookkeeper. When a form is submitted, create the record, send the confirmation, add the task. When a job is marked complete, generate the invoice and schedule the follow up for fourteen days later.
None of that needs a language model. Tools like Power Automate, n8n, Make and Zapier were built for it, and they are very good at it. If you want the detail on which of those to pick, we have compared Power Automate, n8n and Zapier and separately n8n, Make and Zapier for Australian businesses.
The reason this matters is reliability. A rule that moves a file will move that file correctly on the ten thousandth run. It does not have an opinion, it cannot be talked into something by the contents of an email, and when it breaks it breaks loudly and in an obvious place. For anything that touches money or compliance, that predictability is the feature you are actually buying.
So the honest starting position is that most workflows people describe to us as AI projects are ordinary automation with one awkward step in the middle.
Where AI earns its place
That awkward step is the point. AI is worth paying for when the work involves something you cannot write down as an instruction.
Reading things that have no fixed shape. Every supplier sends a different invoice layout. Customers describe faults in their own words. A field technician uploads a photo of a damaged part. There is no rule that reliably pulls a total off four hundred different invoice templates, but a model reads all of them without being told about each one in advance.
Making a judgement you cannot express as logic. Deciding whether an incoming email is a complaint, a sales enquiry or an invoice query is trivial for a person and nearly impossible to write as a set of keyword rules. You can try, and the result is a brittle list that misses anything phrased unusually.
Producing language. Drafting a reply, summarising a long thread for someone who was not on it, turning six lines of site notes into a paragraph a client can read. The output still wants checking, but the blank page problem is solved.
Matching things that are nearly the same. "ACME Pty Ltd", "Acme Proprietary Limited" and "acme p/l" are one supplier to a human and three to a database. Fuzzy matching in a rules engine is a long afternoon of edge cases and it still misses some.
Outside those four situations, reach for a rule. If you can describe the logic precisely enough to explain it to a new starter in a sentence, you do not need a model to do it.
One workflow, split down the middle
Invoice processing is the example we get asked about most, so here is what the split actually looks like in something we would build.
An invoice arrives by email, and a rule notices it and pulls the attachment. AI reads the PDF and extracts the supplier, the ABN, the invoice number, the date, the total and the line items, because that document looks different for every supplier on your list. Then rules take over again. They check the ABN is valid, match the total against the purchase order, confirm the supplier is one you have dealt with before, and post the result into Xero. Anything that fails a check, or any invoice over an amount you have set, gets flagged to a person instead of posted.
Count the steps and AI is doing roughly one job out of seven. It is the job that made the whole thing impossible to automate before, which is exactly why it is worth paying for, but it is still one step. The value came from automating the other six, and the model just unblocked the part that used to force a human to retype numbers off a screen.
That shape holds almost everywhere. AI handles the judgement, code handles everything around it, and a person stays on the exceptions.
What the pitch leaves out
Three things get skipped in most sales conversations, and all three change how you should design the workflow.
The first is that AI is not deterministic. Give a model the same invoice twice and you can get two slightly different answers. That is fine when it is drafting an email and genuinely dangerous when it is deciding what to pay. Anything financial or regulated needs a validation rule behind the model and a threshold above which a human signs off, which is why the invoice example above checks the extraction rather than trusting it.
The second is that it costs money every time it runs. A rule is effectively free. Every AI step is a call you pay for, and a workflow that fires a few hundred times a day adds up in a way a Zapier task never did. Sometimes the sums still work comfortably. Sometimes you discover the elegant version costs more per month than the person it was meant to free up, while the boring version does most of the same job for nothing.
The third is that if the automation makes decisions about people, you have obligations coming. The Privacy Act reforms bring automated decision making disclosure in on 10 December 2026, and that covers things businesses do not always think of as decisions, like ranking applicants or flagging accounts. Worth knowing before you build it into a process rather than after.
The test we actually use
When someone asks us whether a workflow needs AI, we work through it in the same order every time.
Write down the steps in plain language. For each one, ask whether you could hand it to a new employee as a written instruction with no judgement required. Every step where the answer is yes is a rule, and it should stay a rule. The steps where the answer is no are where a model belongs, and there are usually fewer of them than people expect.
Then ask what it costs when that step gets it wrong. If the answer is that someone re reads an email, run it and move on. If the answer is that you pay the wrong supplier, put a check behind it.
That is the whole method. It is not sophisticated, but it stops you buying a language model to do arithmetic, and it stops you spending three weeks writing rules for something a model handles in an afternoon.
Start with the job, not the tool
The reason so much automation disappoints is that it starts from the technology instead of the work. Someone sees a demo, buys a platform, then goes looking for a process to point it at. The projects that pay off run the other way around. You find the task that eats a day a week, work out which parts of it are rules and which part is the judgement in the middle, and automate accordingly.
Most of the time you will find the answer is mostly rules with a bit of AI in the middle. That is not a disappointing result. That is what a workflow looks like when someone has been honest with you about it.
If you want a hand working out which of your processes are worth automating and what the split looks like, that is what our business automation work is. And if the judgement step turns out to be the bulk of it, custom AI agents are the other half of the same conversation.