Recruiting reports that show where hiring stalls

Why this matters

Most applicant tracking systems give counts by stage. A count tells you volume, not motion. A candidate can sit in hiring manager review for three weeks and still appear in the same bucket as someone added this morning. That hidden wait is where good people drop out.

Recruiting reports that show where hiring stalls focus on age and movement. They show days in stage, last activity, owner and the reason a candidate has not moved. They also split candidate wait from recruiter work and from hiring manager work, because those need different fixes.

Time to hire alone hides the stall. A fast offer can mask a slow interview loop if the requisition opened late. A slow offer can hide a smooth pipeline if approvals sit. Report by stage and by cohort, then read the bottleneck.

Before you start

You need stable data. Each stage change in the applicant tracking system should write a timestamp and an actor. If stage history is missing, export candidate snapshots weekly and keep them. At minimum, capture candidate ID, requisition ID, stage name, stage entered date, stage exited date, disposition reason, source, recruiter, hiring manager, interview completed date, scorecard submitted date and offer approval dates.

Define a stall threshold for each stage before you look at the data. Screening might be three business days. Hiring manager review might be two. Interview scheduling might be five. Feedback might be two. Offer approval might be two. Offer response might be five. The numbers depend on the role and the team. Pick business days for internal queues so weekends do not create false alarms. Put thresholds in report settings, not a spreadsheet.

Pick the grain before you build. Use one row per candidate and stage for aging. Use one row per requisition for a funnel view. Use weekly application cohorts for conversion. Do not mix these views in one table. Restrict access to candidate names and offer fields. Write down the definitions so two people reading the report get the same answer.

How to do it

Start with a stage aging report. It should list every open candidate, their current stage, days in that stage, business days since last activity, owner, requisition and next scheduled event. Sort by days over the threshold. Add a waiting reason field with a short picklist. Values like awaiting recruiter screen, awaiting hiring manager review, awaiting candidate availability, awaiting interviewer feedback, awaiting offer approval and awaiting offer response are enough to start.

Build cohort conversion next. Group candidates by application week or requisition open week. Count movement from application to screen, screen to hiring manager review, review to interview, interview to offer and offer to acceptance. List the top disposition reasons at each drop. Split the view by source and by requisition. This shows whether a source sends poor-fit candidates or the interview loop loses good ones.

Track feedback and offer approvals as separate queues. A candidate waiting on interviewer feedback has a different owner than one waiting on finance approval. Report the oldest open item in each queue, not only the count. The oldest item is the one that needs a call today.

Run a weekly stall review with recruiters and hiring managers. Pull the short list, assign one next action per candidate and one process fix per recurring stall. Record owners and dates in the applicant tracking system or a shared log. Keep the review short and focused on movement.

1. Define stall thresholds by stage. List each stage and how many business days counts as stalled. Get hiring manager agreement so the report has authority.
2. Capture stage timestamps and actors. Make the applicant tracking system write stage entered, stage exited, actor and reason on every change. Backfill what you can, and mark older records as incomplete.
3. Build the current stage aging report. Show open candidates by stage, days in stage, last activity date, owner, requisition and next scheduled event. Sort the oldest items first.
4. Add a waiting reason field. Use a short list of reasons such as awaiting hiring manager review, candidate availability, interviewer feedback or offer approval. Require a reason when a candidate passes the threshold.
5. Build cohort stage conversion. Group candidates by application week or requisition open week. Count movement from one stage to the next and list the top disposition reasons at each drop.
6. Split feedback and offer delays from sourcing delays. Report interviewer feedback backlog and offer approval queue separately. Assign a different owner to each queue.
7. Run a weekly stall review. Pull the short list and set one next action per candidate and one process fix per recurring stall. Record owners and dates in the applicant tracking system or a shared log.
8. Validate against sample records. Open ten candidates in the applicant tracking system and compare their stage history with the report. Fix mapping or missing timestamps before you trust trends.

How to check it worked

Reconcile the report against sample candidate records. Pick candidates in each stage and compare stage dates, owner and disposition with the report. If the report says a candidate is stalled but the applicant tracking system shows recent activity, fix the mapping. Look for records with missing stage dates and mark them as incomplete rather than guessing.

Check the review log after a few weekly cycles. Every stalled candidate should have an owner and a next step. Every recurring waiting reason should have a process owner. If the log shows the same candidate on the list week after week with no action, the report is not driving decisions.

Ask hiring managers to name their oldest candidate and the reason for the wait. Ask recruiters to use the same waiting reasons across requisitions. Check whether feedback backlogs and offer approvals get escalated before candidates withdraw. Those behavior checks matter more than a clean chart.

Audit data quality on a regular schedule. Look for candidates not attached to a requisition, missing disposition reasons and interviews without feedback. If those gaps are common, make the fields required at the stage change. A report built on missing data will point at the wrong bottleneck.

Mistakes to avoid

Do not average everything into one number. Average time in stage hides the long tail. Use the oldest item and the threshold list. Snapshot counts hide aging. Current pipeline views hide rejected candidates and declined offers, so use cohort conversion for drop-off and stage aging for live queues.

Do not mix calendar days and business days in one report. A five calendar day target crosses a weekend. Pick one convention per report and write it down. If you change the convention, note the date on the report so old and new numbers are not compared by mistake.

Do not build twenty reports with no owner. Three focused reports beat a dashboard nobody opens. Each report needs a named owner and a decision it supports. If nobody changes a schedule, an approval or a candidate action after reading it, remove it.

Do not let stage names drift. If Phone screen becomes Recruiter screen mid-quarter, trends break. Keep stage IDs stable and change labels only. Map old stages in the report. Do not compare sources when the source field is free text. Use a picklist and capture source at application. If your applicant tracking system cannot produce these views without manual exports, the Cloudverg Recruiting system implementation package at a fixed price of $9,500 is one option among others. It sets up stages, scorecards, scheduling, offer approval and reports on time to hire, source and stage conversion in three to four weeks.

Frequently asked questions