Most conversations about automation start with a tool. A new AI model, a workflow platform or an integration product promises to remove manual work, and the question becomes where to apply it. That order is understandable, but it tends to automate whatever is most visible rather than what is most valuable, and it can quietly move decisions away from the people who are accountable for them.
A more reliable starting point is the work itself: what actually happens, step by step, and which of those steps need human judgement. Once that is clear, the choice of technology usually becomes simpler, and often smaller, than expected.
Start with the work, not the tool
Consider an illustrative example: a wholesale distributor that receives customer orders by email. Some arrive as PDF purchase orders, some as spreadsheets and some as a few lines of text. Someone reads each one, keys it into the accounting system, checks the customer’s credit position, confirms stock, books a delivery slot and replies to the customer. Exceptions, such as a discontinued product, an unusual quantity or an account on hold, are resolved by whoever happens to know the history.
Described as “order processing”, this sounds like a single task that could be handed to software. Mapped properly, it is a sequence of quite different activities. Some are mechanical. Some involve reading untidy input. A few are genuine decisions with commercial consequences. Treating them all the same way is where automation projects tend to go wrong, either by automating too little to make a difference or by automating decisions that should have stayed with a person.
The mapping does not need to be elaborate. A working session with the people who do the job, a whiteboard and a few real examples, including the awkward ones, will usually reveal more than any requirements document.
Separate preparation from decisions
Once the steps are visible, it helps to sort them into three broad kinds of work.
- Mechanical steps. Copying data between systems, reformatting it, reconciling two lists, sending a standard confirmation. These follow fixed rules and are tedious for people to do.
- Preparation. Gathering the information a decision needs: reading a purchase order, extracting the lines, matching product codes, pulling the customer’s account status and drafting a reply.
- Decisions. Approving credit beyond a limit, accepting a substitution, prioritising one customer over another, or deciding that something looks wrong. These carry consequences and rely on context that is rarely written down.
Most of the time saved by automation sits in the first two groups. Most of the risk sits in the third. Keeping that distinction explicit is the single most useful discipline in deciding what to automate.
Automate the preparation of work. Keep the decision with the person accountable for it, until there is evidence that it can safely move.
Four questions for every step
For each step in the map, a few plain questions help decide how far to automate it.
- How often does it happen? A step repeated hundreds of times a week justifies more engineering than one that happens monthly.
- What does a mistake cost, and how quickly is it noticed? An error caught at the next step is very different from one discovered at month-end, during an audit or by a customer.
- How easily can the output be checked? If a person can verify the result at a glance, automation can be bolder. If checking takes as long as doing, the benefit shrinks.
- Who is accountable for the outcome? If the answer is a named role, that person should decide how much of the step is automated and how it is reviewed.
The answers rarely point to “automate everything” or “automate nothing”. They usually point to a specific boundary within a step: for example, extract and validate every order line automatically, but route anything over a credit threshold or involving a substitution to a person.
Where simple rules are enough
Not every automation needs AI. Many of the mechanical steps in a typical operational workflow are better served by ordinary software: validation rules, lookups, integrations between existing systems and well-designed forms that capture information correctly in the first place.
Rules have useful properties. They behave the same way every time, they can be tested exhaustively and their failures are easy to explain. If an order should never be dispatched to an account on hold, that is a rule, not a judgement, and it should be enforced in the system rather than inferred by a model.
A useful habit is to ask whether a step is difficult because the logic is complex or because the input is untidy. Complex logic is often clearer as code. Untidy input is where AI starts to earn its place.
Where AI earns its place
AI is most valuable in the preparation layer, where people currently spend time reading, interpreting and summarising unstructured material. In the distributor example, that might mean extracting order lines from emailed PDFs in different formats, matching free-text product descriptions to catalogue codes, classifying incoming messages or drafting a reply for someone to approve.
These are tasks where a rule-based approach struggles, and where the output can be checked. They also share an important characteristic: when the AI is uncertain or wrong, the result can be routed to a person rather than acted on directly.
That only works if quality is measured. Before an AI step handles real work, it needs a representative set of real examples with agreed correct answers, a clear definition of what “good enough” means for that task and a way to rerun those checks whenever the prompt, model or data changes. Without that evidence, it is impossible to say whether the system is helping or simply moving errors somewhere less visible.
Design the human step properly
Keeping a person involved is not the same as designing for human judgement. A review step that asks someone to approve a long queue of items with little context quickly becomes a formality. The approval becomes a click rather than a decision.
A well-designed review step shows the original input alongside the proposed output, highlights what the system was unsure about and makes it as easy to correct as to accept. It sends exceptions to the people who understand them, not to whoever is next in a queue. And it records corrections, so they can be used to improve rules, prompts and test sets over time.
There is also a compliance dimension. Where decisions significantly affect individuals, UK and EU data protection rules place limits on decisions made solely by automated means. A clear, documented human decision point makes those obligations easier to meet and easier to explain.
Widen autonomy on evidence
The boundary between automated preparation and human decision does not need to be fixed forever. It should move when the evidence supports it.
If, over a meaningful period, a particular category of order is extracted and validated correctly almost every time, and reviewers rarely change anything, it may be reasonable to let that category flow through with sampling rather than full review. If corrections cluster around a particular supplier format or product range, that is where to invest in better rules or examples. Each change should be deliberate, measurable and reversible.
This is slower than switching everything on at once. It is also how automation earns trust from the people who depend on it, which is what determines whether it is still in use a year later.
A practical starting point
For an organisation considering automation, a sensible first step is modest:
- Choose one workflow that causes visible rework or delay.
- Map it with the people who do it, using real examples.
- Mark each step as mechanical, preparation or decision.
- Pick the step with the most repetitive effort and the lowest consequence of error, and automate that first.
- Define how quality will be measured before going live, and review it regularly.
The aim is not to remove people from the process. It is to remove the work that does not need them, so that their time goes on the decisions that do.