Accepted Proposal to Project Kickoff: A Small Service Team Handoff

Quick answer: When a customer accepts a service proposal, transfer the agreed scope, open questions, decision makers and next date into one delivery record before anyone starts work. The salesperson’s “yes” is a milestone; it is not a complete brief for the person who will do the job.

For: a small service team where the person who wins an enquiry is not always the person who delivers it. This is an operating checklist, not contract advice. The example below is hypothetical and makes no claim about customer outcomes.

Decide what has actually been accepted

Begin with the latest agreed proposal or written summary. Record its version and date, the selected option, and any change the customer accepted after it was sent. Do not ask a delivery colleague to reconstruct scope from a CRM stage, a calendar booking and a long email thread. If the customer’s reply is ambiguous, let the account owner clarify it before work is scheduled.

Separate three statuses in the record: agreed (a decision has been confirmed), open (someone must answer it), and assumed (the team has a working guess). An assumption should never quietly become a promise. This is particularly useful when a quote includes several options or exclusions.

Use a handoff table that leads to an action

The point of the handoff is to let a new owner answer “what do I do next?” without replaying the sale. Keep the record short enough that the team will maintain it. On a phone, swipe the table sideways to see every column.

Do not move private credentials into this record. Link to the normal approved access route if the work needs account access. For client documents, decide who should upload, view and revise them; the client-file exchange guide gives a way to choose a route. Do not email a password because a handoff checklist asks for “access.”

Run the transfer in five steps

1. Freeze the accepted version. Put one proposal reference in the handoff record. List later agreed changes with their date and who confirmed them. If an option is not chosen, mark it open.
2. Assign two owners. The account owner remains responsible for commercial clarification; the delivery owner owns the work plan. If one person fills both roles, write the name once and keep the responsibilities clear.
3. Check capacity and dependencies. Compare the requested start with actual availability. Identify any client input needed before a task can begin. A target date can be shared as a target; do not silently treat it as booked capacity.
4. Send a short kickoff summary. State the agreed service, first step, who to contact, what you need from the customer and when the next update will arrive. Ask for correction if any item is wrong.
5. Close the loop internally. The delivery owner reads the record, raises missing information and explicitly accepts the handoff. Update the CRM stage only when your team’s stage evidence is met; our stage exit guide explains how to define that evidence.

Atlassian’s current project kickoff play calls for clear roles, a shared purpose and success criteria. Its play is a resource for larger group kickoff conversations. The five-step transfer here is an editorial adaptation for a small service job; it does not require adopting a particular project-management tool.

See a hypothetical handoff

A fictional consultancy offers an audit with an optional implementation phase. The client writes, “Let’s do the audit in November.” The account owner records: proposal v3 with its recorded date; audit accepted; implementation not accepted; customer approver [name]; delivery owner [name]; input needed [existing process notes]; target kickoff in November, subject to capacity confirmation. The delivery owner can now schedule the audit without assuming an implementation sale.

If the customer later asks to include an extra department, record that request as open until the appropriate person confirms its effect on the work. Do not hide the change in a comment on an old task. The useful test is whether a teammate who was absent from the sales call can identify what is agreed, what is open and what they should do today.

Give the customer a clear first message

“Thanks for confirming [accepted service and proposal reference]. [Delivery owner] will lead the next step. We plan to [first action] on [confirmed date or stated target]. Before then, please send [specific input] through [agreed route]. We will update you by [achievable time]. If our summary of the agreed work is incomplete, reply before we start that part.”

This is sample wording, not a ready-to-send promise. Replace every bracket with verified information. If the date is a target, say so. If the service depends on an input the customer has not yet agreed to provide, ask rather than imply it has arrived. Keep the customer’s requested communication route in view. The lead follow-up guide covers the earlier enquiry and proposal stages; this guide begins after acceptance.

Copy the working record and do one check

Project reference: ___ · accepted proposal/version and date: ___ · included work: ___ · excluded or unselected work: ___ · agreed changes: ___ · customer approver/contact: ___ · account owner: ___ · delivery owner: ___ · inputs and approved route: ___ · confirmed dates versus targets: ___ · open questions with owners: ___ · next customer update: ___ · delivery owner accepted on: ___.

Pick one recently accepted project. Ask the delivery owner to find its scope version, first task and next customer update without asking the salesperson. Fill the missing field, then make the handoff record the place both people check before kickoff. If the work needs a broader project board, choose it after this minimum record is reliable.

Source checked 2 October 2026: Atlassian Team Playbook, Project Kickoff. The specific handoff fields, status labels and example are Practical SaaS Lab editorial recommendations. No software was tested and no measured improvement is claimed.