How to Document a Handoff So Work Stops Getting Dropped

How do you document a handoff?

Three lines. What gets passed, named as an artifact rather than a status. Who confirms it arrived, named as an individual. And what the receiver does when it shows up incomplete. That third line is the one almost nobody writes, and it is the only one that matters on a bad day.

This is deliberately smaller than a process manual. A twenty-page document nobody opens loses to three lines somebody remembers.

Why do documented processes still drop work?

Because documentation describes steps, and work goes missing at the seams between them. A step has an owner. A seam sits between two people who each did their part correctly, which means it belongs to neither.

Most dropped balls are not carelessness. They are somebody who received something partial, had no sanctioned move available, and sat on it while waiting for clarity that never arrived.

What should get passed at a handoff?

An artifact, not a state. "The job is ready" is an opinion, and two people can hold different versions of it. The signed change order, the confirmed part number, the load number with an appointment time attached: those either arrived or they did not, and both parties can check the same way.

When you cannot name an artifact, that is itself the finding. It usually means the upstream step ends in a judgment that was never written down.

Who should confirm the handoff landed?

A person. Not operations, not the shop, not accounting. A name, or the role one specific individual holds today. Departments are where confirmations go to die, because everyone assumes somebody else acknowledged it.

What should happen when a handoff arrives incomplete?

Pick one and write it down: send it back, proceed and flag it, escalate, or hold. Any of the four is a defensible answer. Having no answer is what converts a small gap into a two-day silence that nobody can account for afterward.

This single line resolves more recurring failures than any other part of the exercise, because incomplete arrivals are the common case, not the edge case.

Why does fixing a step often create a new handoff?

Because a fix aimed at a step relocates the problem to the edge of that step. Quoting was slow, so an approval went in; quoting is faster, and there is now a handoff to the approver that did not exist before. Three of those in a year and the operation has more edges than it started with problems.

Asking what this step must hand the next one, and who confirms it, designs the edge in rather than leaving one behind.

Where should you start?

One handoff. The worst one, which you already suspect. Ten minutes and three lines.

The common discovery is that the third line was never decided by anyone, which is exactly why the same failure keeps recurring in the same spot. Once it is written, the fix is usually smaller than the argument that preceded it.