An AI automation opportunity assessment identifies which step is worth improving before choosing a tool. Classifying enquiries, extracting document fields and transferring approved records need different approaches. Use the worked process list to assess inputs, output ownership and what happens when the step fails.
Map the input and output behind the task name
Break a broad activity such as proposal preparation into stages: reading the enquiry, identifying missing information, matching the scope, calculating costs and obtaining approval. Those stages do not necessarily belong in one AI system. Some involve interpreting language; others require exact calculations or a responsible person's decision.
For every candidate, record the trigger, information source, required output and person who uses the result. Distinguish frequent routine work from rare but consequential decisions. If different people perform the same task inconsistently, the next step may be agreeing on a process rather than automating it.
Compare three candidate tasks using the same checks
These tasks are illustrative method-selection examples, not measured time or cost results from a business. Observe each task in the existing process first. Do not turn a task into an automation project while its input or correct output remains undefined.
- Where does the input come from, and which examples will test it?
- How is a correct output recognised, and who uses it?
- What would an incorrect output disrupt?
- Who retains the review and correction work?
| Candidate task | Starting approach to test | First acceptance check |
|---|---|---|
| Route free-text enquiries to the right team | AI category suggestion with colleague review | Uncertain requests are not definitively misrouted |
| Extract an order reference from a document | Suggested field with a source-page reference | A reviewer can check the value against the document |
| Transfer an approved record to another system | Explicit-rule integration | Sending the same record twice does not duplicate it |
Separate decision support from permission to act
A system can summarise a document, flag a missing field or prepare a draft task. Specify which outputs remain suggestions and which become records after an authorised approval. Changing a price or sending a commitment to a customer requires a separate decision.
In an illustrative first project, classify incoming enquiries as a new project, existing-customer support or review needed. A colleague approves the result; the assistant does not independently quote, book or send a customer message. The pilot is bounded to evaluating enquiry classification.
Include review and correction effort in the pilot decision
Include short messages, long explanations, missing information, mixed requests and out-of-scope cases. Define the expected action and review conditions before testing. Misdirecting an urgent support request and correcting a general category label should not automatically carry the same weight.
Record the existing processing time, new workflow time, colleague review, corrections and outstanding work separately. A faster draft is not a demonstrated saving until the complete workload is compared. This guide provides no return-on-investment promise; it explains how to structure the comparison.
When the process owner, maintenance responsibility and fallback route are defined, record a decision to proceed, narrow the scope or try a different method. Check whether the same examples remain relevant when the operation changes.