How to Repair a Broken Handoff at Work

Begin with a particular item and two named roles. “Our communication is poor” is too broad to investigate. “The person arranging the display cannot use the label cards submitted by the preparation team” identifies a boundary. One person prepares something; another needs it for a different action. You can inspect the material that crosses between them.

Write a simple sentence: “When preparation has produced the agreed label card, it passes the card and its location to display arrangement.” This sentence names the output and the next use. It also exposes a missing requirement. A card without a location might be complete as a piece of writing but incomplete as an input to arranging the display.

Follow a recent item across that boundary. Find the original request, the last usable version, the sending message and the receiver’s first attempt to act. Ask what the receiver could see at that moment. Avoid explaining the problem using information added afterwards. A corrected attachment sent the next morning was unavailable to the person working the previous afternoon.

Check whether the difficulty truly concerns transfer. If the receiving person has a complete, accepted item but cannot start because all available time is already committed, clearer wording will not create that time. The process bottleneck guide helps distinguish missing readiness from a constraint on doing the work.

A handoff can also occur within one person’s work. You may finish drafting on Monday and prepare publication on Thursday. Your later self needs to know which version was agreed, what remains undecided and where the files live. The same questions apply, although another person is not involved.

Keep the first investigation small enough to finish. Choose one kind of item, one receiving role and one transfer point. If you discover a second boundary, note it separately. Otherwise a repair to file transfer can quietly become an attempt to redesign every activity around it, making it difficult to tell which change helped.

Contents · Next chapter

The word “done” is useful only when people know which action it describes. A sender may mean “I uploaded the file”. A receiver may hear “The request has been fulfilled”. Both people can speak sincerely while referring to different events. Replace that single word with a few states whose meanings you can inspect.

These are working definitions for this guide. Agree equivalent language that fits your task. A receiving team may call acceptance “ready for layout”, for example. That can be clearer than a formal label if everyone understands what it requires.

Specify the scope of receipt. “Received the message” is different from “Opened all six attached files”. When only part of a delivery arrived, say which part. A truthful partial acknowledgement is more useful than a complete-looking tick followed by an unexpected request for the missing material.

Acceptance also needs an object. The receiver may accept responsibility for arranging seven display cards while returning five for clarification. It would be misleading to label the twelve-card set simply “accepted”. Identify the seven accepted item numbers and the five exceptions. The set can remain partly accepted while individual items move forward.

Do not turn acceptance into an unlimited promise. It normally means that the stated material is suitable for a defined next step, under the conditions checked. A later discovery may require reopening the item. Preserve the earlier event and add the new finding; do not rewrite the history to suggest that the problem was always known.

A short conversation can reveal whether your current labels work. Ask the sender and receiver separately what “submitted”, “ready” and “closed” mean. Where the answers differ, repair the meaning before adding another status field to the software.

Contents · Previous chapter · Next chapter

The receiver’s next action is the best starting point for deciding what must cross the boundary. Ask them to demonstrate a recent item they could use without clarification. Watch what they open, compare, choose and record. Their practical needs may differ from the fields the sender finds easiest to fill.

For a display card, the receiver may need the agreed wording, the current revision, the intended position and the required orientation. For a reading-resource upload, the receiver may need the final file, its visible title, an agreed destination and confirmation that the links open. The set should follow the actual task; neither example supplies a universal list.

Separate essential conditions from convenient extras. A missing display location prevents placement. A missing comment explaining why the title was chosen may have no effect on placement. Requiring every historical discussion to accompany every card increases the reading burden and can bury the one unresolved decision that matters.

Make each essential condition observable. “High-quality file” is too broad. “The filename and first page show revision 3, which is the revision named in the agreed request” tells the receiver what to compare. The check is still limited: it confirms version agreement, not every possible quality feature of the document.

Agree who may resolve a mismatch. A display arranger might be allowed to correct an obvious spelling error but lack permission to change the agreed wording. Name the decision owner for those cases. Being able to see a problem does not automatically give someone authority to decide it.

Where a requirement is unknown, record it as unknown and give it an owner. Do not replace uncertainty with the sender’s favourite assumption merely to produce a complete form. If the next step can safely proceed without that fact in this ordinary task, state the narrow condition under which proceeding is acceptable.

