How to Identify an Operational Bottleneck Worth Solving With AI

An operational bottleneck worth solving with AI is not simply a slow task. It is a recurring constraint with a measurable effect on outcomes, a clear enough workflow to assess, and a safe way to handle uncertainty when the system cannot proceed.

Where does operational work usually get stuck?

Work often gets stuck where people, systems and decisions meet. A team may be waiting for information, transferring data between systems, checking inconsistent documents or escalating exceptions without a clear route to resolution.

Common warning signs include:

• Work queues growing faster than teams can clear them.
• Repeated copying and pasting between systems.
• Documents requiring the same checks each time.
• Frequent handovers between teams.
• Delays caused by missing or inconsistent information.
• High volumes of routine enquiries.
• Exceptions that depend on a few experienced people.
• Rework caused by unclear instructions or incomplete inputs.

These are symptoms, not diagnoses. A backlog may appear to be a capacity problem when the actual cause is poor input quality. Repeated manual checks may show that two systems do not share data reliably. Automating the visible task without addressing the underlying constraint can simply move the queue elsewhere.

How do you find the real bottleneck?

Map one workflow from its trigger to its completed outcome. Do not begin with a preferred tool or a broad objective such as “use AI in operations”.

Identify what starts the work, which people and systems are involved, what decisions are made, which exceptions occur and what marks completion. Then find the points where work waits, returns to an earlier stage or needs manual intervention.

A useful workflow map should answer:

• What triggers the workflow?
• What outcome must it produce?
• Which inputs are required, and where do they come from?
• Which systems and teams handle the work?
• What decisions are made at each stage?
• Where do delays, errors or exceptions occur?
• Which actions require human judgement or approval?
• What counts as successful completion?
• What happens when the workflow fails?

Follow a small number of real items through the process instead of relying only on documented procedures. The official process may omit spreadsheets, inboxes, messaging threads and informal approvals that keep work moving. Those workarounds are often where the real bottleneck becomes visible.

What should you measure before considering AI?

Record an operating baseline before changing the workflow. Without one, the team cannot tell whether a new system improved the task or merely changed how the work is done.

Choose measures that reflect both the business outcome and the known constraint.

Operational measures and what each helps establish

Measure	What it helps establish
Work volume	How many cases, documents or requests enter the workflow.
Cycle time	How long work takes from trigger to completion.
Waiting time	Where work sits without progressing.
Error rate	How often an output is incorrect or incomplete.
Rework rate	How often completed work returns for correction.
Exception rate	How much work falls outside the standard path.
Escalation rate	How often another person or team must intervene.
Approval time	How long decisions remain pending.
Completion rate	How much work reaches the required outcome.
Cost per case	What the current process costs to complete.

Use definitions the team can apply consistently. For example, cycle time needs an agreed starting point, finishing point and method for treating paused cases. You do not need every available metric. You need enough evidence to establish whether the bottleneck matters and whether the proposed intervention can be assessed against a clear standard.

What makes a workflow suitable for an initial AI deployment?

A strong initial workflow is narrow enough to evaluate, valuable enough to matter and structured enough to observe. Its inputs, decisions and expected outputs should be understood before a system is built.

A workflow may be suitable when:

• It occurs often enough to justify intervention.
• The desired outcome can be clearly defined.
• Representative inputs are available.
• Quality can be assessed against agreed criteria.
• The current constraint has a measurable operational effect.
• Exceptions can be identified and routed safely.
• Human approval points can be retained where necessary.
• The work can be isolated without redesigning the entire operation.
• Relevant data can be accessed and handled appropriately.
• Failed or uncertain outputs can be detected before they cause unacceptable harm.

Conditions do not need to be perfect. However, unclear ownership, unavailable data or an undefined quality standard should be addressed before the build begins.

When is AI not the right intervention?

AI is not the default answer to every slow or manual process. A simpler intervention may be more reliable, easier to maintain and less costly.

• Process redesign may be better when unclear ownership, unnecessary approval layers or inconsistent procedures cause delays.
• System integration may be more appropriate when employees repeatedly transfer structured information between two systems using stable rules.
• Conventional automation may suit predictable, rules-based tasks where valid inputs and outputs can be specified in advance.
• Better forms, templates or validation may address missing information before it enters the process.
• Training or clearer authority may be necessary when the constraint is organisational rather than technical.

AI should also be deferred when there is no agreed outcome, representative data, way to evaluate quality or safe route for uncertain outputs. In these cases, the first task is to make the workflow measurable and manageable.

What is the difference between a tool-first pilot and workflow-first deployment?

A tool-first pilot begins with a product or model and looks for somewhere to apply it. Success is often judged by whether the tool can produce an impressive demonstration.

A workflow-first deployment begins with a defined operational constraint. The team chooses technology only after understanding the inputs, systems, decisions, risks and outcome the intervention must support.

