Why work gets stuck between teams: how to improve business handovers.

The request has been sent. The ticket has been reassigned. Someone has put “with the next team” in the tracker.

From the customer’s perspective, absolutely nothing has happened.

Business handovers are where many otherwise capable operations lose time, information and ownership. If people spend their days chasing colleagues or returning incomplete work, the problem may lie in how teams connect. This article explains what to examine before introducing another coordination meeting.

1. Why sending work is different from progressing it

Passing a shopping list to someone without telling them where the shop is, what the budget is or when dinner starts does not guarantee a successful evening.

You have transferred a document. You may not have transferred an executable task.

A handover needs sufficient information, a clear purpose and an understood next action. Its effectiveness depends on what the recipient can do with it, not simply whether the sender has dispatched it.

This is an interface problem: the output of one process becomes the input to another. If each team defines success independently, the join can fail while both departments report strong performance.

I’d examine whether transfers lead to acceptance and action, rather than treating an email timestamp as evidence of progress.

2. Ask the receiving team what it actually needs

A beautifully completed form can still omit the one fact needed to make a decision. The colour coding rarely compensates.

The receiving team usually discovers that omission after the customer has already waited.

Define the minimum information and quality required for the next stage. That may include a decision already taken, supporting evidence, a customer commitment or an exception requiring attention.

Acceptance criteria should be specific enough to test and proportionate to the work. Requiring every conceivable document creates a different form of delay.

Compare those criteria with the sender’s instructions. If the requirements differ, repeated rejection is predictable. Resolve the mismatch jointly and test the revised handover using typical work and awkward exceptions.

3. Trace the cost of incomplete handovers

One missing detail creates a message. The message creates a reminder. The reminder creates a phone call. Eventually, someone schedules a meeting about communication.

The original missing detail remains surprisingly productive.

John Seddon’s failure demand concept helps explain customer contact generated by an inadequate service. Within the operation, incomplete transfers also generate avoidable correction, clarification and chasing.

Record the reason for returned work and examine how much additional effort follows. Distinguish useful clarification on unusual cases from recurring omissions that better preparation could prevent.

The aim is to find the conditions creating the rework. A rejection count without investigation can encourage departments to argue about fault while preserving the same burden.

4. Make waiting visible between stages

A parcel can spend more time sitting in a depot than travelling towards you. An application can do the office equivalent without ever leaving a laptop.

Processing speed explains only part of the customer’s wait.

Separate touch time from elapsed time. Touch time is effort applied to the work; elapsed time includes waiting for allocation, information, decisions and the next stage.

Follow timestamps across the complete journey and look at the age of unfinished items. A team may process received work promptly while a queue outside its formal measurement grows older.

Agree when responsibility starts and stops. Otherwise, a waiting area can become an unowned gap between two apparently efficient processes.

5. Clarify who handles exceptions and rejected work

When a handover is incomplete, “send it back” may be necessary. Sending it backwards indefinitely is less promising.

A customer should not need an interest in organisational boundaries to receive an answer.

Define who resolves the exception, what information they need and when escalation is appropriate. Make it clear who remains responsible for the customer while the internal issue is investigated.

This is ownership across a dependency. The receiving team need not silently repair everything, and the sending team should not lose visibility as soon as it transfers the case.

A shared exception route can prevent contradictory updates and duplicated effort. Repeated exceptions then become evidence for process improvement rather than a permanent second workflow.

6. Stop preventable defects near their source

If a suitcase is open before it goes onto the conveyor, the best solution is rarely to station someone further along collecting socks.

Correcting the visible mess is necessary. Fixing the clasp prevents another journey becoming a scavenger hunt.

Toyota’s quality-at-source thinking and jidoka principle emphasise recognising abnormalities before defective work continues unchecked. In service work, an intake check or clear acceptance standard can serve a similar purpose.

The response should match the consequences. Contain affected work, explain the issue and establish a correction route without pausing unrelated service unnecessarily.

Measure false rejections and additional checking effort too. A handover control should improve reliable progress, rather than become a new bottleneck that rejects harmless variation.

7. Test the whole journey, not one department’s numbers

A sending team can halve its processing time by passing on unfinished work. The receiving team then needs twice as long to repair it.

There has been a local improvement and a rather unfortunate overall result.

Use balanced measures: complete handovers, returns by reason, waiting time, total completion time and customer impact. Compare similar work and account for changes in demand or complexity.

A small pilot makes it easier to see whether clearer requirements actually improve flow. Include the people using the handover in the review, especially where an apparent saving has created work elsewhere.

The practical test is whether the next team can act and the customer receives the outcome sooner, with the required quality.

8. When handovers need independent review

If several teams agree the process is difficult but disagree about why, another instruction to communicate better may not settle it.

You may need somebody to follow the work across the boundary.

DeaconOps’s Operational Diagnostic examines how work, information and decisions move through the operation. It can identify where handovers create delay and what evidence supports changing them.

Where the problem is already established, Improvement Projects can help redesign the requirements, ownership and controls, then support implementation.

Start a conversation if the operation is spending more time passing work around than completing it. For the ownership dimension, read why accountability breaks down.

Questions about business handovers

Should every handover have a checklist?

Only where a checklist helps people supply essential information reliably. Simple work may need very little; complex or consequential transfers may need more explicit controls.

Who should own work while another team is reviewing it?

Agree that explicitly. Ownership of the customer outcome and responsibility for the next decision may sit with different people, but neither should be ambiguous.

Is a shared inbox enough to improve coordination?

It can provide visibility, but it does not establish acceptance criteria, decision rights or responsibility for exceptions. Those arrangements still need to be designed.

---

About the author

Dean Cain is the founder of DeaconOps, with more than 15 years’ experience across operational delivery, leadership and regulated environments. Read about the DeaconOps approach.