If you look at where work goes wrong in a small business, it is very rarely somebody doing their part badly. It is the moment between one person finishing and the next person starting.
The anatomy of a dropped handover
Somebody finishes their part. They assume the next person knows. The next person is waiting to be told. Nothing happens. Days later a customer asks and it surfaces.
Nobody was negligent. The handover was never defined.
What a defined handover has
- A trigger. What specifically means the previous step is done. Not "when it is finished": an observable event.
- A named recipient. A role, not a hope. "Whoever picks it up" is not a handover.
- A notification. The recipient learns about it without checking anything.
- The context attached. Everything they need is with the item, not in someone's head or an email thread.
- An acknowledgement. Something changes state when they take it, so it is visible whether it has been picked up.
- A timeout. If it is not picked up within a defined period, somebody is told.
That last one catches almost everything the others miss.
Context is the usual failure
Even when the handover happens, the recipient frequently gets the item without the history. So they ask, or they guess, or they call the customer and ask them to repeat something they already said.
Whatever was collected earlier should travel with the item automatically. This is one of the strongest arguments for structured intake: an email thread cannot be handed over cleanly; a record can.
Find yours
Map the path a job takes through the business and mark every point where responsibility moves. Then ask, for each: how does the next person find out, and what happens if they do not?
Most businesses have three or four of these and can name the one that fails most often immediately.
Fix the worst one first
Not all of them. One handover made reliable is worth more than a diagram of all of them, and doing one properly usually shows you that the others share a cause.