A support handover is not simply forwarding a list of open tickets at the end of a shift. It transfers unfinished work with enough context for a decision: who owns the next step, what the customer asked, what the team has already done, what is due, and when the next update should happen. The departing teammate records the current state; the arriving teammate confirms ownership of important exceptions. A shared inbox makes this easier, but does not replace the operating agreement.

Quick answerBefore leaving, review every open queue, record the current state and next action, highlight deadlines and risks, assign an available owner for the next shift, and get explicit acceptance for critical cases. After the change, check for unowned work, missed commitments, and duplicate replies.

Keep one working record, not a new story on every shift

Start with a common view of open conversations across messaging, social, email, and website chat. A customer may use more than one channel, but do not merge two identities merely because their details look similar. Each case needs a stable reference, the reply channel, a factual summary, relevant prior messages, current state, deadline, and next action. If something is unclear, mark it as uncertain. A guess made during a rushed handover is not a verified customer fact.

A useful summary answers “where did we stop?” in a few lines: request, last human response, decision already communicated, dependency, and owner. Keep it in the controlled conversation record rather than copying sensitive details into a personal spreadsheet or group chat. Intercom’s official guide describes internal notes for bringing colleagues into a conversation without sending those notes to the customer. Zendesk’s documentation describes assigning a ticket to a group or an agent. Those are vendor-specific mechanisms, not a substitute for defining your own handover rule.

Do not leave the work in a departing agent’s personal queue. If they will be unavailable, route it to the correct team or an available new owner. A group assignment does not necessarily mean an individual has accepted the case. Our guide to conversation ownership explains why that distinction matters.

Make the transfer a two-step process: prepare, then accept

During preparation, the outgoing shift separates urgent or time-sensitive cases from routine work, updates states, and flags anything that cannot wait for ordinary triage. During acceptance, the incoming shift names who will take the next action and when. If no one is available, leave the case visibly awaiting assignment and escalate to a manager. Putting an absent colleague’s name on it just to empty the queue creates false confidence.

Use a short live handover for high-impact cases even if routine items move asynchronously. Read the record together, confirm what the customer was told, and register the transfer. When another department must perform a task, distinguish the person accountable for customer communication from the person completing the internal work. The first role must not disappear while the second team investigates. Intercom’s assignment documentation distinguishes team and teammate assignments in its product. That is a useful reminder to test your own tool’s behavior rather than assuming that moving a case into a team inbox finishes the handover.

Protect commitments and the customer’s experience

Prioritize promised callbacks, incidents, sensitive complaints, and cases waiting on a third party. A promise still needs a next update even when the final answer is not ready. A shift change does not restart the clock. If the arriving team cannot meet a commitment, correct the expectation with a human message, record the reason, and make a new realistic commitment. Our promised follow-up guide shows how to keep that work visible without duplicate reminders.

Before replying, the new owner checks the latest outbound message, internal note, and case state. That avoids two agents answering the same conversation with conflicting information. If the customer switched channels, confirm where they expect the response. The customer does not need a detailed explanation of your staffing plan; they do need continuity. If you introduce a new agent, say what they already understand and what happens next instead of asking the customer to repeat information the team already holds.

Give high-risk exceptions a separate route with a named supervisor, review time, and escalation threshold. Do not label everything urgent, and do not promise after-hours coverage that does not exist. The escalation rules guide can help distinguish severity from ordinary queue age.

Turn the checklist into a verifiable routine

Allow time before departure to update the queue and some overlap to confirm critical cases. The right duration depends on volume, channels, and staffing; there is no universal number of minutes. A small team can use a simple board if it is the controlled, current source of truth. A larger operation may segment work by team, location, or language, but should still have a consolidated view of promises and unowned cases.

Each week, review a sample of actual handovers. Was the case accepted? Was the context sufficient? Did the first action happen on time? Was the customer kept informed? Were there conflicting replies? Count unowned cases after the shift and missed commitments, but read examples before declaring the process improved. For the remaining queue, use the backlog prioritization guide to weigh age, risk, and the value of the next action.

Shift handover checklist
  • Open work reviewed across supported channels
  • Factual summary and latest reply visible in each case
  • Next action, deadline, and customer commitment preserved
  • Customer communicator and internal executor identified
  • Critical cases accepted by the incoming owner
  • Unowned work escalated rather than hidden
  • Duplicate replies and channel changes checked
  • First review of the new shift recorded

Official sources consulted