A practical path to
business automation.

Start by writing down what actually happens, not what the process document says should happen. Sit with the person who does the work, or do it yourself, and note every step, every handoff and every place the work waits for someone's attention. Waiting time is usually the most expensive part of a process and the easiest thing to miss when you only look at the steps themselves.

Record where information currently lives: which calendar, which spreadsheet, which inbox, which paper form. Automation has to read from and write to something, and half of the effort in most rollouts is reconciling data that lives in more than one place under more than one name.

Finally, note who is affected by the process besides the person performing it — the customer waiting on a callback, the technician waiting on a confirmed address, the office waiting on a signed estimate. Their experience of delay and error is the real thing you are trying to improve, and it is easy to lose sight of once you are deep in workflow diagrams.

• Write the process as it is actually performed, including the workarounds.
• Time each step, including how long work waits before someone picks it up.
• List every system and document the process touches, and who owns each one.
• Identify who outside the team feels the effect of delay, error or inconsistency.
• Note any step that already fails occasionally — automation will not fix a step it cannot see.

Treat each phase as done when you can answer these plainly, not optimistically. A phase that is 'mostly working' is a phase that will generate support tickets while you try to build the next one.

• Audit phase: Do you have a written baseline for time, error rate and volume that someone could check the new process against later?
• Mapping phase: Is every branch and exception named, and does every step have a named owner — a specific system or a specific role, not 'whoever is free'?
• Prioritization phase: Can you explain in one sentence why this process was chosen first, using volume, effort and reversibility rather than which team complained loudest?
• Rollout phase: Has the new process run on real work for long enough to hit its common exceptions, not just the happy path?
• Review phase: Have you compared the result to the original baseline, and does someone own watching it going forward?

Some steps should stay assigned to a person even after the surrounding process is automated. Judgment calls about pricing, exceptions to policy, and any conversation involving a genuinely upset customer are better handled by someone with context and the authority to make a decision on the spot.

Escalation paths need to be explicit rather than implied. Define, in writing, which situations route to a person immediately, which are logged for follow-up, and what happens when no one is available to take the handoff. An automated system that cannot say 'I don't know, let me get someone' is more likely to guess than to stop.

Review is also a human responsibility on an ongoing basis. Automated processes should be checked periodically against the outcomes they were meant to produce, not just monitored for uptime. A workflow can run without errors and still be quietly producing the wrong result if the underlying process assumptions have changed.