Stale deals: test each fact's proof, not the last activity
A deal goes stale fact by fact, often while the CRM still shows activity. Mark each fact proven, assumed, stale, contradicted or missing, and ask the customer for the proof the fastest-ageing fact needs.
Take one deal and list the facts it rests on: the decision date, the budget, the problem and technical fit. For each, ask who at the customer confirmed it, in what form and when, and mark it proven, assumed, stale, contradicted or missing. A deal with recent emails and calls can still rest on facts that stopped being true weeks ago, and only the proven ones should hold up the forecast.
Every qualification element is an evidence claim, and each claim has an age: a decision date loses its standing much faster than a signed-off test result.
Pipeline hygiene: what a stale flag in the CRM measures
CRM stale flags use different clocks. Capsule flags an opportunity stuck in a milestone "without any communication stored", Freshsales counts "the time elapsed from the day of deal creation", and Pipedrive's rotting clock restarts on actions that include "sending, receiving, archiving, unlinking, or deleting emails linked to the deal". In Pipedrive, a seller's email can reset that clock without confirming any deal fact. Use a stale flag to find deals to inspect, then check the evidence behind each fact.
Five statuses for a deal fact
Give every fact in the deal one of five statuses:
Proven: the person who owns the fact confirmed it in their own words, a document of theirs or an action, and you have the record with its date.
Assumed: you inferred it, or someone else passed it on. A contact telling you the budget is approved is an assumption about the budget holder.
Stale: it was proven, but the evidence needs reconfirming because of its age, silence or a change that may affect it.
Contradicted: something the customer said or did later conflicts with it. A decision date that passed without a decision is contradicted, and so is a budget the customer has since frozen.
Missing: no one at the customer has said anything about it.
Use proven facts as the evidence for a deal's stage and forecast category. A proven fact on its own may not be enough to justify either. The other statuses tell you what to ask next. The five evidence questions for each MEDDICC element cover what counts as an answer; the status adds when that answer was given and whether it still holds.
Two clocks: the age of the proof and the customer's silence
Two clocks matter. One tracks when the customer last confirmed each fact. The other tracks the customer's silence across the deal. Silence is a reason to review earlier evidence, not proof that every fact has changed. What needs reconfirming depends on the fact and what has happened since.
Set the windows from your own sales cycle, as a rule of thumb, and keep this order:
Start with the decision date. It concerns a future commitment: if the date passes without a decision, the earlier date no longer holds.
The budget comes next. An approval belongs to someone with authority, and that person or their priorities can change without your contact knowing.
Then check the problem. The impact and the customer's sense of urgency can both change, even when the original problem remains.
Check technical fit too. A signed test result records what happened against the criteria at the time. Ask whether those criteria, the system or the people evaluating it have changed before treating the result as current proof of fit.
In Lightspeed's 2024 Sales Benchmark Report, a survey of 154 companies across its portfolio and network, new deals had a 41% slippage rate, and only 62% of delayed deals eventually closed. When the customer changes a decision date, record the new date and who confirmed it. If an old date passes without a decision and no replacement is confirmed, the old date no longer supports the forecast. Your quarter-end date is not evidence of the customer's deadline.
Worked example: one deal read on two dates (names and dates invented)
A software deal is reviewed on 2 September and again on 14 October.
On 2 September, the record looks complete. The problem is proven: the operations director wrote on 20 August what the outages cost her team. Technical fit is proven: the customer's architect sent signed test results on 27 August. The decision date is proven: the IT director who chairs the steering group wrote on 28 August that it decides on 30 September. The budget is assumed: the seller's call note of 25 August says the contact called it approved, and the contact is not the person who approves it. The close date in the CRM is 31 October, which is the seller's quarter end. No one at the customer gave that date, so it is missing.
By 14 October the customer has sent nothing since 10 September. The seller has logged two sent emails and a call that went to voicemail. Suppose the CRM treats those as activity and shows no stale flag. Read fact by fact, the deal has changed:
Decision date: 30 September passed with no decision and no new date. Contradicted.
Budget: still assumed. The seller's 25 August note is seven weeks old.
Problem: proven eight weeks ago, with five weeks of silence since. Stale.
Technical fit: the signed results stand, and nothing suggests the requirements changed. Still proven.
Close date: still missing.
Of the five, only the test result remains supported in this review. It is not enough on its own to support the deal's forecast category. First ask the decision owner what happened to the missed decision and whether there is a new date.
The proof to ask for next, fact by fact
Ask for the proof that would move a fact back to proven, from the person who owns it.
Start with the deal you are least sure of. Write each fact on its own line with its status, the person who confirmed it and the date, and send the one request the fastest-ageing fact needs this week. Can you, or whoever forecasts this deal, tell what was agreed, who it covered and whether it still applies? If not, the fact is not proven yet.
In my opportunity qualification training with MEDDICC, a widely used third-party framework, each participant brings a current opportunity and leaves with the next customer meeting prepared. Managers get review questions for pipeline reviews and one-to-ones.
| Fact | Proof from the customer | Stale or contradicted when | Ask next |
|---|---|---|---|
| Decision date | Proof from the customer The decision owner's date, in their own email, invitation or plan | Stale or contradicted when The date passes without a decision, or silence leaves the current date uncertain | Ask next What has to happen before you decide, and who sets the new date? |
| Budget | Proof from the customer The approver's own statement of what they can approve | Stale or contradicted when Assumed if only the contact reported it; recheck if the approver changes | Ask next What can you approve for this purchase, and whose agreement do you need? |
| Problem | Proof from the customer The customer's own description of what it costs them | Stale or contradicted when The person who described it has gone quiet or moved on | Ask next Does this still land on your team, and has the cost changed? |
| Technical fit | Proof from the customer The customer's sign-off of results against their own criteria | Stale or contradicted when Recheck current fit if requirements, the system or evaluators change | Ask next Have your requirements changed since you signed off the results? |
| Close date | Proof from the customer A customer-confirmed purchase date; a consequence helps establish its urgency | Stale or contradicted when Missing customer confirmation if the date is only your quarter end | Ask next Which date on your side does this purchase have to meet? |
Sources
- Stages of an Opportunity. Capsule CRM, undated.
- What are stale deals? How do they work? Freshworks, 15 February 2024.
- The Rotting feature. Pipedrive, 3 September 2026.
- Lightspeed's 2024 Sales Benchmark Report: Key Takeaways for Startup Founders and Sales Leaders. Lightspeed Venture Partners, 20 November 2024.
Facts last checked on 4 November 2026.