The client handover that survives your last day

The folder is shared. The recordings are there. The contact list has names and titles. The person taking over the client still asks: “What do I need to know before I call them?”

The missing piece is usually a connection between the records. A document says what was proposed. A later email changes the scope. A calendar entry holds a date that nobody has approved. The outgoing owner can reconcile those facts from memory; the incoming owner cannot.

A handover should transfer that working understanding without requiring access to every private note its author ever made. The first page needs to explain the current situation, the next commitment and where a reader can verify both.

Begin with the next live obligation

In this fictional example, Mira is taking over a client pilot from Leon. Leon’s draft handover begins, “The client relationship is going well.” That is reassuring and operationally thin.

A more useful opening would be:

Next obligation: Send a revised workshop plan to Amira by Wednesday. Leon accepted this in Monday’s email. Mira is proposed as the new owner; acceptance is still needed.
Current decision: Keep the pilot small until the client reviews the first workshop. Expansion is not approved.
First question: Does Amira want the finance reviewer in the planning call, or only in the approval step?

The note puts a real task ahead of a relationship rating. It also distinguishes the outgoing person’s request from the incoming person’s acceptance.

A date on a handover sheet should not silently make a colleague responsible. Atlassian’s responsibilities guidance keeps unaccepted and unassigned work explicit until people resolve it. That is a useful discipline for a transition, even when you are not using its process or tools. [1]

Give people roles that matter to the next action

A title can be accurate and still fail to explain the person’s part in the work. “Director” does not tell Mira who supplies information, who makes a decision and who simply needs an update.

These roles come from the fictional work described, not assumptions about hierarchy. In a real handover, link them to the agreed process and check whether they are still current.

Avoid encoding judgments such as “difficult stakeholder” when a factual description would be more useful. “Requested a budget breakdown before approval” tells the next person what happened and what to prepare. It does not ask them to inherit your interpretation of someone’s personality.

Separate the record from the story you tell about it

The handover template keeps the next obligation, owner acceptance, open decision and source links in separate fields.

For example, “The client may expand in November” belongs under a possibility unless it has been approved. “Amira mentioned November in a planning call” can be a fact about that call. “Expansion is agreed for November” is a different claim.

Preserve the underlying decision and its date when you summarize. Include rejected alternatives if they explain why the present choice exists. Otherwise your successor may spend their first week proposing an option that the client already considered and declined.

This is where a short handover can be more helpful than a comprehensive chronology. It selects the facts that change what the new owner should do.

Check that the receiver can open the evidence

A link that works for Leon may fail for Mira. Open source permissions are part of the handover, not an administrative detail to discover on the client call.

Ask the incoming owner to open the current plan, decision record and key exchange in the approved workspace. Share only what they are entitled to access. A private mailbox, personal CRM or meeting-prep notebook should not be copied wholesale merely because some of its contents are relevant.

GitLab’s published account-transition process provides a concrete operating example: an internal transition record gathers linked context and account information, is reviewed, and precedes the customer communication. The process is specific to that organization’s customer-success transition; it does not supply a universal handover timetable. [2]

The transferable idea is to check the internal handoff before presenting continuity to the client as complete.

Let the incoming person test the note

Give Mira the first page and ask three questions: What is due next? What remains undecided? Where would you look if the client remembers the decision differently?

This is an editorial review exercise, not a validated score. Its value is in the questions it reveals. If Mira must ask Leon to explain every sentence, the note still depends on knowledge that is leaving.

Revise the unclear parts, confirm ownership and agree on a narrow route for genuine late questions. “Message me anytime” can sound generous while leaving no practical boundary. An agreed contact period or escalation owner is easier for everyone to use.

Use personal memory to prepare the shared record

Kluro can help an authorized user recover connected conversations and the context of a promise. Use that context to prepare the handover, then publish the approved record in your organization’s shared workspace. Keep private relationship notes separate.

Keep the shared final record in the client or organization’s approved system. The consultant use case explains why remembering the previous exchange matters; permission to move that exchange elsewhere remains a separate question.

The handover is finished when the next owner can act and check their understanding. A larger folder is not necessarily closer to that result.