Which processes are ready for AI? A practical audit
Prioritise work that combines operational value with manageable complexity, representative evidence and a safe fallback.
Inventory work, not AI ideas
Look at inbound channels, handoffs, data entry, checks, clarification loops and status communication. Interview people who perform the work. Capture workarounds and spreadsheets as well as the official process. For each candidate, record trigger, outcome, roles, systems, inputs, variants, exceptions and current effort.
Work backwards from a usable result
Ask what the next person or system needs in order to continue. A sales team may not need an “answered lead”; it may need a complete record with sector, need, urgency, consent status and an open question. That result determines what must be extracted, which rules must be checked and how uncertainty should be presented.
Map every system boundary and human decision. Pay attention to email-to-CRM, document-to-ERP and call-note-to-calendar transitions. These are integration opportunities, but they are also responsibility boundaries. A small-looking step becomes higher impact when it changes master data, sends an external message or commits capacity.
Establish a practical baseline
Sample cases across different days and categories. Separate active handling from waiting, and record clarification, rework and common causes of failure. Where system data is unavailable, use labelled estimates from staff rather than presenting assumptions as measurements. The purpose is a traceable starting point against which a pilot can be judged.
Keep value, feasibility and risk separate
| Dimension | Question |
|---|---|
| Value | How often does the case occur, and where do delay or rework arise? |
| Feasibility | Are inputs available and systems connectable? |
| Quality | Can outputs be judged against representative cases? |
| Risk | Who is affected and what would an error cause? |
| Operations | Who owns exceptions, knowledge and monitoring? |
Treat missing lawful data access, uncontrolled write actions or absent ownership as gates—not as small deductions from a score.
Use a portfolio view, not a single magic score
A high-value process with unresolved data access belongs in a discovery track, not at the top of a build queue. A technically easy case with little operational value may still be a useful learning exercise, but should not be represented as a strategic business case. Keep readiness and potential visible side by side so decision-makers can see why one candidate moves first.
Readiness includes people. If the subject-matter team cannot provide cases, review output or maintain knowledge, a critical dependency is missing. Operational AI is not an IT-only delivery because exceptions, acceptance and day-to-day ownership remain embedded in the business.
Test real cases before a polished demo
Build an appropriately governed sample of historical cases. Include routine, incomplete, contradictory and deliberately difficult inputs. Define acceptance before seeing prototype output: field completeness, correct source use, safe action selection or handoff quality may be the relevant measures.
Separate development examples from evaluation
Use one set of cases to design and diagnose the workflow, then hold back another set for comparison. Otherwise the team will gradually tune to familiar examples. For each evaluation case, record the expected result, acceptable variants and critical errors. A stylistic difference is not equivalent to a wrong system action.
Add negative and out-of-scope cases: missing identity, conflicting sources, unsupported requests, unavailable systems and attempted instruction manipulation. The goal is not to force automation to solve everything. It is to demonstrate that the workflow recognises its limits and hands off safely.
Start with a high-learning process whose errors are detectable and whose output an expert can review quickly.
Choose a narrow end-to-end pilot
The pilot may be narrow, but it should include the real data path, rules, integration, logs and human handoff. Its output is not only software: it should produce acceptance criteria, ownership, a test set, known limitations and a go, revise or stop decision.
Define decision gates before delivery begins
Agree what must be true to move from prototype to limited pilot and from pilot to production. Gates can cover source accuracy, required-field capture, safe refusal, tool permissions, incident handling and owner availability. Include a stop or rescope outcome. Ending a weak use case with documented evidence is better than extending it because effort has already been spent.
A lightweight audit workshop
Before the workshop, collect a system sketch and several representative cases. During the session, describe current work without discussing technology first. Agree the result, variants, risks and measures. Only then assign each step to a possible mechanism: deterministic rule, AI interpretation, retrieval, system function or human decision. Record open legal, security and integration questions as explicit work rather than filling them with optimistic assumptions.
The resulting brief should be readable by operations, IT, privacy and management. A process map, a candidate assessment and a page of pilot boundaries are often enough to support the next decision. Detailed architecture is valuable after ownership and access have been confirmed.
Record who will revisit the audit, because volumes, systems, risks and ownership can change before a candidate reaches production.
Related pages
Sources
General information, not legal advice.