Time to fill, with the clock stated

Leadership asks why hiring takes so long; talent acquisition disputes the number itself. Both are right, because the delivered figure never states which clock it runs on, and the fields it reads can be backdated after the fact.

RulePrint the clock on the report: which event starts it, which event stops it, and median beside mean, always.

Nevertime a fill from editable date fields. Approvals delayed, entries backdated, and positions showing open past their fill all bend them.

◆ Why nobody trusts the numberthree mechanical reasons, all verified in the field.

Failure	What it does to the number
The clock is unstated	Requisition approval, posting date, offer accept, and start date give four different durations. Reports pick silently; readers assume differently.
Dates get backdated	Practitioners report managers backdating requisition entries and delaying approvals, so state-field arithmetic times the paperwork, not the search.
Filled still shows open	Filled positions keep displaying open until the start date passes, a verified delivered-view artifact that inflates open counts and durations read from states.

◆ The reportMay's five fills, clock printed, median beside mean.

The owned version computes from stage events: this table runs posting to start, stated in the header, and the five May fills are the five May hires on the headcount page. The median sits beside the mean because one slow executive search should stretch the average, not the story.

Fill, May 2026 · clock: posting to start	Days
REQ-2114 · Sales	29
REQ-2098 · Support	38
REQ-2101 · Sales	44
REQ-2087 · Technology Delivery	51
REQ-2079 · Technology Delivery	63
Median 44 · mean 45.0	5 fills

Sample values are illustrative, never client data.

◆ The querytwo events per fill, one subtraction.

-- time to fill, posting to start, from the event fact
SELECT r.requisition_code,
       DATEDIFF('day', p.event_ts, s.event_ts) AS days_to_fill
FROM fct_application_event s
JOIN dim_requisition r ON s.requisition_key = r.requisition_key
JOIN fct_application_event p
  ON p.requisition_key = s.requisition_key AND p.stage = 'posted'
WHERE s.stage = 'started'
  AND s.event_ts >= DATE '2026-05-01' AND s.event_ts < DATE '2026-06-01'
ORDER BY 2

Swap the posting event for requisition approval and the same query answers the longer clock. That is the point: the clock becomes a parameter you state, not an assumption you inherit.

Use case

Problem

Time to fill is relitigated in every talent review because the clock is unstated and the underlying date fields can be backdated.

What we build

The event-based fill clock: start and stop events stated on the report, median beside mean, computed from the owned stage fact.

What you get

A duration nobody disputes, switchable between clocks by parameter, tied to the same fills headcount reports.

Which clock does your time to fill run on?

We ship the report that prints its clock, on events you own.

Talk to us

Terms on this page

clock: The start and stop events a duration is measured between.
backdating: Entering a dated field later, with an earlier date.
median: The middle value. Half the fills were faster, half slower.
mean: The average. One slow search moves it; the median holds.
posting: The event that makes an opening visible to candidates.
start: A hire’s first day. This report’s stop event.
state field: A current-value date on the requisition, overwritable, unlike an event.