A signed proposal is a starting point. The delivery team still needs to know why the client bought, what was agreed, who makes decisions and what must happen before work begins. When those answers stay inside the salesperson’s inbox, the kickoff becomes another discovery call.
Use this checklist to build one repeatable handover from sales to delivery. Adapt the fields to your service, keep the first version small, and make the missing information visible instead of pretending the project is ready.
The useful idea
Onboarding is complete when the delivery team can explain the agreement, the client can explain the next step, and somebody owns every open question.
Define what ready to start actually means
Write a short entry condition for delivery. For a design studio, that might be an agreed brief, a named approver, source assets and a confirmed first milestone. For a consultancy, it might be access to the relevant information and agreement on the question being answered.
Give each condition an owner and an evidence link. A checkmark labelled ‘brief received’ is weaker than a link to the brief that the project lead has actually read. Separate missing information that blocks work from information you can collect later.
- Agreed deliverables and the current proposal or scope.
- Client decision maker and the person coordinating day to day.
- Project lead, first milestone and next client commitment.
- Required assets, access and outstanding questions.
Carry the sales conversation into the project
Ask the person who won the work to record the reason the client chose you, the concern they raised most often and any commitments made outside the formal proposal. Delivery needs this context to make good choices when the brief leaves room for interpretation.
Keep the handover concise enough to read before kickoff. Link the original conversation for detail, but do not require the team to reconstruct the engagement from a long email thread. If a promise cannot be verified, label it as a question to confirm with the client.
| Handover field | Useful answer |
|---|---|
| Business objective | What should change for the client? |
| Success evidence | How will they decide the work is useful? |
| Decision process | Who reviews, approves and resolves disagreement? |
| Open concern | What could delay the first milestone? |
Send a welcome message that answers the next question
A useful welcome message explains who is leading the work, what happens next, what you need from the client and where decisions should be recorded. It should reduce uncertainty without introducing a long list of tools or rules.
Be explicit about dates and dependencies. ‘We plan to present the first direction on Tuesday, provided the source assets arrive by Thursday’ gives the client something they can act on. Avoid presenting a tentative date as an unconditional promise.
- Introduce the project lead and the client’s main contact.
- Explain the next milestone and anything needed before it.
- Name the place for project questions and feedback.
- Share the kickoff agenda and invite missing decision makers.
Use kickoff to confirm decisions, not repeat the proposal
Circulate the brief before the meeting. Spend the conversation checking understanding: what matters most, where the team can make its own decisions and what requires client approval. Invite the people who can answer these questions, rather than everyone who might eventually see the work.
Close by reading back the first commitments. Record the decision, owner and date while everyone can correct it. Send a short summary afterwards with the links to the agreed brief and the first milestone. A meeting recording can supplement this summary; it should not replace it.
Check the handover after the first week
Ask the delivery lead what they had to ask twice and ask the client what was unclear. These are more useful improvement signals than whether your onboarding checklist contained every possible field.
Remove fields nobody uses, clarify questions that produced vague answers and add a condition only when it solves a recurring problem. Onboarding should prepare the work, not become a separate administrative project.
- Can the team state the agreed outcome without asking sales?
- Does the client know the next milestone and their part in it?
- Are blockers owned, with a next check-in date?
- Were new commitments added to the project record?
Client handover checklist
Copy this into your next client project and replace the bracketed fields.
CLIENT HANDOVER Client: [name] Project lead: [owner] Client approver: [name] Outcome: [what should change] Scope and evidence: [link] First milestone: [deliverable and date] Client inputs needed: [item / owner / date] Open questions: [question / owner / next step] Communication location: [link] Ready to start: [yes / blocked, with reason]
Bring the context into your workspace.
Explore how Tamaam connects the relationship and the work around it. Tamaam is in development; product pages show previews and illustrative workflows. Joining early access does not start a subscription.
Found something we should clarify? Send a correction or question.
