Time to hire is almost never slow because anyone is working slowly. It is slow because the candidate spends most of the clock sitting in a queue, waiting for someone to open an email, check a calendar, or sign off. Once you time-stamp every handoff in your recruitment cycle time, you usually find the actual working hours add up to a day or two. The rest is waiting.
That distinction matters because it changes what you fix. Speed up the people and you shave minutes off tasks that were never the problem. Fix the queues and you cut days off the number that actually shows up in your reporting.
Time to hire and time to fill are not the same number
These two metrics measure different windows, and mixing them up is why so many hiring dashboards look wrong.
Time to fill starts when the requisition opens, whether or not anyone has applied yet. It includes the time spent writing the job ad, posting it, and waiting for the first applications to land. If a req sits open for three weeks before a single candidate applies, that three weeks counts.
Time to hire starts later. It begins when a specific candidate enters your pipeline, either by applying or by being sourced, and ends when they accept. It excludes the sourcing lag and measures only how your process treats the people already in it.
If you want to know whether your job ads and sourcing channels are working, look at time to fill. If you want to know whether your process is the bottleneck, look at time to hire. Most teams that complain about a hiring bottleneck are actually describing that same problem, and they fix the wrong end of it because they never separated the two.
Why the obvious fixes do not move the number
The default response to hiring that feels slow is to make everyone faster. Write tighter job ads. Push interviewers to respond same day. Chase recruiters for status. None of it moves the number much, because the clock keeps running whether or not anyone is doing anything.
A recruiter who takes twenty minutes to screen a CV is not your delay. A CV that sits unopened for four days is. An interviewer who takes forty minutes to write feedback is not your delay. Feedback that sits unread by the hiring manager for a week is.
This is a queueing problem, not a speed problem. In queueing terms, the total time in a system is the work time plus the wait time, and in most hiring pipelines the wait time dwarfs the work time by a factor of ten or more. Making the work faster when the work was never the bottleneck does not touch the wait. You need to find where the candidate is actually sitting still, then attack that specific gap.
The four queues where the time actually goes
Here is a worked example to make the split concrete. It is illustrative, built from stated assumptions, not a measured average from any client, so treat the numbers as a way to reason about your own pipeline rather than a benchmark to hit.
Assume a mid-level hire with four handoffs after application:
- CV review. The actual read takes ten minutes. If it sits in a shared inbox behind eleven other CVs and only gets opened during a Friday batch review, the queue time is four days.
- Interview scheduling. Finding a slot that works for three people, the candidate, the hiring manager, and one peer interviewer, takes maybe five minutes of actual coordination if everyone answers immediately. If it goes back and forth over email because one calendar is not shared, the queue time is five to seven days.
- Hiring manager decision. Reading the interview notes and forming a view takes fifteen minutes. If the manager is heads down on a deadline and the decision sits in their inbox, the queue time is a week or more.
- Offer approval. Drafting and checking the offer letter takes twenty minutes. If it needs a second signature from someone traveling, the queue time is three to five days.
Add the actual work: under two hours across the whole process. Add the queue time: two and a half to three and a half weeks. That gap is where the wait actually lives, and it is invisible if you only ever look at how long each stage took to complete, rather than how long the candidate waited before that stage started.
Measure the gaps, not the durations
The fix starts with a different measurement discipline, the same one used in a time and motion study on a factory floor, just applied to a hiring pipeline instead of a production line.
Time-stamp every stage transition for a req: applied, screened, interview scheduled, interview held, decision made, offer sent, offer accepted. Most applicant tracking systems already log these events, whether or not anyone looks at them.
Then compute the gap between each consecutive pair of timestamps, not the duration of the stage itself. The gap between "screened" and "interview scheduled" is your scheduling queue. The gap between "interview held" and "decision made" is your hiring manager queue. The gap between "decision made" and "offer sent" is your approval queue. These four gaps, summed, are usually most of your recruitment cycle time.
This is a two-hour spreadsheet exercise on data you already have, not a new tool. The output is a list of gaps ranked by size, which tells you exactly where to spend the next hour of your attention.
Look at the median and the worst decile, not the average
A mean hides the problem you are trying to find. If nineteen reqs close in four days and one sits for three weeks waiting on a signature, the average tells you six and a half days, a number that describes none of your actual reqs.
Pull the median instead, it tells you what a typical hire looks like. Then pull the ninetieth percentile, the worst one in ten. The gap between the two tells you how bad your worst case gets and how often it happens. A median of six days with a P90 of nine days is a tight process. A median of six days with a P90 of twenty-eight days means one stage occasionally breaks completely, and that stage is costing you candidates who accept a competing offer while yours sits in someone's inbox.
Fix the P90 outliers first. They are usually caused by one specific gap, one specific person, or one specific approval step, and they are the reqs a good candidate does not wait around for.
What automation genuinely removes from the queue
Some of these waits are mechanical, and mechanical waits are exactly what automation is good at removing.
Scheduling three calendars for an interview does not need a human doing back-and-forth email. A tool that reads free-busy across calendars and proposes slots removes that queue almost entirely, often down to same-day. Chasing a hiring manager for feedback is a reminder sequence, not a judgment call, the same way chasing a rep for a follow-up call is. Nudging an approver who has not opened an offer letter is a scheduled ping, not a conversation. Sending the offer letter itself is a template merge.
This is the same pattern as lead follow-up in sales. First response time to an inbound lead behaves exactly the same way: the actual reply takes two minutes to write, but if it sits in a queue for six hours because nobody was watching the inbox, that queue is what loses the deal. The fix in both cases is the same, remove the human from the parts of the wait where no judgment is actually happening.
What automation cannot fix, and why we would say so
If the bottleneck is a hiring manager who has not decided what they actually want in the role, no reminder sequence touches it. A scheduling tool cannot make someone commit to a headcount plan. A nudge cannot resolve disagreement between a hiring manager and a department head about whether the role needs five years of experience or two.
That is a decision problem, not a process problem, and it shows up in the data as a long gap at the "decision made" stage that does not shrink no matter how many reminders you send. Selling a scheduling system against that gap would take the client's money and not shorten their cycle time at all. The honest move is to say so and point at the actual conversation that needs to happen instead, usually between the hiring manager and whoever owns the req.
A one week check you can run without buying anything
You can find out which of these you actually have before you spend a cent.
Pull your last twenty closed reqs. Time-stamp the six transitions: applied, screened, interview scheduled, interview held, decision made, offer sent. Compute the four gaps for each req. Sort all eighty gap values by size and look at the worst decile.
If the biggest gaps cluster around scheduling, you have a mechanical fix: calendars, reminders, a scheduling tool. If they cluster around the decision stage and the same one or two names show up every time, you have a decision problem that needs a conversation, not software. This check usually lands on a part time COO or an ops lead's desk rather than a dedicated recruiting function, since most growing companies do not have one yet, and it takes a working afternoon, not a project.
Where this fits next to sales admin time
The same split between work and queue shows up everywhere manual handoffs live: quoting, order entry, job status chasing, and lead follow-up all have a few minutes of real work buried inside days of waiting for the next person to notice. The admin cost calculator uses the same logic, hours lost sitting in a queue are hours you can price, whether the queue holds a candidate, a quote, or a lead waiting on a reply.
Common questions
What is the difference between time to hire and time to fill?
Time to fill runs from when the req opens to when someone accepts. This one runs from when a specific candidate enters the pipeline to when they accept, so it is the number that tells you about your process rather than your sourcing.
How long should hiring take?
There is no fixed good number worth quoting, because it depends on role seniority and approval layers, the useful question is not what the number is but which stage gap is largest for your own last 20 reqs.
Can automation actually reduce how long hiring takes?
It removes the mechanical waits, scheduling, chasing feedback, nudging approvals, but it cannot remove a wait caused by a hiring manager who has not decided what they want, that is a decision problem and no tool fixes it.
How do I find out where my hiring process is actually slow?
Timestamp every stage transition on your last 20 closed reqs, calculate the gap between each pair of timestamps, and sort by the worst decile rather than the average, the biggest gap is your bottleneck.
We build this kind of measurement and the automations that follow it inside the tools a client already runs, n8n, their ATS, their calendar. If you want to find out how many of those twenty hours a month are sitting in your hiring queues, start with the Revenue Roadmap or book a call.
