How to choose the first workflow to automate

Build a shortlist from operational friction

Ask each team where information is copied, where customers wait and where managers chase updates. Look for work that happens every week rather than rare frustrations. A credible candidate should have an identifiable trigger, a known owner and enough examples to examine.

Do not begin with the process that sounds most futuristic. Begin with the process whose current cost and desired result can be described in ordinary business terms.

Score frequency, effort and consequence

Frequency shows whether an improvement will accumulate value. Effort includes the minutes spent completing the task and correcting avoidable mistakes. Consequence covers delayed revenue, poor customer experience, compliance exposure or lack of management visibility.

A high-frequency, moderate-effort process is often a better pilot than a rare, high-consequence decision. The team gets repeated opportunities to learn without placing a critical outcome under unproven automation.

• How often does the workflow run?
• How many people touch it?
• How much correction or chasing is involved?
• What happens when it is late or wrong?
• Can improvement be measured from existing records?

Check process stability and data readiness

Automation magnifies ambiguity. If staff disagree about the correct steps, first agree the operating rule or define where judgement is required. Review at least ten real examples, including unusual ones, and identify the information used to reach the outcome.

The input does not need to be perfectly structured, but it must be accessible and lawful to use. Missing ownership, inconsistent identifiers or unknown document versions are signs that preparation is needed before implementation.

Separate rules, AI tasks and human decisions

Use deterministic rules for required fields, calculations, permissions and known routing. Use AI for tasks such as classifying text, extracting information or preparing a draft where some uncertainty is acceptable. Keep people in control of sensitive, unusual or financially important decisions.

This separation makes the system easier to test. It also prevents a model from being blamed for workflow rules that should have been explicit software logic.

Define a first release and success measure

Limit the pilot to one source, one team or a small number of categories. Define the baseline before build: current turnaround time, correction rate, backlog or manual touches. Then choose a small set of measures that the team will review after launch.

Include quality and adoption, not just time saved. A faster process that staff do not trust or that creates more correction work has not succeeded.

Use the pilot to make the next decision

The pilot should reveal data quality, edge cases, user behaviour and platform constraints. At the review point, decide whether to expand, adjust, keep the smaller solution or stop. Stopping a weak idea after a bounded test is a good outcome compared with scaling it.

A workflow review can help turn the shortlist into a scoped first phase without committing the business to a broad transformation programme.