A workflow diagram shows the route. A handoff register makes each transfer accountable. It records what one person or system must provide before the next can continue. That makes it especially useful when a project passes through sales, operations, delivery and approval, with different tools at every stage.
Before you start
Create one row per transfer, not one row per department. A shared spreadsheet is enough to start. Ask the receiver what they need to act without chasing context, then compare that answer with what the sender normally provides. Missing information becomes an explicit acceptance condition.
The workflow
- Identify sender, receiver and backup. Use roles where staffing changes, but link each role to a current person. Avoid a receiver called “the team” unless the team has an explicit duty owner.
- Describe the handoff package. List the record link, required fields, attachments and version. Link to the source of truth rather than copying different versions into every notification.
- Set an acceptance rule. The receiver should be able to mark accepted, rejected with a reason, or blocked. A notification being delivered does not mean the work was accepted.
- Specify the timing convention. Distinguish elapsed hours from business hours, and define the start event. Make holiday or absence handling part of the agreement rather than an unwritten exception.
- Define escalation and closure. When a transfer stalls, send the context to the backup. When it succeeds, record who accepted it and when. Prevent a replay from creating another independent task.
Worked example
Illustrative example: sales transfers a signed project to delivery. The package needs the signed scope, primary contact, billing status and promised start date. Delivery rejects the handoff as incomplete if the scope is missing. Sales keeps ownership until the package is accepted. This avoids a misleading “won” status that everyone assumes means delivery has started.
Your worksheet
- Handoff name: ___
- Sender / receiver / backup: ___
- Trigger and record ID: ___
- Required package and version: ___
- Acceptance criteria: ___
- Due time and business-hours rule: ___
- Rejection reason and return path: ___
- Accepted by / accepted at: ___
Test it
- Send a complete test package and verify acceptance is recorded.
- Remove one required item and confirm ownership remains clear.
- Repeat the same event and verify it updates the existing handoff rather than creating duplicate work.
What to measure
Review rejected handoffs and the reasons behind them. A rising rejection count can reflect better visibility rather than a worsening process. Compare acceptance time, missing fields and repeated clarification requests before deciding whether a change helped.