How to Write a Handoff That Does Not Come Back

Why this matters

You handed off six things last quarter and you are busier than you were before. That is not a sign you delegated the wrong tasks. It is a sign the handoffs were written to describe the work rather than to survive the first case the work did not anticipate, so each one comes back to you a few times a week wearing a question mark. Six tasks returning twice a week each is twelve interruptions a week you created for yourself, and every one of them arrives at the worst possible moment because you are on a call.

A handoff that does not come back is a specific artifact with specific parts. Writing it takes about an hour per task. That is the whole cost, and it is the highest-return hour on an owner's calendar.

Step 1: Log the boomerangs for two weeks before you rewrite anything

Do not start by rewriting the handoff you feel worst about. Start by finding out what is actually coming back and why, because owners consistently misdiagnose this: it feels like a people problem and it is almost always a specification problem.

For ten working days, every time a delegated task returns to you, write one line: the task, what they needed, and how long it took you. Nothing else. Ten seconds a line.

Then sort every line into exactly one of three causes. If a line fits two, pick the one that came first in time, because fixing the earlier cause usually eliminates the later one.

Worked log. An owner runs this for two weeks across six delegated tasks and logs 23 returns. Sorted: 12 authority, 6 information, 5 exception. That is an average of about 1.9 returns per task per week, but the average hides the shape - 9 of the 23 came from one task, the weekly schedule build, which alone was returning about 4.5 times a week. The other five tasks together produced 14 returns over two weeks, about 1.4 per task per week. The rewrite priority picks itself, and it is not the task the owner would have guessed.

Step 2: Know the three reasons work comes back

Authority. They knew what to do and were not sure they were allowed to do it. This is the most common cause by a wide margin and the easiest to fix. The tell in your log: the return is a yes/no question, and your answer took under a minute.

Information. They needed something they could not find. A password, a supplier contact, last year's numbers, which customer gets the priority window. The tell: your answer was a fact, not a judgment, and you retrieved it from memory or from a place only you know about.

Exception. The situation was genuinely outside what the handoff covered, and it needed a call. The tell: you had to think. These are the legitimate returns, and a handoff with zero exception returns is usually a task nobody is really running.

The ratio between these three tells you what kind of shop you are running. Heavy on authority means you are the approval gate and the shop is throttled by your phone. Heavy on information means the shop's knowledge lives in your head and nobody can work when you are under a house. Heavy on exception means the handoffs are basically sound and the work is genuinely varied.

Step 3: Write the ceiling as a number, not as an adjective

"Use your judgment on small stuff" produces one of two behaviours and you cannot predict which. A cautious person asks about everything, because nobody wants to be the one who guessed wrong about what small meant. A confident person decides something you consider large, and you find out afterward, and the whole shop watches you react.

State the ceiling as a quantity tied to something the shop already measures. In a service business the cleanest anchor is your own typical ticket: they can approve anything up to about the size of a routine service call without asking, anything up to roughly twice that with a message to you afterward, and anything above that comes to you first. Three tiers, two numbers, and both anchored to a figure everyone in the shop already has a feel for.

Do the same for time. They can hold a customer window open for up to two working days without asking. They can move a scheduled job by up to one day. Beyond that, ask.

Then raise the ceiling on a schedule rather than on request. Review it at the 90-day mark and, if nothing above the ceiling has gone wrong, roughly double the first tier. A ceiling that never moves teaches the person that the ceiling is the point rather than the training wheels.

Step 4: Write the exception path before you need it

Every handoff needs one sentence covering the case you did not write down, and it has to say what to do rather than who to ask. "Come find me" is not an exception path, because the entire problem is that you are not findable when it happens.

A usable exception path has three parts: the default action, the notification, and the deadline for the notification. For scheduling: if the situation is not covered here, protect the customer's promised date, tell me the same day, and we will fix the process afterward. For ordering: if it is not covered, do not order it, hold it for the morning list, and tell the customer we will confirm tomorrow.

The default action is the part people skip, and it is the part that does the work. Pick the default by asking which mistake is cheaper to undo. Protecting a promised date can cost you an overtime hour. Missing one can cost you the customer. So the default protects the date, and you accept the occasional overtime hour as the price of not being the bottleneck.

Step 5: Point at the source, do not summarize it

Every information return in your log is a fact that lived in your head or in a place only you knew. Do not solve this by writing the fact into the handoff sheet, because a copied fact goes stale and then somebody acts on a stale fact and you get a worse problem than an interruption.

Point at where the live version lives: the supplier list is in this record, the priority customers are flagged in the system with this field, the current pricing is on this page. If the live version does not exist anywhere, that is the actual finding, and creating it is worth more than the handoff sheet, because it fixes the problem for every future person holding this task and not just this one.

Step 6: Keep the sheet to one page, structured the same way every time

Four blocks, in this order:

1. The outcome, in one sentence. What good looks like when this is done well, stated as a result rather than an activity.
2. The ceiling. The two numbers from Step 3, plus the time equivalents.
3. The exception path. Default action, who to tell, by when.
4. The sources. Where the live facts live, by location, not by copy.

Steps are notably absent, and that is deliberate for someone already working in your shop. Writing out the steps is what makes a handoff sheet run four pages and get read once. If a task genuinely needs its steps written, that is a separate procedure document with its own life, and the handoff sheet points at it.

Rewriting the handoff that was coming back four times a week

Back to the log. The schedule build produced 9 of 23 returns, about 39% of all returns, from one of six tasks. Sorted by cause: 6 authority, 2 information, 1 exception.

The 6 authority returns were all versions of the same question - can I move this job. The old handoff said "keep the schedule tight and check with me on anything major." The rewrite: you can move any job up to one day without asking, you can move a member's scheduled visit up to one week, and moving a job that already has a confirmed customer window comes to me first.

The 2 information returns were both about which customers get priority in a squeeze. The old handoff did not mention it because the owner had never made it explicit anywhere. The fix was not a line in the sheet, it was flagging the priority customers in the system where they can be seen while the schedule is being built.

The 1 exception return was a genuine one, a customer with a medical situation asking for a window the shop does not normally offer. That return should happen and the rewrite does not try to eliminate it.

Result. Two weeks after the rewrite, the schedule build produced 2 returns, so about 1 per week, down from about 4.5 per week. That is a drop of about 3.5 returns per week, roughly 78% of the original weekly return rate for that task. One of the two remaining returns was an exception, which is the healthy kind. The owner spent about 50 minutes writing the sheet and flagging the customer records.

The return rate, and what healthy looks like

Keep the log running one week a month. It costs a few minutes and it is the only way to notice a handoff slowly reopening.

A reasonable target: under 1 return per task per week within 30 days of the rewrite, and under 1 return per task per month by the 90-day mark for anything reversible and high volume. Judgment-heavy work will sit higher permanently and that is correct.

Watch the mix rather than the count. A task producing 3 returns a month that are all exceptions is in better shape than one producing 1 a month that is always the same authority question, because the second one means a ceiling you wrote is being ignored - usually because the person got burned once and has decided asking is safer than deciding. That is the failure mode worth catching early: the rate looks fine, the sheet looks fine, and the person has quietly gone back to asking permission for one specific thing because of how you reacted the last time they did not.

References

• See related: Delegating a Task: The Clean Handoff
• See related: How to Delegate Without Losing the Thread
• See related: The Owner Bottleneck: When Everything Needs My Approval
• See related: Delegating the Decision, Not Just the Task
• Trade-standard practice for written work instructions and authority limits in small businesses