The receiver should be able to answer three questions after this agreement: what can I accept, what must I pause, and whom do I contact? Write the answers in language that a substitute receiver could understand. Then try them against one ordinary item and one awkward item before treating them as settled.

Contents · Previous chapter · Next chapter

A handoff record should help the receiver begin. It is not a diary of everything the sender did. Give it enough context to identify the correct material and enough precision to expose the unresolved parts. Put the most immediately useful information where a reader will encounter it first.

A practical record can start with the item identifier, its purpose and the requested next action. Add the current file or physical location, the version being transferred and the relevant deadline or sequence. Then state the conditions checked, any exceptions and the person responsible for resolving them. Finish with the receiving acknowledgement when it occurs.

Those entries belong to a fictional example. Adapt the fields to your own task, then remove any that do not change the receiver’s action. The record can be a short message, a row in an existing table or a note attached to the material. A separate application is unnecessary when the current tools already preserve a clear shared record.

Make the item identifier stable even if the file changes. If revision 3 replaces revision 2, the receiver must be able to tell that both refer to C14. Otherwise a correction can look like a new request and produce duplicate work. Preserve a short correction note identifying what changed and what earlier version it supersedes.

A link is useful only when the intended receiver can use it. Check ordinary access through the agreed working arrangement. A sender opening their own file proves little about another person’s access. If you cannot check directly, request confirmation from the receiver before declaring the material available.

Keep the record alongside the work wherever possible. When essential status lives in one private message and the current file lives elsewhere, the next person must reconstruct the handoff from fragments. A concise reference in the shared record is often enough to prevent that reconstruction.

Contents · Previous chapter · Next chapter

“Thanks” is a polite response, but it leaves the status open. The receiver might be acknowledging the message, accepting the work, or promising to inspect it later. Ask for a response suited to the transfer rather than interpreting any reply as proof of acceptance.

For a small file transfer, a useful acknowledgement might be: “I can open C14 revision 2. Its position is B3. I have accepted it for placement; placement is not yet complete.” This response is slightly longer than a tick, but it tells the sender what was checked and what remains to happen.

You do not need an elaborate restatement for every routine item. If a shared table reliably identifies the item, version and entry conditions, the receiver can record the acceptance there. The important point is that the evidence corresponds to the event claimed. An automatic delivery notification establishes something different from a person’s check of the work.

Where a misunderstanding would otherwise persist, ask the receiver to describe the next action in their own words. “Which version will you place, and where?” is more informative than “Do you understand?” The question gives both people an opportunity to discover a mismatch without requiring either to declare themselves confused.

The sender also has work to do during acknowledgement. Read the response for differences. If the receiver names revision 1 when revision 2 was sent, resolve the difference immediately. A response received and then ignored is not a completed check of shared understanding.

HSE describes handover as preparation, an exchange, and incoming staff checking relevant information. HSE: Shift handover.

The source concerns industrial handover and safety-related practice. The example messages in this article are original teaching examples for ordinary work; they are not an approved adaptation for a safety-critical setting.

An acknowledgement should end with a truthful next state. If the material cannot yet be checked, “Received your message; inspection pending” is enough. It preserves uncertainty clearly and allows the sender to decide whether the agreed timing needs attention.

Contents · Previous chapter · Next chapter

When the receiver cannot continue, replace “This is wrong” with an exception that another person can act on. Name the item, the failed receiving condition, the evidence and the next needed decision. For example: “C14 opens, but the file is revision 1 while the request names revision 2. Please provide revision 2 or confirm a changed requirement.”

Give the exception a current owner. In ordinary collaborative work, this is the person who has agreed to obtain the answer or correction. The receiver can retain custody of the item while the sender owns the clarification. Those are different responsibilities. Keeping the item visible prevents each person from assuming that returning a message made it disappear from their work.

Agree what happens while the exception is unresolved. A single card can remain on hold while independent cards move forward. A set that must be used together may need to wait as a whole. Choose according to the task dependency, and record the choice. Do not split a coupled item merely to improve the accepted count.

When a correction arrives, compare it with the exception before accepting it. A newer file is not automatically the right file. It might correct the title but leave the location blank. Retain the original acceptance conditions and check the changed parts against them. If the correction introduces another problem, state that problem explicitly.

