A good handoff lists every commitment the buyer heard, including promises made by email or on calls, with where each was made, a named owner, what "delivered" means, and the receiving team's answer: accepted, queried or cannot deliver. It is finished when nothing is left queried.
What a sales to customer success handoff must carry
A handoff is not a summary of the deal. It is a list of everything the buyer now expects, each with an owner who has agreed to deliver it. The contract is only part of that list. What they heard on calls and read in emails is the rest, and it is the part that causes the trouble.
We recommend one row per commitment, with seven fields:
| Field | What goes in it |
|---|---|
| Commitment | What the customer was told they would get, in their words where possible |
| Where it was promised | Contract clause, proposal page, email or call, with a date |
| In the contract? | Yes or No. A No is not wrong, but it must be visible |
| Owner after handoff | A named person, not a team |
| How we will know it is delivered | What the customer would accept as done |
| Receiving team's answer | Accepted, Queried or Cannot deliver |
| Open question | What still has to be settled, and with whom |
The free handoff template has these columns, drop-downs for the answers, a count of promises made outside the contract and a completed example. No sign-up.
How to run the handoff
- The seller lists every commitment before the meeting. Contract, proposal, emails and call notes. Flag the ones outside the contract for an explicit decision.
- Record where each was promised. A date and a document, so nobody argues later about what was said.
- The receiving team names an owner for each row. One person, who says yes.
- The receiving team answers every row. Accepted, Queried or Cannot deliver.
- Settle the queried rows with the client before kickoff. A changed promise told early is an adjustment. Told at month two, it is a broken one.
You should treat the handoff as finished only when no row is queried and every "cannot deliver" has a replacement the client has already heard about.
A worked example
Illustrative. It describes no real client or deal.
A software company sells a six-month implementation. The seller lists six commitments. Two were made outside the contract: a weekly check-in agreed on the discovery call, and a custom margin report promised in an email.
| Commitment | Where it was promised | In the contract? | Owner after handoff | Receiving team's answer |
|---|---|---|---|---|
| Go live on the new platform by 1 March | Order form, clause 4 | Yes | Implementation lead | Accepted |
| Migrate three years of order history | Proposal, page 6 | Yes | Data engineer | Queried |
| Weekly check-in for the first eight weeks | Discovery call, 14 Jan | No | Customer success manager | Accepted |
| A custom margin report by month one | Email from the account executive, 22 Jan | No | Customer success manager | Cannot deliver |
| Single sign-on with their identity provider | Order form, clause 7 | Yes | Implementation lead | Accepted |
| Named escalation contact | Proposal, page 9 | Yes | Head of customer success | Accepted |
Four rows are accepted. Two remain unresolved:
- Migrate three years of order history: Proposal says three years; the data export only holds two. Confirm with the customer before kickoff.
- A custom margin report by month one: Not in scope or price. Agree with the customer what replaces it before the kickoff call.
What this shows: 2 of 6 commitments were never in the contract, and one of them cannot be delivered. What it does not show: whether the customer agrees the list is complete. Only the client can confirm that, which is why the kickoff call should open with it.
Reconcile a promise before handoff
A 48-second silent walkthrough using synthetic examples. Captions are included in the picture; the full explanation follows below.
Download the video (MP4) ยท Download captions (VTT)
Walkthrough transcript
Silent walkthrough. All examples are synthetic.
A closed sale does not settle delivery readiness. Compare the recorded promise with what the receiving team can actually check.
The proposal says three years. The available export contains two. Preserve both facts instead of silently rewriting the commitment.
The data engineer owns the check. The sample sign-off is a proposed acceptance step; it is not evidence that migration has succeeded.
Keep the commitment queried while the discrepancy is resolved. Customer agreement and any scope change still need to be recorded.
Find out whether the missing year exists elsewhere. If it does not, obtain an explicit decision rather than a quiet handoff assumption.
Use the handoff template to preserve commitments and receiving decisions. Keep unresolved questions visible until someone actually settles them.
What is this account being promised?
Before an account changes hands, list every commitment the customer heard, wherever it was made, and have the receiving team answer each one.
Your starting question: What must be known and accepted before this account changes hands?
Start by checking
- Whether every commitment the customer heard is on the list, including ones made by email or on a call.
- Whether each commitment has a named owner who has accepted it.
- Which commitments the receiving team has queried or cannot deliver, and what the customer will be told.
Evidence to gather
- The contract and the proposal.
- Emails and call notes from the sale.
- The receiving team's answer to each commitment.
Not established yet
- Whether the customer agrees the list is complete.
- Whether queried items can be delivered at the agreed price.
- How the customer will react to a changed promise.
Mistakes that make a handoff fail
- Handing over the contract and calling it done. Promises in calls and emails also need an explicit receiving owner.
- A team as the owner. "Customer success" cannot say yes. A person can.
- No answer from the receiving side. A list the receiving team has only read is a briefing, not a handoff.
- Hiding a promise that cannot be kept. Raise it before kickoff, with what you can offer instead.
For the wider reasons handovers break down, see why client handovers fail.
Bring the account context to the meeting
Alongside the commitment rows, record why the customer bought, the outcomes they expect, how success will be checked, decision-makers and day-to-day contacts, target dates, integrations and unresolved risks. Link the supporting records with appropriate access. The seven-column worksheet is the commitment register; it is not a place to copy sensitive account records.
Start the meeting by confirming that context. The seller then walks through the evidence for each promise; the receiver accepts it, asks a specific question or explains why it cannot be delivered. Finish by assigning each open item a decision owner and date. Confirm changes with the customer through your normal authorised process before treating them as agreed.
An implementation handoff concentrates on delivery scope, dependencies and acceptance. A customer-success handoff also needs ongoing success criteria, adoption responsibilities and the route for unresolved concerns. Where both teams are involved, name each responsibility instead of assuming one team accepted the other's work.
In the example, two outside-contract promises out of six recorded commitments is a flag to inspect, not a measure of handoff quality across customers. Track unresolved commitments as a count with its denominator and reporting date; a lower number is useful only if the decisions and customer expectations are actually reconciled.
If a promise still lacks testable acceptance evidence, use the requirements traceability matrix to connect the need, owner and agreed evidence.