Business Automation

Process automation usually stops at the easy half. A script moves a file, a form writes to a database, a scheduled job sends a reminder, and the queue stays exactly as long as it was, because what took the time was judgement: whether this is a request the team handles at all, whether this customer qualifies, whether this amount sits inside the rule or outside it.

Task automation that handles one step in isolation also tends to create work of its own. Somebody now has to confirm whether it ran, what it changed and which items it passed over. Any system that cannot say what it did is a system a person has to check by hand, which is the cost it was supposed to remove.

The useful unit is the request, end to end, including the cases it refuses. A workflow automation that succeeds on the eighty per cent it understands and silently drops the rest has not automated the process. It has concealed the remainder.

Requests arrive where they already arrive: a monitored inbox, a form, a queue, a webhook from another system. Nothing here asks the business to change how work reaches it, because a process everyone has to remember to route somewhere new is a process that quietly goes around the system.

Classification comes before anything acts. A refund, an address change and a complaint carry different rules and different consequences, and running the wrong path against the wrong request is worse than running nothing at all.

Extraction then pulls the specific values that request type needs, as structured fields rather than a summary. Those values are checked against the business's own records, not against the message alone. A customer who states an account number is asserting something; the record is what confirms it.

Then the decision, which is the whole point: complete the request in the systems that hold the truth, or escalate it to a person with the reading already done. Both outcomes are written down, and so is the reasoning, because a month later the only question anyone asks is why.

There is no shortage of automation tools, and choosing between them matters less than most comparisons suggest. An orchestrator sequences the steps, retries the ones that fail and keeps a trace of every run. A model handles classification and reading. A database holds state, because a process that cannot resume is a process that restarts from the beginning each time something times out.

The distinction that matters in automation technology is not which platform. It is whether the system holds state and whether it can account for itself. Automation software that executes steps and records nothing reproduces exactly the audit problem it was bought to solve, and does it faster.

Models are chosen per step rather than once. Classification and extraction rarely need the largest model available, and using one everywhere is how a system becomes expensive without becoming better.

A system that writes into finance and customer records needs limits before it needs accuracy. Every action runs under an identity with defined permissions, so what it may touch is a decision somebody made rather than a side effect of what it turned out to be capable of. Every action is logged, including the ones refused.

Where the line sits between acting and asking is a business decision, not a technical one. Which request types complete on their own, which always wait for a person, what an unrecognised request does, and what happens when a rule and a record disagree, are questions the people who own the process answer. The system enforces the answer; it does not invent it.

It does not remove people from work where the judgement is the work. Exceptions, disputes, anything discretionary and anything a regulator will ask about stay with a person, prepared rather than decided.

It does not automate a process nobody can describe. If two people in the business apply a different rule to the same request, that disagreement has to be settled first. A system will otherwise encode one of the two answers permanently, without telling anyone which one it picked.