Avoid forcing every exception through the sender when another agreed role holds the answer. A missing display position may need the organiser’s decision. The sender can coordinate that decision, but repeatedly rewriting the same card cannot supply information nobody has confirmed. Route the question to the appropriate role within your ordinary arrangements.

Set an agreed point for revisiting an unresolved item. “Waiting for information” without a next check can become indefinite storage. The point can be a meeting, a planned work session or a reasonable response time already agreed by the people involved. It need not be a new performance target.

Close an exception only when its stated condition has been resolved, the resolution has reached the receiver and the item has a truthful new state. “I asked someone” describes an action towards resolution. It does not establish that the receiving person can now continue.

Contents · Previous chapter · Next chapter

The best place to repair a handoff depends on what needs to be clarified. A brief conversation may resolve an ambiguous intention quickly. A written note may preserve the exact revision, item numbers and remaining exceptions. Use the tools already available to the people doing the work, and make the final agreed state easy to find.

If you resolve a problem in conversation, update the shared record afterwards. Otherwise only the participants present at that moment know that the instruction changed. Another receiver may follow the old note correctly and still produce an unwanted result. The repair needs to reach the working record as well as the people involved.

For work passed between different schedules, make the message usable without immediate conversation. State what the receiver may proceed with, what remains on hold and where an unresolved question should go. A missing colleague should not force the next person to invent the intended result merely because the message says “as discussed”.

Check the audience. Posting in a group space does not establish that the responsible receiver has seen or accepted the item. Name the receiving role or agreed person, while keeping the discussion accessible to any relevant substitute. The purpose is to make responsibility findable, not to copy every participant into every message.

Watch for shorthand that changes meaning between people. “Final”, “live”, “approved” and “urgent” can conceal different assumptions. Replace the ambiguous word with the relevant fact: approved wording, current working file, permission to publish, or a particular required sequence. Precision is useful where it changes action.

HSE distinguishes uncertainty about a message from mistakenly believing it has been understood. HSE: Person-to-person communication model.

The model originates in nuclear-plant communication work. We use this narrow distinction to examine ordinary misunderstandings; the model does not certify this guide or its examples. In a paper-display task, a receiver confidently choosing the wrong meaning of “final” still needs a repair, even when nobody reports feeling confused.

After a clarification, ask one practical closing question: “Where will the next person see the agreed instruction?” If the answer is only in someone’s memory, the handoff remains vulnerable to the next change of person or schedule.

Contents · Previous chapter · Next chapter

Willow Reading Room is a fictional community group preparing a small paper exhibition. Nila prepares display cards. Owen arranges them on an exhibition board. The twelve cards have stable identifiers L01 to L12. The agreed transfer requires a readable current file, confirmed wording, a position on the board and the required orientation. Owen accepts usable cards for arrangement; arrangement is complete only when a card has been printed, placed and checked against the position list.

At 09:00, Nila sends a record headed “Twelve cards ready”. It contains twelve item rows and eleven file links. L12 has no file link. Of the eleven links, ten open for Owen; L10 returns an access-denied message. Owen therefore has the twelve-item record, but he has not received twelve usable files.

Inspection of the ten files he can open shows seven that meet all agreed receiving conditions. Three others fail different conditions. The table accounts for each expected card exactly once at 09:10.

The arithmetic is seven plus one plus one plus one plus one plus one: twelve unique cards. The ten opened files comprise the seven acceptable cards and L03, L06 and L08. Adding inaccessible L10 gives eleven supplied links. Adding absent L12 gives the twelve expected item records. These counts describe different things and should not share one “received” total.

At 09:12, Owen records: “I received the twelve-item record. Ten files open. Accepted for arrangement: L01, L02, L04, L05, L07, L09, L11. Five exceptions are listed below; no cards have been placed yet.” He and Nila agree that the seven independent accepted cards can proceed without the other five.

They assign the revision, orientation, access and missing-file repairs to Nila. The board organiser, Asha, must confirm L06’s position; Nila agrees to obtain that decision and update the record. Owen does not guess the position. The organisers also agree that the five held cards will be reconsidered when their conditions are resolved.

This is already a useful repair, although no missing card has yet been fixed. Everyone can distinguish the expected set, supplied material, accepted work and remaining decisions. The original phrase “twelve cards ready” has been replaced by an account that matches what the receiver can use.

