A human handoff is the moment an item leaves one person's desk and waits for the next. Designing it means writing down three things before you touch automation: who owns the item after the handover, what event causes the next person to start, and how long the item sits in between. Without those three, the end-to-end time of a workflow is invisible, and any improvement you make is unmeasurable.

The public workflow mapper at aiautomationconsulting.com.de, called Handoff, does exactly this and nothing more. It is a hands-on desk for mapping one workflow by minutes: you record work minutes and wait minutes per stage, across two to eight stages, and it returns totals, a wait share, the largest wait with ties named, a text table and a downloadable Markdown plan. The page states that nothing is uploaded, nothing is saved, and no AI model stands between you and the arithmetic.

Start from the gap, not the tool

The mapper's own framing is that waiting is where the work hides. Each person in a workflow typically knows their own few minutes; nobody states the end-to-end time. The page illustrates this with a before-and-after invoice example that it explicitly labels as invented to illustrate the idea, not measured, and not a result of any engagement. In that invented example, four stages carry 13 work minutes against 4,780 wait minutes, so waiting is about 99.7% of elapsed time, and the approval stage holds the largest wait by the writer's own notes.

Treat that example as arithmetic, not as a finding. It shows the shape of the problem — a long queue dwarfs a short burst of activity — and it shows why averaging "how long it takes" across staff never surfaces the queue. It tells you nothing about any real invoice process, including yours.

Record work and wait separately, per stage

The core discipline is separation. For each stage write two numbers: minutes a person is actively working on the item, and minutes the item is waiting before the next stage picks it up. The mapper accepts these per stage and computes totals and a wait share. Splitting the two is what makes the largest wait nameable at all; a blended figure hides it.

A hypothetical example, invented here to show the format and not to describe any organisation: a request arrives (0 work / 900 wait), a coordinator triages (5 work / 240 wait), a specialist drafts (40 work / 1,200 wait), a reviewer approves (10 work / 60 wait). The largest wait sits with the specialist queue, so that is the candidate to inspect first. Note the word candidate.

Practical limitations: these numbers come from memory and notes, and memory is poor at waits. The mapper's page makes no correction for that — it takes your entries as given. If you cannot state a wait from a record, mark it unknown in your notes rather than guessing a precise figure you will later defend. A rough, labelled approximation is more honest than false precision.

Name the owner role and the trigger for each handover

The Handoff page's own guidance for making a handoff explicit is to name the owner role and the trigger for each handover. Apply that as a column in your notes, not just a number. For each boundary ask: which role receives the item, and what observable event tells that role to start? A shared mailbox is an owner role; "someone notices" is not a trigger. A status change to "ready for review" is a trigger; "when it comes up" is not.

Two tests help. First, could a new starter identify the owner and trigger from your notes alone without asking anyone? Second, does the trigger happen in a system that records a time? If yes, you have a candidate for measurement later. If no, the handoff depends on human attention, and that is itself worth knowing before you automate anything.

Decide what evidence would count before you change anything

This is the step most handoff projects skip. Before touching the workflow, write down what you would accept as evidence that the handoff changed. Useful, concrete forms include: the wait minutes for the named stage, drawn from the same source you used to baseline it; the count of items whose wait exceeded a stated threshold; the number of items an owner role had to chase. Avoid outcome words like faster, smoother or saved time unless you can point at the number that changed and the period it covers.

The guide Define evidence before building covers turning that evidence into a test you could fail. The distinction matters: the mapper identifies the largest wait as a candidate for a small test, not a measured saving, and its related guide describes choosing a small automation test based on evidence from your own notes. Nothing on that page promises a result.

Do not borrow someone else's numbers

Two adjacent public exhibits show what honest framing looks like, and both are worth reading before you present handoff figures to anyone. The statistics worksheet at 13labs.com.de states plainly that its outputs are illustrative, generated from the numbers you type, not evidence about the real world, and carry no significance claims, p-values or predictions; it also says removing an outlier is a judgment call offered so you can see the effect, not a recommendation. The agent memory reference at aiagentmemory.com.de publishes fixture metrics — for example BM25 mean_recall@k 0.90 on a synthetic corpus of 16 entries — and labels them observed numbers on a tiny fixture, not a benchmark, adding that full JSON output differs between runs and the cause is not yet diagnosed.

Copy that habit into handoff work. Label hypothetical numbers as hypothetical. Separate observed from assumed. Keep one acknowledged unknown visible — in the agent memory case it is run-to-run JSON divergence; in yours it might be the true wait on a stage with no timestamp.

Where this method stops

Mapping one workflow by minutes will not tell you why a queue exists, whether a policy requires it, or what an improvement would cost. It will not produce a benchmark, a rate of return, or evidence about any organisation beyond the notes you supplied. Two to eight stages is a small scope; larger processes need decomposing into mappable pieces first. And the arithmetic is only as good as your waiting estimates.

That is the point of the constraint: a small, owned, number-backed description of a handoff is something you can act on and later test. Use the mapper at the project brief builder stage — record the goal, current workflow, constraints and the evidence you require — then read Scope a small implementation pilot and From a working demo to an operating system to carry one bounded change forward without overclaiming what it achieved.