Every Repeated Manual Handoff Is a Signal

If you want to find the weak points in how a business runs, do not look at the tasks. Look at the seams between them.

A handoff is any moment where work stops being one person's responsibility and becomes another's. Sales to operations. Estimator to scheduler. Field technician to billing. Support to engineering. Each one is a small negotiation, and each repeated one is telling you something.

Why handoffs are where things break

Context does not travel. The person handing off knows things they do not write down — the customer was irritable, the access is round the back, the price was agreed as an exception. Some of this is captured in a form field; most is not. The receiving person makes decisions with less information than the sending person had.

Nobody owns the gap. During a handoff, the item briefly belongs to no one. If it falls, both parties reasonably believe the other had it. This is the mechanism behind almost every "how did nobody follow up on this?" incident.

Waiting is invisible. The time an item spends sitting in a queue between two people does not appear in anyone's workload, so it is never measured. In most processes, waiting is the majority of the total elapsed time.

Information gets retyped. Handoffs frequently involve re-entering the same details into a different system or form, which introduces errors and consumes time. See the hidden cost of re-entering the same information.

Reading the signal

Different handoff symptoms point at different underlying problems. It is worth learning to distinguish them.

The receiving person has to ask questions before they can start. The handoff is missing required information. The fix is structural: define the minimum set of facts required to begin, and make it impossible to hand off without them.

Items sit in the gap for a predictable period. There is no trigger, only a habit. Someone checks a folder when they remember. The fix is a notification or a scheduled pull, not a reminder to try harder.

Work bounces back and forth. The boundary is drawn in the wrong place. Two people are doing overlapping parts of one job. The fix is to move the boundary, not to improve the communication across it.

Everyone copies the same person into everything. That person is functioning as the actual routing system. This works until they are on holiday, and it is invisible on any process diagram.

The handoff happens by email or chat message. There is no record of state. Nobody can answer "where is this?" without reading a thread. The fix is a shared record with a status, however simple.

The same customer is asked the same question twice. The handoff lost information the customer already provided. This is the version customers see, and it costs more than the internal inefficiency does.

Three ways to improve a handoff

In rough order of value:

1. Remove it. The best handoff is one that no longer exists. Can the same person carry the item further? Often the boundary was drawn around a system's permissions or an old org chart rather than around the work. Giving one person access to the next step can eliminate an entire seam.

2. Automate the transfer. If the handoff must exist, the movement of information across it should not be manual. The receiving system should get the data directly. The person on the other side should be notified without anyone remembering to notify them.

3. Standardise what crosses. If it must be manual, define exactly what accompanies the item. A short, required, complete set of fields beats a long optional form every time. The test is whether the receiver can start work without asking anything.

Instrumenting the seams

You cannot improve what you cannot see, and handoffs are unusually easy to instrument because they are discrete events.

For each significant handoff, capture three things: when the item became ready to hand off, when the receiver started it, and how many times it came back. Those three numbers tell you almost everything.

• A long gap between ready and started is a trigger problem.
• A high return rate is a completeness or boundary problem.
• A gap that varies wildly is usually a capacity problem in the receiving team.

You do not need special software for this. A status field with timestamps in the system you already use is enough to start.

An example worth recognising

A residential services company had a persistent complaint that jobs were being scheduled without the right parts. The instinct was to blame the schedulers.

Tracing one job end to end showed something different. The technician who diagnosed the problem recorded the required part in a free-text notes field, because there was no structured field for it. The scheduler read the note, interpreted it, and ordered what they thought was meant. About one in six interpretations was wrong.

Nobody was careless. The handoff had no defined shape, so the information crossing it was lossy by design. Adding a required part-number field — a change of about an hour's work — removed most of the problem. No new system, no automation, no training programme.

That is the typical shape of these fixes. The seams are where the cheapest large improvements live.

Handoffs are not a defect. Specialisation is valuable and boundaries are necessary. But every one of them is a place where the business pays a small tax, and the businesses that run visibly well are usually the ones that have counted their seams and made each crossing deliberate.