## TL;DR
Every handoff covers: open critical tickets (with next action and owner), ongoing incidents, expected events (maintenance, new hires starting), and anything weird to watch. Keep it to one page or one chat message. The handoff lives in the same channel every time so nobody hunts for it.

## The error
```text
(Process task; no error.)
```

## Steps
1. List open P1/P2 tickets: ticket number, one-line status, next action, owner. Expected: listed. If it has no next action, it does not belong in the handoff.
2. Note ongoing incidents and their current state. Expected: noted. Link the incident channel or ticket.
3. Note expected events: scheduled maintenance, VIPs traveling, new hire cohorts starting. Expected: listed. Surprises the next shift could have prepared for are handoff failures.
4. Note anything weird: recurring flaky alerts, a system behaving oddly, a user to watch. Expected: captured. The "probably nothing" items are exactly what handoffs are for.
5. Post it in the fixed location (dedicated channel or ticket) at the same time every shift. Expected: consistent. The next shift acknowledges with a reaction or reply.

## When to use
- Every shift change
- Follow-the-sun handoffs

## When not to use
- Incident command handoffs (richer format)
- Async teams (use a living doc instead)

## Compatibility
- Any chat or ITSM; the template is universal

## Variants
### Overlapping shifts
A 15-minute overlap call beats any written handoff for complex days.
### Single-person shifts
Write it anyway; your future self is the next shift.

## Why it happens
Context lives in heads; heads go home. The handoff externalizes the working state so the next shift starts informed instead of archaeology.

## Edge cases
- Keep it short; a handoff nobody reads is decoration. One page maximum.
- Review handoff quality monthly; vague handoffs are a coaching opportunity.

## Provenance

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