Customer handover between sales and delivery is successful only when the receiving team can fulfil the actual promise without asking the customer to start again. A signed quote may confirm the product and price, but delivery also needs agreed scope, locations, important dates, required customer inputs, exceptions and a named owner. The handover is not merely a CRM status change. It is an exchange of accountable information, followed by the receiving team's acceptance that the work can proceed.
For a UK product or service supplier, errors can affect promised dispatch dates, installation arrangements and the commercial relationship. This guide sets out a practical handover design that distinguishes confirmed facts from assumptions, makes ownership transitions visible and tests whether the customer experiences continuity. It uses the UK Government Data Quality Framework to explain why a field that is filled in is not necessarily correct, and a verified process-mapping illustration to clarify what each team supplies and receives.
1. Agree the exact trigger for the handover
First decide what authorises delivery preparation. An accepted quotation, signed agreement or confirmed purchase order may be the proper event, depending on the company's business. A deal marked likely to close is not necessarily permission to reserve stock or promise an installation date. Record the source agreement and version; a salesperson's positive conversation should remain a proposed opportunity until the agreed commercial acceptance occurs.
Define an interim state for orders missing technical prerequisites or customer approval. Sales may be able to prepare an outline for delivery before acceptance, but the team should see which actions remain provisional. An automatically created delivery task should never silently turn an estimate into a confirmed instruction.
Assign responsibility for preparing the handover and for accepting it. If the receiving manager finds missing information, the work must remain visible with a named person able to clarify. The business should not describe the transfer as complete merely because an assignment property has changed.
2. Carry the customer's intended result, not just the SKU
A product name and quantity explain what was ordered, but not always why the customer chose it. For specialist equipment, delivery may need to know the intended operating environment, compatibility requirements or access constraints. For a service engagement, the customer may have agreed a particular outcome or reporting arrangement. Record these requirements alongside references to the accepted commercial scope.
Keep the customer's statements distinct from interpretation. A note saying the customer hopes to begin using a device next Tuesday is not equivalent to a promise that installation is booked. Distinguish requested, estimated and confirmed dates. Where a material assumption remains unresolved, present it to delivery as a question rather than silently recording a final value.
Use a small case-specific pack rather than dozens of compulsory fields. The handover should give delivery enough context to plan and make decisions. Overloading the record with irrelevant sales commentary makes important conditions harder to find.
3. Separate confirmed commitments from possible options
Review delivery dates, service locations, product variants, pricing exceptions, warranty terms and other material promises against the accepted source. Staff can discuss options without binding the business to them. When a salesperson has suggested a faster dispatch or optional installation, label it as proposed until the authorised commitment is confirmed.
A handover should link to the signed scope or order reference, not depend on a summary that may omit qualifications. When the scope changes, retain the earlier approved version and identify the amendment authority. It should be possible to explain why a changed task was introduced without rewriting the original agreement.
Give the delivery team a route to challenge impossible or contradictory promises before telling the customer the work is scheduled. The objective is not to excuse poor preparation; it is to uncover an issue while a responsible colleague can resolve it properly.
4. Identify dependencies and exceptions before scheduling
List the information and resources needed to carry out the work: stock allocation, equipment compatibility, site access, customer contacts, permits where relevant and specialist availability. Separate prerequisites already completed from those awaiting evidence. If a customer has not confirmed access arrangements, the installation may be ready for planning but not final booking.
Record who must resolve each missing item and where its outcome will be stored. An engineering specialist may confirm compatibility; purchasing may check stock; finance may resolve an approval condition. The receiving delivery coordinator should see the outstanding decisions without being forced to search private chat messages.
Test exception paths such as an order with an incorrect postcode, a split delivery, one discontinued product or a customer requiring several site visits. A useful handover shows what can proceed and what must wait, rather than marking the entire project as ready merely because the ordinary template was completed.
5. Use CRM as a controlled reference, not a second ledger
CRM can link account ownership, opportunity history, order references, accepted documents and next actions. It should not silently become an authoritative inventory or accounting ledger. Agree which application owns each fact, including product stock, invoice status and confirmed shipment handover. Show verified links in CRM where delivery needs them, and make source timestamps available for consequential decisions.
For shared data, the Government Data Quality Framework distinguishes completeness, accuracy, consistency, timeliness, validity and uniqueness. These dimensions are useful beyond its public-sector context. A populated promised-date field can be complete but inaccurate if somebody entered a speculative sales date. Likewise, a customer owner field may be correctly formatted but out of date.
Use stable identifiers to avoid matching different company branches on name alone. Where the CRM and order system disagree, create a reconciliation task rather than letting the last integration event overwrite a verified customer commitment.
6. Require receiving-team acceptance and a customer introduction
Have the delivery owner acknowledge the case only after reviewing material commitments and prerequisites. For routine repeat orders, a brief structured acceptance may be enough. For complex or unusual projects, a direct conversation between sales and delivery may be necessary to interpret the customer's expectations. The documented outcome of that conversation should remain available to staff who later take over.
Tell the customer who now coordinates delivery, how to contact them and what the verified next step is. Avoid promising a date or capability that the receiving team has not confirmed. The introduction should be concise, respectful and based on the information the customer has already provided; there is no need to make them repeat the sales conversation.
Keep responsibility visible during the overlap. Sales may remain involved in commercial changes, while delivery owns operational scheduling. If the customer requests a scope variation, route it to an authorised commercial reviewer without allowing one team to assume the other has approved it.
7. Test delays, changes and incomplete handovers
Prepare a representative test set: ordinary repeat order, equipment requiring technical checks, missing site details, changed accepted date, customer with two active projects and a failed CRM-to-delivery connector. Specify the expected owner, source link and next action before testing. A duplicate event must not create two jobs or trigger two welcome messages.
Ask a delivery colleague who did not participate in the sale to identify the agreed outcome, current scope, outstanding dependencies and customer-facing commitments. If they cannot do so without interviewing the customer, the handover needs improvement. A green workflow status is not sufficient evidence of understanding.
Reconcile the initial case after an integration outage. Preserve original source-event IDs, check what the destination already contains and do not replay an outdated task if the agreement has since changed. Any delayed notification must describe the verified current position.
8. Use feedback to improve the preceding sales process
Measure avoidable clarification loops, incorrect start dates, missing approvals, duplicated customer records and occasions when customers must restate details. Sample source documents rather than relying entirely on staff self-report. Avoid claiming that a handover improvement caused increased retention or faster delivery without a suitable baseline and relevant comparison.
When several orders arrive without a compatibility field, improve discovery or quoting rather than asking delivery to chase indefinitely. Where an important date is recorded ambiguously, change the definition and training. A correction should fix the origin of the error, not merely add another mandatory box to the handover form.
Finally, review open work when a salesperson or delivery coordinator leaves. Handovers are not only a sales event; they are a continuity principle. A good system preserves who made a promise, which facts supported it, who now owns execution and what the customer can reasonably expect next.
Handover quality depends on trustworthy shared information
The UK Government Data Quality Framework distinguishes completeness, accuracy, consistency, timeliness, validity and uniqueness. Although designed for public-sector data management, the dimensions provide a practical check on CRM handovers. A field labelled 'agreed delivery date' may be complete but inaccurate if it contains a sales estimate rather than a confirmed customer commitment. Similarly, the receiving team might see a valid account owner who is no longer responsible for the project.
Test a sales-to-delivery handover against the actual accepted proposal and customer correspondence. Distinguish confirmed scope from assumptions, remaining dependencies from completed prerequisites, and decisions from proposals. Give the receiving owner a route to reject or clarify inconsistent records before promising implementation dates. Preserve source links so the team can investigate contradictions without repeatedly asking the customer for already-agreed facts.
Practical measure: review exceptions such as missing approvals, incorrect dependencies and customer requests to repeat their original requirements. Merely transferring a completed CRM form is not independent proof of an accurate handover; the framework does not mandate any particular sales-delivery template.
Official reference
What must be transferred: an accepted order record or a reviewed delivery pack?
The accepted order is the commercial authority; the delivery pack makes dependencies, ownership and remaining uncertainty actionable. Neither should replace the other.
| Criterion | Accepted commercial record | Reviewed delivery handover |
|---|---|---|
| Scope | Signed items, terms and approved variations. | Maps approved scope to practical tasks and exclusions. |
| Dates | Identifies actual customer commitments. | Confirms resource, access and supplier prerequisites. |
| Unknowns | May include conditions requiring clarification. | Shows open questions with named owners and stop points. |
| Data quality | Authority of the documented promise matters. | Checks source accuracy, completeness and timeliness. |
| Acceptance | Customer's commercial agreement to proceed. | Delivery team's acknowledgement of responsibility and readiness. |
Practical decision: never convert an estimated term into a delivery promise merely because it appears in CRM. Transfer the accepted source and require a reviewed handover where delivery depends on additional checks.
Side A source: UK Government — Government Data Quality Framework, official public-sector data-quality guidance, accessed 1 November 2026; it supports checking field meaning and accuracy but is not a commercial contract rule. Side B source: Peter Gladdish — SIPOC process map, 27 August 2026, process-scope illustration showing explicit inputs and outputs. This is an editorial comparison of distinct evidence stages, not a measured vendor benchmark.
Frequently Asked Questions
What information belongs in a sales-to-delivery handover?
Include the customer's desired outcome, confirmed scope and material commitments, relevant contacts, dependencies or unresolved questions, agreed next actions and clear ownership. The exact fields should reflect what the delivery team genuinely needs rather than a universal form.
Should the handover be a meeting or a document?
Use the lightest combination that reliably transfers context. A structured CRM record or document can preserve facts and decisions, while unusual or complex work may benefit from a direct conversation. Neither format should force the customer to repeat information the business already has.
How can a business tell whether handovers are improving?
Look for recurring clarification loops, missing commitments, unclear ownership, avoidable customer repetition and surprises after signature. Use patterns from delivery feedback to improve qualification, proposals or CRM prompts rather than treating one metric as definitive proof.