Most failed automation projects were not failures of technology. They were failures of arithmetic. Somebody counted the transactions and forgot to count the ways those transactions differ from each other, and the bot went live against a process that existed only in a slide. Process documentation automation work has a reputation problem, largely deserved. Traditional documentation produces a flowchart of the ideal path, signed off by a manager who has not performed the task in four years, filed somewhere nobody reads. That artefact is worthless as an automation input. What is needed instead is narrower and much more useful: a count of the variants, with volumes, and an honest map of where a human is exercising judgement rather than following a rule.
The happy path is a minority of your volume
Walk any back office process, invoice processing, order entry, employee onboarding, bank reconciliation, and you will find a documented route that covers perhaps sixty to seventy per cent of transactions. The rest go somewhere else: the supplier who sends a photograph rather than a PDF, the order that arrives with a customer reference in the wrong field, the intercompany transaction handled differently, the case where the amount exceeds a threshold and an approval appears by email, the one customer whose terms were negotiated by the chairman. Automation economics live entirely in that residual. A bot that handles the happy path removes sixty per cent of the volume and none of the difficulty, because the remaining forty per cent still needs the same team, the same knowledge and the same system access. Worse, once the easy work is gone, the people are left with nothing but exceptions, which is slower per item and much harder to staff. So the question that determines feasibility is not "can this be automated" but "what proportion of real volume falls into variants we can specify." That is a number, and producing it is a two-week exercise, not a six-month programme.
Three artefacts worth producing
Everything else is optional. These three decide the project. The variant census. Take a real sample of transactions, several hundred if possible, from a period that includes a month end. Classify each one by how it actually flowed. Count. You will typically find between eight and thirty distinct variants, a handful of which carry most of the volume and a long tail that carries almost none. This single table tells you the achievable automation rate before anyone buys anything. The decision inventory. Everywhere the process says "check", "review", "verify" or "confirm", write down what is actually being decided, what information the person uses, and what rule they apply. Some of these turn out to be rules that were simply never written down, which are automatable. Others turn out to be judgement supported by context the system does not hold, which are not, and pretending otherwise is how bots end up approving things they should not. The input contract. For every piece of data entering the process: where it comes from, in what format, who controls that format, and how often it changes without notice. Automation is far more sensitive to upstream instability than to complexity. A simple process fed by an unstable input breaks weekly; a complex process with a fixed input runs for years.
| Artefact | What to observe |
|---|---|
| Variant census | Count how real sampled transactions actually flowed |
| Decision inventory | Record information, rules and judgement needed at each review |
| Input contract | Name each format, source, owner and change dependency |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Run it as a sprint, not a programme
The reason documentation has a bad name is that it is usually commissioned as a deliverable rather than a decision. A sprint format avoids most of that. Two weeks. Sit with the people doing the work rather than interviewing their manager, because the manager describes the policy and the operator describes the process. Sample real transactions rather than relying on recall. Capture screens and keystrokes where the work is system-based, and photograph the physical artefacts where it is not. Produce the three tables above, a recommended automation scope expressed as a percentage of volume, and an explicit list of what will still arrive at a human. Then stop. Where transaction volumes are high and the process lives inside one system, event log analysis can shortcut much of the census by reconstructing the actual paths from timestamps. It is genuinely useful and it is not a substitute for watching the work, because the interesting variants are usually the ones that leave the system for a WhatsApp message and come back.
Practical Guidance for a Process Documentation Sprint
- Count variants before estimating benefits. Any automation business case without a variant census and volumes attached is an opinion with a spreadsheet around it.
- Sample real transactions, including a month end. Period-end behaviour is different, it is where the pressure is, and it is routinely excluded from process studies.
- Observe operators, not managers. The gap between the described process and the performed process is the entire subject of the exercise.
- Write down every judgement step and the rule behind it. If nobody can state the rule, that step stays human, and the design should route to a person rather than guess.
- Document the inputs and who controls them. An upstream format owned by a third party is the most common cause of a bot that worked for a month.
- Set the automation line at a volume threshold, not at completeness. Decide to cover the variants representing, say, eighty-five per cent of transactions, and design a clean exception route for the rest. Chasing the tail is where projects die.
- Design the exception path first. The queue, the ownership, the service level and the feedback loop. Exceptions are the permanent part of the process; the automated path is the easy part.
- Make the bot maintain the documentation. Log every case the automation cannot handle, with a reason code. After six months that log is a better process document than anything a consultant produced, and it is current.
The Regional Angle
The first regional problem is linguistic, and it is rarely named. Procedures here are written in English because that is the language of the system and the auditor, while the work itself is performed and explained by teams speaking Hindi, Urdu, Malayalam, Tagalog, Arabic and several others. The real process, the part containing all the variants, is transmitted verbally between colleagues in a language the documentation is not written in. A sprint conducted only in English, only with supervisors, reliably produces a description of the policy rather than the process. Running the observation sessions with someone who speaks the floor language changes what you find, and it is the single highest-return adjustment to the standard method. The second is turnover. Expatriate staff rotation in regional back offices is high, and when someone leaves they usually leave the country. The undocumented variant knowledge does not move to a competitor down the road; it evaporates. That makes the census valuable independently of any automation decision, and it is a better argument for funding the sprint than the automation business case is, because it is true whether or not a bot ever gets built. Third, the documents themselves. A substantial share of regional transaction flow still arrives as scanned purchase orders on letterhead, stamped delivery notes, handwritten annotations, bilingual invoices with Arabic and English in the same layout, and PDFs that are photographs. Capture tools handle clean structured documents well and this material considerably less well. The variant census in this region needs a document-quality dimension that the global templates do not include, and the automation rate it produces should be calculated against actual received documents rather than the sample the vendor demonstrated with. Fourth, approvals. In owner-led and family-controlled groups, which are most of the regional mid-market, a meaningful proportion of exceptions originate as a verbal instruction from someone senior. The order goes through because the customer called the chairman; the payment is released because the managing director said so. These are not defects to be designed out during an automation project, and treating them as such guarantees the automation is bypassed. Document them honestly as an approval variant, give them a route through the system that captures who authorised what, and you will have improved the control environment more than the bot improves the cost line. Finally, multiplicity. A group operating ten or fifteen entities across mainland, free zone and neighbouring countries is frequently running the same nominal process a dozen slightly different ways, because each entity was set up by different people at different times under different requirements. The census should run across entities, not in one of them, or you will automate a variant that exists in a single company and discover the others afterwards.
The objection worth taking seriously
The objection is that documentation is a consulting product. It takes weeks, produces a binder, and is out of date by the time it is bound. Meanwhile modern automation tooling is cheap enough to build, fail and iterate, so the faster route is to automate the obvious path, watch what breaks, and fix it. Discovery through failure is honest, quick and produces artefacts that are true by construction. The harder version is more damaging. Variant mapping is unbounded. The tail of exceptions is effectively infinite; every additional day of observation surfaces another case, and there is no principled stopping point. Worse, mapping the as-is process tends to entrench it, because the map becomes the specification and nobody asks why the process has thirty variants in the first place. Many of them exist only because a system limitation or a policy nobody remembers made them necessary, and the right response is elimination rather than automation. Both points are correct and they change the shape of the work rather than its necessity. The stopping rule is volume, not completeness: cover the variants that carry the bulk of transactions, route the rest to people, and let the exception log extend the map over time. The entrenchment risk is answered by making variant elimination an explicit output of the sprint, with a column asking why each variant exists and whether it should. And the build-and-iterate argument holds only where failure is cheap. When the process touches payments, payroll, tax filings or customer commitments, discovering the variants in production is not iteration. It is an incident with a reconciliation attached.
Common Questions
How long should this take?
Two to three weeks for a single process, including observation, sampling and the three tables. Anything longer has usually turned into a documentation project rather than a decision, and anything much shorter has skipped the transaction sample.
What automation rate is realistic?
It depends entirely on the variant distribution, which is why the census comes first. Processes with a few dominant variants and stable inputs reach high rates; processes with a flat spread of many variants rarely justify the investment at all, and finding that out in week two is a good outcome.
Do we need process mining software?
Only at high volume and where the process is contained within systems that produce usable event logs. It is a powerful accelerant and a poor substitute for observation, since the most disruptive variants are the ones that leave the system entirely.
What should we expect over the next twelve months?
Expect automation vendors to keep bundling discovery and task-mining capability into their platforms, which is genuinely useful and also conveniently shortens their own sales cycle. Expect document capture to improve faster than process understanding does, which will shift the bottleneck further onto variant knowledge. And expect the organisations reporting the best automation results to be the ones that were willing to publish their exception rates alongside their success rates.
Process Documentation Sprint — two weeks on the floor, a counted variant census with real volumes, and an automation rate you can put in a business case without crossing your fingers.