How to map process handoffs
How to map the handoffs in a process: find every point where work changes hands, record how the receiver is told, and measure the wait. With a live employee offboarding example.
Mapping handoffs means finding every point where work changes hands, recording how the receiving team learns it has work, and measuring how long it waits before they start.
The short version
- Cycle time in most processes is queue time between teams, not work time inside them.
- Every handoff has a trigger mechanism, a wait, and an acceptance condition.
- "They check the shared inbox" is a queue with no owner, not a trigger.
- Count the crossings: too many means the work is split wrong, not drawn wrong.
- Handoffs where being late is expensive should be drawn as decisions, not steps.
Work does not stop inside a step
Measure any operational process end to end and the arithmetic is usually uncomfortable: the work takes hours and the process takes days. The difference is not inefficiency inside the steps. It is the gaps between them: the interval where one team has finished, the next has not started, and nobody currently considers the item theirs. Those intervals are the handoffs, and they are almost never documented because no single team experiences them.
A handoff is not an arrow. It is an event with three properties worth writing down: a trigger mechanism (how the receiver finds out), a wait (how long before they act), and an acceptance condition (what they need in order to start). A crossing drawn as a plain line implies all three are instant and complete, which is exactly the assumption that produces a process everyone believes is fine and a customer who is still waiting.
The example below is employee offboarding, which is handoffs almost end to end: HR to the manager, manager to IT, IT back to HR, then payroll and facilities. It also contains the handoff with the highest cost of being late in the whole HR domain (same-day access revocation), which is why it is drawn as a decision rather than left as a step somebody will get to.
A process that is mostly handoffs
Employee offboarding across HR, manager, IT, payroll and facilities. Watch how often the work changes hands.
The first crossing sets the clock
Notice arrives with HR, splits on voluntary versus involuntary, and the last working day is confirmed by the manager. Every downstream deadline hangs off that date, so the handoff that communicates it is the one worth timing.
The handoff you cannot be late on
"Immediate access cut needed?" routes to same-day revocation. Drawing it as a decision rather than a step is deliberate: it forces someone to answer the question on day one instead of leaving it in a checklist IT will reach on Thursday.
Handoffs that bounce
Handover drafting, project transfer and runbook updates sit with the manager, then a sign-off decision that can send it back. A rejected handoff is a second crossing nobody counted, and it is where offboarding usually overruns.
Three teams on the last day
Exit interview with HR, final pay with payroll, assets with facilities, then remaining access with IT, with an unreturned-asset route back into payroll. Four lanes acting in one day only works if each knows the date, which takes you back to stage one.
The handoffs after the person has gone
Final pay released, records archived to the retention policy. Post-exit steps are the ones most often missing from an offboarding process, because by then nobody is chasing and the person who would have noticed has left.
How it works
Map the process with lanes first
Handoffs are only visible once the flow is split by owner. Put each step in the lane of the role that performs it (in QueryChart that is the Vertical lane column), and the crossings appear on their own without anyone having to look for them.
Mark every line that crosses a lane
Go through them one at a time and list them. A fifteen-step process crossing lanes eight times is normal and worth knowing; the count itself is often the most persuasive number in the whole exercise, because nobody has ever seen it before.
Record how the receiver is told
For each crossing, write the trigger mechanism into the step's comment: a system status change, an assigned ticket, an email, a shared queue, a stand-up. Where the honest answer is "they check", you have found a queue with no owner and a wait nobody is measuring.
Record what the receiver needs to start
The acceptance condition matters as much as the trigger. IT cannot provision without a confirmed date; payroll cannot finalise without the asset position. Handoffs fail as often from incomplete information as from late notification, and the two have different fixes.
Time the wait, even roughly
Ask each receiving team how long an item typically sits before they pick it up. Rough numbers are enough: the point is the shape, and the shape is almost always that one or two crossings hold most of the elapsed time. Put the numbers on the steps.
Fix the mechanism before the process
Most handoff problems are fixed by changing the trigger (a notification instead of a check, a shared queue with a named owner instead of an inbox) rather than by moving work. Redesign the process only when the crossing should not exist at all.
Mistakes to avoid
Handoffs drawn as plain arrows
An unannotated crossing implies instant, complete transfer. That assumption is where the missing days live.
Counting steps instead of crossings
Step count tells you how much work there is. Crossing count tells you how long it will take. They are frequently unrelated.
Optimising inside a lane
Making a team's own steps faster is satisfying and usually changes nothing, because the item spends most of its life between lanes rather than in them.
Assuming the receiver knows
"They'll see it in the system" is a trigger only if someone looks. Ask when they look, and how often.
Map your own handoffs
Open the offboarding example as your own chart, rename the lanes, and annotate each crossing with how the next team is told.
Related guides
Frequently asked questions
What is a process handoff?
The point where responsibility for a piece of work passes from one person, team or system to another. It has three parts worth documenting: how the receiver is notified, what they need in order to start, and how long the item waits before they do. Handoffs matter disproportionately because no single team experiences them: the sender considers the work done and the receiver has not started, so the interval belongs to nobody and is measured by no one.
How do I find handoffs in a process?
Draw the process with a lane per accountable role, then list every connection that crosses a lane boundary. That is the complete set. Doing it any other way (asking people where the delays are, reviewing tickets) finds the crossings that are already causing complaints and misses the ones that are merely slow. In QueryChart the lane assignment is a spreadsheet column, so the crossings can be enumerated directly from the rows.
How many handoffs is too many?
There is no absolute number, but the ratio is telling: if a fifteen-step process crosses lanes ten times, work is changing hands almost every step and the split of responsibility is probably wrong. Look for a lane that could own a contiguous block instead of receiving and returning the same item twice. Reducing crossings usually beats speeding any of them up.
How do I reduce handoff delay?
Change the trigger before you change the process. Most delay comes from the receiver not knowing there is work (a shared inbox nobody owns, a status field nobody watches), and replacing that with a real notification or an assigned queue with a named owner fixes the wait without touching who does what. Redesign the flow only when a crossing should not exist, and give it an owner when it must.
