## TL;DR
Bad handoffs make every shift start from zero, so write the handoff as three lists: what is on fire, what to watch, and what was promised to whom. Keep it under ten lines so the next shift actually reads it. The handoff is a baton, not a diary, and the test is whether the incoming shift can act without asking a single clarifying question.

## The query

```text
shift handoff template for 24/7 support teams
```

## Use this when

- The incoming shift re-asks questions the outgoing shift already answered
- Follow-the-sun coverage keeps dropping context between regions
- Handoffs live in chat scrollback nobody reads
- Customers get asked for the same info twice across shifts

## Not for

- Incident postmortems and root-cause reviews
- On-call paging and escalation chains
- Internal standups and status meetings
- Shift scheduling and coverage planning

## Steps

### 1. List open fires first, with the current state

Each fire gets one line: what it is, where it stands, and the next action. "Outage on [service], workaround holding, engineering ETA 2am" beats a paragraph.

Expected output: the incoming shift knows what needs them in the first minute.

### 2. List watch items with tripwires

Things that are quiet now but might blow up: "Ticket [id], customer calm but workaround expires Friday." The tripwire tells the next shift when to act.

Expected output: no surprise escalations that the last shift saw coming.

### 3. List promises with names and times

Every commitment the last shift made: who was promised what, and by when. Promises are what customers remember across shifts.

Expected output: zero missed callbacks because "I didnt know you promised that."

### 4. Keep the whole thing under ten lines

If it is longer, it wont be read at 2am. Link to tickets instead of summarizing them.

Expected output: a handoff the incoming shift reads in full, every time.

### 5. Post it in the same place, every shift

One channel, one thread format, no exceptions. Hunt-the-handoff defeats the purpose.

Expected output: anyone can find any shift's handoff in under ten seconds.

## Ready-to-use template

```text
HANDOFF [date] [shift] to [shift]

FIRES:
- [issue]: [current state], next: [action]
- [issue]: [current state], next: [action]

WATCH:
- Ticket [id]: [why it might blow up], act if [tripwire]

PROMISES:
- [customer name]: [what was promised] by [time]
- [customer name]: [what was promised] by [time]

NOTES: [anything else, one line max]
```

## Variant phrasings

### support shift handover template

Fires, watch, promises. Same three lists, whatever you call them.

### follow the sun handoff best practices

Same place every shift matters most across time zones. The format travels, the channel has to be fixed.

### how to do shift handoffs in customer support

Under ten lines, promises named explicitly. The promise list is the part teams skip and regret.

## Why it happens

Handoffs fail because the outgoing shift writes what they did, a diary, while the incoming shift needs what to do, a baton. Tired people at shift change default to summarizing their day. The three-list format forces the writer to translate activity into action items for someone else.

## Edge cases

- No fires and no promises: still post the handoff. "All quiet" is information, and the habit matters more than any single note.
- A fire with no owner: the handoff assigns one explicitly. Unowned fires dont survive shift changes.
- Three-plus time zones: the middle shift reads two handoffs. Keep each one tight or the middle shift drowns.
- Sensitive customer situations: keep details in the ticket, put only the promise and the tone warning in the handoff.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_K9BGg1TDKMCwBcv01SSl4w