Sales-to-delivery handover template

Define the handover boundary

Sales owns an accurate account of the agreement and the conversations that affect delivery. The delivery owner checks whether the proposed work can start with the available scope, capacity and inputs. The handover is complete when the receiving owner has reviewed the record and accepted it, or explicitly accepted a limited start with conditions.

This is an internal transfer of responsibility. Client onboarding is the wider process of collecting information, establishing communication and preparing the client for delivery. Use the onboarding checklist after the handover to manage that client-facing work. Keeping the two purposes separate avoids repeating the same questions in different trackers.

Gather the evidence before the meeting

Link to the accepted proposal or agreement, the latest scope and any approved changes. Add the relevant written decisions that clarify timing, exclusions or responsibilities. A CRM summary can point to this material, but a summary should not silently replace the accepted agreement.

Record a document version and the date you checked it. If two records disagree, identify the conflict and its owner. The person preparing the handover should not settle an ambiguity by choosing whichever version is easiest to deliver.

• Client and engagement reference; sales owner; receiving delivery owner; handover date.
• Client objective in the client’s terms, plus the first observable delivery outcome.
• Included deliverables, explicit exclusions and the agreed review or acceptance process.
• Timing, dependencies, named client decision-maker and agreed commercial start conditions.
• Open questions, risks, extra requests and promises requiring verification.

Run a short acceptance review

Send the completed record before the review so the receiver can inspect the source material. During the review, prioritise conflicts and missing decisions. Reading every field aloud is less useful than testing whether another person can explain what must be delivered and what would prevent a start.

The delivery owner records one of three outcomes. “Accepted” means the required information and readiness conditions are sufficient. “Accepted with conditions” permits only the work specified in the decision. “Returned for clarification” keeps ownership of the unresolved item with a named person and requires a new review.

A date in the calendar is not proof of capacity. If the proposed schedule has not been checked, label it as awaiting confirmation. The receiving owner should know which dates are agreed commitments and which are provisional planning assumptions.

Make exceptions actionable

Every open item needs a description, an owner, a due date and the decision or evidence that will close it. State what remains blocked while the item is open. Use the escalation route agreed for the engagement when the owner cannot resolve the item within the available time.

A verbal promise should be recorded as a claim to verify until the appropriate person confirms it. An additional request should be assessed through the agreed change process. Neither should be included as a delivery commitment merely because it appears in the notes.

Where work can start safely despite an exception, name the permitted tasks and the limit of that approval. If no one has the authority to accept the risk or the necessary information is missing, return the handover for clarification.

Worked example: a hypothetical training provider

This fictional example is for illustration; it is not a STRATEVOLVING case study. A training provider sells a remote workshop for a client team. The accepted scope includes one session and a standard participant workbook. Sales has also noted a request for a custom workbook, but no approved change exists.

The delivery lead accepts preparation of the standard workshop and records the custom workbook as an unresolved request. The sales owner must clarify whether the client wants a separately scoped change. The client contact must confirm participant numbers by the preparation deadline.

The receiving lead records “accepted with conditions”: standard preparation can proceed, custom content cannot. The record identifies the decision owner and review date. If participant numbers affect feasibility, the lead can instead return the handover until the required input is confirmed. The decision depends on the actual delivery constraints.

Keep one current record and learn from it

Save the accepted handover where both owners can find it. When an approved change affects delivery, update the current record and retain a short change history. Avoid circulating competing copies with different dates or informal scope changes hidden in chat.

Review the first milestone against the handover: which question was repeated, which commitment was unclear, and which missing input caused delay? Use those observations to improve the fields and acceptance criteria. A useful handover gives the receiver enough information to act without reconstructing the sale.

The download includes a blank record, an exception table and a decision block. Adapt the headings to your business and keep sensitive information in your controlled systems. If handovers repeatedly rely on the founder to explain everything, explore Optimize to structure responsibilities and a practical workflow with your team.