Handoff
Every handover is declared complete by the person leaving. That single fact explains almost everything that goes wrong with them.
The failure this exists to prevent: the account that arrives as a folder. Documents, a CRM record, a link to a shared drive, and none of the four things that actually matter, all of which live in one person's head and leave with them.
What this needs
Shared context. If an account-context document exists, read it first for the contract shapes and what customer success owns. Where it is absent, carry on and name the assumption.
Minimum: the account and both names. Enough to produce the checklist, the questions and the acceptance step.
Better with the account history, the open commitments and the last few months of correspondence, since that is where the undocumented promises are.
Best with thirty minutes of live overlap between the two people. Every written handover is a substitute for that conversation and a worse one.
Step 1: Name the type, because they transfer different things
- Sales to customer success. The thing that must transfer is the promise: what was sold, on what expectation, and what was said that is not in the contract
- CSM to CSM. The thing that must transfer is the relationship and the folklore: who matters, who is difficult and why, what has already been tried, and what the customer should not have to explain again
- Customer success to support, or into a pooled or digital model. The thing that must transfer is the context that stops the customer re-explaining themselves, which is the entire reason they resent being moved
Each still needs the mechanics. Each fails on a different thing.
Step 2: Ask the four questions that never make it into a system
These are what a folder cannot carry, and asking them directly is most of the value of this skill.
- What was promised that is not in the contract? The roadmap remark in the deal cycle, the "we can probably do that", the timeline someone gave verbally. It exists on almost every account and it is what the renewal gets judged against
- Who is the sceptic? Every account has one and they are almost never in the CRM. Not knowing who they are means walking into the first meeting without knowing where the resistance comes from
- What nearly went wrong, and what fixed it? The incident, the escalation, the near-miss. It shapes how they read everything you do afterwards
- What would you do first if you were staying? The single best question to ask a departing owner. It surfaces the thing they know matters and have not got to, which is exactly the thing no document records
Where the answer to any of these is "nothing", press once. Nothing is rare.
Step 3: Let the receiving side define complete
The structural fix, and the one thing that changes handover quality. The person leaving cannot judge whether the person arriving can run the account, and has every incentive to believe they can.
- The receiver writes or accepts the checklist
- The receiver marks it complete, not the sender
- Anything the receiver cannot answer after reading it is an open item, and it goes back
This does not need process. It needs one sentence agreed at the start: you tell me when this is done, not me.
Step 4: Transfer the mechanics, briefly
The part everyone does. Keep it short so it does not crowd out Step 2.
- Contract: term, renewal date, notice date, value, what is in scope
- Commitments outstanding, with dates and owners
- Open tickets, escalations, and anything in flight
- Stakeholders, roles, and who has actually been met
- Access: systems, shared folders, channels, calendar series, distribution lists
- Cadence: what meetings exist and what they are for
Where a stakeholder picture needs real work, stakeholder-map does it properly. Where the account is being inherited with no handover at all, account-research reconstructs it from the record.
Step 5: Do it live, and time-box it
- One live conversation beats any document. Thirty minutes, the receiver asking, the sender answering, both looking at the same list
- A joint customer call is worth more than both. Introduce, hand over, and let the customer hear continuity rather than read about it
- Put a date on it. A handover with no deadline drifts until the sender leaves, at which point it is not a handover, it is an excavation. If the sender has a last day, the handover date is before it, not on it
Step 6: Handle the customer-facing half separately
The internal transfer and the customer's experience of it are two different jobs, and doing the first well does not do the second at all.
The customer's real fear is not who the new person is. It is that the history goes away and they have to start again. Address that specifically, name what carries over, and never let them discover the change from an auto-reply. customer-update Step 6 covers the message.
Where the account is mid-escalation or close to a renewal, delay the change if you can. Where you cannot, the outgoing person hands over live rather than the incoming person introducing themselves cold.
Step 7: Leave the receiver a first action
End with one thing the receiver should do in the first week, and why. It converts a folder into a starting point, and it is the clearest signal that the sender actually thought about the account rather than emptying their notes into a document.
Output
- The type, and therefore what must transfer
- The four answers: the undocumented promise, the sceptic, the near-miss, and what they would do first
- The mechanics: contract, commitments, open items, stakeholders, access, cadence
- The acceptance step: who signs it off, which is the receiver, and by when
- The live session, scheduled, and the joint customer call if there is one
- The customer-facing message, separately
- The receiver's first action
- What could not be transferred, named rather than left implied
assets/handover-checklist.md is the same structure as a fill-in checklist.
Failure modes
- The sender declares it complete. Structurally guaranteed to be optimistic
- The account arrives as a folder. Everything documented, nothing that matters
- Never asking what was promised outside the contract. It exists, and it surfaces at renewal
- No sceptic named, so the first meeting has an unexplained source of resistance in it
- No live conversation. A document is a substitute for one and a worse one
- No date, so it drifts to the sender's last day and becomes archaeology
- Access transferred and context not. The new person can log in and cannot answer a question
- The customer finding out from an auto-reply
- A handover during an escalation or a renewal, done anyway because a calendar said so
- No first action, so the receiver starts by reading rather than doing
What good looks like
- The receiver said it was complete, and could answer questions about the account without opening anything
- The undocumented promise is written down, with who said it
- The sceptic has a name
- It happened live, before the sender's last week
- The customer heard it from a person, and knows what carries over
- There is one specific thing for the receiver to do in week one
- What could not be transferred is stated rather than quietly missing
Related skills
customer-update for the message to the customer, particularly a change of CSM
account-research when there was no handover and the history has to be reconstructed
stakeholder-map for the relationship picture in depth
onboarding-plan for the sales-to-customer-success case, where the handover feeds the plan
offboarding for the departure case, which is a different thing entirely
Supporting files
assets/handover-checklist.md - the checklist, signed off by the receiver, usable without an assistant
1---2name: handoff3description: Runs a handover so the receiving side can actually take it: sales to customer success, customer success to support, or one CSM to another. Trigger whenever the user says "handoff", "handover", "handing over my accounts", "sales to CS handover", "transition the account", "I am leaving and need to hand over", "onboarding a new CSM", "what do I need to pass on", or names an account changing owner. It defines completeness from the receiving side rather than the leaving side, forces out the things that never make it into a system, sets an acceptance step with a date, and separates the internal transfer from what the customer is told. Use customer-update for the message to the customer, and account-research when the handover never happened and the history has to be reconstructed.4---56# Handoff78Every handover is declared complete by the person leaving. That single fact explains almost everything that goes wrong with them.910The failure this exists to prevent: **the account that arrives as a folder.** Documents, a CRM record, a link to a shared drive, and none of the four things that actually matter, all of which live in one person's head and leave with them.1112---1314## What this needs1516**Shared context.** If an `account-context` document exists, read it first for the contract shapes and what customer success owns. Where it is absent, carry on and name the assumption.1718**Minimum: the account and both names.** Enough to produce the checklist, the questions and the acceptance step.1920**Better with** the account history, the open commitments and the last few months of correspondence, since that is where the undocumented promises are.2122**Best with** thirty minutes of live overlap between the two people. Every written handover is a substitute for that conversation and a worse one.2324---2526## Step 1: Name the type, because they transfer different things2728- **Sales to customer success.** The thing that must transfer is **the promise**: what was sold, on what expectation, and what was said that is not in the contract29- **CSM to CSM.** The thing that must transfer is **the relationship and the folklore**: who matters, who is difficult and why, what has already been tried, and what the customer should not have to explain again30- **Customer success to support**, or into a pooled or digital model. The thing that must transfer is **the context that stops the customer re-explaining themselves**, which is the entire reason they resent being moved3132Each still needs the mechanics. Each fails on a different thing.3334## Step 2: Ask the four questions that never make it into a system3536These are what a folder cannot carry, and asking them directly is most of the value of this skill.37381. **What was promised that is not in the contract?** The roadmap remark in the deal cycle, the "we can probably do that", the timeline someone gave verbally. It exists on almost every account and it is what the renewal gets judged against392. **Who is the sceptic?** Every account has one and they are almost never in the CRM. Not knowing who they are means walking into the first meeting without knowing where the resistance comes from403. **What nearly went wrong, and what fixed it?** The incident, the escalation, the near-miss. It shapes how they read everything you do afterwards414. **What would you do first if you were staying?** The single best question to ask a departing owner. It surfaces the thing they know matters and have not got to, which is exactly the thing no document records4243Where the answer to any of these is "nothing", press once. Nothing is rare.4445## Step 3: Let the receiving side define complete4647**The structural fix, and the one thing that changes handover quality.** The person leaving cannot judge whether the person arriving can run the account, and has every incentive to believe they can.4849- The receiver writes or accepts the checklist50- The receiver marks it complete, not the sender51- Anything the receiver cannot answer after reading it is an open item, and it goes back5253This does not need process. It needs one sentence agreed at the start: **you tell me when this is done, not me.**5455## Step 4: Transfer the mechanics, briefly5657The part everyone does. Keep it short so it does not crowd out Step 2.5859- Contract: term, renewal date, notice date, value, what is in scope60- Commitments outstanding, with dates and owners61- Open tickets, escalations, and anything in flight62- Stakeholders, roles, and who has actually been met63- Access: systems, shared folders, channels, calendar series, distribution lists64- Cadence: what meetings exist and what they are for6566Where a stakeholder picture needs real work, `stakeholder-map` does it properly. Where the account is being inherited with no handover at all, `account-research` reconstructs it from the record.6768## Step 5: Do it live, and time-box it6970- **One live conversation beats any document.** Thirty minutes, the receiver asking, the sender answering, both looking at the same list71- **A joint customer call is worth more than both.** Introduce, hand over, and let the customer hear continuity rather than read about it72- **Put a date on it.** A handover with no deadline drifts until the sender leaves, at which point it is not a handover, it is an excavation. If the sender has a last day, the handover date is before it, not on it7374## Step 6: Handle the customer-facing half separately7576The internal transfer and the customer's experience of it are two different jobs, and doing the first well does not do the second at all.7778The customer's real fear is not who the new person is. It is that the history goes away and they have to start again. Address that specifically, name what carries over, and never let them discover the change from an auto-reply. `customer-update` Step 6 covers the message.7980Where the account is mid-escalation or close to a renewal, delay the change if you can. Where you cannot, the outgoing person hands over live rather than the incoming person introducing themselves cold.8182## Step 7: Leave the receiver a first action8384End with one thing the receiver should do in the first week, and why. It converts a folder into a starting point, and it is the clearest signal that the sender actually thought about the account rather than emptying their notes into a document.8586---8788## Output89901. **The type**, and therefore what must transfer912. **The four answers**: the undocumented promise, the sceptic, the near-miss, and what they would do first923. **The mechanics**: contract, commitments, open items, stakeholders, access, cadence934. **The acceptance step**: who signs it off, which is the receiver, and by when945. **The live session**, scheduled, and the joint customer call if there is one956. **The customer-facing message**, separately967. **The receiver's first action**978. **What could not be transferred**, named rather than left implied9899`assets/handover-checklist.md` is the same structure as a fill-in checklist.100101---102103## Failure modes104105- **The sender declares it complete.** Structurally guaranteed to be optimistic106- **The account arrives as a folder.** Everything documented, nothing that matters107- **Never asking what was promised outside the contract.** It exists, and it surfaces at renewal108- **No sceptic named**, so the first meeting has an unexplained source of resistance in it109- **No live conversation.** A document is a substitute for one and a worse one110- **No date**, so it drifts to the sender's last day and becomes archaeology111- **Access transferred and context not.** The new person can log in and cannot answer a question112- **The customer finding out from an auto-reply**113- **A handover during an escalation or a renewal**, done anyway because a calendar said so114- **No first action**, so the receiver starts by reading rather than doing115116---117118## What good looks like119120- The receiver said it was complete, and could answer questions about the account without opening anything121- The undocumented promise is written down, with who said it122- The sceptic has a name123- It happened live, before the sender's last week124- The customer heard it from a person, and knows what carries over125- There is one specific thing for the receiver to do in week one126- What could not be transferred is stated rather than quietly missing127128---129130## Related skills131132- `customer-update` for the message to the customer, particularly a change of CSM133- `account-research` when there was no handover and the history has to be reconstructed134- `stakeholder-map` for the relationship picture in depth135- `onboarding-plan` for the sales-to-customer-success case, where the handover feeds the plan136- `offboarding` for the departure case, which is a different thing entirely137138---139140## Supporting files141142- `assets/handover-checklist.md` - the checklist, signed off by the receiver, usable without an assistant