Look for repeated friction
Ask teams where work waits, where the same information is copied and which questions recur. Useful candidates often sound ordinary: finding the right policy, preparing a case summary, checking an incoming document or transferring an approved record. Record the current steps before discussing tools. A task that looks slow from the outside may be waiting on a decision that automation cannot remove.
Use five selection questions
Is the task frequent enough for a change to matter? Is the input information available and usable? Can you define a good output? Is there an owner who can review the work and change the process? Can the consequences of failure be managed within a bounded pilot? These questions are a discussion aid, not a formula that proves commercial value. A high-value idea can still be a poor first project if access or ownership is unresolved.
Choose the smallest complete workflow
Small does not mean disconnected. A summary tool should appear where a person needs the summary. An extraction tool should produce information the destination system can actually use. Scope a complete path for one team, document type or enquiry category. Leave room for the exception path, because that is where many demonstrations stop and operational work begins.
Build the baseline before the prototype
Observe how long comparable tasks take, what quality checks are performed and how often work is repeated. Note the distribution as well as the average: a few difficult cases can consume much of the effort. Record how staff judge success. The baseline gives you something meaningful to compare with a pilot, including the time needed to review AI outputs.
An illustrative example: preparing a support case
Imagine a team that reads a long thread and checks two systems before replying. A first scope could gather the case history and prepare a source-linked summary for the agent. It does not need to send customer replies or change account details. Evaluate whether the summary includes the important facts, omits unsupported claims and helps the agent complete the task. This is an example of project selection, not a reported customer result.
Decide what would make you stop
Set the decision criteria in advance. Stop or change direction if the required data cannot be accessed, review takes longer than the current process, quality remains unsuitable or a simpler integration solves the problem. A pilot that reveals a poor fit can still be useful if it prevents a larger investment. Do not keep expanding scope just to make the original idea look successful.
Prepare a one-page brief
Describe the problem, user, input, desired output, existing systems, baseline and important exceptions. Name the process owner and identify the next decision. That brief gives a delivery partner enough context to discuss feasibility and a first stage. It also makes the work easier to explain internally: a specific improvement to a real process, with a way to decide whether it is worthwhile.
Compare your candidate workflows
A discussion aid to adapt to your workflow.
| Selection question | A useful sign |
|---|---|
| Does the task repeat? | The team can show recurring examples and estimate the workload. |
| Can we access the inputs? | Sources, permissions and system owners are identifiable. |
| Can we judge a good result? | A reviewer can explain what is correct and what needs fixing. |
| Is there a process owner? | Someone can change the workflow and support adoption. |
| Can we contain failure? | The first scope has a review path and a way to stop. |
Make it specific
How does this apply to your business?
Bring us the workflow, your current systems and the decision you need to make.
Discuss your project