When something goes wrong in a business process, the failure is usually located at a boundary rather than inside a step. The work was done; the context around it did not travel.
Each handover drops part of the context
The person completing a step holds information about why choices were made, what was unusual and what was left unresolved.
What passes to the next person is typically the output and a short note, because everything else feels obvious to the person who has just been doing it.
The receiver then makes reasonable decisions on incomplete information, and the error surfaces several steps later where its cause is no longer visible.
Responsibility becomes ambiguous at the boundary
Within a step, ownership is clear. At the transition, both parties can reasonably believe the other is handling an outstanding item.
The problem intensifies where the handover crosses a team boundary, since neither manager sees both sides and each measures only their own portion.
Work that falls into that gap is often discovered by a customer, because nobody internally was looking at the join.
Queues form where the pace differs
Two teams working at different speeds create a backlog at the boundary, and the backlog itself becomes a source of error as items age.
Aged items lose the context that made them clear, and the person who created them may no longer be available to explain.
Measuring how long items wait between steps often reveals more about a process than measuring how long each step takes.
Written handovers work only when they are short
Detailed handover templates are completed thoroughly for a few weeks and then filled in mechanically, which is worse than nothing because the record looks reliable.
Formats that ask for the small number of things that actually vary, particularly exceptions and unresolved items, survive longer in practice.
The test of a handover format is whether the receiving person reads it, and length is the strongest predictor of whether they do.
Fewer transitions beat better transitions
Improving a handover has limits. Removing it does not, and processes redesigned to keep related work with one person often eliminate the failure entirely.
That has a cost in specialisation, since a single person handling more of a sequence needs broader capability and creates a dependency when absent.
The trade is between the efficiency of narrow roles and the reliability of continuous ownership, and the right balance depends on how expensive the errors are.