Which business processes should you automate first?

Look for repeatable friction, then question the process

A team copying enquiry details from an inbox into a tracker has an obvious candidate for automation. But the first question is why that copy exists. Perhaps the tracker is unnecessary, or the enquiry form could write to it directly. Removing a step can be simpler to maintain than automating it.

Spend a working week recording repeated tasks: what starts them, who handles them, which systems they touch, and what a successful result looks like. Include waiting and correction time. Ask the people doing the work to show you a recent example, including one that went wrong. A process diagram built only from the ideal case hides the expensive part.

Choose a contained first workflow

A useful starting point has a predictable input, a small number of rules, and an output someone can inspect. Routing enquiries, preparing an internal task, or collecting a weekly report may fit. Sending consequential messages, changing access, or making irreversible updates needs tighter controls and a clearly agreed approval boundary.

Use this checklist to compare candidates. A low score is a signal to clarify the process, not proof that it can never be automated.

• Frequency: does the task recur often enough to justify building and supporting it?
• Clarity: can two people follow the same rules and reach the same result?
• Inputs: are the necessary records available and consistently structured?
• Exceptions: can you recognise an unusual case and route it to a person?
• Reversibility: can you correct a duplicate, missed step, or wrong update?
• Ownership: is someone responsible for checking that the workflow still works?

Estimate net time saved, not the fastest demo

Consider an illustrative enquiry workflow handling 80 items per week. At six minutes each, the manual process takes 480 minutes, or eight hours. Suppose automation handles the routine preparation, but every enquiry still needs one minute of review: that uses 80 minutes. Twelve exceptions need an additional five minutes each, using another 60 minutes. Allow 40 minutes for monitoring and maintenance.

The resulting estimate is 480 − 80 − 60 − 40 = 300 minutes: five hours of weekly capacity released. Those assumptions need checking in a pilot. If exception volume doubles, the result changes. Time released is also not automatically cash saved; the team needs useful work to do with that capacity.

Design the unhappy path before the launch

Ask what happens when a field is missing, an account loses access, a service is unavailable, or the same event arrives twice. Give each case an explicit destination. A visible review queue is easier to manage than a workflow that silently skips work or repeatedly sends the same request.

AI can help interpret unstructured text, draft a response, or suggest a category. Treat those outputs as proposals where mistakes matter. Agree which actions require a person, what evidence they should see, and how to correct an error. A confidence label alone is not a substitute for testing on examples representative of your actual work.

1. Record the original input and the outcome of each attempted step.
2. Make repeated requests safe, or detect duplicates before acting.
3. Assign failed and ambiguous cases to a named review queue.
4. Document how to pause the workflow and complete work manually.

Pilot one slice and keep an owner

Run a small batch alongside the existing process, with external actions disabled or explicitly approved. Compare completion time, error rate, exception volume, and the effort needed to resolve failures. Include difficult examples instead of testing only clean inputs. Define what would make you stop the pilot before it begins.

If the results justify rollout, assign an owner, a maintenance allowance, and a review date. Record the connected accounts and the rules the business agreed. Start the next automation only when the first is understandable and supportable. A modest workflow people trust is a stronger foundation than a large network of automations nobody wants to touch.