A task is a stronger candidate for automation when its inputs are available, its output can be checked and its exceptions are manageable. Start with the work itself. A tool that looks impressive in a demonstration may create more checking effort in a real process.
Describe one unit of work
Write the task as an observable action: turn an approved meeting transcript into a draft action list, or classify an incoming support message against an existing category list. Avoid starting with an entire department or a goal such as improving productivity. Define the input, the expected output, the owner and the stopping point.
List the steps a person actually performs. If most time is spent locating missing data or resolving ambiguous ownership, faster text generation may not address the bottleneck. Fixing an input process can be more valuable than automating the final draft.
Use a screening worksheet
| Question | Evidence to collect |
|---|---|
| Does it repeat? | Task count over a representative period |
| Are inputs consistent? | Examples of complete and incomplete inputs |
| Can the result be checked? | A reference answer or explicit acceptance checklist |
| What happens when it fails? | Rework, escalation and potential downstream effects |
| Can a person stay in control? | A named reviewer and an approval point |
These are screening questions, not a numerical safety certification. A high task count does not cancel out a serious inability to verify outputs. Treat unresolved critical issues as reasons to narrow or postpone the experiment.
Compare two candidate tasks
Consider drafting internal meeting summaries and issuing final customer refunds. Both may be repetitive, but their consequences and controls differ. A summary draft can be checked against the transcript before circulation. A refund changes a customer account and needs authorization, reliable records and transactional controls. Begin with a draft or recommendation step rather than assuming that the whole action should be autonomous.
For the summary pilot, define success as correctly capturing agreed decisions, owners and dates without adding invented commitments. Include examples where no decision was made. Otherwise, a model may appear successful merely because every test contains an easy action item.
Set a stop rule before testing
Decide which failures stop the pilot immediately and which can be fixed through review. Record total effort, not only AI generation time. If the reviewer must repeatedly reconstruct the original work, change the scope or stop the experiment. An unsuccessful pilot is still useful if it prevents a larger, poorly justified rollout.
Keep the initial decision reversible. Use sanitized inputs, keep original records and avoid connecting the experiment directly to consequential systems. The goal is to learn whether this specific workflow is useful under clearly defined conditions.