Automation preserves assumptions
Every automation contains a rule about what should happen next. If the business has not agreed on ownership, required information or exceptions, the automation will encode one version of the confusion.
That can make the process harder to understand because the failure moves from a visible human conversation into background logic.
Stabilise the normal path
Before automating, describe the normal process in plain language. Identify the trigger, inputs, owner, outcome and next step. Run it manually enough times to see whether it is genuinely repeatable.
List the exceptions first
Ask what should happen when data is missing, a customer changes their mind, a threshold is exceeded, an approval is required or a downstream system is unavailable.
A safe automation knows when to stop and ask for human judgement.
Measure the current cost
Estimate frequency, time, error correction, chasing and commercial impact. This gives the business a baseline for deciding whether automation is worth the effort and whether it worked.
Automate the smallest stable slice
Start with a bounded step that has clear inputs and recovery. Keep logs, make ownership explicit and preserve a manual path. Expand only after the business can observe both success and failure.
Define “done” before writing rules
A surprising amount of automation failure comes from an unclear finish line. What does completed mean? Is the customer informed, the record updated, the next owner notified and the exception queue empty?
Write the completion condition in business language. This gives the automation a testable outcome and makes partial failure visible. Otherwise a workflow can report success because an API call completed while the customer or team is still waiting.
Prefer observability over cleverness
Early automations should be easy to inspect. Use clear names, simple rules, logs that a business owner can understand, and alerts for failure. Avoid creating a dense web of invisible dependencies just because a platform makes them technically possible.
The purpose is to reduce operating effort. If nobody can explain what the workflow did yesterday, the system may be saving clicks while creating a new form of risk.