What to automate first: a workflow automation prioritisation guide

Start with the workflow, not with automation. The workflows worth automating first repeat with a known rhythm, move defined inputs to defined outputs, follow decision rules a person can state, and hand work between systems or people in a structured way. Everything else is a candidate to keep manual, integrate, or fix first — and a workflow that is not ready is a valid reason not to automate anything yet.

An automation project should begin with the process as it actually runs today: how work enters, which steps are performed, who owns each handoff, where exceptions are handled, and which systems hold the data. Choosing a tool first inverts that order and usually ends with automation built around a product instead of around the process. When the workflow itself is not yet understood well enough to describe it, the honest first step is to finish understanding it — not to start automating.

Repetitive execution: the same steps run again and again with the same shape.

Clear inputs and outputs: the workflow starts from defined information and produces a defined result.

Stable decision rules: the routing and approval decisions follow rules a person can state and review.

Structured handoffs: work moves between people or systems in a predictable way.

Avoidable manual transfer: data is copied or re-keyed by hand instead of moving between systems.

Predictable exceptions: the exceptional cases are known and can be described in advance.

Meaningful operational frequency: the workflow runs often enough that automation changes how the work is done.

Unstable process: the process is still being redesigned, so an automated version would have to be rebuilt as quickly as it is built.

Unclear ownership: no one can name who is accountable for the workflow end to end.

Constantly changing rules: the decision rules shift week to week and cannot be pinned down.

Highly contextual judgement: the work depends on context and judgement that cannot be given to a machine in advance.

Rare execution: the workflow runs so seldom that the automation is never exercised often enough to stay reliable.

Poor underlying data: the data the workflow depends on is incomplete, inconsistent, or not trustworthy.

Unresolved process defects: the process itself has known defects, and automation would carry them along unchanged.

Automation can institutionalise a bad process: once the steps run automatically, the underlying defects keep repeating. When the process itself is the problem — unclear ownership, contradictory rules, duplicated steps, data that is never correct — redesign and simplification come first. 'Fix the process first' is a valid outcome of a prioritisation review, not a delay.

Integration connects existing systems so they exchange data. Workflow automation executes and orchestrates repeatable workflows. Both sit within the broader Business Systems operating layer, but they are distinct from each other — and both are distinct from custom development, the purpose-built software that becomes relevant when existing systems, configuration, and integration are insufficient. A workflow that looks like an automation problem is often an integration problem: the process is sound, but the systems do not share data cleanly. Distinguish the three before choosing.

AI can assist with interpretation, classification, and generation inside a workflow: reading an incoming document, categorising a request, or drafting a reply for review. But AI is not synonymous with automation. A workflow can be fully automated without AI, and AI can be used in a process that stays human-run. AI-enabled interpretation and reasoning belongs to the AI Systems domain, under appropriate controls, and is evaluated separately from whether a workflow should be automated at all.

Approvals where accountability must rest with a named person.

Judgement calls that depend on context the systems do not hold.

Exception handling for cases that were not described in advance.

Decisions about business rules and process ownership.

Escalations that carry business or relationship consequences.

A bounded, well-understood workflow is a better starting point than a broad transformation. One workflow that is clearly scoped, with stable rules and clean data, can be automated, monitored, and refined — and the experience it creates is what makes the next candidate tractable. A broad programme that automates many workflows at once multiplies integration, control, and maintenance risk without first proving the approach on a real workflow.

What does the workflow do today, and who owns it end to end?

How often does it run, and what changes when its execution becomes automatic?

Which decision rules can be stated, and which depend on judgement?

What data does the workflow depend on, and is that data trustworthy?

How are exceptions handled, and who is accountable for them?

Which systems must exchange data, and how are failures detected and handled?

What is the honest outcome if the workflow is not automated at all?

A prioritisation review of workflows has five valid outcomes: automate the workflow; integrate existing systems when the gap is data exchange; simplify or redesign the process first when the process itself is the problem; retain human execution and control when judgement and accountability dominate; or defer and leave the workflow as it is until it is stable and frequent enough to justify the work. Automation is one option among these, not the default answer — and 'no automation required' is a complete and correct conclusion.