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.
A worked example, stage by stage
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.
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.