A deal closes on Friday. By Tuesday, the project manager opens the folder, reads what was sold, and quietly does the math on how badly the next 90 days are going to hurt. The sales promises operations can't keep are already baked into the signed statement of work, and nobody is going back to renegotiate with the client.
This is the silent margin killer at almost every services and technology firm in the US and Canada. It's not that sales is lying. It's that the system lets them commit to things nobody on the delivery side ever validated.
The instinct is to blame the seller. They oversold. They didn't loop in delivery. They wanted the commission. That framing feels right, and it's wrong.
The reason sales makes promises operations can't keep is structural. The seller has a quota, a pipeline, and a buyer who wants answers in the room. Operations has capacity constraints, a backlog, and zero presence in the sales conversation. The CRM treats the deal as closed the moment it's signed, and the project is born inside a completely separate system — usually a spreadsheet, a Jira project, or a PM tool nobody from sales ever opens.
The result is two universes. Sales lives in commitments. Operations lives in constraints. The handover is the moment those universes collide, and the collision happens after the contract is signed.
Most firms try to solve this with a handover meeting. Sales walks operations through the deal, deliverables get reviewed, the PM asks questions, everyone nods. Some firms add a deal desk, a solution architect, or a pre-sale review checklist.
These fixes fail for one reason: they happen after the commitment is already made. A handover meeting after signature is an autopsy, not a negotiation. The PM can flag risks all day — the client already signed, the dates are in the contract, the scope is locked. Operations inherits the problem and has to absorb it through overtime, scope creep arguments, or a quiet margin haircut nobody talks about.
The deal desk model is closer, but it still operates as a gatekeeper sales has to get past — which means sales finds workarounds, especially when revenue is behind plan. Any process that depends on the seller voluntarily slowing down to validate feasibility will get bypassed the moment the quarter is on the line.
The reframe is simple. Sellers should not be the source of commitments about delivery. The system should be.
That means start dates, scope inclusions, team assignments, and timelines are not typed into a proposal by the seller from memory. They are pulled from operational reality — current capacity, defined service packages, tested timelines from similar projects, and team availability that lives in the CRM next to the deal. The seller's job is to position and qualify. The system's job is to constrain what can be promised.
This is what a properly architected CRM does. Each deal is connected to presale tickets that force discovery to happen before the proposal exists. Each proposal pulls from a library of scoped deliverables with known effort. Each timeline references capacity that operations actually controls. The seller can still negotiate — but inside guardrails the business set, not inside their own optimism.
Once that structure exists, the five promises below stop being commitments operations has to clean up. They become conversations sales has to have with the client in real time, with the constraints visible.
This is the most common one, and the most damaging. The seller closes the deal, the client asks when kickoff happens, and the seller — wanting to keep momentum — commits to a start date that has nothing to do with current team load.
Operations inherits a project that's already late before the kickoff call. The PM either pulls people off active projects (damaging those margins), runs the new project with the wrong team (damaging quality), or pushes the start date and burns the client relationship in week one. There is no good option.
The fix is mechanical. Start date commitments should be drawn from a live capacity view, not the seller's guess. If the next available slot is six weeks out, that's the date in the proposal. The seller can negotiate priority, escalate to leadership, or offer a phased start — but they cannot invent a date the delivery team never agreed to.
The client asks during the sales process if a specific integration, report, training session, or feature is part of the scope. The seller, reading the room, says yes. It feels like a small add. The contract gets signed with vague scope language.
Three weeks into delivery, the PM realizes the "small add" is forty hours of work the SOW doesn't price for. Now there's a conversation with the client about change orders, and the client remembers — correctly — that the seller said it was included. Margin gone. Trust dented.
The structural fix is a deliverable library. Every service the firm sells is defined as a discrete deliverable with known effort, dependencies, and price. The seller assembles proposals from that library. If a client asks for something that isn't in the library, that triggers a scoping ticket — not a verbal yes in the meeting.
Clients buying high-value services want to know who's working on their account. They ask about seniority, certifications, industry experience. The seller, wanting to win, talks about the firm's best people by name.
The senior people are 130% booked. They were 130% booked when the seller made the promise. The project gets staffed with whoever is actually available — usually a mix of mid-level and junior — and the client notices in the first two weeks. The senior person makes a token appearance on the kickoff, then disappears. The PM spends the rest of the project managing client expectations the seller created.
This one is harder to fix because clients legitimately want to know team composition. But the right answer isn't naming people who aren't available — it's having defined role-based staffing models, with experience levels documented and visible. The seller commits to a staffing pattern (one principal, two seniors, one analyst) backed by the resourcing system, not to specific names the firm can't deliver.
The client has a board meeting, a launch, a quarter-end. They need the work done by a specific date. The seller, reading the pressure, commits to the date.
The date is shorter than any comparable project the firm has ever delivered. The PM does the math and realizes hitting the date requires either cutting scope, doubling the team, or working weekends for two months. The seller is gone — onto the next deal — and the PM is the one telling the client at week four that the date is slipping.
The fix is historical data. Every project the firm has delivered has a real cycle time. That data should live in the CRM, tied to the deal record. When a seller is building a proposal, the system should surface comparable projects and their actual durations. Committing to a deadline shorter than 90% of comparable work should require explicit approval, not a verbal yes in a sales meeting.
The client describes their workflow, their existing tools, their process quirks. The seller — wanting to differentiate from competitors selling rigid templates — promises full customization to match.
Operations inherits a project where every assumption from the standard methodology is up for negotiation. Every meeting becomes a debate about how the client wants things done. Effort balloons. The project that was scoped at six weeks runs twelve. The client isn't being unreasonable — they're holding the firm to what was sold.
The fix is to be explicit about the line between configuration and customization. Configuration is the work the standard methodology already includes — adapting templates, setting up integrations, tuning workflows inside defined parameters. Customization is anything beyond that, and it's a separate priced item. The seller can absolutely sell customization. They just can't give it away as part of the base package.
If you're not sure how bad the problem is in your firm, these are the signals to watch for over the next 30 days:
If three or more of those are true, the problem isn't your team. The problem is that your CRM lets sales commit to things the delivery side has no way to validate before signature.
When commitments come from a system instead of from a seller's optimism, three things change immediately. Project margin stops eroding between sale and close because the scope is defensible. Operations stops being the department that says no to clients, because the boundaries were set during the sales conversation, not after it. And sellers stop being the villain in delivery's internal narrative, because the system constrained them in the first place.
The five sales promises operations can't keep don't go away because you trained the sellers better. They go away because the architecture of the deal — what can be committed, what triggers escalation, what data the proposal pulls from — makes the bad promises impossible to make in the first place. If you want to see how this actually looks inside a CRM built for firms that sell projects, here's the model we implement for services and technology companies dealing with exactly this handover problem.