Handle a client handover
Moving a client between account managers without losing context, access, or the thread of what was already shipped.
A handover fails in one of two ways: the incoming manager does not know what was already tried, or the outgoing manager's access outlives their involvement. Both are avoidable in half an hour.
What you'll learn
- The order to do a handover in
- What to brief the incoming manager on, from the platform itself
- The access and delivery cleanup that gets forgotten
Step 1: Add the incoming manager first
Invite them scoped to that client's workspace, before anything is removed. Overlap is the point: they should be able to read the history while the outgoing manager is still available to explain it.
Step 2: Brief them from the ledger, not from a document
The Changes ledger is the handover document. Walk it together:
| Look at | Why it matters to the incoming manager |
|---|---|
| Confirmed moved | What worked here. Do more of it |
| Observed live | Live, too early to score. Do not re-ship these |
| Not measurable, by reason | Where the measurement loop is broken for this client |
| Drifted | Something regressed. Probably the first job |
| Withdrawn | What was considered and rejected, so it is not proposed again |
Then read two sentences from Proof together. Nothing conveys a client's position faster than how an engine describes them.
Step 3: Move the delivery
- Report schedule. Update recipients if the outgoing manager was on them, and update the sender details if you use per-manager branding.
- Notification preferences. Alerts are configured per person, so the incoming manager must set their own. The outgoing manager's settings do not transfer.
- Any webhooks or API keys the outgoing manager created for this client.
Step 2 is the one that causes a silent gap: the client's alerts were going to somebody who no longer works on them, and nobody is being told.
Step 4: Remove the outgoing manager's access
Remove them from the workspace once the overlap period is done. Then check the report recipients again, because removing a user does not remove their address from a schedule.
Step 5: Tell the client
One short email: who is taking over, when, and one specific thing the new manager is already working on from the ledger. The specific thing is what makes it read as continuity rather than as churn.
The checklist
| Done | Item |
|---|---|
| Incoming manager invited, scoped to the workspace | |
| Ledger walked together, including Not measurable and Drifted | |
| Two Proof sentences read | |
| Report recipients and sender details updated | |
| Incoming manager's own alerts configured | |
| Outgoing manager's keys and webhooks revoked | |
| Outgoing manager removed from the workspace | |
| Report recipients rechecked after removal | |
| Client told, with one specific next action |
Try this in Outercite
Before your next handover, open the client's ledger and group it by tier. If everything is at Attested, the handover problem is smaller than the measurement problem.
Related
Client permissions model
Roles and workspace membership.
Changes
The ledger you are handing over.
Set up alerts
The per-person settings the incoming manager needs.
Last updated on
Send the weekly client update
A short weekly email keeps a retainer visible between monthly reviews. Here is what to put in it and what to leave out.
Pitching AI visibility to clients
How to present AI search visibility to a client who has never thought about it, using their own data rather than industry statistics.