Notice what has not been established. The table does not show that Nila is careless, that Owen works slowly, or that a new software system is needed. It shows five observable obstacles at one boundary. The next actions follow those obstacles rather than a general judgement about either person.

Contents · Previous chapter · Next chapter

By 09:30, Nila has supplied the correct revision for L03 and restored Owen’s access to L10. Owen checks both against the receiving conditions and accepts them. L03 and L10 leave the exception set once each. The accepted set now contains nine cards; L06, L08 and L12 remain on hold.

By 09:45, Nila supplies a landscape version of L08 and the missing file for L12. Owen checks both. L08 now meets the agreed orientation and the other conditions. L12 has confirmed wording, revision, position and orientation. Both are accepted. The accepted set reaches eleven cards, with L06 alone still awaiting a confirmed board position.

At 10:00, eight of the accepted cards have been printed, placed and checked: L01, L02, L03, L04, L05, L07, L09 and L11. The three accepted but unfinished cards are L08, L10 and L12. L06 remains unaccepted. No other cards have arrived, and none have been cancelled, removed or counted twice.

The reconciliation is eight completed plus three accepted and unfinished plus one unaccepted: twelve. Cumulative acceptance is eleven, and it includes the eight completed cards. Therefore you must not add eleven accepted to eight completed. Those totals overlap. The table instead uses mutually exclusive present states.

The handoff repair has removed four of the five initial exceptions. It has not completed four extra cards by itself. Owen’s arrangement work is a separate activity, and the case gives no measured work times from which to calculate his capacity. Eleven accepted cards cannot be described as eleven finished display cards.

L06 also remains a real obligation. Nila records that Asha’s location decision is pending and retains the agreed responsibility to obtain it. Owen keeps the item visible as held. If its position is confirmed later, acceptance and completion can be recorded then. Calling the whole set “complete” at 10:00 would hide the remaining work.

The lesson is not that every transfer needs these exact tables. It is that a repair should preserve the identity of the work while its state changes. When the same item can be followed from exception to acceptance to completion, people can see what was recovered and what still needs attention.

Contents · Previous chapter · Next chapter

Choose a measure that answers a useful question about the boundary. If the problem is missing material, count expected items against material actually available. If it is repeated clarification, record which receiving conditions fail and whether the same condition recurs. If it is delayed acknowledgement, record the relevant sending and response times using the same definition each time.

Use a clear denominator. In the Willow case, seven of twelve expected cards met the receiving conditions at the initial inspection. That is about 58.3 per cent. Seven of ten opened files met those conditions, which is 70 per cent. Both calculations are correct, but the second excludes the inaccessible and absent files. It answers a narrower question.

For understanding the whole expected transfer, report seven of twelve and the five exceptions. If you also report the file-inspection result, label it explicitly. A percentage without its population can make a handoff appear healthier simply because unusable items were removed from the denominator.

Avoid turning response speed into the sole goal. An immediate “accepted” response made before checking the file is fast but unreliable. A later truthful response may be more useful. Observe whether people have enough information and a reasonable opportunity to perform the agreed check before judging the elapsed time.

Similarly, count unique items separately from messages or repair attempts. L03 may involve an initial message, a correction message and an acceptance message. It is still one card. More conversation may reflect necessary recovery work; fewer messages may reflect either a clearer transfer or an exception that nobody reported.

Look for unwanted consequences. Did the new record create unnecessary copying? Did a useful conversation disappear because people believed the form replaced it? Did a sender hold completed items until every item in a large set was ready? A transfer can improve on one measure while making the overall task harder.

One repaired case demonstrates that these particular items were handled more clearly. It does not prove that the method will work across every person, task or busy period. Use the small operational change guide when you are ready to examine a change more systematically.

Contents · Previous chapter · Next chapter

A handoff becomes less obvious when work goes to a shared queue. There may be no named individual at the moment of sending. In that arrangement, distinguish arrival in the queue from acceptance by the role responsible for the next step. Agree who monitors incoming work and how someone claims an item before acting on it.

Do not let two people unknowingly accept the same task. A stable item identifier and a visible current owner can prevent duplicate layout or duplicate messages. If two people deliberately work together, record that arrangement and separate their responsibilities. “Shared” should describe a real agreement rather than the absence of one.

