Sales to project handover: give delivery the agreed work

The delivery packet

• Customer and people: day-to-day contact, approver and internal owner.
• Accepted baseline: dated proposal or scope version and evidence of the decision.
• Outputs and exclusions: what is being delivered and what is not.
• Inputs: files, access, decisions and the person supplying each.
• Prerequisites: commercial and operational conditions that must be confirmed through the real process.
• Dependencies: items blocking start or later milestones.
• Commitments: dates actually agreed, with conditions.
• Open questions: unresolved facts and the next person to clarify them.

Link source records instead of copying contradictory versions of the agreement into several places.

A fictional handover that is not ready to start

Sale: a five-page website, accepted scope revision 3. Customer approver: Dana. Delivery owner: Lee. Inputs: approved text and photographs from Dana; domain access through the agreed secure process.

Current evidence: scope accepted, but photographs and domain arrangements remain pending. Decision: prepare the project and ask for the missing inputs; do not announce the launch date as fixed. The commercial process separately confirms any required payment or activation condition.

Let delivery challenge the packet

The receiving owner should be able to explain the first task without asking sales to retell the entire conversation. Ask: “What was promised? What is missing? Who decides if the customer asks for more?”

Return ambiguous items as questions. “Standard package” is not enough when exclusions, language count or customer responsibilities were discussed separately. Preserve those decisions in the accepted baseline.

Confirm the handover, not just the project record

Record who received the packet, when and which questions remain. Separate “handover received” from “ready to start”. Notify the customer of the next contact and the actual next action.

This is an operating template usable in a document or your existing system. It does not assert that any CRM automatically verifies payments, transfers permissions or creates the complete project from a sales status change.

Worked example: a reception refurbishment handoff

This is a fictional example, not a completed customer project. Copy it without signing up and replace the facts before use.

• Accepted scope: repaint the reception and replace the agreed light fittings; structural work is excluded.
• Commercial evidence: link to the accepted proposal and verify any start-payment condition separately.
• Delivery owner: Sam; customer decision-maker: Alex.
• First milestone: confirm the site visit and material selection before agreeing a start date.
• Open question: who provides access outside business hours?
• Start condition: owner accepts the packet, scope is accessible and outstanding prerequisites have an owner.

Do not mark the handoff complete merely because a deal changed stage. Delivery must be able to find and understand the accepted agreement. This template does not promise automatic project or payment creation.

Continue with: Client Project Kickoff Agenda and Decision Record · Scope Change Request Template: Record the Decision Before Work Starts.