The handover from sales to delivery is where the margin goes
Sales tools are built to close and delivery tools are built to track work. Neither owns the moment between them, which is where scope quietly changes and nobody notices until invoicing.
A deal closes. Somebody types the details into the project tool. Work starts.
That retyping step is where a surprising amount of margin disappears, and it is almost never anybody’s job to fix, because it sits in the gap between two systems that each work fine on their own.
What the gap actually costs
The CRM holds what was sold: the scope in the proposal, the price, the terms, whatever was promised on the call to get it over the line. The delivery tool holds what is being built: tasks, assignees, hours.
Between them a human reads one and types the other, and three things happen every time.
Detail gets dropped, because retyping is summarising. The clause about two rounds of revisions was in the proposal and is not in the task list, so the third round happens and nobody flags it.
Detail gets added, because the person setting up the project knows what the work really involves and quietly includes it. That is competence, and it is also unbilled scope.
And the two records start drifting. When the client asks what was agreed, there are now two answers, and the one people reach for is whichever system they live in.
The reconciliation nobody schedules
By invoicing, someone has to work out what was actually delivered against what was actually sold. That reconciliation is real work, it is done under time pressure at month end, and it is done by comparing two systems that were never designed to be compared.
The usual outcome is not a dispute. It is a quiet decision not to bill for something because proving it would take longer than the amount involved. That is the margin, leaving without ever appearing in a report.
What fixes it, and what does not
What does not fix it: a better CRM, a better project tool, or a rule that people must be more careful. The failure is structural — two records of the same commitment, maintained separately by different people for different reasons.
What does fix it is making the sold scope the thing delivery is planned against, rather than a document delivery is inspired by. Concretely, three properties:
One record of what was agreed, which the project references rather than copies. If the proposal changes, the plan reflects it without anyone retyping.
Changes captured where they happen. A client asking for something extra on a call is a scope change. If capturing that costs more than three clicks, it will not be captured, and the tool has failed regardless of what it can do in principle.
Delivered-versus-sold visible before month end. Not as a report someone runs, but as a number that is already there when you look. The reconciliation stops being a task because it never accumulates.
The part that is genuinely hard
This is mostly an integration problem, and integration problems are underestimated in a predictable way. Two systems both have a concept of “customer”, and the two concepts do not match. One allows a customer to have several contacts, the other assumes one. One treats a closed deal as immutable, the other expects the plan to change weekly.
Mapping those honestly — deciding which system owns which fact, and what happens when they disagree — is the actual work. Teams that skip it end up with a sync that runs successfully every night and produces data nobody trusts.
We built OperationsHub around holding sold scope and delivered work in one place rather than syncing two. The demo page shows the handover step and what the delivered-versus-sold view looks like day to day.
If you would rather keep the tools you have and close the gap between them, that is an integrations and APIs scope, and the mapping questions above are the ones worth answering first.