You can hear it on the kickoff call if you listen for it.
Somewhere in the first fifteen minutes the client explains their situation again — the background, the constraint, the reason this matters now. And they explain it slightly slower than last time, because they're recalibrating who in this room already knows.
It's polite and nobody names it. But something has been spent. The client has just learned that the understanding they built with you doesn't automatically extend to the people doing the work, which means they now have to manage that themselves — a job they didn't know they were buying.
The sharper version arrives a few weeks in, when they ask about the thing. The one they mentioned on the second call. It's not in the scope, it's not in the plan, and nobody on the delivery side has ever heard of it.
Two people, two different records
This isn't carelessness. It's a difference in what each side keeps.
Delivery receives artifacts: a signed scope, a set of deliverables, some notes in a CRM. Those are accurate, and they're what a delivery team can act on.
The client keeps the conversation. And the conversation is where the actual purchase happened — the moment somebody understood their situation, the aside about the thing that's been annoying them since last year, the reassurance that was given quickly and sincerely and never written down.
Ask a client what they bought and they'll describe that conversation. Ask the contract and it'll describe deliverables.
The part of the sales conversation that decided the sale is exactly the part that doesn't survive the handoff — because no form has a field for the reason someone bought.
There's a second asymmetry stacked on top, and it's the reason founders are consistently the last to spot this in their own business. The person who sold — usually you — knows all of it, and knows it so thoroughly that its absence from the written record is invisible. It doesn't feel like undocumented context. It feels like the obvious background of the engagement.
What actually gets lost
Be specific about the categories, because "context" is too vague to fix.
Why now. Not why they need this — why they're doing it this quarter rather than last year. There's always a reason, it's usually specific, and it's the single best predictor of what they'll care about during delivery.
What success sounds like in their words. Not the deliverables. The sentence they'd say in six months if this went well. That sentence contains the real acceptance criteria, and it's almost never the same as the scope.
Everything promised outside the scope. The yes, we can probably look at that too. The we usually handle that as part of it. These are said in good faith and forgotten within a week by everyone except the person who's counting on them.
Who else cares. Including the person who was quiet on the call and will be judging the result. Every engagement has one, and delivery meets them for the first time in week five.
None of those four are captured by any CRM field, project template or scope document in general use. That's not an oversight in the tools — it's that all four are properties of a conversation, and the tools record transactions.
The note that closes it
The fix is one artifact that doesn't currently exist: a document produced by whoever sold, for whoever delivers, carrying what the contract can't.
Not a summary of the scope. Delivery already has the scope. A record of the conversation, in four fields, in the client's own language:
- Why they're buying now, rather than last year.
- What they said success looks like — quoted, not paraphrased.
- Anything promised or implied that isn't in the scope — stated plainly, so it can be decided rather than discovered.
- Who actually cares internally, including the quiet one.
That's the whole thing. Ten minutes to write, immediately after the call while it's fresh, and it removes an entire category of failure.
The third field is the one that earns it. Every promise made in a sales conversation and not written down becomes a week-six conversation where somebody is either doing unpaid work or telling a new client that their memory of the discussion is wrong. Both of those are expensive in different currencies. Writing it down means the decision happens at the handoff, while it's still a scoping conversation.
The trigger matters more than the template
Here's where most attempts at this fail. The document gets designed, everyone agrees it's a good idea, and it gets written when there's time — which means it exists for calm months only, and calm months aren't when the handoff breaks.
So give it a hard trigger: kickoff doesn't happen without it.
Owned by whoever sold. Written before the kickoff call is scheduled. Not a suggestion — a gate, in the same way that sending an invoice is a gate on getting paid.
That single rule is the difference between a handoff process and a handoff intention. Ten minutes is a cost the seller will happily pay when it's required and will reliably defer when it's optional.
Then close the loop out loud
The last step takes ninety seconds and it inverts the entire experience for the client.
Open the kickoff by restating their situation back to them — from the note, in their words, before asking any questions at all.
You're doing this now because the contract renewal in March forces a decision. Six months from now, success looks like your ops lead not having to chase three people for the monthly numbers. And you mentioned the reporting piece, which isn't in scope — let's talk about that today rather than in week six.
Instead of learning that context doesn't travel here, the client learns that it does. That's a claim about your business that's genuinely hard to make any other way, and it lands on day one — which is where it matters.
A great onboarding process is your first act of execution. It answers the unspoken question every new client has: am I in good hands?
The first seven days matter more than the next seventy, and a handoff that drops context spends those seven days making the client wonder.
Where the note also earns its place
The four questions were designed for the sales-to-delivery seam, and the same artifact does real work at two other handoffs that most businesses handle just as badly.
Delivery to whoever owns the relationship afterwards. When a project ends and an account manager or customer success person takes over, exactly the same evaporation happens — they inherit the deliverables and none of the reasons. What changed for them, what they asked about that wasn't in scope, what they've said they need next. Same four fields, different tense.
Between people on the same project. When somebody goes on leave or a piece of work moves between team members, the receiving person gets the task and not the context. This is where the anything promised outside the scope field earns its keep most often, because in-flight promises are the most perishable thing in a project.
There's also a use nobody plans for and everybody eventually needs: the note is the best possible input to an AI-assisted anything. Draft a status update, prepare a review, summarize an account — every one of those produces generic output from a scope document and specific output from a record of why somebody bought. The four questions are, incidentally, the highest-value structured data a service business can start capturing.
What this fixes that isn't about clients
There's a founder-level version of this problem that's worth naming.
Once you know context evaporates at the handoff, the rational response is to stay on every project long enough to prevent it. And that response is correct, which is exactly why it never gets fixed — the workaround works.
But every engagement that only goes well because you were personally in the room to carry the context is an engagement that has taught the business it needs you in the room. That's how founder dependency gets manufactured: not by a decision, but one project at a time, each time reasonably.
The four-question note is the smallest possible intervention on that. It doesn't remove you from delivery. It removes the specific reason you can't be removed.
That's what the Execution pillar means by the identity shift — from being the person who does the work to being the person who designs how the work gets done. It's not about removing yourself. It's about removing your dependency, and the handoff is one of the places that dependency is actively being created.
Do it on your next engagement
You don't need a system for this. You need a template with four questions and a rule that kickoff waits for it.
Write it after your next sales call, while the conversation is still fresh. Read it out at the kickoff. Then ask the delivery team whether it changed anything — and ask the client, at the end of week one, whether they felt understood.
Both answers will tell you whether this was your gap. In most founder-led businesses, it is.
If the handoff is one symptom of a delivery process that was never designed — where every project runs differently and the founder is the only continuity — the useful step is naming which constraint is actually holding the business, not fixing seams one at a time.
Get The OPERATE Report →