Map the decision, not just the task
Start with the point at which a person or team must decide, approve, prioritise or act. What evidence do they use? What happens when the information is incomplete or contested? Who is affected by an incorrect answer? This shows where AI can assist and where human authority, escalation or a non-automated path must remain.
Locate the friction in the workflow
Useful opportunities often sit where work waits, evidence is re-entered, judgement repeats or context is lost between systems. Describe the current path using real inputs, hand-offs, exceptions and outcomes. A feature list begins with technology; a workflow map begins with the work that needs to become clearer, faster or more reliable.
Rank readiness beside expected value
A valuable idea without usable data, ownership, a legal basis, an integration path or enough change capacity is not automatically the best first pilot. Compare expected value with data quality, access, technical feasibility, user readiness, risk and the ability to measure whether the work has improved. This avoids selecting an impressive demonstration that cannot be operated.
Design adoption into the pilot
Feedback, exception handling, support and escalation are product requirements. A controlled pilot should name the users, the decision it supports, the inputs it uses, the limitation of the output and who acts when it is wrong or unavailable. A demonstration can skip these conditions; operational use cannot.
Leave with an accountable next step
The output of this exercise should be a prioritised route: the first use case, its owner, a small set of acceptance criteria, required safeguards and a decision point. That may lead to a pilot, prerequisite work or a reason not to proceed yet. A decision is useful when it changes what the organisation does next.
Observe the work before changing it
A workflow map is stronger when it is built from a real example rather than a workshop description alone. Follow one request or case from trigger to outcome. Note what enters the process, the systems opened, the points where somebody waits, the judgement that is repeated, the information that is copied and the exception that changes the route. Ask the people doing the work what they do when the normal path fails. Their answer often reveals the actual control or support function that a feature list would miss. The aim is not surveillance; it is to understand the operating conditions of a better product decision.
Choose a measurable change, not a vague ambition
A first pilot should improve a named part of the work: for example, make a known classification step clearer, reduce a defined re-entry of information, give a reviewer better context or route a repeatable exception to the right owner. The measure need not be a large financial claim. It can be evidence that the workflow completed, that a human reviewer had the information needed, that an exception was recognised or that a user could complete a task without an informal workaround. Establish the current state before the pilot so a later comparison is possible.
Separate data readiness from model enthusiasm
A useful workflow may still be a poor first AI use case if its inputs are inconsistent, unavailable, unauthorised or impossible to explain. Consider the source, quality, freshness, permissions, retention and sensitivity of the information before selecting a model or provider. Decide what happens when the system does not have enough context. In some cases the practical first step is a data or process improvement, a structured form, a clear ownership rule or an integration assessment. That is progress if it makes a later AI decision safer and more useful; it is not a failure to adopt AI.
Design the hand-off as carefully as the output
An assisted workflow must say what a person receives when the system cannot continue, when an output is uncertain or when the consequence of error is too high for automation. A hand-off is not merely an escalation email. It needs an owner, enough context to act, a visible status and a way to correct or challenge what happened. Build this into the pilot acceptance criteria. If the human path is slower, unclear or unable to see the relevant context, the system can create a new queue rather than resolve the existing bottleneck.
Close the loop with the people doing the work
A pilot should create a structured route for users to identify missing context, correct an output, explain an exception and show where the new workflow moves friction rather than removes it. Review that feedback with the product owner and delivery team at an agreed cadence. Separate usability issues, data problems, policy questions and model behaviour so each has an appropriate owner. The purpose is not to collect a large volume of comments; it is to learn whether the workflow is becoming more dependable and whether the organisation has the capacity to operate it. That evidence should shape the next investment decision.