Make the handoff explicit

Automation rarely fails at the model. It fails at the seam: the moment a ticket leaves one person's desk, enters a tool, and arrives somewhere else. If nobody wrote down that seam, the automated version will not invent it correctly. This guide shows how to make a handoff explicit before you automate anything, and how to record it in a plan you can hand to a colleague.

A handoff here means four things written in one place: what arrives, who or what acts on it, what counts as done, and what happens when it is not done. If any of the four is missing, you have a gap that a script will paper over and a person will later have to unpick.

Start with time, defined plainly

Before you can say where waiting lives, agree on words. The Lean Enterprise Institute defines cycle time as the time required to produce a part or complete a process, as timed by actual measurement. It also separates processing time — the time a product is actually being worked on — from production lead time, the time required to move all the way through the process from start to finish, and notes that processing time is typically a small fraction of lead time.

That gap is the whole point. When you map a workflow, you are not only recording minutes of work. You are recording the minutes in between, where nothing is happening and someone is waiting. The mapping tool on this site asks for two numbers per stage — work minutes and wait minutes — precisely so the second number is visible rather than implied.

Write the four lines for each seam

For every stage in your workflow, draft a short note in this shape. Keep it in plain sentences; it does not need to be formal.

1. Input: what physically arrives, and in what form. "A PDF invoice in the shared inbox" is better than "an invoice".
2. Actor: the named role, not a person's name — for example "accounts clerk" or "the extraction step".
3. Done test: the check that confirms the step finished, such as "three required fields present and totals match".
4. Exception path: what happens when the done test fails, and who is notified.

Line three and four are where most proposals are thinnest. A step that cannot fail is a step nobody has examined.

Separate the decision from the doing

NIST's AI Risk Management Framework, in its appendix on human-AI interaction, makes a distinction worth borrowing: human roles and responsibilities in decision making and in overseeing AI systems need to be clearly defined and differentiated, and human-AI configurations can span from fully autonomous to fully manual. The same source notes that some systems may not require human oversight at all, while others specifically require it.

Applied to a handoff, that gives you a design choice to make on purpose rather than by accident. For each stage, ask: does the automated step decide, or does it prepare a decision for a person? Write the answer down. A prepared decision still needs a destination and a deadline, or it becomes a queue nobody owns.

Check whether the step is fit for the handoff

NIST's trustworthiness chapter is a useful checklist for writing the done test. It lists characteristics including valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, and privacy-enhanced — and warns that addressing them individually will not ensure trustworthiness, since tradeoffs are usually involved and rarely do all characteristics apply in every setting.

In practice, pick the two or three that matter for your seam and write them into the done test. A summary step handing off to a customer-facing reply will care about accuracy and tone. A step handling personal data will care about what may be logged. Deciding which ones apply is a judgement call for the people doing the work, not something the tool can infer.

Keep the record honest and local

A handoff document is only useful if it stays true. Two habits help. First, mark estimates as estimates; a plan full of unlabelled guesses will be read as fact by whoever inherits it. Second, re-derive totals whenever an input changes, so the written plan never carries a number that no longer matches the stages above it.

The mapper at /map/ is built around those habits. It holds two to eight editable stages, computes total work, total wait, elapsed time and wait share, and identifies the largest single wait — flagging ties rather than silently picking one. Everything stays in your browser: there is no network call and no model inference behind the figures. Exporting produces a local Markdown plan that labels its numbers as hypothetical, and the export is invalidated whenever you edit a stage until you run the calculation again.

A short working sequence

Walk the process once with a timer and a notebook. Write the four lines for each seam. Set the done test against the trustworthiness characteristics that actually apply. Then map it, read the largest wait, and ask whether that wait is a queue, a decision, or a missing trigger. Only after that is it worth asking what a model could do — and the answer may well be "carry the item, not make the call".

When you want to go further, the companion pages cover finding the waiting and choosing a small test. NovCog, the publisher of this site, describes its own consulting work at novcog.com.