{"slug":"handoff-workflow","meta":{"title":"Handoff Workflow","slug":"handoff-workflow","kind":"topology","summary":"Work crosses a boundary between teams, and the transfer itself is the risky part — so the handoff is an explicit event with a receiver, a checklist and an acceptance.","problem":"Sales closes a deal and operations finds out from a calendar invite. Context lives in the first team's heads and in an email thread the second team cannot see, so the receiving team starts by re-asking the customer questions they already answered.","family":["workflow","coordinate"],"data_shape":["record"],"principles":["orientation","consistency","minimize-distance"],"interaction":["decision"],"density":"low","complexity":"medium","status":"stable","visibility":"public","use_when":["Work passes between teams with different tools, vocabulary or incentives.","Things are routinely dropped or repeated at the boundary.","The receiving team needs context the sending team holds."],"avoid_when":["One team does everything. A stage change is enough.","The boundary is nominal and nobody has ever noticed a problem there."],"alternatives":[{"slug":"linear-workflow","when":"The stages are within one team and no context transfer is needed."},{"slug":"checklist-workflow","when":"The concern is completeness of many items rather than transfer between people."}],"ask_leo":"Model the boundary between these teams as an explicit handoff.\n\n- A handoff is an EVENT on the record, with a sender, a named receiver, a\n  timestamp and a state — offered, accepted, or returned.\n- The receiving team must accept. Until they do, the record is still the\n  sender's responsibility, and that must be visible to both sides.\n- Define what must be present before a handoff can be offered — the fields,\n  files and answers the receiving team always needs — and check them at the\n  moment of handoff, not afterwards.\n- Let the receiver REJECT the handoff with a reason, sending it back to the\n  sender. Rejection is the mechanism that makes the quality bar real.\n- Carry the context across: the whole history, the comments and the documents\n  stay on the record. Never start a new record on the other side of the\n  boundary.\n- Show both teams a view of what is in flight at the boundary — offered but\n  not accepted — because that is where things sit unnoticed.\n- Record how long acceptance takes. That number is the health of the boundary.\n","related":[{"title":"Assign an Owner","url":"/patterns/assign-owner","summary":"Who holds it between handoffs, and who is accountable in the meantime."},{"title":"Stage-Gated Workflow","url":"/patterns/stage-gated-workflow","summary":"The gate mechanism a handoff's readiness checklist is built from."}]},"body":"## The shape\n\n```\n   SALES                    ┃  boundary  ┃                 OPERATIONS\n   ─────                    ┃            ┃                 ──────────\n   Deal won                 ┃            ┃\n      │                     ┃            ┃\n      ├─ readiness check ───▶ OFFERED ───▶  awaiting acceptance (2 days)\n      │   ✓ signed contract ┃            ┃        │\n      │   ✓ site address    ┃            ┃        ├─▶ ACCEPTED — ops now owns it\n      │   ✗ access contact  ┃            ┃        │\n      │      ▲ blocks offer ┃            ┃        └─▶ RETURNED \"no access contact\"\n                                                        ▲ the quality bar, made real\n```\n\nFour properties:\n\n1. **The handoff is an event**, not a status change. It has two parties.\n2. **Acceptance is required.** Between offer and acceptance the sender still\n   owns it — otherwise work falls into the gap and nobody is accountable.\n3. **A readiness check before offering**, so the receiving team's needs are\n   enforced at the boundary rather than complained about after it.\n4. **Rejection with a reason**, which is what gives the readiness check teeth.\n\n## Why it works\n\nHandoffs are where internal processes fail, and they fail for a structural\nreason: **responsibility becomes ambiguous exactly at the moment it moves.** A\nplain status change from \"Sold\" to \"In delivery\" declares a transfer without\nanyone confirming they received it.\n\nRequiring acceptance closes that gap. It also produces the single most useful\nnumber about the boundary — time-to-acceptance — which tells you whether the\nreceiving team is keeping up long before anyone escalates.\n\nRejection is the part teams resist and the part that changes behaviour. A\nreadiness checklist with no consequence gets half-filled. One that can send the\nrecord back, with a reason, visible to both managers, gets filled.\n\n## Carry the context, do not restart\n\nThe most damaging version of a bad handoff is a **new record on the other\nside**. Sales closes an opportunity; operations creates a project; the two are\nlinked by a name typed twice. Everything the customer said is now on the wrong\nside of a wall.\n\nOne record that changes hands keeps the history, the comments and the files\nwhere the next person will look for them. If two systems genuinely must be\ninvolved, the handoff should copy context forward and keep the link, not start\nfrom a blank form.\n\n## Getting it wrong\n\n- **A status change with no receiver**, so nobody actually took it.\n- **No acceptance step**, so the gap between teams is invisible.\n- **Readiness checks with no rejection path**, which makes them advisory and\n  therefore ignored.\n- **A fresh record on the receiving side**, which discards the context that was\n  the entire point.\n- **No visibility of what is in flight**, so items sit at the boundary unnoticed\n  — the classic place work disappears for a week.\n\n## Exemplars\n\n**Sales-to-delivery handoffs** in professional services are where this pattern\npays for itself fastest, because the cost of re-asking a client questions they\nalready answered is immediate and visible to the customer.\n\n**Clinical handovers** in hospitals are the most studied version, and the\nfinding transfers directly: structured handover with explicit acceptance reduces\ndropped information, and the structure matters more than the content of any\nindividual field.\n\n**Support-to-engineering escalation** shows the readiness check working — a\nreproduction, a version, and an account, checked at the boundary, is what stops\nthe ticket bouncing back and forth.\n\nThe extractable rule: **a handoff nobody has to accept is not a handoff, it is\nan announcement.** Acceptance is what converts a boundary from a place work\ndisappears into a place work is measured.\n"}