An automatable workflow becomes visible when an interview reconstructs one real case, not when a manager describes an ideal future. The interviewer should leave with a trigger, inputs, decisions, exceptions, permissions, evidence, and an accepted end state. The following twelve questions are designed to produce that record. Ask them of the person who performs the work, and require an observable example whenever an answer sounds abstract.
Reconstruct how the work actually moves
Use a recent difficult request rather than a perfect case. Put the original message, file, or record on the table and follow it in order. The first group establishes the basic path.
- Question one: What observable event starts this work, and who notices it first?
- Question two: Which inputs are available at that moment, and which usually arrive later?
- Question three: What accepted state proves the work is complete rather than merely passed onward?
- Question four: Where does the case wait, change systems, or require information to be copied?
These answers produce a sequence, but not yet an automation boundary. Deployment choices can change cost and control even for the same sequence. The local deployment economics article helps the interviewer ask which operating assumptions belong in the record before a platform choice is treated as neutral.
Expose judgment, exceptions and authority
The middle of a workflow is where a simple diagram usually fails. Ask the operator to show what changed the path of the selected case and who was allowed to make that change.
- Question five: Which judgment determines the next step, and what evidence supports it?
- Question six: Which recent exception broke the normal path, and how was it resolved?
- Question seven: What correction or rework occurs repeatedly, and who detects it?
- Question eight: Which actions may a system propose, which require approval, and which remain prohibited?
Do not convert familiarity into authority. A person may know where a case should go without being permitted to disclose data or approve the action. A security case is useful because it makes permissions and retained evidence concrete; the medical data security case study shows why access and audit questions belong inside workflow discovery rather than after a build.
Turn the interview into a test decision
The final questions determine whether the workflow can support a bounded experiment and how that experiment will be judged.
- Question nine: How often does this event occur under normal conditions?
- Question ten: What evidence must be retained so another reviewer can reconstruct the outcome?
- Question eleven: Who accepts or rejects the result and owns the remaining operational risk?
- Question twelve: What finding would make the team narrow, pause, or reject automation?
Now draw the process from the answers. Mark the trigger, every handoff, decision, exception, permission boundary, reviewer, and accepted state. Separate facts shown by the case from assumptions that still need testing. The payback-period guide helps connect the proposed output to an accepted business state instead of stopping at a feature description.
Run the interview with the case materials visible and capture answers in the same order as the work. Avoid voting on solutions during the conversation. When two participants disagree, preserve both accounts and assign a follow-up check against the record. The disagreement may reveal an undocumented branch, a role boundary, or a completion state that different teams interpret differently. Those discoveries are part of the workflow map, not noise to be edited out.
Frequently Asked Questions
The primary respondent should be the person who performs the work. Include the process owner when permissions, acceptance, or risk decisions arise.
A difficult case exposes waiting, judgment, exceptions, corrections, and authority boundaries that an idealized process description often hides.
Record each unknown as an assumption with an owner and a way to verify it. Do not convert missing evidence into a confident process claim.
Produce a process map and interview record showing the trigger, handoffs, decisions, exceptions, permissions, reviewer, accepted state, and stop rule.
A strong interview record can be checked by someone who was not in the meeting. It also permits a useful stop decision when the evidence, owner, or safe boundary is missing. If the team wants these twelve answers challenged and converted into a shortlist, request an AI Opportunity Report.