Business Automation
Map the Process Before You Automate It
Automating the process on the diagram is easy. The process people actually follow has four undocumented branches, and that's the one your bot will meet.
Automation projects usually begin with a process diagram supplied by whoever owns the process. It is accurate about intent and frequently wrong about practice, because it describes the path as designed rather than the paths as walked. Automating the designed path produces a bot that works for the cases everyone already agreed about.
Get the event log
Most systems of record already contain the evidence: timestamped records of who did what to which case. Extract case ID, activity, timestamp and actor, and you can reconstruct what actually happens without interviewing anyone.
Group by the sequence of activities and count. The output is a ranked list of real paths, and the surprise is usually how many there are.
What the log tells you that interviews don't
• Path frequency — which variants are worth automating and which are noise.
• Rework loops — activities that repeat, the clearest sign of a broken handoff.
• Waiting time between steps, which is usually most of the elapsed duration.
• Who really performs each step, as opposed to who is supposed to.
• Cases that skip a control step entirely.
The most common path is the one to automate. It is often not the one in the documentation.
Fix before you automate
The mapping frequently reveals that the process itself is the problem — a redundant approval, a handoff that generates rework, a step that exists because of a system limitation that was removed years ago. Removing a step is cheaper, faster and more reliable than automating it, and it reduces the surface the automation has to cover.
Automate the fat head, route the tail
If three variants cover 80% of cases, automate those three and route everything else to a person deliberately, with a note saying why it was routed. Attempting full coverage is how automation projects overrun: the last 20% of cases contain most of the complexity and almost none of the volume.
Then re-run the analysis afterwards
The same event log gives you your before-and-after measurement for free. Compare path distribution, cycle time and rework rate three months post-launch. It also catches the failure mode where the automation works perfectly and people have started routing around it — a new variant appearing in the log with a human actor is exactly that signal.
The documented process had five steps. Event log showed eleven distinct paths and the most common one wasn't in the documentation at all. That gap was two years of accumulated workarounds.
Automating before mapping is how you end up with a bot that handles 60% of cases and a manual process for the rest — which is more total work than before, because now there are two processes.