I’ve spent the last decade watching Salesforce implementations happen with varying degrees of success – as a technical consultant, tier four support, product manager at Salesforce, and leader at an ISV.
Across different industries, client sizes, and delivery shop expertise, one area of pain that everyone experiences is the sales-to-delivery handoff. It’s rare for delivery teams to be delighted with what sales hands to them, and this lack of shared context impacts stakeholder trust and project timelines and budgets.
70% of failed software implementations fail because of misaligned, missed, or misunderstood requirements. Requirements are the foundation of successful projects, and poor sales-delivery handoffs are the first time projects can fail in this way. And they often do!
Root Causes of Bad Handoffs
There are three reasons sales-delivery handoffs suck.
First: Sales is incentivized to say yes. I’m a first-time founder, and the advice every single salesperson has given me on how to sell is: “always say yes.” As a former delivery person, horrifying! But you have to do what you have to do to close a deal, especially a big one. Their job is to close deals, not to tell the customer “we can’t do that.”
Second: Sales conversations are high-level by design. They’re about vision, transformation, and ROI. Even if the account executive is committed to not overpromising what the delivery team can actually do, they’re not getting into the nitty-gritty. As a result, potentially complex pieces get smoothed over and omitted. It’s not anyone’s fault – it’s just the nature of sales.
Third: Sales teams aren’t exactly known for their notetaking skills. This is not a ding on sales teams – they’re out there selling and juggling multiple opportunities, as they should be, not spending hours taking detailed notes and updating the CRM. It’s a problem as old as time!
The Cost of Bad Handoffs
Here’s what this looks like in practice.
Imagine that a company with >$5B in revenue and more than 3,000 employees needs to move a small part of their business from their legacy system, which looks like MS-DOS, to Salesforce. This small part of their business has <100 users. How long should this implementation take, and how much should it cost?
If you guessed more than two years and millions of dollars burned so far, and they’re still not live: congratulations, you guessed correctly!
When I was pulled into this project, the implementers and the client had not yet agreed on requirements. Yes, after two years.
What on earth had they been doing for years and millions of dollars? How did they get into this vortex of time and money?
- The person who sold them the product and the implementation was no longer at the company. When the client said, “But salesperson X promised us this!”, we had no way to verify or push back.
- The client was seemingly obsessed with having side conversations. One person from their team would talk with one person from my team, agree on something, and then never document it, or just document it somewhere that no one else was tagged in. You can imagine how that went.
- Someone in one department at the client org would agree to something, only to be overridden by someone else in another department at the client org: the client kept changing their mind. We could force internal alignment when these issues came up, but we couldn’t predict them. Every time, it was a disruption and a delay (and sometimes rework).
These aren’t all the fault of a bad sales-delivery handoff, but a bad sales-delivery handoff opened the door to scope creep and didn’t set clear expectations with the client about the cost of misalignment. The high-level vision that was sold was still aligned and clear – but the actual implementation details were impossible to agree on.
Not all projects are this messed up, of course. But many projects have a flavor of this: sales and the client agree to a high-level vision, eliding details, and everyone gets excited. But when the rubber hits the road – in other words, once delivery is handed the project – things get complicated. The high-level vision that sales promised breaks down into really complicated details to deliver, and it’s hard for the client to define the details.
Or keep them straight – I just talked to a delivery leader this week whose main problem is that clients keep changing requirements mid-build, but they don’t want to change their timeline or budget. They end up doing a lot of rework for free just to keep the client happy.
Requirements are the foundation of a project, and when sales hands you a pile of sand and calls it bedrock, you’re going to have a bad time.
If you’re reading this, you’ve probably seen these problems because they are so common. Maybe in your case, it was your initial discovery with the client, and they asked: “Wait, didn’t we already cover this with your sales team?” And on day one, you had to scramble. It’s not impossible, but it’s not a great start.
How To Make It Better
The incentive and process problems that cause bad sales-delivery handoffs are built into the structure of sales and delivery teams, so you might think that the only way to make them better is to totally refactor the culture and cross-departmental processes. Which obviously is not happening anytime soon!
But there are some small, practical steps you can take, without a big process overhaul, to improve sales-delivery handoffs:
1. Record Everything
It sounds obvious, but many teams aren’t doing this consistently:
- Record every sales discovery meeting.
- Store it in an accessible place.
- Use the recording.
Nearly everyone has #1 down – it’s actually leveraging those recordings that gets skipped. Nobody wants to watch hours of meeting records, so storing them in a place accessible to AI is essential.
Try routing all sales call recordings into a tool like Google’s NotebookLM. Then ask it questions like: “Did anyone talk about integrations?” or “Did they mention any specific workflows or automations?”
The delivery team doesn’t have to watch hours of recordings, and account executives don’t have to take notes.
2. Overlap
The best experience happens when sales and delivery are partners – sales will say “no” more for delivery, and delivery will say “yes” more for sales.
But you can’t always get that type of partnership – at the very least, it takes time and goodwill to build that trust.
In the meantime, you can prioritize overlap: include delivery tech leads in sales discovery calls once the deal is likely to close. The tech lead can listen in, flag areas of risk, and collaborate with sales to build responsible estimates.
Note that this has to be a tech lead, not a delivery leader. Delivery leaders are already in sales calls – it’s part of their job to sell. Tech leads are the ones who can actually assess technical feasibility, spot integration risks, and flag potential roadblocks before they become change orders.
3. Traceability
The ideal solution to the sales-delivery handoff is for delivery to get a digest of the sales conversations in a way that’s easy to understand, comprehensive, and automated. And most importantly, the context should be traceable, so you can know what stakeholder asked for what thing, and in what conversation.
NotebookLM can get you a comprehensive list of requirements from recordings. Including delivery on sales calls builds business context and client relationships. But purpose-built requirements management tools can tie these together – connecting each requirement back to the exact conversation, stakeholder, and timestamp where it originated.
Final Thoughts
You don’t need to implement everything at once. Start small. Incremental changes that benefit both sales and delivery will foster a culture of collaboration, which helps make even more changes happen.
The sales-to-delivery handoff will never be perfect. But for most shops, it can be so much better than it is right now. When you get it right, everything downstream gets easier: fewer change orders, fewer awkward client conversations, more transparency and trust.
That’s worth investing in.
