Your colleague should inherit the context, not the mystery.

Imagine returning from lunch to a message that says “Please handle the customer we discussed.” You remember two customers and half a conversation. The person who wrote the note is now at an appointment.

A customer support handover should explain the request, the confirmed facts, the last promise, the next action, its due time and the new owner. It is complete when the receiving person can carry out that next action and has accepted responsibility.

Hand over the open promise first

Start with what the customer expects next. “Update due at 16:00 IST” is more useful at the top of a handover than a long account history. Include why the timing matters and which parts are confirmed.

Atlassian's response handbook keeps an explicit owner and recorded observations during incidents. Our everyday support checklist adapts those coordination ideas to a smaller task; it is not an incident-response standard.

Write the smallest note that preserves the work

Use a fixed set of fields

The note below is a fictional workshop example. Keep the original conversation available through an approved link, but do not require the next person to read twenty messages before learning what they must do.

Include what must not be assumed

Record uncertainty explicitly. A proposed date is not a confirmed booking. A refund under review is not a refund issued. If the customer has already sent a document, identify where it is so your colleague does not ask for it again.

Make acceptance a real step

Ask the receiver to read back the next action and timing in their own words. This is especially useful for sensitive, time-bound or unfamiliar work. Correct a misunderstanding before the first owner leaves.

Google's Collaborative Inbox guidance treats reassignment as an explicit change. Match that idea in your own process: update the visible owner instead of leaving two people assuming the other has the job.

Plan for the handover that cannot happen live

Before planned leave, review open work early enough for questions. For an unexpected absence, give a designated colleague access to the shared queue and the ability to identify promises due today. Do not rely on searching a departed person's private messages.

Separate customer-visible notes from internal discussion. Keep permissions current when roles change, and avoid exporting the whole inbox to a personal device just to make a handover easier. The shared-inbox guide covers the basic access routine.

Check whether the note works without its author

Pick an ordinary open request and let a colleague explain what they would do next. If they ask “Which order?” or “Was that approved?”, add the missing fact. Remove old details that obscure the current action.

Use the escalation brief when the next person needs to make a specialist decision. Keep the enquiry tracker current after the handover so a later message does not revive the old ownership. The result should be a usable record, not a larger document nobody reads.