It's Monday. Your operations lead opens a forwarded email from your top salesperson. Subject line: "New project — kickoff this week."
Inside: a PDF proposal, a thread with the client that's been going for three weeks, and a one-line note that says "let me know if you have questions."
Your ops lead has questions. A lot of them. The proposal mentions deliverables that aren't in your standard scope. There's a timeline that assumes resources nobody confirmed. Pricing references a discount your CFO didn't approve. And the client already thinks the project starts Wednesday.
This is the handover. And this is where the margin of the project starts disappearing — before a single hour of work has been logged.
If you run a company that sells projects, you probably already have a CRM. You have a project management tool. You have a finance system. You may even have integrations between some of them.
And yet, when a deal closes, the information that operations actually needs to execute well doesn't travel cleanly from one system to the next. It travels in a forwarded email, a Slack message, a verbal briefing in a hallway.
The reason isn't that your team is careless. The reason is structural: your sales process and your operations process were designed independently, by different people, with different priorities. They were never meant to share a single source of truth.
Your CRM tracks what your salesperson cares about — deal stage, close date, contract value. Your project tool tracks what your operations lead cares about — tasks, deadlines, resource allocation. Neither one tracks the conversation that happened during pre-sale. The promises. The exceptions. The reason the client agreed to the price.
It's easy to assume the handover problem is about documents — that if the proposal and the contract get to operations, you're covered. You're not.
What gets lost is everything that lives in the salesperson's head and never made it into a system. The off-hand comment the client made about a deadline being flexible. The internal discussion about whether to include a feature that's now ambiguous in the scope. The understanding that the client's procurement team is slow and you should start work before the PO arrives.
None of that is in the CRM. None of that is in the project tool. It exists only as informal context — and informal context evaporates the moment the salesperson moves on to the next deal.
The consequence: your operations team starts the project with an incomplete picture. They make assumptions. Some of those assumptions are wrong. By week three, there's a misalignment with the client. By week six, there's a difficult conversation about scope. By the end of the project, your margin is 40% lower than the proposal projected.
The instinct, when a handover goes badly, is to schedule a meeting. A kickoff call. A weekly sync. More documentation. A handover checklist.
This works for a while. Then the volume of deals grows, the team grows, and the checklist becomes another thing that doesn't get filled out properly. The kickoff meeting becomes a 20-minute summary that misses the same things it always misses, because the salesperson doesn't know what the operations team doesn't know.
The handover problem isn't a communication problem. It's a system problem. As long as the information about a deal lives in one tool, and the information about a project lives in another, the handover is a manual translation step — and manual translation steps fail at scale.
You can't checklist your way out of this. You have to redesign where the information lives.
The companies that have solved this don't have a better handover process. They have an architecture where the handover isn't a discrete event at all.
Pre-sale work — discovery notes, scope discussions, client commitments, internal exceptions — gets captured in the same system where the deal lives, in structured fields that operations can actually read. Not as PDF attachments. Not as email forwards. As data.
When the deal closes, the project doesn't get created from scratch in a separate tool. It's already there, attached to the deal, populated with everything operations needs. The salesperson doesn't "hand over" the project — they keep visibility into it. They can open the deal record six weeks later and see project health, hours burned, invoices issued, and pending issues. Without asking anyone.
Operations doesn't inherit a mystery. They inherit a fully briefed project with the context already attached to the record. The kickoff meeting becomes a 15-minute alignment, not a discovery session.
If you're going to fix this, the first step isn't choosing software. The first step is mapping where information actually lives today versus where it should live.
Walk through the last three projects you closed. For each one, identify the moments where operations had to ask sales for context that should have been documented. Write them down. You'll find a pattern: the same three or four types of information go missing every time.
Then look at your stack. Your CRM probably has the ability to capture this information — through custom fields, deal properties, associated records. The reason you're not capturing it isn't a tool limitation. It's that nobody designed the system to require it. Sales can close a deal without filling in the fields that operations will later need, so they don't.
The fix is to design a deal record where the fields operations needs are mandatory before the deal moves to "closed won." And to extend the lifecycle of the deal past the close — so the salesperson can see the project from the same record they used to sell it, and operations can update status in a place sales already lives in.
This isn't a tool change. It's an architecture change. Most companies that have HubSpot, Salesforce, or any modern CRM have the building blocks — they just haven't been assembled with this problem in mind.
The reason this gap exists in most companies is that whoever implemented your CRM was thinking about sales pipelines, not about how a project-based business actually runs. They set up deal stages. They added some automation. They moved on.
For a company that sells projects, that's about 30% of the work. The other 70% is designing how the deal connects to projects, tickets, invoices, and the actual operational execution that happens after the close. Without that, your CRM is a glorified contact database, and the handover problem will keep happening regardless of how good your sales team is.
If this sounds like the situation you're in — modern tools, smart team, but information still falls through the cracks every time a deal moves from sales to operations — the underlying issue is almost certainly architectural. Here's what an implementation built specifically for companies that sell projects looks like, including how the deal-to-project connection is structured so the handover stops being a recurring failure point.