Short answer
Choose a bounded workflow with visible repetition, usable inputs, and a recoverable failure path.
An AI automation opportunity is credible when the current process happens often enough to matter, the desired output can be reviewed, representative inputs are available, exceptions can be named, and a person or system can remain responsible for consequential actions. Score the workflow before selecting a model or vendor. Estimate frequency, handling time, delay, rework, error cost, data access, integration effort, judgment, privacy, and the effort required to evaluate outputs. If the process is unstable or nobody owns the result, fix that first. If rules already describe the decision completely, normal deterministic automation may be cheaper and easier to operate than generative AI.
01 · When to pay attention
A promising automation candidate leaves observable evidence at each step.
- 01
The workflow begins with a clear event—such as a form, email, ticket, document, database change, or scheduled review—and ends with a named output.
- 02
The team can provide representative examples, including difficult cases and examples of unacceptable output rather than only ideal demonstrations.
- 03
People repeat the work frequently, wait on the same handoff, copy information between systems, or recreate the same draft, classification, or summary.
- 04
A reviewer can judge whether the result is acceptable and the business can define when the system must stop, escalate, or ask for more information.
- 05
The required data can be accessed lawfully and securely, with owners who can approve use, retention, and exposure to third-party services.
- 06
The value does not depend on replacing every human step; a smaller assisted step would still reduce delay, inconsistency, or unnecessary effort.
02 · Working method
Score the workflow across value, feasibility, and operating responsibility.
Use a one-page map. Do not start with model comparisons. A process map exposes whether AI is necessary and where evaluation and human control belong.
Value and recurrence
Record monthly frequency, current handling time, queue delay, rework, avoidable errors, missed opportunities, and the people affected. Use ranges when data is incomplete and mark the source. High volume is not enough: a small recurring task may still be low value, while an infrequent compliance failure may be high consequence and unsuitable for autonomous handling.
Inputs and decisions
List every source, format, permission, decision, and exception. Separate retrieval, extraction, classification, transformation, recommendation, drafting, and action. This prevents a single “AI workflow” label from hiding several systems with different accuracy and control requirements.
Evaluation and failure
Define examples, expected criteria, unacceptable outcomes, confidence or quality signals, and how reviewers correct the system. Decide what happens when a model, API, integration, or source is unavailable. A useful proof includes failure tests and recovery, not only a polished successful path.
Ownership and operation
Name the business owner, technical owner, reviewer, escalation path, access approver, and person responsible for monitoring cost and quality after launch. Include logs, version changes, retention, vendor dependencies, and a manual fallback. Automation without an operator becomes an unmanaged production system.
03 · Comparison
Use the least complex pattern that can meet the workflow requirement.
These patterns can be combined. Begin with the smallest one that produces a useful, testable outcome.
| Pattern | Use when | Primary control |
|---|---|---|
| Process change | The delay comes from unclear ownership, duplicate approval, missing fields, or a step that should be removed. | Clear policy, form, owner, and service expectation. |
| Deterministic automation | Rules and inputs are stable enough to describe exactly, such as routing, validation, calculation, or synchronisation. | Tests, permissions, idempotency, retries, and reconciliation. |
| AI-assisted step | One extraction, classification, summary, search, or draft can be evaluated before it affects the next action. | Representative evaluation set and a named reviewer. |
| Agent workflow | The task requires tools, state, branching, and several bounded decisions that cannot be reduced to one model call. | Tool permissions, checkpoints, traces, budgets, stop conditions, and human approval. |
Practical sequence
Run a two-week opportunity assessment before commissioning a large build.
- 01
Collect candidates
Ask each person to name recurring work, the trigger, current owner, frequency, waiting time, output, exception, and cost of failure. Keep the list broad, but reject ideas described only as “use AI for this department.”
- 02
Map the top workflows
Observe the work and inspect real inputs. Draw the steps, systems, decisions, handoffs, permissions, and failure paths. Measure a representative sample instead of relying only on remembered averages.
- 03
Score and challenge
Score value, recurrence, data readiness, integration effort, evaluation difficulty, risk, owner readiness, and manual fallback. Ask whether a process fix or deterministic automation would deliver most of the value with less operating cost.
- 04
Specify one proof
Choose the smallest slice with a useful output and a real reviewer. Define the baseline, test set, acceptance and rejection criteria, logging, human checkpoint, budget, rollback, and decision date before implementation begins.
Practical boundary
The checklist is complete when the team can reject an automation idea with confidence.
A useful assessment does not produce a backlog where every item becomes an AI project. It should identify process fixes, ordinary integrations, assisted steps, agent candidates, and ideas that should not proceed. My AI Opportunity Audit uses this principle to rank a small set of changes and turn the strongest candidate into a 30-day action plan. The Agentic Brief case study is relevant because it combines user-authorised context with a bounded publishing workflow; it is evidence of one implementation pattern, not proof that the same architecture suits a different company or data responsibility.
Risk and design references
Primary sources for defining oversight and AI-system risk.
MOFU · Choose the delivery model
Once the workflow is mapped, decide who should implement it.
Compare an independent consultant, agency, internal hire, and software vendor in the next guide. If the opportunity is still unclear, the fixed-scope AI Opportunity Audit is the appropriate starting point.
Compare delivery optionsQuestions
Questions teams ask when choosing an AI automation opportunity.
Which business processes are best for AI automation?
Begin with bounded recurring processes that have accessible inputs, a clear output, representative examples, an accountable owner, and a practical review or recovery path. Research, document handling, classification, summarisation, support preparation, reporting, and follow-up may be candidates. Suitability depends on the specific data, decisions, and consequences—not the department name.
How do we calculate AI automation ROI?
Build a range from observed frequency, handling time, queue delay, rework, error cost, implementation, integrations, review time, model and vendor usage, monitoring, maintenance, and expected adoption. Separate time released from cash saved. Run a measured proof before annualising benefits, and record assumptions that could invalidate the estimate.
Should we automate the whole workflow?
Usually not first. Start with the bottleneck or repeated judgment that can be evaluated independently. Keeping the surrounding process and human owner intact reduces integration and change risk. Expand only when the first slice works under real inputs, exceptions, cost, and review conditions.
When is normal automation better than AI?
Use deterministic software when stable rules can describe the required decision, exact output matters, inputs are structured, and exceptions are known. Validation, routing, calculations, synchronisation, and permissions often need ordinary code. AI is useful when language, retrieval, ambiguity, or flexible classification makes fixed rules insufficient.
How much data do we need for a proof of concept?
There is no universal row count. You need enough representative examples to cover normal work, important variations, edge cases, and unacceptable outcomes. Preserve a test set that was not used to tune the system. For rare high-consequence failures, a small dataset may be a reason to narrow the scope or retain human decision-making.
Who should own an AI automation after launch?
Name a business owner for the outcome and policy, a technical owner for reliability and changes, and reviewers for consequential outputs. Also assign access approval, incident escalation, vendor and cost monitoring, and evaluation updates. Ownership should survive the departure of the original builder or consultant.