How to Identify Business Processes Worth Automating With AI

The automation workshop produces a familiar list: handle email, improve reporting, answer customer questions, and reduce administration. Every department has a candidate, but the list does not reveal which project is likely to work. Broad activity names hide the inputs, exceptions, decisions, and downstream consequences that determine feasibility.

Selecting a process for AI automation is an exercise in operational investigation. You need to find a task where interpretation creates meaningful effort, the necessary data is available, the result can be checked, and mistakes have a manageable response. A compelling demonstration is useful only if those conditions survive real work.

This guide offers a practical way to narrow a long list into a small, testable opportunity. The scoring examples are decision aids rather than an objective ranking system. Your organisation's constraints and evidence should determine the final choice.

Observe work before asking for automation ideas

Ask employees to walk through recent cases using the actual documents and systems involved. Watch where they search, copy information, wait for answers, resolve ambiguity, and correct earlier mistakes. The most useful candidate may be a small step nobody mentioned in the workshop.

Separate active effort from elapsed time. An invoice may take a week to approve while requiring only a few minutes of reading. Automating extraction will not remove a delay caused by unclear approval ownership or an absent manager.

Record case volume and variation. A task performed frequently with moderately varied text may be a good candidate for assistance. A rare, highly consequential judgement may deserve a different approach even if it takes longer each time.

Include the people who handle exceptions. A manager may describe a clean process, while the support team spends its day dealing with missing references and conflicting records. Automation selection based only on the nominal workflow will underestimate the work that remains.

Define a candidate as an input-to-outcome path

Replace “automate email” with a concrete statement such as “classify incoming supplier requests and prepare a draft record for review.” Name the input, intended output, responsible user, and point at which the task is complete.

Draw the boundary around one useful outcome. If the proposal includes reading a request, negotiating terms, updating records, approving expenditure, and contacting a supplier, break it into smaller decisions. Different steps may require different controls and technologies.

Identify the downstream consumer. A draft classification is valuable only if somebody or some system can use it. Ask what format, evidence, and quality that consumer needs before estimating the benefit.

Write the failure outcome too. An unreadable document might return to a manual queue. An ambiguous account match might require staff confirmation. A candidate without a workable exception path is not ready for a credible pilot.

Check whether the problem needs AI

Stable rules, exact lookups, and structured data transfers often fit conventional automation. If a task simply copies a known field from one supported system to another, an integration may solve it without a model.

AI is more relevant when the task involves interpreting varied language, extracting meaning from inconsistent documents, or proposing a response from a constrained body of information. Even then, deterministic validation can handle the parts with clear rules.

Sometimes the best improvement is process repair. A required reference field in the intake form may eliminate more ambiguity than a sophisticated matching assistant. Improving a supplier template may reduce extraction errors at their source.

Use a simple comparison: manual process, process improvement, conventional automation, and AI-assisted automation. Estimate what each option solves and leaves unresolved. This prevents a technology preference from becoming the selection criterion.

Look for evidence that the output can be verified

A promising task has a result that staff can check efficiently. Extracted invoice fields can be compared with a source document. A suggested support answer can be checked against an order and approved policy material.

Verification becomes harder when the task asks for broad strategic judgement or an answer without accessible evidence. If an expert must repeat the entire analysis to know whether the output is useful, the expected time saving may disappear.

Ask what a reviewer needs to reject a bad result. Source links, field-level comparisons, and explicit unresolved items can make review practical. A long fluent explanation without evidence may increase rather than reduce the cognitive burden.

Include verification effort in the candidate description. “Drafting takes ten minutes” is incomplete if the new draft requires fifteen minutes of checking. The relevant measure is effort to reach an accepted outcome.

Assess data readiness through representative cases

Confirm that the necessary inputs exist and that the team can access them through an appropriate, supported path. A promising use case can stall because documents live in personal inboxes or a vendor system offers no usable export.

