The Failure Mode Is Automating the Wrong Version of the Process
Ask someone to describe how a process works and you get the documented version — the one from the training deck. Watch them actually do it and you get a different process, full of manual patches nobody wrote down: the spreadsheet that catches what the system misses, the email someone sends because the approval step doesn't actually trigger anything. Automate the documented version and you've automated something that no longer matches reality.
Map the Workarounds, Not Just the Workflow
The workarounds are usually where the actual signal is. A manual patch exists because something upstream doesn't do what it's supposed to. Understanding why the patch exists — not just that it exists — tells you what the automation actually needs to handle, and often surfaces a bigger problem than the one you started with.
Start at the Step That Generates the Most Exceptions
Not the step that takes the most time. The step that produces the most "wait, what do I do here" moments — because that's the step absorbing the most judgement, and judgement is expensive to replicate badly. Fixing that step first tends to simplify everything downstream of it, sometimes to the point where the rest barely needs automating at all.
The Person Doing the Job Is the Source of Truth
Not the process document, not the system that's supposed to enforce it. Whoever does this work every day knows exactly where it breaks, what they skip under deadline pressure, and what they don't trust the system to get right. That conversation is worth more than the documentation, and it's usually free — nobody asks for it before scoping automation work, and it shows.