Comparison of tool-first pilots and workflow-first deployments

Tool-first pilot	Workflow-first deployment
Starts with a product or capability.	Starts with an operational constraint.
Searches for a possible use case.	Defines a specific workflow and outcome.
Tests whether the tool can perform a task.	Tests whether the system improves the workflow.
May rely on selected demonstration inputs.	Uses representative operating inputs.
Treats exceptions as edge cases.	Designs exception handling into the workflow.
Focuses on the initial output.	Includes integration, oversight and ongoing evaluation.

A promising model output is not the same as a dependable operating system. The surrounding workflow determines how inputs are gathered, outputs checked, exceptions handled and changing conditions managed.

How should human oversight and exceptions be designed?

Assign human oversight to specific decisions rather than relying on a vague instruction to “keep a human in the loop”. Define who reviews each output, what they must check, when approval is required and how rejected work returns to the process.

Exception handling needs the same precision. Distinguish between work the system may complete, work it may prepare for approval and work it must escalate without acting.

Ask the following questions before deployment:

• Which decisions may the system make?
• Which outputs require approval before use?
• What level of uncertainty triggers escalation?
• Who owns each type of exception?
• What evidence must accompany an escalation?
• How is a correction recorded?
• When should the system stop processing?
• How will recurring exceptions guide future improvements?

Consider data access and governance at the workflow level, including what information enters the system, where it is processed and who may access it. Requirements under POPIA depend on the context and the applicable processing activities; obtain appropriate legal or privacy advice where needed.

How do you define whether an AI system is reliable for the task?

Define reliability against the actual task, not a general impression of model quality. Evaluation should reflect what a correct, useful and safe output means within the operating workflow.

Possible criteria include:

• Accuracy against an approved reference.
• Completeness of required fields or actions.
• Correct routing of exceptions.
• Consistency across similar cases.
• Appropriate escalation when information is missing.
• Compliance with required approval steps.
• Cycle-time change compared with the baseline.
• Rework or correction rates.
• Performance across representative input types.

Agree acceptance thresholds before judging the build. A system may perform well on common cases yet fail on rare but important exceptions, so the evaluation set should include routine work and known problem cases.

What evidence should you bring to a bottleneck diagnostic?

A productive diagnostic needs evidence about the workflow, not a polished AI brief. Bring enough detail to show how work currently moves and where the constraint appears.

• A plain-language description of the workflow.
• The business outcome it supports.
• Examples of typical inputs and outputs.
• Current process maps or operating procedures.
• Systems used at each stage.
• Work volumes and demand patterns.
• Available cycle-time, error, rework and exception data.
• Common failure modes.
• Approval and escalation rules.
• Data-access and sensitivity constraints.
• The people responsible for the workflow.
• Previous attempts to improve it.
• The smallest useful outcome worth testing.

Remove or protect confidential and personal information before sharing examples unless an appropriate process for handling that data has been agreed. If reliable figures are unavailable, say so. The diagnostic can then identify which baseline measures must be established before evaluating an intervention.

What happens after a suitable workflow is identified?

Once a suitable bottleneck has been selected, define the smallest valuable workflow that can be built and evaluated responsibly.

1. 01Set the scope. Define the trigger, outcome, users, systems and boundaries of the first workflow.
2. 02Confirm the baseline. Record the measures that will show whether the constraint improves.
3. 03Document inputs and outputs. Agree what the system receives, produces and must not do.
4. 04Set evaluation criteria. Establish quality and acceptance thresholds before testing.
5. 05Design approvals and exceptions. Make ownership, escalation and correction routes explicit.
6. 06Test representative work. Investigate weak points before wider use.

If the workflow proves suitable, the focus shifts to dependable operation: monitoring quality, managing changes, reviewing exceptions and keeping accountability clear. If the evidence shows that AI is unsuitable, narrowing, redesigning or stopping the work is a valid outcome.

Is your workflow ready for a diagnostic?

You do not need a complete technical specification. You need a recurring operational problem, a defined outcome and enough evidence to examine where the work gets stuck.

Before starting a diagnostic, check whether you can answer these questions:

• Which workflow is affected?
• What operational outcome should improve?
• Where does the delay, error or rework occur?
• How is the problem measured today?
• Which systems and teams are involved?
• What decisions require human judgement?
• What data and governance constraints apply?
• What would a valuable first result look like?

Incomplete answers are still useful. They show where the diagnostic should begin: with the workflow, systems, constraints and outcome that need closer examination.

Last reviewed: 12 October 2026.

Sources and further reading

• Framework Artificial Intelligence Risk Management Framework (National Institute of Standards and Technology) — guidance on managing AI risks across design, deployment and use.
• Privacy Protection of Personal Information Act resources (Information Regulator South Africa) — official information on POPIA and responsible personal-information processing.