Inspect data quality rather than accepting a general assurance that the organisation has plenty of data. Look for missing fields, inconsistent identifiers, duplicated entities, outdated records, and conflicting sources of truth.

Evaluate permissions and data handling early. The pilot should use only information the organisation is authorised to process through the selected service and workflow. This is a concrete implementation requirement, not an item to postpone until the demonstration succeeds.

Choose a sample that reflects the work. Include short and long inputs, different suppliers or teams, and difficult cases. A set assembled from the cleanest examples will make the candidate look more mature than it is.

Estimate benefit with an honest operating model

Start with volume, current effort, expected adoption, and the portion of the task the proposal can actually remove. Subtract review, exception handling, support, and new administration. Keep these assumptions visible instead of compressing them into a single savings claim.

Released staff time may create capacity rather than cash savings. Explain how the business would use that capacity. A team with a persistent backlog has a different opportunity from a team whose workload is constrained by customer demand.

Include implementation and recurring costs. Integration work, data preparation, user-interface changes, model usage, monitoring, and maintenance may all be necessary. A low price per model call does not establish a low cost per completed task.

The GOV.UK guidance on measuring service benefits emphasises establishing a baseline. That principle is useful here: measure the present workflow before changing it, then compare outcomes using definitions that remain consistent.

Treat consequences separately from average accuracy

Two tasks with the same error rate can have very different consequences. Misclassifying an internal note may be easy to correct; sending an incorrect commitment to a customer can require a more involved response.

Identify the worst credible mistake in the proposed boundary. Ask whether it is detectable before an external action, whether it can be reversed, and who would repair it. Use that analysis to decide whether the task should remain draft-only or require review.

Do not rely on a high average score to justify every case. A model might perform well on ordinary documents while failing on rare but important conditions. Define specific evaluation categories for those conditions.

Separate access risk from content quality. An accurate answer delivered to the wrong person is still a failure. Candidate selection should consider whether identity and permission checks can be enforced by the application around the model.

Compare candidates with a small evidence table

Use a short set of dimensions: recurring effort, input readiness, output verifiability, integration effort, consequence of error, and accountable ownership. Record evidence and unknowns alongside any score.

Avoid adding the numbers mechanically when one dimension is a hard constraint. A task with strong benefits but no authorised access path is not made feasible by a high total. Mark the constraint and identify what evidence would resolve it.

For an illustrative comparison, supplier-document extraction may have accessible inputs and easy field checks but require entity matching. A broad management-advice assistant may have low integration effort yet weak verification. The first could be a stronger pilot even if the second produces a more impressive demonstration.

Review the table with operations, engineering, and the intended users. Disagreements often reveal missing assumptions: one team expects automatic execution while another imagines a reviewed draft. Resolve those differences before estimating delivery.

Choose a pilot that answers a decision

A pilot should test the central uncertainty, not recreate a smaller version of the full vision. If account matching is the hardest issue, evaluate matching on realistic cases before building a polished conversation interface.

Define the scope, sample, baseline, evaluation method, and stop condition. Specify what evidence would support expansion, what would justify a narrower design, and what would lead you to stop.

Choose a comparison appropriate to the process. Staff might complete comparable cases with and without assistance, or reviewers might assess outputs without knowing which method produced them. The aim is to reduce avoidable bias, not to impose an elaborate experiment on every small project.

Keep a record of the actual configuration: model, prompt, retrieval sources, tool access, and validation rules. Otherwise, the team may be unable to reproduce the result after the prototype changes.

Measure completed work and the work left behind

Track accepted outcomes, correction effort, exception volume, and the time required to finish the task. Include cases the system declines or cannot process. Excluding them makes the result look better while leaving operations to carry the hidden workload.

Segment the results by input type and user group. A process may work well for one supplier format and poorly for another. This can support a useful limited rollout rather than an unjustified all-or-nothing decision.

Record whether users actually choose the assisted route when alternatives remain available. Low adoption may indicate poor fit, unclear control, or inadequate evidence presentation. It is not automatically a training problem.

