Handoff Workflow

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.

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:

The handoff is an event, not a status change. It has two parties.
Acceptance is required. Between offer and acceptance the sender still owns it — otherwise work falls into the gap and nobody is accountable.
A readiness check before offering, so the receiving team's needs are enforced at the boundary rather than complained about after it.
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.

Ask Leo for this

Paste this into your Leo chat. It describes the behaviour, not the code, so Leo can fit it to your data.

Prompt

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.