A substitute needs the current state, not merely the original request. Suppose Owen leaves after accepting L08 but before placing it. His substitute needs to know that the orientation issue was resolved, which version was accepted and that placement remains unfinished. The original exception alone would send the substitute backwards; the original request alone would hide the earlier correction.

Partial acceptance needs special care when items depend on each other. Seven independent cards can be placed while five wait. Seven pages of a twelve-page booklet may be unsuitable for assembly if pagination depends on the complete set. Ask whether the accepted part has a useful, separable next action. Where it does not, record the set as held while preserving individual inspection results.

When several receivers need the same material for different purposes, acceptance by one does not necessarily establish suitability for the others. A proofreader may need editable text. A printer may need a fixed page size. The sender can use one item identity while documenting the relevant receiving conditions for each boundary.

Occasionally a person accepts an item and then becomes unavailable. Follow the normal local arrangement for reassignment and update the shared record. The replacement receiver should acknowledge the current material and remaining work. Forwarding an old message without the latest state can recreate the original problem during the attempted rescue.

These situations benefit from the broader idea of consolidating what works: preserve a successful method in a form another person can use. The practical test is whether continuity depends on one person’s memory or is supported by an understandable record.

Contents · Previous chapter · Next chapter

A handoff record explains this particular item and its current state. A checklist prompts a few checks that are easy to miss. Work instructions explain how to perform a task. These tools can support each other, but they solve different problems. Choosing among them starts with observing why the receiver cannot continue.

If senders know how to prepare the file but repeatedly forget to check its revision, a short verification prompt may help. The checklist guide explains how to turn an omission-prone moment into observable checks and clear exception actions. The checklist should point to the actual evidence, not invite a general “looks fine” response.

If the sender does not know how to create the required file, a checkbox saying “correct file prepared” supplies no missing knowledge. Use clear work instructions to explain prerequisites, actions, choices and acceptance checks. Then observe whether a person unfamiliar with the task can produce a usable result.

If the file is correct but the receiver does not know what to do next, inspect the handoff itself. The missing element may be the intended use, authority to proceed, location or current ownership. Adding more production instructions would make the document longer without answering the receiver’s immediate question.

Consider an ordinary reading-card task. Instructions can explain how to create the card from the agreed text. A checklist can prompt the sender to compare revision, orientation and position before transfer. The handoff record can identify this card, link its current file, name any exception and capture the receiver’s response.

Keep shared facts in one reliable place where possible. If the required orientation appears in three independent documents, one may be updated while two remain old. Refer to the agreed requirement rather than copying it repeatedly without a maintenance arrangement. When a copy is necessary for use, identify its relationship to the current reference.

Finally, do not add all three tools automatically. For a familiar, occasional task, a clear message and an existing shared record may be enough. Add a supporting tool because you can identify a real difficulty it will address. Retain it only while it helps people produce or transfer usable work.

Contents · Previous chapter · Next chapter

Try this fictional case before reading the next chapter. Cedar Story Circle is preparing six audio-description scripts for a modest community reading display. Sera prepares the scripts; Malik formats them for printed reading stands. The identifiers are R01 to R06. Each item requires agreed wording, a current revision, a named stand position and a file Malik can edit. Formatting is complete only when the finished page is checked and saved in the agreed output folder.

At 14:00, Sera sends one shared-folder link and writes, “Everything is in the folder.” Malik can open the folder and view all six files. R01, R02 and R03 meet every receiving condition. R04 has the correct text and position but is view-only for Malik. R05 is editable and otherwise complete, but its stand position is blank. R06 is editable and complete, but Sera’s message says revision 2 while the file and the agreed request both show revision 3.

Malik replies “Received, thank you” and starts formatting R01. At 14:10, Sera asks whether all six are accepted. Malik has not yet named the exceptions or resolved the revision mismatch. No formatting has been completed. For this exercise, the six scripts can be formatted independently.

Write a better response for Malik. Identify which items can be accepted now, which require clarification and what evidence is needed for each exception. Decide whether opening the folder proves receipt of usable material. Decide whether Malik should accept R06 by assuming that the message contains a typo. State whose agreement is needed to resolve that mismatch.

