What is time to hire and how is it measured?

The application form asks when the candidate can start, and everyone building a duration calculation looks there first. That field is not a date, it is a list of five options: Immediately, Within 2 Weeks, Within 1 Month, Later, Specific Date. In the schema it sits as text as well.

The job of the field is to state the availability of the candidate, not to measure the process. A candidate saying Immediately and the actual first day at work are independent of each other. A spreadsheet that puts both into the same calculation throws no error; it hands you a plausible looking number that measures something else entirely.

The most solid field for the end of the duration is the start date on the employee record; it sits as a date both on the employee record and on the employment period. The number of people who started within a period comes from there too: the employee export carries both a Start Date column and a start date range filter.

The one thing to watch is how that date gets filled. If the start date was left empty on the information request form, the date the record was created is written instead. Every form left empty pins the start date to the day the onboarding flow finished. If the real first day differs, the duration shifts by exactly that much.

The counter runs from the date the application was created, not from the last status change. An application that arrived twenty days ago still counts as waiting even if it was pulled into Reviewing yesterday. The card answers how long this candidate has gone unresolved, not how long they sat at this stage.

The seven day threshold is baked into the code and has no setting in the panel. A team whose service level target is ten days cannot build its own threshold there; the card still marks seven days. The counter itself is the full number, but the list underneath shows at most twelve records; twelve people in the list and twelve people waiting are not the same thing.

• The card counts the Pending and Reviewing statuses only. A candidate parked at the interview stage for months never enters that number.
• The trend window of the pool summary is a fixed 30 days and is not affected by the dashboard date picker.
• The observability dashboard is open on every paid plan and during the trial; the pool summary comes with the application screen.

When the status of an application changes, the record update, the audit entry and a field event complete in a single database transaction. The audit row keeps the changed field, the old value, the new value and the user who made the change together, and the row carries its own timestamp. That is exactly the raw material of a stage to stage duration calculation.

No ready made average comes out of that data, but a single candidate journey can be read on screen. One warning: the date in the timeline prints the day, the short month, the hour and the minute, with no year. January and December look identical there; reading a duration that spans months by eye off that screen misleads you.

Two more paths are worth knowing. If you roll back from Accepted or Hired while the application still has an open document or information request, the transition raises a warning and asks for a justification before it continues; that justification becomes its own audit row. And when the onboarding flow completes, the application is pulled straight into Hired without passing through the transition service: that move writes no audit row carrying a status field, its trace is a field event.

The choice has nothing to do with the product and everything to do with arithmetic. A single record that stayed open for six months lifts the average on its own; the median does not move. With five hires in a period, the average is already the story of one record.

A practical rule: while the hire count is small, do not print a single ratio, print two numbers. How many people, how many days, and which record is the longest. One average out of a small denominator is the most common place hiring reports go wrong.

A duration does not stretch in one place, it builds up in two. The first is the head of the pool: a full Waiting card means the problem is not screening, it is the pile nobody has opened. The days lost there are the most expensive days, because the candidate has not spoken to you yet. The second is between Accepted and Hired; that wait is mostly spent on open document and information requests, which is why the state of the document chain is part of the duration story.

The interview stage in between is the only side stage whose duration can be measured: the interview record keeps the scheduled time and the completion time in separate fields. But that stage is open on the Trial, Professional and Enterprise plans. On a team using Mini or Starter no interview record is ever created, so the duration of that stage leaves no trace in the panel.

One last limit comes from how the product behaves. AI changes the status of no application on its own; it produces suggestions, your team decides, and every transition is written to the audit log. What you measure is always the speed of human decisions, not the speed of the system.

A duration study touches personal data, so the permission boundary belongs at the start. For a user with the personal data mask on, sensitive field values in the audit row are hidden; the masking is applied on the server, not only on screen. Exporting is tied to a separate permission as well.

The calculation itself needs none of those fields. A file built from the Start Date, Department and Position columns carries the duration calculation and keeps you from copying unnecessary personal data into a spreadsheet.