Business process automation and AI
integration

Two numbers decide it. How often the process runs, and how much it varies each time.

High frequency with low variance is where automation pays: the same invoice moved between two systems four hundred times a month. Low frequency with high variance is where it does not. A decision made twice a year by someone weighing context is cheaper left alone, and encoding it produces a rule that is wrong the third time.

The trap sits in the middle. A process that runs often but changes shape whenever an exception appears can be automated, and then every exception becomes a change request. So before anything is written we count the exceptions in the last three months of real cases. If a third of them needed a person to decide, the useful project is not the robot. It is removing the ambiguity that produces the exceptions, then automating what is left.

Automation succeeds quietly and fails quietly. That is the problem. A sync that stops sending orders does not raise its hand, and the first signal is usually a customer asking where something is, several days later.

So the failure path is part of the work rather than an addition to it. Every automated step needs three things: a check that it ran at all, somewhere for failed items to wait instead of vanishing, and a person who gets told. The manual route has to stay usable too. If a connector is down for a day, the team needs a way to keep working that does not involve waiting for us.

We also write down what the automation may do on its own and what it must hold for approval. Refunds, price changes, anything that sends mail to a customer — those usually deserve a person between the trigger and the action.

A language model is good at reading things written for people. An email that asks four questions at once. A scanned delivery note. A support message with the order number buried in the third line. It is poor at arithmetic that has to be exact and at rules that must never bend.

So the split is usually clean. The model reads and classifies. A rule decides and acts. An invoice total is not something to infer; it is something to compute and check against the source. Where a model does decide, its output belongs in a form a person can review before it becomes an action, at least until the error rate is known.

Two questions settle most designs. What does a wrong answer cost here, and would anybody notice it? Where a mistake is cheap and visible, let the model run. Where it is expensive or silent, keep the person in the loop.

Automations are built inside a project and inherited afterwards. The build has a named owner, a deadline and somebody's attention. The inheritance has none of those, and that is where the failures come from — not from logic that was tested, but from the months afterwards, when the thing runs unattended while the world moves around it.

Ownership has to be a person, not a department. That person never has to read the code. They need three things. What the automation is for, what it looks like when healthy, and who to call. Next to them sits one written page: what the process does, what it touches, how to switch it off, and what has to be done by hand while it is off. The last item is the one that gets skipped, and the one that matters on the afternoon a client is waiting.

Then there is quiet failure. It is the expensive kind. An automation that stops with an error gets noticed. One that keeps running against a changed form, an expired token or an endpoint that started returning an empty list does not: it reports success and does nothing, which is worse, because the dashboard still looks normal. So the check is not whether it ran but whether it did the amount of work we expect, with a threshold that fires when a daily job suddenly handles zero rows.

Finally, a review date. Teams reorganise and processes get replaced, and an automation nobody remembers is a piece of software making decisions in your business on assumptions from two years ago. Going through them once a year takes an afternoon, and the usual outcome is that two get switched off.

None of this needs a platform. One page of text, one named owner, one threshold alert and a date in the calendar cover most of what goes wrong, and they are precisely the parts missing from automations that were, technically, built perfectly well.