JaredMake the work easier to move forward.
The sale is agreed. The next team still needs to know what the customer expects, what was actually promised, and what must happen before work can begin. This playbook turns that transition into a reviewable handoff packet: an account brief, a first-milestone checklist, and a short list of decisions. Start with one customer and the source material your team is authorized to use. The aim is to help the incoming owner begin with the right context, without asking the customer to retell every conversation.
An enthusiastic discovery note is not an approved deliverable. A target date in a proposal may depend on access that nobody has requested. A handoff can look complete while the receiving owner has not accepted it. Keep those distinctions visible. This workflow focuses on the first transfer from sales to customer success or implementation; use the account-briefing playbook for ongoing check-ins and the project-handoff playbook for general coverage changes.
What to bring to the task
- The customer account, outgoing sales owner, proposed receiving owner, and the specific responsibility being handed over.
- The approved scope or signed statement of work, plus the latest customer-approved changes. Link the relevant section instead of copying a whole confidential agreement.
- Discovery notes and customer correspondence that explain the desired outcome, stakeholders, success criteria, and any promises requiring confirmation.
- The first milestone, any agreed dates and dependencies, and the person who can accept the result. Mark an unagreed date or owner as unknown.
- An existing onboarding checklist and the intended review audience. Leave passwords, API keys, payment credentials, and unrelated customer information out of the packet.
From context to a useful result.
Set a narrow handoff boundary
Name the account and the phase that is starting. State which responsibilities are proposed to move and which remain with sales, such as commercial scope questions. Give the packet a preparation date and identify the source cutoff. A useful first pass ends at one initial milestone; it does not invent an entire implementation plan or declare a customer ready for launch.
Build an evidence-led commitment list
For every important outcome, deliverable, date, and dependency, record its status as confirmed, proposed, or unknown. Attach the source title, section or message reference, and date where available. Summarize the customer's business goal separately from what the team agreed to deliver. When a signed scope and a later note differ, preserve the discrepancy and ask the responsible owner to resolve it; do not silently choose the more convenient version.
Work backward from the first accepted result
Describe an observable completion condition, such as a customer reviewer checking one sample report against the agreed source. List the prerequisites, their existing owners, and any agreed due dates. Show the blocker chain: the sample file is needed before validation, and an approver must be identified before acceptance. If an owner or date is missing, leave a named question rather than manufacturing an assignment.
Prepare two audiences for review
Keep the internal packet specific: scope boundaries, evidence, dependencies, unresolved promises, and the next decision. Prepare a separate customer-facing kickoff agenda or introduction only if requested. Remove internal pricing discussion, speculation, and information the recipient should not see. Any suggested next step should remain visibly proposed until the responsible person confirms it.
Close the loop with owner acceptance
Ask the outgoing owner to check the commercial context and the incoming owner to accept responsibility or return the packet with gaps. Record who accepted, when, the first next action, and who owns each unresolved question. A critical scope or access gap can block readiness even when the document is finished. The packet stays awaiting acceptance until that decision is recorded; sending a link alone is not completion.
The human review checkpoint
A person confirms scope, recipients, commitments, and responsibility. A drafted packet does not authorize sending an introduction, scheduling a kickoff, updating a CRM, granting access, or changing a date. Those actions depend on available tools and separate authorization. Keep internal-only concerns within the review audience. Do not promise that a product capability, integration, or customer deadline is available merely because it appears in sales notes.
Before you make it a routine
- Does every material commitment point to an approved source or display an explicit uncertainty label?
- Are customer goals, promised deliverables, and suggested next steps clearly separated?
- Does the first milestone have a completion condition, an approver, and visible prerequisites?
- Are disputed dates, unclear scope, and missing access still visible to both owners?
- Can the incoming owner open the authorized sources, and is customer-facing wording free of internal-only detail?
- Has the receiving owner accepted the handoff, with an owner for every remaining critical question?
- For a pilot, record time to acceptance and the number of critical questions still open at kickoff. Use those observations to improve the process; do not assume a time-saving result in advance.
A few useful questions
What if discovery notes and the approved scope disagree?
Show both references and describe the conflict precisely. The account owner must determine which commitment is valid. Keep any dependent estimate or customer promise pending until the discrepancy is resolved. A confident summary is not a substitute for that decision.
Can we begin when information is missing?
Prepare a partial packet with a visible missing-information list. Distinguish questions that block the first milestone from items that can be resolved later. The incoming owner decides whether the remaining gaps are acceptable and who will close them.
Does this require a particular CRM or integration?
The working method can begin with approved documents and notes your team provides. It does not depend on an automatic CRM update, a provisioning feature, or a specific connector. Confirm the tools and permitted actions in your workspace before designing the execution steps.
How is this different from a customer-success briefing?
An ongoing account briefing prepares a conversation. This handoff establishes what the delivery team is taking over, the evidence behind the first commitment, and the point at which a new owner accepts responsibility. That acceptance decision is the central output.
When is the handoff complete?
When the incoming owner accepts responsibility and the unresolved items have explicit owners and next steps. If a critical gap prevents acceptance, record it as blocked. A finished document or a scheduled meeting should not silently change the status to complete.