Start with the work people are already doing

A procedure describes how work is supposed to move. To understand how it does move, take one real item and follow it from arrival to completion. Record each person, system, queue and decision it touches. The item might begin as a form submission and become an email, a spreadsheet row, a ticket and finally an update in an account system. The official process may name only the form and the final update. The middle steps are where people resolve missing information, chase approval and decide which exception applies. This kind of tracing works best with timestamps and artefacts. When did the item enter each state? What did the next person receive? Which information travelled with it, and which had to be looked up again? A process diagram drawn from memory tends to merge several versions of the work into one neat path. The artefacts show the awkward bits. For an AI feature, that path defines the actual task. Automating the documented step while ignoring two manual handoffs can simply move the delay somewhere else. A handoff is more than one person sending work to another. The receiver needs to know what has happened, what remains, and why the item is now theirs. If the system does not carry that state, people rebuild it in a message or conversation. Watch for phrases such as “ready for review”, “waiting on customer”, “needs approval” and “I have checked this part”. These are state labels, even when they exist only in an email subject or a note pasted into a text field. They often indicate that the official application has a status model that is too coarse for the work.

Before adding AI, write those states down. Define the event that moves an item between them and the person allowed to make that move. A model may help classify an incoming item or extract information, but the workflow still needs an explicit transition. Otherwise the output exists without a reliable indication that anybody acted on it. Handoffs also show where context is lost. If each reviewer opens the same source documents and reconstructs the same history, a useful first improvement may be a consolidated work view rather than automated judgement. People leave the official system for a reason. A spreadsheet may support sorting the application cannot do. A private checklist may contain the actual acceptance criteria. A chat channel may be the only place where unusual cases can be discussed quickly. It is easy to dismiss these as bad habits. Some are risky and should be removed, especially when they copy sensitive information into uncontrolled locations. Even then, the workaround tells us what capability is missing. Removing it without replacing that capability pushes the work into a different hidden channel. I look for what the workaround adds:

• a field the main system does not store;
• a view across records that are otherwise separate;
• a temporary state or ownership marker;
• a calculation or comparison;
• a way to ask for judgement on an exception.

Document the job each spreadsheet column performs before deciding which of those fields or calculations belongs in the durable workflow. Some columns can disappear once that job is handled elsewhere. Process documents usually describe the common path. Operational time often goes into the cases that do not fit it: missing identifiers, duplicate requests, conflicting records, unclear ownership, or an approval that arrives after another action has started. Ask experienced operators for recent examples that needed a workaround or a second opinion. Do not ask only what “usually” happens. For each exception, capture the evidence used to resolve it and the state the item should enter when the evidence is insufficient. An AI classifier should be able to return “uncertain” or “needs more information” when that is the correct operational result. Forcing every input into a category makes the queue look complete while hiding unresolved work. The same applies to extracted fields. A blank confirmed by the source is different from a value the model failed to find. Exception handling needs an owner. If the product routes an uncertain item to a shared queue, specify who monitors it, how priority is set, and what age becomes a problem. Without those rules, items can sit there without anybody being expected to act.

Watching someone click through an application can make the screen sequence look like the process. The durable work is in the records underneath: requests, people, accounts, approvals, documents and events. List the identifier for each record and how records relate. Decide which system owns each fact. If a phone number appears in three places, which one is authoritative? If a request is retried, does it create a new record or another attempt against the same record? These details control whether automation duplicates work or updates the wrong item. For AI-assisted steps, keep the input reference, model output, model or prompt version where relevant, reviewer decision and resulting action connected to the same task. A chat transcript alone is a poor operational record because it does not necessarily show which downstream state changed. This record map also exposes permission questions. A user may be allowed to see a request without being allowed to see every document connected to the person who submitted it. Retrieval and generation must respect those boundaries. After observing the work, choose one slice with a clear start and finish. It might be intake through triage, document receipt through field confirmation, or draft response through approval. Name the input event, the accepted output and the person responsible at the end.

Then run representative items through the proposed version beside the current process. Include the exceptions found during observation. Measure elapsed handling time, corrections and unresolved cases using data the workflow can actually capture. Do not treat a fast model response as the task duration. Keep the old path available while the new slice is being tested if the work is consequential. The aim is to learn whether the proposed system carries the necessary state and evidence, including when it cannot complete the task. Pick one recently completed item and reconstruct its path from system records and messages. Mark where information changed format, ownership moved, or somebody left the official system. Then check each marked point with the people who handled the item before writing the first requirements.