What is deal slippage?
In practical sales language, a deal has slipped when its expected close moves later than previously planned. Salesforce explicitly supports historical reporting for opportunities whose close dates were pushed out, while HubSpot stores the expected close date as a standard deal property and also tracks time in the current stage.
That makes close-date movement easy to observe. It does not make every movement suspicious. Procurement can take longer than expected. A customer can change its buying calendar. A legal review can add a legitimate week. A date field can also have been unrealistic from the start.
The date moving is evidence of a changed expectation. It is not, by itself, evidence of the operating rule that produced the delay.
Before you call it slippage, ask what changed.
Review the individual deal first. What buyer event occurred since the last review? Is the next step dated? Did a new stakeholder or approval boundary appear? Is the close date now supported by stronger evidence, or has the date simply been moved because the previous date became impossible?
The single-deal question is: is the new date credible? The DriftMirror question comes one level later: does the same path to a pushed date keep returning across comparable deals?
Four different deals. The same path into slippage.
Repeated slippage is usually more useful than a slippage rate.
A percentage can tell you how much pipeline moved. It cannot tell you whether the same operating path produced those moves. For DriftMirror, the more useful unit is a mechanically comparable episode: the same kind of deal, inside a declared sales motion, with enough observable evidence to compare what happened before the date changed.
This is why two pushed deals do not automatically belong to the same problem. One might slip because procurement entered late. Another might slip after a technical review. A third might have no buyer continuation at all. Recurrence requires the same relevant sequence under comparable conditions, not merely the same final field change.
Six signals to inspect before a close date moves.
No dated buyer continuation.
The opportunity has activity, but no concrete next buyer step anchored in time.
Meaningful buyer movement stops.
Emails or internal activity continue while the buyer-side decision path stops advancing.
A late approval boundary appears.
Procurement, security, legal, finance or another approval enters after the expected path assumed it was already covered.
The close date moves without new evidence.
The date is pushed, but there is no stronger buyer commitment supporting the replacement date.
The same stage stays open.
The opportunity remains in the same commercial position while the calendar moves around it.
The same sequence appears elsewhere.
Comparable deals show the same path before their close dates move.
The close date is often the last visible event, not the first useful intervention point.
By the time a manager sees a pushed date, the important operating decision may have happened earlier. In the example above, the recurring sequence begins when a proposal can leave without a dated buyer continuation. The date move arrives later.
That matters because a rule change aimed only at “better close-date hygiene” can make the CRM cleaner without changing the sales mechanic. DriftMirror instead asks where the repeat is still permitted.
FROM DATE MOVEMENT TO OPERATING RULE
Do not repair the timestamp if the sequence keeps creating it.
A proposal may leave without a dated buyer continuation.
Before a proposal leaves, set the next dated buyer step.
Do not infer the rule from the sequence alone.
The sequence is evidence. The current operating rule is a separate claim. CRM history may show that proposals repeatedly leave without a recorded next step and are later followed by inactivity and date movement. That still does not prove the business rule that permits it.
If the system cannot resolve the rule cleanly, the correct next move is a narrow business confirmation — not an AI-generated root cause. This is an important boundary: DriftMirror shows what keeps happening first, then resolves the rule only where the evidence and business context support it.
A changed timeline can be legitimate. The surrounding evidence decides whether the move belongs to a recurring mechanic.
A cleaner CRM field does not prove the buyer path changed.
Missing data and negative evidence are different. If the source cannot observe the step, keep it unresolved.
One local change gives the next comparable deals a chance to tell you whether the path changed.
How to review slippage in the weekly pipeline meeting.
Start with the deals whose close dates moved since the previous review. For each one, decide whether the new date has concrete buyer evidence behind it. Then stop looking only at the deals individually.
Group comparable opportunities and inspect the sequences immediately before their date moves. If one sequence recurs, promote it from “another slipped deal” to a repeating mechanic. If the current rule can be resolved and one local change is testable, activate that change and watch the next comparable deals.
Related: stalled deals and pipeline review.
Slippage often appears inside the broader stalled-deal problem, while the weekly pipeline review is where teams can consistently separate one-off date changes from repeating mechanics.
Read the Sales Pipeline Review guide
Sources & further reading
Salesforce — Find opportunities whose close dates were pushed outHubSpot — Close date and time-in-stage deal propertiesGong — Sales pipeline tracking and deal-risk signalsSEE THE REPEAT
Stop treating every pushed date as a separate problem.
Open the synthetic workspace and follow one recurring mechanic from deal evidence to current rule, one local change, comparable retest and history.