The first AI workflow worth building is the smallest recurring piece of work where a better result matters, evidence already exists, and a named owner can judge the outcome. Do not begin with a department, a model, or a list of possible features. Begin with one recent case and ask where it waited, where judgment entered, what had to be corrected, and what counted as accepted. That produces a workflow candidate that can be tested without pretending the whole business is ready for automation.
Start with a case file, not an idea list
Choose a recurring event such as a qualified request arriving in a service inbox. Pull a small set of completed cases, including at least one awkward exception. For each case, record the original input, time of each handoff, decision made, correction requested, and final accepted state. This is direct workflow evidence. If a detail is unavailable, mark it as an assumption instead of filling the gap with a forecast.
Read the record in chronological order. A promising starting point usually appears where work repeatedly waits for classification, information has to be copied between systems, or a reviewer makes the same bounded judgment. The observation does not prove that AI is the answer. It proves that there is a stable question worth testing. The constraint-first infrastructure analysis is useful here because it demonstrates why the limiting resource should be identified before extra capacity is proposed.
Reject candidates that depend on permissions nobody has granted, data that is not retained, or an outcome nobody owns. Also reject work that occurs too rarely to produce useful test cases. A fashionable task with no reconstructable history is weaker than an ordinary task with a clear event, an observable delay, and an operator who can explain why a result was accepted.
Pass each candidate through four gates
- Consequence: name the operational effect of the current friction, such as a delayed response or an avoidable correction. Keep money as an explicit hypothesis unless records support it.
- Evidence: confirm that inputs, decisions, exceptions, and accepted outcomes can be reconstructed from real cases.
- Ownership: identify the person who can approve a changed procedure, review uncertain cases, and stop the test.
- Boundary: state what the system may propose, what remains human-approved, and how the team returns to the manual path.
A candidate must pass all four gates. Strong value with weak ownership is not ready. Good data with no accepted-outcome definition is not ready. When deployment choices change cost, privacy, or control, the local AI economics breakdown helps turn those operating conditions into written assumptions instead of treating model access as free.
Write the test before choosing the tool
Turn the leading candidate into a one-page charter. Name the trigger, source, proposed output, reviewer, allowed action, exception path, retained evidence, and rejection condition. In the service-inbox example, the first test might draft a routing recommendation while the operator still makes the decision. The difficult cases stay in scope. Nothing is sent or changed automatically.
Compare each proposed result with the accepted manual result. Record why the reviewer accepted, corrected, or rejected it. The decision is not whether the demonstration looked fluent. It is whether the workflow definition survived contact with normal cases and exceptions without creating a second hidden queue. The payback-period framing is useful when the team must connect a feature to an observable business state rather than present capability as value.
Frequently Asked Questions
Examine enough candidates to compare real evidence, but advance only the one with a clear consequence, reconstructable cases, an accountable owner, and a reversible boundary.
Keep original inputs, handoff times, decisions, corrections, exceptions, and accepted outcomes from recent cases. Label missing facts as assumptions.
Yes. A test that removes the difficult cases may validate only a demonstration. Keep exceptions visible and return uncertain cases to the named reviewer.
Produce a one-page charter naming the trigger, input, proposed output, reviewer, permissions, exception path, evidence, and explicit rejection condition.
Continue only if the owner can explain the evidence, the boundary is enforceable, and the next test remains reversible. Otherwise narrow the candidate or stop. If the team wants a structured outside review of the shortlist, request an AI Opportunity Report.