Understanding the Time in Process Report

this guide explains how ashby's time in process template report works, including which candidates and stage transitions are counted, how the median is calculated, and how a few edge cases (especially small candidate counts) can lead to results that differ from a manual spreadsheet calculation a quick note on terminology for readability, this guide talks about "candidates" moving through stages technically, the time being measured belongs to a job consideration (sometimes called an application), which is the record of one candidate's progress toward one specific job a single candidate can have several job considerations if they're being considered for multiple roles, and each one moves through stages independently and is counted independently in the time in process report in ashby, two things are called "time in process " in addition to this report, ashby also exposes a job consideration field called time in process (days) that field is a single per application duration (days from application start, or most recent unarchive, until consideration ended) the report described in this doc is different it measures the median time spent in each stage, computed across many candidates the two are not directly comparable, and the sum of stage medians from the report will not equal the field value on any single application what is the time in process report? for report template basics, see report catalog templates docid\ aurrqfzh1h8qgf6rh0vqi the time in process template report shows the median number of days candidates spent in each interview stage of your hiring process it's intended to answer questions like "what is the typical time a candidate spends in phone screen before moving on?" "which stage is the slowest part of our pipeline?" "have certain stages gotten faster or slower over time?" for each stage that meets the report's filters, the report computes the median of all completed stage durations across the candidate cohort, where a "stage duration" is the time between when a candidate entered that stage and when they left it the result is one row per stage (or per stage type, depending on your settings) with the median days in that stage as the headline metric default template configuration you can access the time in process template by navigating to reports > report builder > report templates > time in process when you open the time in process template, it is preconfigured as follows you can adjust any of these in the report settings setting default subject applications timeframe rolling 6 months, based on each candidate's most recent interview date group stages on for ashby analytics orgs and orgs using grouped interview plans, off otherwise hide application review stages yes hide lead stages yes hidden stage groups none visualization stacked bar chart visualization settings these settings are located under the visualization menu on the left side of the report template available visualizations stacked bar chart each bar is a candidate cohort (or other grouping); stages are stacked within the bar, so the total height shows the combined median time across stages time in process report stacked bar chart view table one row per stage (or per stage and grouping), with the median days in process as a column what "group stages" does this toggle controls whether the report reports on individual interview plan stages or on the stage groups they map into stage groups are the primary pipeline milestones (e g "recruiter screen," "onsite," "offer") that an admin can define via grouped interview plans, with individual stages from different interview plans mapped into them off each individual interview plan stage is reported on its own "phone screen" in job a and "phone screen" in job b appear as two separate rows, even if both map to the same stage group on stages are rolled up into their stage groups all stages that map into a given stage group, across every job and interview plan, are pooled into a single row for that stage group the grouped view is most useful when you have grouped interview plans configured and want a consistent, company wide view of pipeline speed at the milestone level the ungrouped view is most useful when interview plans differ meaningfully across roles or departments and you want to see each stage in its own context what "hide application review stages" and "hide lead stages" do these options remove application review stages and lead stages from the report they are hidden by default because most customers think of "time in process" as time spent in active interviewing; the time a candidate spends in application review or as a lead is a different category of activity you can re enable either category from the report settings what "hidden stage groups" does this lets you explicitly remove individual stage groups (by name) from the report, even if they would otherwise be included by stage type rules this is useful for custom stages that don't fit the standard pipeline view what is included in the calculation? each stage's median is computed from a pool of stage visits a stage visit is one period of time a candidate spent in a given stage, from the moment they entered it to the moment they left it detailed explanations of the calculation critieria are provided below candidates must have exited the stage visits where the candidate is still in the stage are excluded the report only counts time the candidate has actually finished spending in a stage until a candidate moves out of a stage (by advancing, being archived, or being hired), that in progress visit contributes nothing to the median very short visits are still counted even very brief stage visits are included as data points in the median for example, a candidate who was moved into a stage and then almost immediately moved back out, perhaps because of an accidental click that was corrected within seconds, would be shown in the report the report does not apply a minimum duration to qualify a visit if you notice a stage's median is unexpectedly low, it's worth checking whether there were a small number of accidental short transitions inflating the data; those can have an outsized effect when the overall number of completed visits is small all eligible candidates' visits are pooled together the median for a given stage is computed across every completed visit by every eligible candidate there is no per candidate averaging or deduplication beforehand if three candidates spent 3, 7, and 10 days in phone screen, the median for phone screen is the median of \[3, 7, 10], not the median of some pre aggregated per candidate value multiple stage visits are counted individually when a candidate re visits a stage (for example, after being unarchived back into the pipeline, or because they were moved back from a later stage), each completed visit counts as its own interval for example, if a candidate goes phone screen → archived → unarchived → phone screen again → onsite, that candidate contributes two phone screen intervals to the median one ending when they were archived the first time, and one ending when they later moved to onsite if they were still sitting in phone screen the second time around, only the first visit would count — the second has not finished yet excluded stages the following stage types are always excluded from the report archived stages moving a candidate into an archived state is not itself "time spent interviewing " hired stages being hired is the end of the process, not a stage you measure the following stage types are excluded by default but can be turned back on in the report settings application review stages controlled by the "hide application review stages" option lead stages controlled by the "hide lead stages" option you can also explicitly hide additional stage groups via the "hidden stage groups" setting how the cohort of eligible candidates is chosen the report uses a timeframe to decide which candidates are in scope for example, in the default template, the timeframe is "candidates whose most recent interview occurred in the last 6 months " any candidate that falls in that selected date range is fully in scope; once a candidate is included, all of their completed stage visits contribute to the medians, even visits that happened before the selected date range the timeframe selects the cohort of candidates, not the individual stage visits any other filters you add to the report (job, source, department, etc ) further narrow the cohort the same way how the median is calculated the report uses a discrete median it returns an actual stage duration that appeared in the data it does not average the two middle values when there's an even number of data points specifically the completed stage durations are sorted from shortest to longest the median is the value at position ceil(n/2) , where n is the number of durations when n is odd, this is the usual "middle value" definition when n is even, this returns the lower of the two middle values rather than averaging them this means every median the report shows is a real stage duration that some real candidate actually experienced the tradeoff is that with very small samples, especially n = 2, the result can look different from what you'd compute as a simple average of the two values worked examples imagine a stage where the completed durations (in days) are as follows the table shows what a typical "arithmetic median" calculation would give versus what the time in process report returns number of completed visits sorted durations (days) manual median you might calculate by averaging the middle values what the report shows 1 \[5] 5 5 2 \[3, 9] 6 3 3 \[3, 6, 9] 6 6 4 \[3, 6, 9, 12] 7 5 6 5 \[3, 6, 9, 12, 15] 9 9 6 \[3, 6, 9, 12, 15, 18] 10 5 9 the differences appear only on even sized samples for odd n , the two methods agree as n grows, the difference between the two approaches becomes smaller in relative terms and is most pronounced when only two candidates have completed a stage if you're trying to reconcile the report with a manual calculation and you have a small number of candidates per stage, this is almost always the explanation faqs i only have 2 candidates who completed this stage my math says the median should be 6 days, but the report shows 3 this is the most common time in process question, and it is expected behavior the report uses a discrete median that returns the lower of the two middle values rather than averaging them with two durations of 3 and 9 days, the report returns 3 see the worked examples above why isn't a stage showing up at all? there are a few possibilities the stage is a lead or application review stage and the "hide" options are still set (the default) the stage is an archived or hired stage type — these are always excluded the stage is in the hidden stage groups list no candidates have completed a visit to that stage within the report's cohort a stage that only has candidates currently sitting in it will not appear, because in progress visits don't count are candidates currently in a stage included in the number? no only completed stage visits are counted until a candidate leaves a stage (by advancing, being archived, or being hired), their time in that stage is not yet measured why is my median so low? it looks like seconds or zero days the most common cause is accidental short stage moves; for example, a recruiter advancing a candidate to the wrong stage and immediately correcting it those brief visits are counted as completed stage visits and become data points in the median when the total number of completed visits for a stage is small, even one or two near zero visits can pull the median down dramatically reviewing the underlying stage transitions for the affected stage will usually surface the culprit what about candidates who were archived and then unarchived? the report does not "stitch" together separate visits into one combined duration each completed visit is its own interval in the median calculation the job consideration field time in process (days) behaves differently — it resets on unarchive — but the report treats each completed stage visit as an independent data point regardless of whether it happened before or after an unarchive my report and a colleague's report on the same template show different numbers why? the most common reason is permissions the report's eligible applications cohort respects your object access rules, so two users on the same organization can see different application sets and therefore different medians other reasons include different report filters, a different date range, or one report set to per stage view while the other uses the unified stage type view why is this called a "median" when my intuition says i want an average? the median is much more resistant to outliers than the mean one candidate who sat in a stage for 300 days (perhaps because they were forgotten about, or because they were reactivated months later) can dramatically inflate an arithmetic average, painting a misleading picture of typical hiring speed the median answers "what's the typical candidate's experience in this stage?" more reliably for a small number of candidates, switching to the median has tradeoffs (see the discrete median note above), but for typical pipeline sizes it produces a more useful number summary time in process measures the median days candidates spent in each stage, computed across all completed stage visits in your cohort a visit only counts once the candidate has left the stage in progress stages contribute nothing every completed visit is its own data point, including repeat visits by the same candidate archived and hired stage types are always excluded; lead and application review stages are excluded by default but can be turned back on the median is a discrete median with even numbered samples it returns the lower of the two middle values rather than averaging them this is the usual explanation for "the report shows 3 days but i calculated 6 " for small candidate samples (especially n = 2), expect the report to differ from a simple manual median calculation the job consideration field time in process (days) is a separate metric on individual applications and is not directly comparable to this report's values