Inspect new work created for other teams. An intake assistant might save front-office time while sending more ambiguous records to finance. Evaluate the end-to-end process so the pilot does not merely move effort across a departmental boundary.

Decide how much autonomy is justified

There is a progression from summarising information to proposing a decision, preparing an action, and executing it. Each step changes the evidence and controls required. A successful summary pilot does not automatically establish that autonomous execution is safe or useful.

Use the narrowest authority that produces the intended benefit. If staff spend most of their time collecting information, an evidence-gathering assistant may deliver value without changing any business records.

Anthropic's guidance on effective agents recommends matching system complexity to the problem. In process selection, that means considering a fixed workflow or a single constrained model call before assuming that an agent needs to choose and execute a long sequence of actions.

When execution is appropriate, require enforceable permissions, validated inputs, duplicate protection, and confirmed outcomes. Those are integration requirements to include in the project estimate rather than features to add after users start depending on it.

Give the process an owner after the pilot

A pilot often benefits from close attention by enthusiastic developers and a small group of users. Production needs a sustainable owner for exceptions, evaluation, model changes, source updates, and operational support.

Ask who can decide that the automation should pause. Define a practical fallback and how queued work returns to the normal process. If nobody can explain how to stop it without losing work, the operating model is incomplete.

Maintain a representative evaluation set and review it as inputs change. New suppliers, new product categories, or revised policies can invalidate assumptions from the original pilot. Monitoring should identify those shifts before poor results accumulate.

Budget for maintenance in the same way you would for other business software. AI assistance is not a one-time configuration exercise when it depends on changing data, services, and operational expectations.

## Inspect the exceptions before estimating scale

Ask for a small sample of cases that experienced employees describe as difficult. Look for missing identifiers, conflicting instructions, unusual document layouts, and tasks that cross departmental boundaries. These cases help reveal whether the proposed automation has a coherent stopping point.

Separate exceptions caused by input quality from exceptions caused by business ambiguity. Better extraction may help the former. The latter may require a policy decision that no model should make independently. Recording the distinction prevents repeated prompt tuning around an unresolved organisational question.

Estimate the effort required to route and resolve rejected cases. A pilot that handles ordinary inputs well may still be useful, but only if the remaining queue is visible and staffed. Declining a task transfers work; it does not remove it.

Use the findings to define initial eligibility. For example, start with one supported document format and route others directly to the existing process. Narrow eligibility can make a first release dependable while the team gathers evidence about broader coverage.

Watch for incentives that distort the result

A team measured on automated volume may push unsuitable cases through the system. A team measured only on error avoidance may reject everything. Choose measures that reward accepted outcomes with proportionate effort and correct escalation.

Make it acceptable for pilot participants to report that the feature did not help. Their feedback is part of the investment decision, not resistance to a predetermined rollout. Observe actual work where possible to complement self-reported satisfaction.

Avoid letting the prototype's most enthusiastic user define the entire operating model. Include occasional users and the people who receive its outputs. Their experience may reveal training, review, or integration costs that the initial champion does not encounter.

A useful pilot leaves the organisation better informed even if it stops. Preserve the baseline, failure categories, and identified process improvements so the learning can guide a simpler solution or a later attempt.

Leave the workshop with a testable proposal

The best output from an automation assessment is not a long catalogue of possibilities. It is a short proposal with a defined task, representative inputs, a baseline, a reviewable output, an owner, and a decision the pilot will answer.

For the supplier-request example, the next step might be to evaluate draft extraction and account matching on a bounded sample while keeping submission manual. That scope can reveal whether the interpretation work is tractable and whether staff can review it efficiently.

If the evidence shows that a better intake form solves most of the problem, make that improvement. If AI assistance reduces total effort with manageable exceptions, expand deliberately into the next useful boundary.

Choose the process where you can explain both how success will be measured and what happens when the system is wrong. That combination gives the business a practical path from a promising idea to a maintained operational capability.

---