Start with the work people are already doing

A procedure tells you how work is supposed to move. To see how it actually moves, I'd take one real item and follow it from arrival to done, noting every person, system, queue and decision it touches. It might start as a form submission, turn into an email, then a spreadsheet row, then a ticket, and end as an update in an account system, while the official process only mentions the form and the final update. The middle is where people chase missing information, get approvals and work out which exception applies. Timestamps and the actual emails or files help here, since a diagram drawn from memory tends to squash several versions of the work into one neat path.

If you automate the documented step and ignore two manual handoffs, you've probably just moved the delay. Listen for phrases like "ready for review", "waiting on customer" or "needs approval". They're state labels, even when they only live in an email subject, and they usually mean the official system's statuses are too coarse for the work. Before adding AI I'd write those states down, along with what moves an item between them and who's allowed to move it. A model can classify or extract, but if there's no explicit transition, you end up with output and no reliable sign that anyone acted on it.

People leave the official system for a reason. A spreadsheet might sort in a way the application can't, or a private checklist might hold the actual acceptance criteria. Some of these are risky (copying sensitive data somewhere uncontrolled, for example) and should go, but if you remove one without replacing what it did, the work just moves to another hidden channel. So I look at what each workaround adds:

• a field the main system doesn't store
• a view across records that are otherwise separate
• a temporary state or ownership marker
• a calculation or comparison
• a way to get a second opinion on an exception

Exceptions are where a lot of the time goes, so I'd ask experienced operators for recent examples that needed a workaround or a second opinion, not what "usually" happens. A classifier should be able to say "uncertain" or "needs more information" when that's the honest answer. Forcing everything into a category makes the queue look finished while hiding unresolved work. And whatever queue the uncertain items land in needs someone who watches it, a way to set priority and an age at which it becomes a problem.

Then pick one slice with a clear start and finish, like intake through triage or a draft reply through approval, and name the input event, the accepted output and who's responsible at the end. Run real items through it beside the current process, exceptions included, and measure handling time, corrections and unresolved cases (a fast model response isn't the task duration). If the work matters, keep the old path running while you test.

The work people are already doing (the handoffs, the side spreadsheets and the exceptions) is what an AI workflow has to fit, and the documented procedure only covers part of it. If I built from the procedure alone, I'd probably automate one step and leave the delay sitting in the handoffs around it. To start, I'd take one recently finished item and rebuild its path from system records and messages, marking every spot where the information changed format, ownership moved or someone left the official system. Then I'd check each of those with the people who handled it before writing the first requirements.