A client signs, the deal moves to won, and delivery gets a message: “New account. Let's get started.” A few hours later, the team is asking what was promised, who approves the work, and whether the assets are ready.
The founder becomes the place where missing context is stored. Every question comes back to the person who closed the deal.
I recommend giving delivery a short handoff with one clear purpose: let the team identify its next action and the conditions that could stop it. A closed deal should trigger that review.
Define what delivery needs to accept
Start with the outcome the client expects and the work your team has agreed to deliver. Link the signed scope or approved agreement so the handoff has a reference the team can check.
Then record the first delivery date, the client's approver, your delivery owner, and the inputs required before work can start. If a date depends on access or assets arriving, keep that dependency attached to the date.
This distinction matters when a sales conversation sounds more definite than the underlying commitment. “We can move quickly” does not tell an account manager whether the first batch is due Friday.
Attio's sales-led growth guide describes connecting activity before and after a sale, including handoffs with deal context. The operating question underneath is useful in any CRM: can the receiving team find the commitments it needs without reconstructing the sale?
Make the promises explicit
Consider an illustrative example. A content agency sells a monthly package of eight short videos. The initial handoff says:
“Eight videos a month. Kickoff October 19. First batch October 26. Client will send assets.”
That leaves several decisions open. Does “first batch” mean four videos? How many revision rounds are included? Who can approve a script? Does the delivery date hold if source footage arrives late?
A useful version records the answers:
Commitment | Handoff detail in this example |
|---|---|
Monthly delivery | Eight edited vertical videos, each 30–60 seconds |
First batch | Four drafts targeted for October 26, 2026, if required inputs arrive by October 20 |
Revisions | One consolidated revision round per video |
Client approval | Casey Morgan approves scripts and final edits |
Required inputs | Source footage, brand guide, and permission to use the supplied assets |
Scope boundary | Filming and paid media management require separate scope |
Each promise needs the conditions required to keep it.
Give each missing input an owner
“Waiting on the client” hides the action your team needs to take.
For the example above, the client approver sends source footage by October 20. The agency's account manager checks that the files open and confirms receipt. If the deadline is missed, the delivery manager proposes a revised draft date before the team makes another commitment.
Use the same approach for access, scheduling, and unresolved scope questions. Each item needs a named person, a date, and a next action. Keep uncertainty visible rather than filling a required field with a guess.
GitLab's Professional Services Delivery Methodology describes managing delivery against agreed scope, with clear responsibilities and changes reflected in the plan. The handoff template applies that general discipline to the moment a service business moves from selling to delivering.
Confirm scope, assign missing inputs, and get delivery approval before scheduling work.
Move the reference along with the work
The CRM can remain the home for the sale. The project system can hold delivery tasks. Give both a shared deal or engagement identifier and links to the handoff and approved scope.
If an integration creates the project when a deal is won, have it prepare a draft. Delivery should review the scope and prerequisites before the project is marked ready. This catches a missing approver or an unsupported delivery date while it is still easy to resolve.
Avoid copying the same commitment into several places without a clear owner for updates. If a client approves a scope change, update the authoritative scope, revise the handoff, and tell the people whose work changed.
The accompanying document includes a reusable handoff and a completed example. Its acceptance check asks whether delivery can identify the agreed work, the people involved, the open dependencies, and the next action.
Apply it to the next client who signs. Ask the delivery owner to read it before kickoff and mark what is still missing. That review will show you which parts of the sale need a better place to live.
Resources
A client signs, the deal moves to won, and delivery gets a message: “New account. Let's get started.” A few hours later, the team is asking what was promised, who approves the work, and whether the assets are ready.
The founder becomes the place where missing context is stored. Every question comes back to the person who closed the deal.
I recommend giving delivery a short handoff with one clear purpose: let the team identify its next action and the conditions that could stop it. A closed deal should trigger that review.
Define what delivery needs to accept
Start with the outcome the client expects and the work your team has agreed to deliver. Link the signed scope or approved agreement so the handoff has a reference the team can check.
Then record the first delivery date, the client's approver, your delivery owner, and the inputs required before work can start. If a date depends on access or assets arriving, keep that dependency attached to the date.
This distinction matters when a sales conversation sounds more definite than the underlying commitment. “We can move quickly” does not tell an account manager whether the first batch is due Friday.
Attio's sales-led growth guide describes connecting activity before and after a sale, including handoffs with deal context. The operating question underneath is useful in any CRM: can the receiving team find the commitments it needs without reconstructing the sale?
Make the promises explicit
Consider an illustrative example. A content agency sells a monthly package of eight short videos. The initial handoff says:
“Eight videos a month. Kickoff October 19. First batch October 26. Client will send assets.”
That leaves several decisions open. Does “first batch” mean four videos? How many revision rounds are included? Who can approve a script? Does the delivery date hold if source footage arrives late?
A useful version records the answers:
Commitment | Handoff detail in this example |
|---|---|
Monthly delivery | Eight edited vertical videos, each 30–60 seconds |
First batch | Four drafts targeted for October 26, 2026, if required inputs arrive by October 20 |
Revisions | One consolidated revision round per video |
Client approval | Casey Morgan approves scripts and final edits |
Required inputs | Source footage, brand guide, and permission to use the supplied assets |
Scope boundary | Filming and paid media management require separate scope |
Each promise needs the conditions required to keep it.
Give each missing input an owner
“Waiting on the client” hides the action your team needs to take.
For the example above, the client approver sends source footage by October 20. The agency's account manager checks that the files open and confirms receipt. If the deadline is missed, the delivery manager proposes a revised draft date before the team makes another commitment.
Use the same approach for access, scheduling, and unresolved scope questions. Each item needs a named person, a date, and a next action. Keep uncertainty visible rather than filling a required field with a guess.
GitLab's Professional Services Delivery Methodology describes managing delivery against agreed scope, with clear responsibilities and changes reflected in the plan. The handoff template applies that general discipline to the moment a service business moves from selling to delivering.
Confirm scope, assign missing inputs, and get delivery approval before scheduling work.
Move the reference along with the work
The CRM can remain the home for the sale. The project system can hold delivery tasks. Give both a shared deal or engagement identifier and links to the handoff and approved scope.
If an integration creates the project when a deal is won, have it prepare a draft. Delivery should review the scope and prerequisites before the project is marked ready. This catches a missing approver or an unsupported delivery date while it is still easy to resolve.
Avoid copying the same commitment into several places without a clear owner for updates. If a client approves a scope change, update the authoritative scope, revise the handoff, and tell the people whose work changed.
The accompanying document includes a reusable handoff and a completed example. Its acceptance check asks whether delivery can identify the agreed work, the people involved, the open dependencies, and the next action.
Apply it to the next client who signs. Ask the delivery owner to read it before kickoff and mark what is still missing. That review will show you which parts of the sale need a better place to live.