The pattern
Every functional team optimises its own queue. Work that has left the queue is somebody else's problem, and work that has not arrived yet is not visible. So the boundary between two teams is the one place where nobody is watching, and it is where units of work quietly stop moving.
The classic examples: qualified leads that sales never accepts, closed deals that delivery never receives, delivered work that support has no context for, support issues that never reach the team that could prevent recurrence.
The handoff contract
This is the single most useful artefact in operations work, and it fits on one line per handoff.
- Trigger
- The observable event that starts the handoff. Not a decision someone makes when they get around to it.
- Owner
- The named person or role who becomes accountable at the moment of transfer.
- Required input
- What must accompany the work for the receiver to act without going back for information.
- Standard
- What the receiver must do, and what finished looks like on their side.
- Deadline
- The time within which the receiving action must occur, measured from the trigger.
- Escalation
- Who is told when the deadline passes, and what they are expected to do.
Instrument the boundary
Give the handoff a state
A transfer must be represented in the system — a stage change, a task assignment, a record status. If the handoff exists only as a message, it cannot be measured or escalated.
Timestamp both sides
Sent and accepted. The gap between them is the leak, and it is the only number the boundary review needs.
Make acceptance explicit
The receiver acknowledges, which also means they can reject with a reason when the required input is missing. Rejection with a reason is a feature: it produces the data that fixes the upstream defect.
Report unaccepted transfers
A weekly list of transfers not accepted within the deadline, by boundary. Two weeks of this data usually identifies the one broken handoff causing most of the pain.
The four boundaries that leak most
| Boundary | What goes missing | The input that fixes it |
|---|---|---|
| Marketing to sales | Context: source, qualification answers, what was promised | A required-input list enforced at the transfer |
| Sales to delivery | Scope as sold, verbal commitments, customer contacts | A handoff delivery can reject with a reason |
| Delivery to support | History, known issues, what the customer already tried | A structured handover record, not a conversation |
| Support to product or operations | Recurring causes, frequency, cost of the workaround | Structured issue reasons reviewed monthly |
Each of these has the same shape: the sending team considers the work finished, the receiving team considers it not yet started, and the gap between those two beliefs is where the elapsed time accumulates. Nobody is idle, and nothing is moving.
Where to start when several boundaries leak
Fix the one closest to revenue first, then the one with the highest volume, then the one with the loudest escalations. Attempting all boundaries at once produces four half-implemented contracts and no measurable change. The operations audit playbook sequences this properly.
What good looks like
- Every major handoff has a written contract with six parts.
- Transfers have timestamps on both sides.
- Rejections carry structured reasons and are reviewed monthly.
- Unaccepted work raises an exception the same day.
- Nobody needs to chase by message to find out whether work arrived.
Related work
The discipline behind this is business operations; the documentation layer is covered in no SOPs, no accountability. The revenue-specific version is the marketing-to-sales handoff playbook.
Muhammad Sameed Abid
Muhammad Sameed Abid is a business operations, automation and growth systems professional with 9+ years across operations management, workflow and CRM automation, marketing operations and customer success. He is currently Head of Customer Success at GHA Marketing and writes here about the operating layer underneath growth.