The quickest way to build the wrong automation is to automate the process diagram.
The diagram is usually clean.
Reality is not.
People skip steps. Customers provide incomplete information. Systems disagree. Experienced employees recognise exceptions that were never documented.
Those details are where the real process lives.
Watch the work
Before designing automation, I want to see how the work actually happens.
Which tabs are open? What gets copied between systems? Where does someone stop and think? Which email causes the process to change? What does an experienced person notice that a new employee would miss?
These observations are often more valuable than the formal procedure.
Workarounds are requirements
A workaround is easy to dismiss as bad practice.
Sometimes it is.
But it can also contain important knowledge.
If someone exports data into a spreadsheet every week, ask why. If a team keeps a private checklist next to the official system, ask what the system does not provide. If a manager always reviews one particular exception manually, ask what signal they are using.
The workaround may reveal the requirement the formal process missed.
Separate routine from judgement
Observation helps identify where judgement actually occurs.
Many workflows contain a mixture of predictable steps and genuinely ambiguous decisions.
The predictable steps are strong automation candidates.
The ambiguous decisions may benefit from decision support rather than full automation.
This distinction is easier to see when watching real work than when reading a process document.
Count the interruptions
Operational friction often appears as interruption.
Someone asks for missing information. A colleague messages for an update. A manager is asked to approve a routine exception.
These interruptions are useful signals.
They show where the system is failing to provide information, ownership or confidence.
Removing them can create more value than accelerating the central task itself.
Design around exceptions
A workflow is easy to automate when everything goes correctly.
The quality of the system appears when something does not.
What happens when data is missing? What if confidence is low? What if the customer requests something unusual? What if another system is unavailable?
Exceptions should not be an afterthought.
They are part of the operating model.
Measure before and after
Observation also creates a baseline.
How long does the process take? Where is time spent? How many hand-offs occur? How often are errors corrected?
Without a baseline, automation success becomes subjective.
With one, the business can see whether the system actually improved the work.
Automation begins with curiosity
The best automation projects are not primarily technical exercises.
They are exercises in understanding work.
Watch what people do. Ask why. Notice the friction. Understand the judgement.
Then decide what technology should change.
The automation becomes better because the observation came first.