Deal rotting: next activity date and the weekend gap problem
A booked meeting is an intention, not activity. Why rotting should ignore next-activity dates, count weekends, and reset only on something that happened.
· 3 min read
The problem: a deal that looks healthy but isn't
A deal sits in 'proposal' for three weeks. Nobody has spoken to the customer since the initial call. But a meeting is booked for next month, so the deal card shows an upcoming activity and, in a lot of pipeline tools, that upcoming activity is read as a sign of life — the deal looks fine, sorted near the top, quietly not actually moving. The meeting is a plan, not evidence that anything has happened. Treating a future intention as current health is how a pipeline full of scheduled-but-dormant deals looks busy on a dashboard and produces nothing at the end of the quarter.
Rule one: rotting ignores the next activity date
A deal with a meeting booked for next month should still be counted as stale if nothing has actually happened recently. The alternative — treating a future plan as if it were recent activity — lets a lead be marked healthy on the strength of an intention nobody has acted on yet. This is a deliberate choice, not an oversight: a next-activity date describes what somebody intends to do, and a rot clock exists to describe what has actually been done. Conflating the two erases exactly the signal a stale-deal report is supposed to surface — the deal that looks fine on the calendar and isn't fine in reality.
Rule two: it counts weekends
A seven-day rot threshold set on a Monday should rot on the following Sunday, not skip forward to the next Monday because two of those days were a weekend. Calendar days, not business days, is the honest measurement of how long a customer has actually been left waiting — a customer who has heard nothing for a week does not experience two of those days as not counting. This is a small mechanical choice with a real effect: a business-days-only clock quietly gives every deal an extra day or two of grace it was never explicitly granted, which adds up across a pipeline into deals sitting stale for noticeably longer than the threshold suggests.
What actually resets the clock
The rot clock should reset on something that genuinely happened, not on something somebody typed about happening. A reasonable rule: any event in the deal's own activity history resets it — a reply from the customer, a note added, a stage change — and so does completing an internal follow-up task, since finishing a task is the business actually doing the work a next-activity date only promised. A note added by a salesperson about the deal, without any of those underlying events, still counts, because it is a real, timestamped thing that happened, distinct from a calendar entry describing something that hasn't happened yet. The distinction throughout is simple to state and easy to get wrong in practice: did something occur, or was something merely planned?
Two ways this goes wrong elsewhere
One common failure mode is having no explicit staleness threshold at all, and instead comparing a deal's time in its current stage against that salesperson's own historical average for that stage, flagging it only once it exceeds that average by some fixed margin. This produces a number that cannot be explained to the person it is shown to — 'why is this one flagged and that one isn't' has no answer a rep can act on, because the baseline it is being compared against is invisible and shifts as their own average shifts. A second failure mode is having a real threshold with a real bypass: a rotting or required-field rule that applies when a deal is edited one at a time, but is silently skipped during a bulk edit or an automation run, which is the same class of problem our guide to CRM required-field enforcement covers in detail — a gate that only guards one of several doors into the record isn't a gate, it's a suggestion.
What a rotting list should actually tell a manager
A useful stale-deal view names the deal, how long it has actually gone untouched, and what threshold it breached — worst first, so the deal that has been silent longest surfaces before one that just crossed the line yesterday. It should also be honest about gaps: a stage with no threshold configured at all should show up as unconfigured, not silently excluded as if every deal in it were fine. What this kind of list should not promise is automatically doing anything about the deals it finds — moving a stale deal, reassigning it, or nudging the customer on its own is a different, harder feature involving real trigger logic and real risk of acting on bad timing, and a rotting list that only flags and reports, honestly, is more trustworthy than one that quietly also takes action nobody explicitly asked it to take.
Common questions
Why would a deal with an upcoming meeting still count as stale?
Because a scheduled meeting is a plan, not proof that anything has happened recently. If nothing has actually occurred on the deal — no reply, no note, no stage change — since well before the meeting was booked, the deal has genuinely gone quiet, and a staleness system that lets a future plan mask that is hiding exactly the signal it exists to surface.
Does counting weekends in a rot threshold unfairly penalise deals that go quiet over a weekend?
It measures the honest elapsed time a customer has actually been waiting, which does include weekends from their point of view. A business-days-only clock quietly adds one or two days of unstated grace to every threshold, which sounds minor per deal but compounds across a pipeline into a rotting report that understates how stale things really are.
What actually counts as 'activity' that resets a deal's rot clock?
Anything in the deal's real, timestamped history: a customer reply, a note added about the deal, a stage change, or a completed internal follow-up task. A calendar entry for a future meeting does not count, because it describes something planned, not something that happened.
Should a stale-deal alert automatically reassign or nudge the deal on its own?
Not without real trigger-and-safety logic behind it, which is a materially harder feature than flagging. A rotting report that only surfaces what has gone stale, honestly and without silently also taking action, is more trustworthy day to day than one that quietly does something nobody explicitly configured it to do.