How to Measure Time in a Sales Stage When a Deal Comes Back
Measure sales stage duration when a deal returns. Separate current visit age, accumulated time and time since first entry using a worked example and worksheet.
On this page
A deal spent four days in Proposal, went back to Discovery and returned to Proposal yesterday. In this morning’s review, one report says it’s one day old. Another shows five days in Proposal. A third shows seven days since the deal first got there. The labels need to say which clock each report uses.
Use time since the latest entry to decide whether to follow up on work happening now. Use total time across all visits to see how much time the deal has spent in that stage. If you care how long it’s been since the buyer first reached Proposal, use a third clock and label it separately. Each answers a different question.
Start with stage changes, one deal at a time
Use the CRM’s recorded stage history or a saved copy whose fields and timestamps you can verify. You need a deal ID, the new stage and a timestamp. Give every report the same cutoff and timezone. Start a visit when a deal enters the stage. Close it when the deal changes to another stage. If the deal comes back later, start a second visit. The gap between those visits belongs to whatever stage the deal was in during that gap.
Sort the rows within each deal. If two changes share a timestamp, use a sequence or change ID only if it reliably establishes their order. Deduplicate by the recorded change ID where one is available. A repeat of the same change doesn’t start another visit. A deal that actually moves from Proposal to Discovery and immediately back does start another visit, even if both changes show the same time. If the order is unclear, flag the record instead of guessing from the display order.
A current-stage field by itself can tell you where a deal is today. It cannot reconstruct when prior visits started or ended. If your report starts on June 1 and the first available row already shows Proposal, mark the entry time as unknown unless you can verify an earlier stage change. Counting from June 1 would make that visit look shorter than it may have been.
Work through one deal
Here’s a fictional timeline. All changes happen at 9 a.m. in the same timezone. The report runs June 10 at 9 a.m.
| Event | Date | What to do with it |
|---|---|---|
| Deal enters Proposal | June 3 | Start visit 1. |
| Deal moves to Discovery | June 7 | Close visit 1 at four elapsed days. |
| Deal returns to Proposal | June 9 | Start visit 2. |
| Report cutoff, still in Proposal | June 10 | Visit 2 is open and one day old. |
The current visit age is one day. The total time in Proposal is five elapsed days: four during visit 1 and one during the visit still open. The time since first Proposal entry is seven days, which includes the two days in Discovery.
The completed-visit dataset gets only the first four-day visit. The open visit can appear in a current-age report but should not enter a completed-visit average as a one-day completion. It might last another week. For elapsed time across a daylight-saving change, convert the timestamps to UTC before subtracting them. If your team instead counts business days, define its calendar and show that unit on the report; the two measurements aren’t interchangeable.
Use the clock that answers the meeting’s question
For the weekly follow-up list, start with deals that are in Proposal now. Sort by current visit age. If you want the report to catch deals that repeatedly leave and return, show the number of visits beside the age. A deal can be new to its current visit and still deserve a closer look.
For a process review, decide whether the report counts visits or deals. An average across completed visits lets a deal with three visits contribute three rows. A report of accumulated days per deal lets it contribute once. Show the number of records in either case. If the export omits earlier stage changes, report how many deals had incomplete histories and keep them out of measures that need complete visits. The unit-of-analysis guide shows how changing the row changes the result.
For conversion, keep entry cohorts and follow-up windows consistent. Re-entering a stage can add a visit without adding a second deal to the same cohort. Use the entry cohort guide when the question is how many deals advanced within a comparable window.
Bring a small reconciliation sheet to the next review
Download the blank stage-visit worksheet. It’s a text file you can copy into your reporting notes; no email is required.
For each deal someone questions, capture these fields:
- Deal reference and current stage.
- Report cutoff, timezone and unit: elapsed days or business days.
- Each verified stage entry and exit, with the last visit marked open if applicable.
- Current visit age, accumulated time in the stage and number of visits.
- Missing, duplicated or ambiguously ordered history, plus the person who can check it.
Start with one deal that recently came back to a stage. Put its history beside the report row and calculate both clocks. If they disagree with the export, ask what timestamp and row the export uses before you change its formula. Once both people can reproduce the same number for that deal, they have a rule they can apply to the rest of the pipeline.