Sales-to-CSM handover
Objective. Transfer goals, stakeholders, promises, scope, data needs, risks and pilot evidence to the CSM so that no unresolved promise is hidden in free text.
Teaches the handover that determines whether a won deal becomes a retained, expanding account or an early churn. You will produce a structured handover a CSM can act on, surfacing every commitment made during the sale - especially the soft or implied ones - so the CSM inherits reality, not a sales-optimistic story.
See it in the demo
The customer problem
The most expensive failure in the customer lifecycle is a handover that hides a promise. During the sale, commitments get made in passing - 'we will get that integration sorted', 'yes it handles that case', 'you will see X by month two' - and if they live only in the AE's memory or buried in an email thread, the CSM inherits a customer expecting things nobody scoped. Business impact: the first QBR becomes a dispute, trust collapses, adoption stalls, and the account churns or refuses to expand. The customer does not distinguish 'sales said' from 'CSM said' - it is all Time Champ. A clean handover is not admin; it is the first act of the retention that funds the next three years of the account.
The seven-field handover
Transfer seven things explicitly, each in a structured field (not prose the CSM must mine): (1) GOALS - the customer's actual business outcome and the baseline from the pilot (S08), in their words and numbers. (2) STAKEHOLDERS - champion, economic owner, operational owners, detractors, and who owns which number; note sponsor-change risk. (3) PROMISES - every commitment made, including soft/implied ones, each marked resolved or open with an owner (this is the field that prevents disasters). (4) SCOPE - what was sold: which application(s), which team/process/payer, pilot vs rollout, and explicitly what was OUT of scope. (5) DATA NEEDS - sources, completion/standard definitions agreed, access/role scope, capture policy and comms, freshness, time zones - the required inputs that must be live for value. (6) RISKS - data gaps, unmet dependencies, works-council/comms exposure, integration items escalated to specialists and their status. (7) PILOT EVIDENCE - the charter, the agreed measurement method, the result, and crucially which numbers are capacity vs cash so the CSM does not re-blend them.
What to say / do - surface the promises, especially the soft ones
Run a deliberate promise audit before the handover meeting: re-read your call notes, proposal, demo, and email threads and extract every statement the customer could reasonably treat as a commitment. For each, classify: RESOLVED (delivered or contractually scoped), OPEN-SCOPED (committed and assigned to an owner with a date), or OPEN-UNSCOPED (said in passing, never scoped - these are the landmines). Nothing may remain OPEN-UNSCOPED at handover: either scope it, escalate it, or explicitly retract it with the customer ('to be clear, that EHR integration was not in the pilot scope - here is the path to scope it properly'). The hard rule from the certification gate: no unresolved promise hidden in free text. In the handover meeting, walk the CSM through the seven fields live, and have the CSM confirm they can act on each. The handover is not done when you send the doc; it is done when the CSM signs off that nothing is ambiguous.
Capacity vs cash and specialist items in the handover
Two things routinely get corrupted in handover and both damage the account. First, the capacity-vs-cash separation (S08): if the pilot showed freed capacity, the handover must say so as capacity, not let it drift into a cash expectation the CSM then has to walk back at the QBR. Carry the four-number discipline forward - recoverable value, billed value, collected cash and capacity value stay distinct. Second, any item escalated to a specialist during the sale (packaging confirmation, integration method, security/residency answer - see S06) must be handed over WITH its current status and owner, not assumed closed. If a security answer is still pending, the CSM must know. Write these as explicit RISK or PROMISE entries with the specialist named and the state (answered/pending/committed-by-date). The CSM cannot defend at a QBR what they did not know was still open.
Objections and honest limits
'The CSM can just read the notes.' - No - notes are where promises hide; the structured seven fields force every commitment into the open and the CSM's sign-off is the control. 'We did not actually promise that, the customer inferred it.' - Does not matter to the customer; if it is a reasonable inference, treat it as a promise and resolve or retract it now, cheaply, rather than at a disputed QBR. Honest limits: the handover transfers what is known and agreed - it is not the place to invent outcomes or paper over an unmet data dependency; an unresolved dependency should be handed over AS unresolved, with an owner. And the handover does not end sales involvement where commercial ownership of renewal/expansion sits with sales (confirm internal ownership model) - it transfers delivery and success, and sales stays partnered for the commercial path (C11).
Interpretation check
The customer does not distinguish 'sales said' from 'CSM said' - it is all Time Champ. Therefore no promise, especially a soft or implied one, may be left in free text or assumed closed; every commitment is resolved, scoped with an owner, or explicitly retracted before handover.
In the field
KnackGlobal handover: goals = output per FTE and cost per claim with the pilot's clean-unit baseline; stakeholders = flag ex-Omega-CTO sponsor dynamics and displacement politics; promises = any EHR/clearinghouse integration statements scoped or retracted; pilot evidence = freed claims-capacity kept explicitly separate from denial-recovery cash so the CSM's first QBR with a ~6,000-seat account defends a clean, un-blended number.
Practical task
Produce a sales-to-CSM handover across the seven fields for a closed pilot/deal, run a promise audit classifying every commitment (resolved / open-scoped / open-unscoped) with none left open-unscoped, carry the capacity-vs-cash split and specialist-item statuses forward, and have a CSM review it and sign off that no unresolved promise is hidden in free text.
Self-check
Name the seven handover fields.
Goals (with baseline), stakeholders (with number ownership and sponsor-change risk), promises (resolved/open with owner), scope (incl. what is out), data needs (required inputs), risks (gaps, dependencies, escalations), pilot evidence (incl. capacity vs cash).
What are the three promise classifications and which one may not survive to handover?
Resolved, open-scoped (committed, owner, date), and open-unscoped. Open-unscoped may not survive - it must be scoped, escalated, or explicitly retracted with the customer before handover.
Why carry the capacity-vs-cash split into the handover?
So freed capacity does not drift into a cash expectation the CSM has to walk back at the QBR. The four-number discipline (recoverable/billed/collected/capacity) must stay distinct through delivery.
A security answer was escalated to a specialist and is still pending at close. How is it handed over?
As an explicit RISK/PROMISE entry naming the specialist and its state (pending, committed-by-date) - never assumed closed, because the CSM cannot defend at a QBR what they did not know was open.
When is the handover actually complete?
Not when the doc is sent, but when the CSM confirms (signs off) they can act on each of the seven fields and nothing is ambiguous or hidden in free text.
Verified vs demo. The structure and discipline are process, not demo-dependent; the specific promises, data needs and pilot numbers come only from the real deal and must be transferred exactly, with unmet dependencies handed over as unresolved rather than smoothed over.