Then consider the later facts. By 14:25, Malik can edit R04 after Sera fixes the permission. Sera confirms that revision 3 is intended for R06 and corrects the transfer message. Malik checks and accepts both. R05 still has no confirmed stand position. By 14:40, R01 and R02 have completed formatting; R03, R04 and R06 are accepted but unfinished. No other items have entered or left the set.

Reconcile the six items at 14:40 using mutually exclusive present states. Also report cumulative acceptance. Explain why those two reports cannot be added together. Finally, propose one modest change to the next handoff that addresses an observed failure without inventing a larger procedure.

Contents · Previous chapter · Next chapter

A useful first response would be: “I can view all six files. R01, R02 and R03 meet the agreed conditions and are accepted for formatting. R04 is view-only; please provide the agreed edit access. R05 needs a confirmed stand position. R06 needs confirmation because your message names revision 2 while the file and agreed request show revision 3. Formatting is not yet complete for any item.”

That response preserves what Malik knows and what he does not. Opening a folder proves access to the folder. Viewing all six files establishes view access to those files. Neither proves the edit access needed for formatting. R04 illustrates why the receiving condition must match the next action rather than an easier check.

R06 is a different problem. Its file may be correct, and the message may indeed contain a typo. Malik still needs the contradiction resolved through the person responsible for the transfer, or another person already authorised to confirm the requirement. In this case Sera can confirm the intended revision against the agreed request and correct her message. The exercise gives that confirmation at 14:25; Malik should not invent it at 14:10.

R05 cannot be accepted under the stated conditions until an appropriate decision owner confirms the stand position. Sera can obtain that decision, but filling the blank with an arbitrary position would merely hide the unresolved requirement. The exercise does not supply a later position, so R05 remains an exception.

At 14:40, the six-item reconciliation is two completed items, R01 and R02; three accepted but unfinished items, R03, R04 and R06; and one unaccepted item, R05. Two plus three plus one equals six. Cumulative acceptance is five, comprising the two completed and three unfinished accepted items. Adding five accepted to two completed would count R01 and R02 twice.

A modest next-transfer change could be to verify the receiver’s required access and state the intended revision in one shared record before asking for acceptance. Choose that change because access and contradictory revision information were observed problems. Keep the missing-position exception visible as a separate issue rather than claiming the change will fix every difficulty.

The independent case differs from Willow’s missing-file problem: every file is visible here. The failure is partly about what Malik can do with a file and partly about contradictory instructions. A sound handoff method must respond to those differences instead of applying the same superficial “files present” check everywhere.

Contents · Previous chapter · Next chapter

Take one ordinary item that you expect to pass to another person. Identify what that person will do next. Agree the few conditions that make the item usable, then prepare a short record showing the current material, version, state and unresolved questions. Ask for an acknowledgement that matches the event you need to establish.

If the receiver finds a problem, keep the item visible while it is repaired. Record the failed condition, the person obtaining the correction and the next agreed check. When the correction arrives, confirm that it resolves the condition before changing the item’s state. Continue to distinguish acceptance from completion of the receiving work.

Must every handoff have a form? No. A short message or a row in an existing table can be sufficient. The question is whether the next person can identify the material, understand its condition and know what to do. A form that duplicates reliable information without improving those answers adds maintenance work.

What if the receiver does not respond? Keep the status truthful: sent, with acknowledgement pending. Use the normal agreed contact or reassignment arrangement. Silence does not supply evidence of receipt or acceptance, and repeatedly sending the same unlabelled attachment can create version confusion.

What if the sender believes the item was already checked? Ask which conditions were checked and against which reference. Sender and receiver may be examining different requirements. Agree a proportionate division of checking for the ordinary task, then make the resulting acceptance conditions explicit.

What if the same exception keeps returning? Inspect where the missing or incorrect information first enters the work. Repairing the transfer may contain the immediate problem while a separate upstream issue remains. Use the wider operational recovery hub to choose the next investigation.

The broader Recovery and Transformation guide places this work within a larger recovery path. The Rebuild guide helps you think about making a useful repair sustainable. For this next handoff, the immediate outcome is concrete: the receiving person has usable work, the remaining exceptions have owners, and the recorded state matches what has actually happened.

Contents · Previous chapter · Return to recovery and transformation