NextoraThe handoff from sales to delivery: where client projects lose their first week
The deal closes on Friday. On Monday the delivery team asks the client the same questions sales asked a month ago. A good handoff is the cheapest way to make a new client feel looked after.
Key takeaways
- Most handoff failures are lost context: promises, constraints and the client’s own words that lived only in the salesperson’s head or inbox.
- Write the handoff before the deal is marked won, while the salesperson still remembers the details and still has a reason to write them down.
- Open the project linked to the deal, so delivery can see the full sales history without asking for it.
- Give one person on the delivery side ownership from day one, and introduce them to the client in the same message that confirms the deal.
- Measure the gap between deal won and first delivery activity; anything over a few days is a process problem, not a capacity problem.
The handoff from sales to delivery is the moment a won deal becomes a project, and it is where client projects most often lose their first week. The cause is rarely bad intent or lack of capacity. It is lost context: the promises made in a call, the constraint mentioned in passing, the reason the client actually bought, all of which lived in the salesperson’s head and inbox and never reached the people doing the work.
The client notices immediately. They spent a month explaining their situation, signed, and on the first delivery call they are asked to explain it again. A good handoff fixes that with three things: a written brief made before the deal closes, a project that is linked to the deal so its history comes along, and a single owner on the delivery side from day one.
What gets lost, and why
Sales and delivery work on different timelines and in different tools. Sales lives in the CRM and the inbox, moves fast and is measured on closing. Delivery lives in a project tool, plans carefully and is measured on finishing. The deal record and the project rarely meet, so the handoff becomes a meeting or a forwarded email, and whatever is not said in it is gone.
The things that go missing are predictable:
| Lost context | How it shows up later |
|---|---|
| A date promised in a call | The client asks why the launch is “late” against a deadline delivery never heard of |
| Something explicitly excluded | Scope creep, because nobody can point to where it was ruled out |
| Who really decides on the client side | Work approved by the wrong person, then reopened |
| Why the client bought | Delivery optimises for the wrong outcome |
| A sensitivity: a bad past vendor, an internal sceptic | An avoidable misstep in the first meeting |
None of these is hard to write down. They are just never written down at the right moment.
Write the handoff before the deal is won
The best time to write a handoff is the stage before “won”, when the proposal is accepted in principle and the salesperson still remembers every detail. Once the deal is marked won, the salesperson’s attention has moved to the next one, and the handoff becomes a chore done from memory.
Make it a condition of the stage. If your pipeline has a “contract sent” or “verbal yes” stage, the exit criterion for that stage should include a completed handoff brief. Defining stages by what must be true to leave them is covered in pipeline stages with exit criteria.
The client’s own words
Of everything in a handoff, the most valuable line is usually a direct quote: why the client said they were buying, in their words. It tells delivery what success looks like to the person who signed, which is not always what the proposal says.
The handoff brief: ten questions
A handoff brief does not need a special template. It needs answers to these questions, in plain text, attached to the deal:
- What did we sell? Products, services, quantities, price.
- What is explicitly out of scope? Anything the client asked about that we said no to.
- What dates did we promise, and which are hard deadlines for the client?
- Who are the client contacts, and who makes the final decision?
- Why did they buy? In their own words if possible.
- What does success look like to them in three months?
- What worries them? Past bad experiences, internal politics, budget pressure.
- What did we promise that is unusual? A discount, a custom feature, a named person.
- Where are the documents? Proposal, contract, key emails, call notes.
- How involved will sales stay, and until when?
If the answers fit on one screen, delivery will read them. If they run to five pages, delivery will skim them and ask the client anyway.
An example brief
Here is what a good brief looks like for an illustrative deal: a €48,000 website rebuild for a manufacturing company.
Sold: new marketing site, 25 pages, three languages, hosting for 12 months. €48,000, half on signature. Out of scope: the customer portal they asked about; we said phase two. Dates: live before their trade fair on 3 March; that date is fixed. Contacts: Anna (marketing lead, day to day); the CFO signs off on anything that changes cost. Why they bought: “Our site makes us look smaller than we are.” Worries: their last agency missed a launch; Anna is under pressure internally. Unusual: we promised weekly progress calls. Documents: linked on the deal. Sales stays in: until kickoff.
That is under 120 words, and every line saves a question to the client or prevents a mistake. The fixed date and the reason behind it alone will shape how delivery plans the first month.
Link the project to the deal
A brief helps, but it is still a summary. The full picture, every email, call note and file from the sales process, lives on the deal. If the project is created as a separate record in a separate tool, delivery has to ask for that history or go without it.
The structural fix is to open the project linked to the deal, so anyone on the project can follow the link back and read the sales history themselves. This is the record model a CRM should follow anyway: a lead becomes a contact and a company, the money lives on the deal, and the work you promised happens in a project linked underneath. The reasoning is in the five records a CRM actually needs.
One owner from day one
The most common handoff failure is not missing information but missing ownership. Sales assumes delivery has reached out. Delivery is waiting for an introduction. The client hears nothing for a week after signing, which is exactly the moment they are most likely to wonder if they made the right decision.
Name the delivery owner before the deal is won, and introduce them to the client in the same message that confirms the deal. The salesperson stays available for an agreed period, typically until kickoff, and attends the kickoff to hand over in person. After that, the delivery owner is the client’s person.
For retainers and repeat work, the handoff is smaller but still happens. A client who signs a second project expects the team to remember the first one: the people, the preferences, the thing that went wrong last time. Keep the previous project’s notes linked to the company record, and make reading them the first task of the new project’s owner. Repeat clients are the ones most hurt by being treated as new, because they know you already have the answers.
How Nextora handles the handoff
In Nextora, a project is what happens after Won, and it sits underneath the deal rather than in a separate tool. Records are joined by links rather than copies: link the project to the won deal and the Connections panel in the project’s right rail leads back to the deal, so anyone on the project can open the full sales history, and open the deal with its full history, without asking for it.
Creating a project starts from a gallery of scenarios, client or internal, each with board stages, milestones and starter tasks; only the name is required, and Create now creates it straight away. Describe it in words composes a scenario from a sentence, and the scenario is saved under My recipes, so the next project of the same kind takes one click. A project can have several owners, and the set can never be emptied, so somebody is always accountable.
The handoff brief has a natural home in the project’s Notebook, a set of pages inside the project for the brief, the decisions taken and the note a new joiner needs. The project’s Chat is the team’s conversation, and a channel can be opened to the client, marked Client-visible, which is the same channel the client sees in the client portal. The Overview tab shows health computed from tasks, milestones, risks and dates, so a project that stalls after kickoff turns amber or red on its own, and the projects gallery puts those under Needs attention and Being monitored: a project with no owner, or one that has not moved for more than two weeks, is flagged automatically.
Giving the client a view of progress without giving them the CRM is covered in showing the client the project, and the projects page shows the workspace itself.
Measure the gap
One number tells you whether your handoff works: the time between a deal being marked won and the first real delivery activity, a kickoff meeting, a first task completed, a first message from the delivery owner. Track it for a quarter.
- Under two working days (a rough guide from our experience): the handoff is working. Keep the brief short and the habit alive.
- Three to seven days: usually an ownership gap. Check whether a delivery owner is named before the deal closes.
- Over a week: the client is already noticing. Look at whether projects are created from deals at all, or rebuilt by hand somewhere else.
A good handoff costs the salesperson twenty minutes and the delivery lead one read. It saves the client from repeating themselves, saves delivery from rediscovering scope, and makes the first week of a new relationship feel like a continuation of the sales conversation rather than a restart. If you want to automate the reminders, a workflow that starts when a deal changes stage and creates a task for the delivery owner once the deal is won is a small start; which automation tool to reach for explains the options.
Questions people ask
What should a sales to delivery handoff include?
At minimum: what was sold and at what price, the scope boundaries and anything explicitly excluded, dates or deadlines promised, who the client contacts are and who decides, the client’s reason for buying in their own words, known risks or sensitivities, and links to the proposal, contract and key conversations. Anything a client would be annoyed to be asked twice belongs in it.
Who owns the client relationship after the deal closes?
Ownership of the work moves to delivery, usually a project or account manager, from the moment the deal is won. The salesperson stays involved for an agreed period, often until kickoff, to answer questions and attend the first meeting. What fails is an unspoken arrangement in which both sides assume the other is in touch with the client.
Should the salesperson attend the kickoff meeting?
Usually yes, briefly. The client built trust with the salesperson, and seeing them hand over in person tells the client that what was promised is known to the people doing the work. The salesperson should introduce the delivery lead, confirm the key commitments out loud, and then step back.
How do you stop sales overpromising to delivery?
Make scope visible before the deal is won rather than after. Use proposal and contract templates that state what is included and excluded, involve delivery in pricing unusual requests, and review promised dates at a defined pipeline stage. Overpromising thrives when delivery only sees the deal once it is already signed.
See it on your own process.
Nextora brings CRM, projects, ERP, omnichannel conversations and AI employees onto one record model. Start a 14-day free trial, or book a demo and bring the process you want to fix.