Most automation pitches start with a task. Most real bottlenecks start with a queue. Before you consider an AI tool, model, or script, spend an hour mapping where work actually sits and where the workflow simply waits. This guide shows how to separate working time from waiting time, how to read the two together, and how to keep the measurement honest.
Two clocks, one workflow
Lean vocabulary gives us two useful clocks. Cycle time is the time required to produce a part or complete a process, as timed by actual measurement. Production lead time (also throughput time) is the time required for a product to move all the way through a process or value stream from start to finish. The Lean Enterprise Institute also notes that processing time is typically a small fraction of production lead time.
That last observation is the whole point. If you only measure the minutes someone spends typing, reviewing, or approving, you may measure a small slice of the elapsed experience. The rest is waiting: for a reply, for a batch window, for the right person to notice a queue.
For an AI automation decision, translate this into plain terms:
- Work minutes — hands-on effort by a person or system in that stage.
- Wait minutes — time the item sits idle before that stage finishes.
- Elapsed — work plus wait for each stage, summed across the workflow.
These are descriptive measures, not economic returns. They tell you where time goes, not what an automation is worth.
Why wait first?
Automating work shortens the work. Removing a wait often removes a handoff, a policy, or a batching habit — changes that can be made without any model at all. If you automate typing into a queue that then sits for two days, you have optimized the small number.
A second reason is oversight. NIST's AI Risk Management Framework appendix on human-AI interaction stresses that human roles in decision making and oversight need to be clearly defined and differentiated, and that human-AI configurations span from fully autonomous to fully manual. Those roles are hard to define if you have not mapped where humans currently intervene — which is usually exactly at the waits between stages, not inside them.
A worked example (hypothetical)
The following numbers are invented for illustration and are not a client result.
| # | Stage | Work min | Wait min | Owner role |
|---|---|---|---|---|
| 1 | Intake form reviewed | 10 | 30 | Coordinator |
| 2 | Details confirmed | 20 | 240 | Specialist |
| 3 | Approval recorded | 5 | 240 | Manager |
Total work is 35 minutes; total wait is 510 minutes; elapsed is 545 minutes. Wait share is about 93.6%. Two stages tie for the largest wait at 240 minutes — worth naming both rather than picking one arbitrarily. Note that the biggest single work block (20 minutes of confirmation) is not where the time goes.
Make the measurement trustworthy
Three habits keep a map from becoming fiction:
- Time by observation, not memory. The Lean Lexicon defines operator cycle time as elements timed by direct observation. Ask what actually happened on the last five items.
- Name the owner role, not a person. Roles survive staff changes and avoid turning the map into a performance review.
- Mark uncertainty. Where estimates are used, write that they are estimates. A number with a caveat is more useful than a confident guess.
NIST's trustworthiness section makes a related point about measurement: accuracy figures should be paired with clearly defined, realistic test sets and details about methodology. The spirit is the same — a number without its conditions is hard to act on.
Where automation might enter
Once waits are visible, you can ask a sharper question at each stage: is the wait caused by an information gap, a capacity gap, or a permission gap? An information gap may suit a drafting assistant. A capacity gap may suit routing or batching. A permission gap is a governance question, not a model question.
NIST also warns that in some human-AI configurations the AI can amplify human biases, while judicious organizing of human-AI teams can produce complementarity. That is an argument for keeping an explicit human checkpoint in the map after automation, with its role written down — who reviews, what they can override, and how often overrides are logged.
Do the mapping in the browser
Handoff's workflow mapper is a private, browser-local tool: exactly three editable stages to start, with add and remove buttons for two to eight stages. Each stage takes a label, work minutes, wait minutes (finite values from 0 to 100,000), and an optional owner role. It computes total work, total wait, elapsed, and wait share, including the zero-total case. Results appear as a proportional stacked bar and an accessible table, and the largest wait is flagged with ties noted. You can export a local Markdown plan that includes your notes and an explicit statement that the numbers are hypothetical. No values are sent to a model or over the network; if you change an input, the export is invalidated until you recalculate.
What this is not
This is a time-flow map, not a business case. It does not estimate savings, payback, or headcount. It will not tell you whether an AI system is appropriate — NIST frames that as a contextual assessment of trustworthiness characteristics, risks, impacts, costs, and benefits, informed by a broad set of interested parties. The map gives you the context for that conversation.
Start with three stages. Time one recent item end to end. Find the wait. Then decide whether automation is even the right answer.
For consulting support on workflow discovery and handoff design, see NovCog.
