What is an AI workflow assessment?

How it works

Define the workflow boundary properly

The first discipline is boundary setting. Leaders need to identify one workflow and define where it starts, where it ends and what counts as a case. Without that, the review becomes vague very quickly.

A workflow boundary should include the trigger, the finished state, the owner, the main systems touched and the main case types. It should also say what sits outside scope. For example, "incoming supplier invoices from receipt to approved posting" is a workflow. "Finance admin" is not. "New client onboarding from first accepted proposal to activated account" is a workflow. "Client set up" is not.

Case types matter because many workflows have a quiet standard lane and a noisy exception lane. If those are mixed together, the average picture can mislead. A workflow may look unsuitable for AI because the exceptions dominate everyone's memory, even though the standard cases are highly structured and frequent. The reverse can also happen. The workflow looks orderly on paper, but in practice the exceptions consume most of the time and managerial attention.

Map the workflow as it actually runs

Many teams have a formal process document. What they need here is the real process. That usually requires a mix of methods. Interviews are useful. So is screen sharing. So is short shadowing. Where event data exists, process mining or log analysis can reveal handoffs, bottlenecks, loops and waiting time far more reliably than memory.

The map should show each step, each actor, each decision point, each handoff, each key information input and each review gate. It should also show where work waits, where it returns for rework and where cases diverge into alternative paths. The aim is not to create a pretty diagram. The aim is to expose friction.

Leaders should pay special attention to four points. First, handoffs, because delay, loss of context and duplication often arise here. Second, queue points, because work that sits idle usually signals either unclear ownership or poor sequencing. Third, review steps, because many workflows contain layers of checking that exist because upstream information is weak. Fourth, exception handling, because a workflow can look highly standard until the true variants become visible.

Separate the workflow into task types

AI rarely improves an entire workflow in one move. It usually improves particular task types inside that workflow. That is why the assessment should decompose the work.

Typical task types include extracting fields from documents, classifying requests, matching records, summarising case history, drafting first responses, retrieving policy content, recommending next steps, flagging anomalies, preparing review packs and routing cases to the right queue. Some of these are strong AI candidates. Others remain squarely human.

This task level view helps in two ways. It stops leaders from overpromising broad automation where only a few steps are genuinely suitable. It also reveals where value might come from a relatively small intervention. A workflow can remain mostly human while still improving materially because one badly timed or repetitive task is lifted out or supported.

A useful question is this: which exact pieces of work consume time before a person applies judgement? The more of that preparation burden a workflow contains, the more likely it is to benefit from AI support. Another useful question is this: where does human judgement genuinely add value that should stay central? The more consequential and context dependent the decision, the higher the bar for AI involvement.

Locate friction and describe the real problem

The next step is to translate the map into specific friction statements. "The workflow is slow" is too broad. "Cases wait in queue because incoming information is incomplete and triage rules are unclear" is useful. "Senior reviewers spend time compiling evidence that already exists across four systems" is useful. "Staff draft near identical responses but must search for precedent manually" is useful.

Good friction statements are important because they stop organisations from prescribing AI before the problem is clear. A workflow might be slow because of missing data rather than because staff are reading too much. It might be error prone because of inconsistent templates rather than because decisions are hard. It might have a review bottleneck because approval thresholds are badly set rather than because people need drafting help.

This diagnosis stage should also note what would happen if the organisation did not use AI at all. Sometimes the right answer is a simpler workflow rule, a standard form, better field validation, clearer ownership or a small integration. That does not make the assessment a failure. It means the assessment has done its job honestly.

Test suitability for AI, step by step

A workflow is more likely to suit AI when several conditions are present together. The work is frequent enough to matter. Inputs are mostly digital. Patterns recur often enough for comparison. Quality can be judged with reasonable clarity. Error can be detected and corrected. Exceptions are identifiable. There is enough structure that AI support would fit the operational rhythm rather than confuse it.

Suitability falls when the workflow depends heavily on local context, rare edge cases, face to face interpretation, contested evidence, or legally significant judgement that must be explained case by case. It also falls when the volume is too low to justify the change effort.

This step works best if teams rate each major task inside the workflow rather than applying one blanket judgement to the workflow as a whole. A single workflow may contain one very strong candidate step, one borderline step and one clearly unsuitable step. The assessment should say so plainly.

Reviewability is a key part of suitability. If staff cannot tell when the AI has gone wrong, the task is a weak candidate. If they can review quickly, override safely and learn from exceptions, the fit is stronger.

Check data, access and rights

Once a task or step looks promising, the assessment needs a stricter data view. Where exactly do the inputs come from? Are they complete, current and linked to the case? Are key fields free text or structured? Are documents machine readable? Are there historic examples? Who owns the data? What permissions apply? Can the organisation lawfully use the material in the way proposed?

This is also where privacy and rights screening becomes practical rather than theoretical. If the workflow uses personal data, the team needs to examine legal basis, transparency, minimisation, retention, access and whether a data protection impact assessment is likely to be required. If the workflow informs or makes decisions with legal or similarly significant effects on individuals, meaningful human review becomes critical.

Teams should also check intellectual property and confidentiality. A workflow might appear attractive until leaders realise it depends on sending client, employee or commercially sensitive material into a setting the organisation cannot justify. In many cases the assessment reveals that the workflow is not impossible, but it does require a narrower design or a different technology choice.

Design the human-AI pattern before any build work

The right question is not simply "can AI do this step?" It is "what role should AI play here?" In practice there are several patterns. AI can assist by retrieving, summarising or drafting. It can triage by routing obvious standard cases. It can recommend by producing a ranked view or a proposed next step. It can automate only the lowest risk slice of work. Each pattern carries a different control burden.

The assessment should define who remains responsible, what review is needed, what must be logged, when a case escalates, and what happens if the AI response is unavailable or clearly wrong. It should also be honest about training. A workflow that uses AI well often requires staff to review differently, challenge differently and document differently.

Human oversight is not a token sign off at the end. It must be meaningful. That means the reviewer understands the task, has authority to challenge or override, and is not set up to rubber stamp material at unrealistic speed.

Set the baseline and decide the next move

An AI workflow assessment is incomplete without a baseline. Leaders need a current measure of the workflow before anything changes. Depending on the case, useful measures include cycle time, queue age, first pass accuracy, rework rate, exception rate, escalation rate, staff effort, complaint rate, override rate and service level performance.

The point is not to measure everything. It is to select a small set of indicators that reflect the actual reason the workflow was chosen. A team trying to improve triage should not judge success mainly by a soft satisfaction score. A team trying to reduce risky inconsistency should not judge success only by average handling time.

At the end, the workflow should land in one of four states. Proceed to pilot. Redesign first, then pilot. Fix prerequisites such as data or ownership, then reassess. Or stop, because the workflow is a poor fit right now. The ability to land on each of these states is what makes the assessment worthwhile.