Your Time-to-Fill Metric Starts Too Late.

The invisible month before the job posting

A team lead requests a replacement on March 1. Finance approves it on March 18. The recruiter receives the final brief on March 25, the job goes live April 2, and the candidate accepts May 7. A dashboard that begins at publication reports 35 days. The team that needed capacity waited 67 days from the request. Both numbers can be correct; only one describes the whole operational delay. ^↗

Time-to-fill is not a universal clock with a universal start event. Companies variously begin at approval, requisition creation or advertisement. If those definitions change between quarters, trend lines become misleading. The metric is useful only when the start event, end event and excluded periods are explicit. ^↗

Separate business waiting from recruiting execution

Keep two clocks. The vacancy clock begins at the documented staffing need or authorized request, whichever is appropriate for your governance model. The recruiting execution clock begins when a complete, approved requisition is released to recruiting. Track acceptance as a milestone and actual start date separately, because a signed offer is not the same as restored capacity. ^↗

Add event timestamps for approval, intake complete, publication, first qualified slate, interviews, offer approval, acceptance and start. Do not collapse these into a single average. The difference between request-to-approval and approval-to-first-slate is the difference between a budget decision and a sourcing workflow. ^{↗ ↗}

Pauses are facts, not disappearing days

A requisition placed on hold should have a hold start, hold end, reason and accountable owner. Report both calendar elapsed time and active recruiting days. If a role is frozen for 40 days, the active clock may correctly exclude that pause for recruiter productivity analysis; the vacancy clock should still show the 40 days because the business continued without the hire. ^{↗ ↗}

Never silently restart the clock when a role is reopened, renamed or transferred between recruiters. If the job scope materially changes, retain the original record and record the change event. Otherwise an organization can “improve” time-to-fill simply by closing difficult requisitions and opening replacements. ^↗

A worked example with conflicting conclusions

Imagine two teams. Team A spends 25 days awaiting headcount approval and 20 days recruiting. Team B receives approval immediately but takes 32 days recruiting. If you evaluate only recruiter execution, Team A is faster. If you evaluate vacancy exposure, Team B restores capacity sooner. The right intervention depends on which outcome you are optimizing. ^{↗ ↗}

The same distinction matters for senior roles and high-volume roles. Compare like-for-like job families, locations and levels rather than letting an influx of easy hires change the overall average. Display medians and distributions alongside averages; a few unusually old vacancies can distort the mean. ^{↗ ↗}

Define a defensible measurement contract

Write down the event dictionary: who creates each timestamp, whether it can be edited, what happens when an offer is declined, how evergreen requisitions are handled, and how multi-opening roles are counted. A single requisition for ten hires cannot be treated as identical to a requisition for one hire without an explicit rule. ^↗

Publish a small reconciliation sample every month. Choose ten hires, reconstruct their timeline from the ATS and approval records, and compare it with the dashboard. If more than one timestamp definition is used, correct the schema before asking recruiters to improve their speed. ^↗

What to change this week

Add “request received,” “approved for recruiting,” “offer accepted,” and “start date” to the reporting specification. Require a reason code for hold periods. Then show vacancy elapsed time and active recruiting time side by side. Avoid a single leaderboard that rewards teams for moving the start line. ^{↗ ↗}

The calculator below makes the two-clock gap visible for one requisition. Use it to identify a process question, not to blame a particular recruiter or predict future hiring duration. ^↗

Run the operational check