A deal is not stalled merely because it has been open for many days. The useful comparison is how long similar opportunities normally spend in the current stage, whether the record has recent or upcoming activity, and whether the stage has a defined exit criterion. Salesforce's current guidance distinguishes stage-duration behavior in paths and reports and describes stalled opportunities relative to historical averages. This lesson creates a portable operating rule rather than copying a universal day count.

VISUAL LESSON

What you will learn

  1. 01Calculate stage age from trustworthy history.
  2. 02Build cohort-based stall rules.
  3. 03Connect every flag to review, next step, recycle, or closure.
Deal cards move through pipeline stages while an aging clock flags one stalled record against historical patterns
A stage-aging flag is useful only when it compares similar deals and triggers a specific review or next step.

ILLUSTRATIVE WORKED EXAMPLE

Triage an illustrative proposal-stage cohort

Historical medianComparable won and lost cohort
12d
Review thresholdTeam-selected rule
18d
Current deal ageNeeds evidence review
22d
Days since activitySeparate neglect signal
15d
Illustrative example—not a benchmark. Replace every sample value with your own campaign, market, and measurement data.

PRACTICAL INTERFACE MAP

Move from raw history to an actionable stall queue

Measure01Build stage history

Record opportunity, stage entry and exit, re-entry, current age, owner, amount, segment, activity, and next step.

Compare02Create relevant baselines

Segment by stage, deal type, size, market, motion, and period; compare distributions rather than one overall average.

Act03Apply a reason-coded rule

Review exit criteria, customer evidence, next activity, close date, and owner; advance, hold, recycle, close, or repair.

Conceptual walkthrough. Labels, controls, and availability can vary by account, region, plan, and interface version; verify the current screen before acting.

STEP-BY-STEP LESSON

Stage history → cohort baseline → reason-coded flag → next action

HistoryEntry, exit, re-entry
BaselineComparable distribution
ActionAdvance, hold, recycle, close

THE LEAD ATLAS METHOD

Lead Atlas Data can build a custom business-contact list for the categories, markets, and territories where the pipeline needs new coverage, while the sales team repairs aging and follow-up in existing opportunities.See how custom list research works ↗
01

Define stages by evidence

For each stage, write entry criteria, required customer evidence, exit criteria, permitted backward movement, owner, and expected next action. A stage named Proposal is meaningless if some records enter after pricing is sent and others enter before discovery is complete.

Audit a sample of current opportunities against those definitions. Correct stage hygiene before calculating a baseline; otherwise the model measures inconsistent data entry rather than the sales process.

02

Build reliable duration history

Capture every stage entry, exit, and re-entry with timestamps. Salesforce notes that path and report stage durations can total repeated visits differently, so document the source and calculation. For a portable metric, calculate each interval and also total time spent in a stage per opportunity.

Add open date, current stage age, last activity, next scheduled activity, close-date changes, owner changes, amount changes, outcome, and segment. Preserve raw history so the team can distinguish a long first visit from repeated recycling.

03

Create comparable baselines

Segment history by stage, deal type, size band, market, product, acquisition motion, and a recent stable period when sample size permits. Review median, percentiles, spread, won and lost outcomes, and re-entry patterns. Do not publish a universal stage-day benchmark from a mixed pipeline.

Choose a review threshold from the business's own distribution and operating capacity. Label it as a trigger for human review, not proof the opportunity is dead. Record minimum sample and fallback rules for sparse cohorts.

04

Separate stalled, neglected, and legitimately long

A stalled record may exceed its cohort's stage pattern; a neglected record may have no recent or upcoming activity; a complex deal may be active with a documented timeline. Combine duration with last activity, next step, customer confirmation, close-date pushes, missing fields, and exit criteria.

Assign reason codes such as awaiting customer date, legal review active, no next step, no activity, stage criteria missing, owner transition, scope change, procurement timeline, or should close. Every flag needs evidence and an owner.

05

Run the review and repair the system

In a weekly queue, advance deals that meet exit criteria, hold active exceptions with a dated customer event, schedule the next action, recycle early interest, correct amount or close date, transfer ownership, or close lost when evidence supports it. Track how many flags lead to meaningful cleanup rather than celebrating a smaller pipeline blindly.

Deliverable: stage dictionary, history schema, re-entry calculation rule, cohort baseline table, review thresholds, stalled-versus-neglected logic, reason codes, current queue, owner and next action, advance-hold-recycle-close decisions, and monthly process-improvement review.

THE TAKEAWAY

Use stage history and cohort baselines, define stalled and neglected separately, require a dated next step, and close or recycle records that no longer satisfy the stage.

OFFICIAL REFERENCES

Check the platform’s current instructions.

Platform labels, eligibility, and workflows can change. These official help pages were used to validate this lesson.