Task Handoffs Without Drops: Defining What 'Handed Over' Means

Things do not fall inside a step but between steps. The moment one person finishes their part and expects somebody else to continue is when tasks wait, get forgotten or get done twice - almost always because nobody defined what exactly counts as "handed over".

The three kinds of drop

The first is the worst, because nobody notices until the customer calls. The other two surface faster, which makes them cheaper.

What makes a handoff a handoff

Three conditions, all simple: somebody accepted explicitly - not "I sent it to you" but "I've taken it"; the task lives in one place where its owner is visible; and there is a target time for the next step, even an estimate.

Without the first, the sender assumes it is being handled and the recipient assumes somebody will come back to them. Both are relaxed, nobody is working - and that is precisely the scenario called falling between the cracks.

What must travel with the task

• What exactly needs to happen - in a sentence, not a reference to an earlier conversation.
• What has already been done, so it is not repeated.
• What is missing - if something is missing, that is part of the task.
• A deadline, or at least an urgency.
• Who to come back to with questions.
• The link to the customer or order - a link, a number, a name.

The third item is the forgotten one and the biggest cause of delay: a task handed over without needed information bounces back to the sender, and every such round trip adds a day. How this looks at process level is covered in mapping business processes.

Note that this list is fixed rather than varying by task type. Once it is written in one place - even as six lines at the top of the board - it becomes the default, and handoffs start arriving complete without anyone having to mention it each time.

Why personal WhatsApp is the source of the problem

Not because of the tool but because it has no state. A message is read or not, and there is no way to know whether anybody took responsibility. When a task is handed over in an evening message, it gets read on a phone, deferred "to the morning", and disappears under thirty other messages.

What works is one place with a list carrying owners and statuses - a task board, a system, or even a shared spreadsheet. What matters is not the tool but that there is only one, and that every handoff is visible in it. The same one-queue principle appears in multi-channel orders into one queue in the customer context.

How to spot something stuck

By one simple signal: a task that has not moved for more than X days. What X equals depends on the business, but it must be defined - because without a definition, "stuck" is a feeling rather than a state.

The weekly check that works is a list of everything past the threshold, with a person's name beside each line. That list is always short, takes five minutes to review, and surfaces exactly what would have become a complaint next week.

What matters in that review is asking "what is the next step and when" rather than "why is this stuck". The first question produces explanations and defensiveness; the second produces a decision. In practice a large share of stuck tasks move the moment somebody asks about them out loud, simply because they returned to someone's screen.

Handoffs at end of day and during leave

Those two situations produce the most drops. End of day: a task handed over at five in the afternoon to someone who has finished waits with nobody knowing. Leave: the owner is away, and their tasks sit.

The fix for both is the same - an agreed rule in advance. For end of day: anything handed over after a certain hour counts as received the next morning, and that is said explicitly. For leave: before going, go through the list and hand every open task to a named person, rather than "whoever sees it". Both definitions take a minute and prevent most of the drops that happen at exactly those times.

How do you start without changing how everyone works?

Not by announcing a new method. What works is starting with one type of task - usually the one that drops most - and defining the three conditions for it. A fortnight later, once the team sees things stop falling through, extending it to other types no longer reads as bureaucracy.

What matters is that the rule is simple enough to say in one sentence: "a task transfers only when somebody has written that they are taking it". A rule needing a paragraph of explanation will not be applied, and one needing a form certainly will not.

What happens when the handoff is to the customer

This is a case nobody thinks of as a handoff, and it behaves exactly like one: when you are waiting on material from a customer - an approval, a file, a payment - the task has moved to them, and on your side it sits in a waiting state. The problem is that customers cannot see your board.

So treat it like any handoff: say explicitly what is needed, by when, and what happens otherwise. And on your side, keep a list of everything waiting on customers and review it weekly. In many businesses that is the longest list of all, and it is also what explains why projects run longer than planned.

Sources

• How to improve business efficiency
• Israel Tax Authority - information for businesses