Why operational handoffs break, and what to define at each one

• The passing state is undefined. Sales marks a deal won with no written scope, delivery begins, and the assumptions have to be discovered rather than read.
• Ownership is doubled or absent. Both sides assume the other updates the record, so neither does, and the same information lives in two places with different values.
• The trigger is a habit rather than an event. Information moves when somebody remembers to forward it, which makes timing depend on attention.
• There is no route back. Incomplete work is accepted because sending it back has no defined path, so the receiver absorbs the gap.
• Nobody measures the boundary. Rework and delay are felt but not counted, so the boundary is never a candidate for change.

1. The trigger. The event that starts the handoff, expressed as something that either happened or did not. A stage change, a signature, a payment, a completed check.
2. The passing state. What has to be true of the work when it changes hands, written as a short checklist the sender can complete before passing it on.
3. The recipient. A named role, not a team. "Delivery" is not a recipient; a person accountable for picking it up is.
4. The response expectation. How long the receiver has to acknowledge or challenge it. Acknowledgement is what confirms the handoff actually landed.
5. The failure path. Where incomplete work goes, who decides, and what happens to the deadline while it is resolved.
6. The record. Where the handoff is visible, so it can be checked later without asking the people involved what happened.

Six items per boundary sounds heavy. In practice most of them already exist informally, held by the people who do the work; writing them down makes the informal version checkable and survives a departure.

1. Take one real piece of work and follow it across the boundary, end to end, with both teams present.
2. Write down every question the receiving side asks. Each question is an undefined part of the passing state, and the list is your specification.
3. Turn that list into a checklist the sender completes before passing the work on.
4. Run it for a month and count the handoffs that come back. Counting beats estimating here, because the boundary is invisible until it is measured.
5. Give the boundary one owner, then review the count at the same cadence as your other operational reviews.

The example below is hypothetical. It describes a pattern these boundaries tend to share, not a client account.

Handoff design is part of operational consulting, and it sits inside the wider Operations & Systems capability, alongside SOP documentation, KPI systems, and integration work. Where a boundary keeps breaking because the procedure behind it was never written, the SOP work carries the definition once it exists.