Editorially revised on 9 October 2026.
Build a handover the receiving person can interpret
Shared work needs a record that survives a change of contributor. A useful handover identifies the current version, the work already performed, unresolved dependencies, the next responsible person and the authority needed for a wider release. A message arriving in someone's inbox does not establish that those fields were understood or accepted.
This guide focuses on the shared handover artifact and the receiving person's interpretation. It uses an original fictional desk-shift exercise. For a separate account of one contributor's role and an accurate interview explanation, use the individual teamwork guide.
Harvard Law's OPIA professionalism guidance discusses clarifying an assignment's audience, expected output, background and deadline, and asking appropriate questions. Its legal-career audience and institutional practices are explicit. The narrow communication principles support the exercise; they do not establish a universal Indian workplace procedure or response-time rule. Harvard Law OPIA professionalism guide.
Agree what the handover is for
In the fictional exercise, Ravi and Meera help maintain a reading-room request desk. Kabir receives the afternoon handover. Coordinator Saira controls room-allocation decisions and the wider circulation of the request note. The helpers can record supplied information and ask questions; they cannot promise a room or change the coordinator's decisions.
The handover's purpose is to let Kabir continue the recorded tasks without treating uncertain requests as confirmed bookings. It contains five invented request IDs and no real visitors, contact details, confidential correspondence or participant information.
At 13:00, the contributors agree to prepare an internal review note for Kabir by 13:30. That is an expressly supplied agreement within the fictional scenario. It is not a recommended universal handover interval or a report of actual work.
Establish a single working version
Ravi maintains the source-status column and Meera assembles the handover note. They agree to label the review copy “Handover v1, 13:20”. The label identifies one supplied copy; it is not evidence that every other copy has been deleted or that a software system enforces version control.
If a correction is needed, keep the earlier interpretation traceable. A contributor should be able to tell which version contained the issue, what changed and who provided the confirming information. Renaming a file “final” does not create approval.
The pair use a two-column record so the next action and its boundary appear together:
| Invented request | Supplied status and next action |
|---|---|
| R1 | Requested room time remains unconfirmed. Kabir should ask Saira for the allocation decision; no booking promise is authorised. |
| R2 | Ravi compared the request details with the supplied record and marked the comparison complete. Saira's release decision is not recorded. |
| R3 | The first note mistakenly described an information request as a confirmed allocation. Meera must correct that wording while retaining the earlier version. |
| R4 | A required field is missing. Kabir should request that field through the agreed coordinator route, rather than inventing a value. |
| R5 | The note contains the supplied cancellation message. Kabir must check Saira's instruction before changing the room-allocation record. |
The record deliberately distinguishes checking details, correcting a note and authorising an allocation. Those actions do not become interchangeable because they concern the same request.
Correct a shared interpretation openly
At 13:20, Meera notices the R3 wording error in v1. The source message asks for room availability; it does not confirm a room. She tells Ravi which sentence needs correction and proposes “availability requested; allocation not confirmed”. Ravi checks that proposed wording against the supplied source message.
In the explicitly supplied continuation, they agree to use the corrected wording in “Handover v2, 13:25”, preserving v1 in the exercise record. The correction does not prove that the requester received an allocation or that no earlier reader misunderstood v1. Neither outcome is supplied.
This is a shared artifact correction rather than an attempt to assign fault or guess a colleague's intention. State what the source says, what the note previously said and what the corrected note now records.
Include ownership and authority in the actual handover
Here is the complete original review handover for Kabir:
Internal desk handover — v2, 13:25. Contributors: Ravi, source-status comparison; Meera, note assembly and R3 wording correction. Intended receiving contributor: Kabir. Agreed review handover: 13:30. R1's room time is unconfirmed; ask Saira for the allocation decision. R2's details were compared with the supplied record; wider release remains unrecorded. R3 now says “availability requested; allocation not confirmed”; preserve v1 as the earlier version. R4 lacks a required field; request it through the agreed coordinator route. R5 includes a cancellation message; obtain Saira's instruction before changing the allocation record. Saira retains allocation and wider-release authority. This is an internal review note, not a booking confirmation.
The artifact names its version, purpose, contributors, receiving person and action boundaries. It also leaves the unresolved states visible. In a real setting, use only the information and sharing route you are authorised to use; do not put actual visitor details into a public practice example.
Ask the receiving person to read back the important fields
An acknowledgement can confirm different things. “Received” confirms a message arrived if that is what the receiver actually says. It does not confirm the R1 allocation, the missing R4 field or permission to circulate the note.
For an explicitly supplied receiving response in the fictional exercise, Kabir writes:
I have received v2 and read the five request entries. I will ask Saira about R1 and R5 and request the R4 field through the coordinator route. I understand that R3 is an availability request, not a confirmed allocation. I have not received a wider-release decision for this note.
This response confirms receipt, reading and Kabir's stated understanding and intended next actions. It does not establish that he has already obtained the answers, completed the requests or updated an allocation system. A future intention should remain a future intention in the shared record.
Record the handover result at its actual scope
Ravi and Meera can now record that Kabir acknowledged v2 and identified the unresolved entries. They cannot mark all five requests closed. R1 still needs an allocation decision, R4 still needs a field and R5 still needs an instruction about the cancellation record.
Their contribution is the preparation and correction of a readable internal handover with a supplied receiving response. The exercise supplies no visitor-satisfaction score, booking success rate, time saved or business result. Adding one would weaken the record's accuracy rather than make the handover more complete.
If an authorised later response arrives in a real task, add its source and the action it permits. Do not make the present note imply that the later response was already known when the handover was written.
Handle a missing acknowledgement without guessing why
As a separate author-created variation, suppose the handover message was sent but no receiving response is supplied. The result available to the writer is a sent message and an unresolved receipt or interpretation question. It is not evidence of agreement, refusal, carelessness or completed work.
Use the agreed follow-up route to ask whether the intended copy was received and which action needs clarification. If the timing affects the task, refer to the actual agreed review time and ask for an instruction. Do not invent a fixed number of minutes after which all colleagues must respond.
This variation is separate from Kabir's supplied acknowledgement. Keeping those versions separate makes it possible to discuss uncertainty without rewriting the original exercise's events.
Use a small practice record to improve the artifact
Create a handover from invented IDs, then ask a practice reader to state which version they received, which entries remain unresolved and who can authorise the next actions. Compare their actual response with the fields in the note. If a field was unclear, record the specific revision you made.
That practice may produce a clearer artifact in the exercise; it does not prove a general productivity improvement or certify readiness for confidential workplace systems. Keep the context labelled as independent practice, classroom activity or authorised work, as appropriate.
For written requests and status messages, the separate workplace email guide includes complete original examples. Choose the resource for the task you need to perform, and carry the same distinction between supplied facts, proposed actions and actual acknowledgement into your own handover.