AI workflow automation: what survives contact with reality
Four shapes of work automate well with current technology: reading unstructured documents into structured fields, routing things to the right place, drafting something a person will edit, and checking one source against another. Three shapes look automatable and reliably are not: work whose rules live in people's heads rather than anywhere written, work where the exceptions outnumber the standard cases, and work whose real function is that a named person took responsibility for it. The most common expensive mistake is to pick a process from the second group because it is the one that hurts most. Pain correlates with variety and with political weight, which are precisely the two properties that make a first automation fail, and a failed first project makes the second one much harder to authorise.
The four that work
Reading documents into fields. Invoices, contracts, forms, reports: taking something written for a human and producing structured data. This is the most reliable category available today, and the reason is that the output is checkable. A field is either right or wrong, which means the system can be measured and a person can verify a sample without re-reading everything.
Routing. Deciding which team, queue or person should handle something. Valuable because it is high volume and because being wrong is cheap: a misrouted item is forwarded, not lost. Routing also degrades gracefully, since a system that is unsure can simply send the item to a default queue.
Drafting for editing. Producing a first version a person will revise. Works because the human review is built into the process rather than bolted on, and because the value is real even when the draft is mediocre: starting from something is faster than starting from nothing for most people.
Checking one source against another. Reconciliation, completeness checks, finding the discrepancy between what two systems believe. This is work people find tedious and do badly, which is an unusually good combination: the automated version is often more accurate than the manual one, not just faster.
The three that do not
Work whose rules are not written anywhere. Every experienced person in the process knows that requests from this client are handled differently, that this category is always escalated in December, that this field is unreliable and should be cross-checked. None of it is documented. Automating this work means first extracting the rules, which is a months-long exercise in its own right and is the actual project. Attempting it as a side effect of a six-week automation produces a system that is confidently wrong in ways nobody anticipated.
Work where exceptions outnumber the standard case. If two thirds of items need special handling, automating the third that does not saves very little while adding a system to maintain. The arithmetic is visible on the ROI calculator and it is usually unfavourable. This category is worth revisiting later, after the exceptions have been analysed and possibly reduced, which is a process problem rather than a technology one.
Work whose function is accountability. Some steps exist so that a named person has signed off, and the value is the signature rather than the analysis. Automating the analysis is fine and often useful. Automating the signature removes the thing the step was for, and the organisation will reinstate it within a year, usually after an incident.
Choosing the first one
High volume, low variety, recoverable when wrong. Those three properties matter more than how much the process costs today, because the first project's real deliverable is not the time saved. It is evidence that this works here, which is what makes the second and third projects possible.
The instinct to start with the most painful process is strong and should be resisted. The painful process is painful because it is complicated and because people disagree about it, which means a first attempt will either fail or take three times as long, and either outcome sets the whole programme back a year.
The freed hours problem
This is the part that business cases handle worst. Automating four hours a week across fifteen people frees roughly 2,800 hours a year, which looks substantial and frequently converts into nothing measurable.
The reason is arithmetic rather than cynicism. Nobody's job disappeared; fifteen people each got about an hour a day back. Whether that becomes value depends entirely on what fills it, and if nobody decided in advance, it fills with whatever was already waiting.
Organisations that realise the value decide before the project what the time is for, and the decision is specific: this team takes on the backlog they have never had capacity for, or absorbs the volume growth planned for next year without hiring, or spends the time on the part of the work that was being skipped. Any of those is defensible. "Improved productivity" is not, because it cannot be checked afterwards.
What to measure, and when
Measure the manual baseline before building anything, on real cases, with a stopwatch rather than from memory. This takes a day and it is the only way the eventual claim about time saved means anything. Projects that skip it end up arguing about whether they worked.
After launch, measure two things monthly. The share of items the system handled end to end without intervention, which is the real automation rate and is always lower than the pilot suggested. And the evaluation set, run against fixed cases, which catches quality decay before a user does. Both numbers should be visible to the people whose work changed, because a system whose performance is a secret is a system they have no reason to trust.
Start with the boring process
If you have a high-volume, low-variety task that everyone finds tedious, that is the right first conversation. Bring a description of how it works today, including the exceptions.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
