A sale is not ready for delivery simply because a proposal has been accepted. Operations needs a clear account of the promise, the assumptions and the customer’s responsibilities. A structured sales-to-operations handover reduces ambiguity and helps the business deliver the agreed scope without quietly transferring unresolved questions to the execution team.
Define when the handover happens
An internal handover transfers responsibility and information from sales to delivery, with confirmation that the recipient understands and accepts them. This differs from handing the finished product or service to the customer. Choose a trigger appropriate to the business, such as contract approval and confirmation of required commercial conditions. Do not use a vague “deal won” status if important details remain unresolved. For complex work, involve operations before the final commitment so capacity and feasibility can be checked.
Separate preliminary planning from authority to begin chargeable work. Confirm who may approve a start, what evidence is needed and which exceptions require escalation. The handover should make commercial decisions visible rather than leave the delivery team to infer them from an email thread.
Create a concise handover record
Scope defines what the business will deliver and what the agreement excludes. Acceptance criteria are the agreed conditions used to judge whether outputs are complete. A dependency means that work cannot start or finish until an input arrives or another activity is completed.
| Item | What delivery needs |
|---|---|
| Scope | Deliverables, exclusions and accepted version |
| Timing | Milestones, dependencies and agreed dates |
| Acceptance | Who approves the result and on what evidence |
| Customer inputs | Access, data, approvals or materials required |
| Open issues | Owner, due date and effect on starting work |
Link to the authoritative agreement instead of copying inconsistent versions into several systems. Record where an assumption still needs confirmation. A blank field should not be interpreted as approval or as an unlimited commitment.
Connect each promise with delivery evidence
Select specific commitments from the accepted proposal, such as an analysis, a review session or a delivery date. Identify the evidence that will show completion and who will review it. If the proposal uses a broad expression such as “comprehensive support”, clarify its meaning before the team and customer develop different expectations.
- Distinguish approved commitments from proposals not yet accepted.
- Identify the customer’s inputs, the organisation’s work and third-party contributions.
- Link each exception to a decision owner and review date.
- Communicate material changes to the team and customer through the agreed channel.
At the first delivery review, compare current work with the record. Interviews may reveal a wider requirement than sales understood, or essential data may be unavailable. Treat this as a scope or readiness question requiring a decision, rather than an informal request the team silently absorbs. Clear boundaries protect the commercial relationship and expose realistic options.
Check feasibility before accepting the transfer
The operations owner should confirm that the scope is understood and that the required people, materials and partners are available, or that a credible plan exists to secure them. Identify constraints that affect the promised dates. If the commitment cannot be met, refer it promptly to the authorised decision-maker with options and consequences rather than silently accepting it.
Commercial urgency does not remove delivery constraints. Where the business chooses an exception, record who approved it and how the consequences will be managed. Keep the customer informed through an agreed contact so several departments do not offer conflicting dates.
Example: an unconfirmed data deadline
In a hypothetical example for illustration, a consultancy sells a 4-week process review, assuming the customer will provide transaction data during the first week. The proposal mentions the review period but the handover does not identify the data dependency. Delivery starts without the records and the schedule becomes unrealistic.
A better handover names the dataset, customer owner, due date and effect of delay. The team confirms data requirements with the customer before agreeing the working schedule. If data arrives late, both parties discuss the impact and obtain approval for changes from their authorised representatives. The team does not extend the deadline unilaterally or turn an internal assumption into a new customer obligation. The example is illustrative and does not describe an ATMACSS client.
Make readiness to start an explicit decision
Review the handover with a sales representative and the person accountable for delivery. Ask the delivery owner to describe the outputs, boundaries and required inputs in their own words. This can expose differences hidden by a quick approval of a completed form. Decide whether the whole assignment can start, an independent part can begin, or an essential input prevents any start.
In the process-review example, the team might prepare interview questions before transaction data arrives. It cannot complete the transaction analysis without that data. Record what may begin, what remains on hold and who decides the effect of delay on the schedule. Starting preparation does not prove that every delivery condition has been met.
If a replacement employee takes over, use the same record and confirm what changed. Do not create a disconnected copy of the authoritative agreement. Check that file links work and that the recipient can access the approved version. A link in a form does not establish that information is accessible or current.
Confirm the shared understanding with the customer
Use a kickoff or confirmation step proportionate to the work. Introduce the delivery contact, explain the next milestones and confirm the customer’s inputs and acceptance arrangements. Give the customer a clear route for questions and changes.
This step should align understanding, not reopen settled commercial terms without reason. Capture material clarifications and ensure both the commercial and delivery owners can access them. Good internal documentation is insufficient if the customer has a different understanding of what will happen.
Keep changes separate from the original promise
Change control means recording a proposed adjustment, assessing its impact and approving it before implementation. New requests may emerge after the first customer meeting. Record the request, assess its effect on effort, timing and cost, and obtain the required approval before treating it as part of the agreed scope. Not every change needs a lengthy document, but material changes need a traceable decision.
Do not rely on a salesperson’s memory or an informal comment to resolve a dispute over commitments. Review the accepted agreement and approved changes. If the wording is ambiguous, clarify it with the authorised parties rather than presenting an internal assumption as a customer obligation.
Review handover quality through delivery evidence
Review handover quality when the assignment ends. Ask which information, if available earlier, would have prevented delay or rework. Add fields that address recurring problems and remove repetition that nobody uses. The aim is a short record that supports delivery, rather than a long form completed only to close the sales stage.
Track recurring missing information, avoidable rework and delays attributable to handover gaps. Use consistent definitions and avoid assigning blame from a single anecdote. Review completed cases with sales and operations together to identify which part of the process needs improvement.
ISO’s quality-management guidance explains the importance of connected processes, customer requirements and continual improvement. The proposed handover record is a practical tool for applying this thinking, not a mandatory ISO template.
Handover is complete when the delivery owner understands the required output, necessary inputs, authorised starting work and acceptance conditions. Keep one authoritative agreement, make unresolved issues visible and approve changes before turning them into work. This makes the start of delivery a decision that both parties understand.
Start with one recent order and compare the accepted promise with what delivery actually received. ATMACSS business development support can help connect commercial growth with reliable execution. For downstream fulfilment issues, see managing order and delivery exceptions.