The question owners usually ask about AI in a business process is how accurate it is. It is an understandable question and not a very useful one, because the answer is never completely accurate, and designing around a number that moves with every model release is not a plan.
The useful question is what happens when it is wrong. That is a design question about the workflow around the model, not a question about the model itself, and it is answerable in advance.
What AI is actually good at in a small business workflow
Three jobs, broadly, and they have something in common.
Drafting. Producing a first version of something a person will edit — a reply, a summary, a description. The person remains the author.
Extracting. Pulling structured information out of unstructured input: dates and amounts from an email, line items from a supplier document, an address from a message.
Classifying and routing. Deciding which category something belongs to, so it reaches the right person or queue faster.
What these share is that each produces something reversible and reviewable. A draft can be rewritten. An extracted figure can be checked against the document beside it. A misrouted enquiry can be moved. None of them is a decision the business has to live with.
The trouble starts when the same technology is pointed at work that is none of those things.
Approval gates, and the way they usually fail
An approval gate is a point where the workflow stops and waits for a person. The design questions are where to put them and how few you can get away with.
Put them where reversing the outcome becomes expensive. Before something reaches a customer. Before a figure enters a system others will rely on. Before anything that is awkward to undo.
The common failure is putting one on every step. It feels prudent and it produces the opposite of oversight: people who approve without reading, because ten approvals a day is a queue rather than a decision. Now the rubber stamp is on the record, and the business is worse off than with no gate at all, because it has documented supervision that did not happen.
A gate that works has three properties. The reviewer can see what is being proposed and what it was based on, in one place, without opening something else. Rejecting is as easy as accepting — if approval is one click and rejection means writing an email, the gate is decorative. And the volume is low enough that reading is realistic.
This is the same bottleneck problem we described in three places a quotation gets stuck, and it behaves the same way here: a queue in front of one person is not oversight, it is a delay with a governance label on it.
Fallbacks: what happens when it cannot answer
Every AI step needs a defined answer to two situations: the service is unavailable, and the model is not confident enough.
For most small business workflows the right fallback is the same in both cases — hand it to a person, with a note saying why it was handed over. That is unglamorous and it is almost always correct. The work continues, nothing is silently guessed, and the exception is visible.
What matters is that the fallback is decided during design rather than discovered during an outage. A workflow that stops dead when a model is unavailable was not designed; it was assembled. And a workflow that carries on regardless, using whatever the model produced under uncertainty, is worse — it has chosen to be wrong quietly.
It is also worth knowing what "not confident" means in your specific setup, because it is a threshold somebody chooses. Ask whoever builds it where that line is and what happens on each side of it.
The record
Keep what went in, what came out, and what a person did about it.
Without it you cannot answer a customer who asks why something was sent to them, you cannot tell whether the automation is improving or degrading, and you cannot investigate a complaint except by guessing. This is the audit trail argument from the spreadsheet post, and AI makes it more pressing rather than less, because the reasoning behind an output is not visible in the output.
It does not need to be elaborate. A row per event, readable by a person who was not there, is enough to change an argument from opinion into a record.
What not to give it
Anything irreversible. Anything where money leaves the business. Anything where being wrong produces no signal — those are the cases that accumulate damage quietly, and they are precisely where a human check is worth its cost.
And anything you could not explain to the customer affected by it. If the answer to "why did this happen?" would be that a system decided, and nobody can say on what basis, the process is not ready to be automated regardless of how well it performs.
Sometimes the honest answer is a rule, not a model
A good deal of work described as needing AI is a rule somebody has not written down.
If the logic fits in a sentence — enquiries mentioning these three words go to this person, anything above this value needs approval — write the rule. It is cheaper to build, it is testable, it behaves identically every time, and you can explain it to anyone who asks. A model asked to do the same job introduces variation into something that had none.
Reach for AI where the input is genuinely unstructured and the variation is real. Use a rule everywhere else. Most useful workflows end up as mostly rules with AI at the two or three points where the input is messy — which is a duller design than the one usually pitched, and considerably more reliable.
Our position on this is on the homepage and it has not changed: the workflow is designed around the level of oversight you need, important actions can require human approval, and there are fallbacks and records of what happened. Those are three choices, not a feature, and they are worth making deliberately.
Every automation we build is set up this way by default. The Automation Sprint (S$4,800, two weeks) lists approval gates and fallbacks as part of the package, not an extra, and the AI Receptionist logs every call with a summary, transcript and recording, so there is always a record to check.
