Two different numbers, measured separately

You enter, per requisition, the date it was opened, the date the first candidate entered the process, the date the accepted candidate entered the process, and the date the offer was accepted. If you also enter stage counts, applications received, screens completed, submittals sent, interviews held and offers made, the calculator returns stage-to-stage conversion alongside the timing.

What comes back is a per-requisition line and a set summary. The summary carries the median and the mean for both measures, the range, and the count of requisitions included, because a median of three requisitions is a number you should not lean on. Conversion rates come back as ratios between adjacent stages rather than as a single funnel percentage, which is the form you can act on.

A mean is the total divided by the count, and one catastrophic requisition wrecks it. Nine roles filled in around thirty days and one that dragged on for a year gives you a mean somewhere near sixty-three days, a figure that describes none of the ten roles and flatters or damns your desk depending on which direction the outlier ran.

A median is the middle value once the roles are sorted. It tells you what a typical requisition on your desk looks like, and it does not move when one role goes badly wrong. Report the median as your headline and keep the mean beside it, because the gap between them is itself the signal: a mean far above the median means you have a tail of stuck requisitions, and the tail is the thing worth fixing.

The calculator returns both and shows the range, so the outlier is visible rather than baked silently into an average that gets quoted in a client meeting.

We are not going to publish an industry time-to-fill figure for you to measure yourself against, because the ones in circulation are not comparable to your desk. They mix in-house and agency data, permanent and contract, hourly and executive, and they rarely agree on when the clock starts. A number you cannot reproduce the methodology for is a number you should not be managed by.

The comparison that works is your own. Run the calculator on the last twenty requisitions you filled, split by client, by role family and by recruiter, and look at the spread rather than the headline. Then run it again next quarter with the same definitions. Movement against your own baseline is real information. Movement against a figure from a survey you did not take part in is not.

The calculator will process the figures you enter in order to compute the result and will not retain them afterwards. Nothing entered into the free tool is written to a Surhires account, and the tool does not need an account to run. The arithmetic happens against the numbers you supply and nothing else.

This tool is lighter on personal data than most of the others here, because dates and counts are not identifying on their own. That changes the moment you paste in a candidate name, a client name or an email address to keep your rows straight. If you do, you are making a processing decision about somebody else's data in a free web tool, and that decision is yours as controller. Use requisition references rather than names and the question does not arise.

It will not tell you why a requisition was slow. It measures elapsed time between the dates you supply; the cause sits in the stage history, the hiring manager's calendar and the brief. It will not account for a requisition that was reopened, rescoped or filled by a second desk unless you enter it as a separate line.

It will not produce a cost per hire. That needs your fully loaded recruiter cost, advertising spend, agency fees and referral payments, and none of those are in the inputs here. It will not forecast how long the next role will take either. A median over past requisitions describes what happened; it is a reasonable planning anchor and a poor promise.

The reason this is a free tool rather than a core feature is that entering dates by hand is the wrong way to run the measure. Inside Surhires every stage change is timestamped as it happens, so time to fill, time to hire and stage-to-stage conversion are derived from the working records rather than typed into a spreadsheet on a Friday.

That also makes the split views possible without extra work: per client, per recruiter, per role family, per source. The Recruiter Performance Dashboard reports time to first reply and interview-to-offer conversion from the same underlying events, so a slow desk and a slow client are distinguishable rather than pooled into one average that satisfies nobody.