--- 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. - A handoff is an EVENT on the record, with a sender, a named receiver, a timestamp and a state — offered, accepted, or returned. - The receiving team must accept. Until they do, the record is still the sender's responsibility, and that must be visible to both sides. - Define what must be present before a handoff can be offered — the fields, files and answers the receiving team always needs — and check them at the moment of handoff, not afterwards. - Let the receiver REJECT the handoff with a reason, sending it back to the sender. Rejection is the mechanism that makes the quality bar real. - Carry the context across: the whole history, the comments and the documents stay on the record. Never start a new record on the other side of the boundary. - Show both teams a view of what is in flight at the boundary — offered but not accepted — because that is where things sit unnoticed. - Record how long acceptance takes. That number is the health of the boundary. 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. --- ## The shape ``` SALES ┃ boundary ┃ OPERATIONS ───── ┃ ┃ ────────── Deal won ┃ ┃ │ ┃ ┃ ├─ readiness check ───▶ OFFERED ───▶ awaiting acceptance (2 days) │ ✓ signed contract ┃ ┃ │ │ ✓ site address ┃ ┃ ├─▶ ACCEPTED — ops now owns it │ ✗ access contact ┃ ┃ │ │ ▲ blocks offer ┃ ┃ └─▶ RETURNED "no access contact" ▲ the quality bar, made real ``` Four properties: 1. **The handoff is an event**, not a status change. It has two parties. 2. **Acceptance is required.** Between offer and acceptance the sender still owns it — otherwise work falls into the gap and nobody is accountable. 3. **A readiness check before offering**, so the receiving team's needs are enforced at the boundary rather than complained about after it. 4. **Rejection with a reason**, which is what gives the readiness check teeth. ## Why it works Handoffs are where internal processes fail, and they fail for a structural reason: **responsibility becomes ambiguous exactly at the moment it moves.** A plain status change from "Sold" to "In delivery" declares a transfer without anyone confirming they received it. Requiring acceptance closes that gap. It also produces the single most useful number about the boundary — time-to-acceptance — which tells you whether the receiving team is keeping up long before anyone escalates. Rejection is the part teams resist and the part that changes behaviour. A readiness checklist with no consequence gets half-filled. One that can send the record back, with a reason, visible to both managers, gets filled. ## Carry the context, do not restart The most damaging version of a bad handoff is a **new record on the other side**. Sales closes an opportunity; operations creates a project; the two are linked by a name typed twice. Everything the customer said is now on the wrong side of a wall. One record that changes hands keeps the history, the comments and the files where the next person will look for them. If two systems genuinely must be involved, the handoff should copy context forward and keep the link, not start from a blank form. ## Getting it wrong - **A status change with no receiver**, so nobody actually took it. - **No acceptance step**, so the gap between teams is invisible. - **Readiness checks with no rejection path**, which makes them advisory and therefore ignored. - **A fresh record on the receiving side**, which discards the context that was the entire point. - **No visibility of what is in flight**, so items sit at the boundary unnoticed — the classic place work disappears for a week. ## Exemplars **Sales-to-delivery handoffs** in professional services are where this pattern pays for itself fastest, because the cost of re-asking a client questions they already answered is immediate and visible to the customer. **Clinical handovers** in hospitals are the most studied version, and the finding transfers directly: structured handover with explicit acceptance reduces dropped information, and the structure matters more than the content of any individual field. **Support-to-engineering escalation** shows the readiness check working — a reproduction, a version, and an account, checked at the boundary, is what stops the ticket bouncing back and forth. The extractable rule: **a handoff nobody has to accept is not a handoff, it is an announcement.** Acceptance is what converts a boundary from a place work disappears into a place work is measured.