How to decide what to automate first

When a team decides to automate, the instinct is often to start with the most visible pain or the most interesting technology. Both are usually the wrong place to begin. The first automation should be chosen to build confidence and return value quickly, because success makes the next step easier — and a messy first attempt makes everything harder.

Start by mapping, not building

Before choosing anything, document how work actually moves today. Not how it is supposed to move — how it really does, including the workarounds. This is where the true bottlenecks show up, and they are frequently not where people assume. A map also reveals which steps are stable enough to automate and which are still in flux.

Score candidates on four dimensions

Once you have a map, weigh each candidate step against four factors:

• Volume — how often it runs. High-frequency work returns effort faster.
• Stability — how fixed the logic is. Stable steps automate cleanly; shifting ones fight back.
• Risk — the cost of an error. Lower-risk steps are safer places to start.
• Payback — the time or error reduction relative to the effort to automate it.

The best first candidate usually scores high on volume, stability, and payback while staying low on risk. It is often unglamorous. That is fine — an unglamorous win that people trust is worth more than an ambitious one that they do not.

Match the automation to the step

Not every step needs AI. Where the logic is fixed, rule-based automation is more predictable and easier to audit. Where inputs vary and interpretation is required, AI-assisted automation earns its place. Where a workflow spans several steps and coordination, an agentic approach may fit — with human approval on anything consequential. Choosing the simplest option that reliably does the job is a feature, not a compromise.

Roll out in stages

Even a well-chosen automation should be introduced carefully. Running it in shadow mode — alongside the current process, without taking action — lets you compare its behavior to reality before you depend on it. From there, a limited scope, then full operation. Define exception handling up front so unusual cases escalate to a person rather than being forced through logic that was not designed for them.

Measure what you set out to improve

Finally, decide in advance how you will know it worked: cycle time, error rate, volume handled. Automation is worth doing when it improves an operational outcome, not because it is automated. A first success measured honestly is the strongest argument for the second.