Cutting BGV turnaround in high-volume hiring

Ask an operations lead why background verification takes eleven days and you will usually hear about the checks: courts are slow, employers do not reply, universities take weeks. Some of that is true. Most of it is not where the time goes.

Instrument a high-volume programme properly and the picture inverts. The checks themselves are frequently the smaller half of the elapsed time. The larger half is queue time — a case sitting still, waiting for a person to look at it, waiting for a candidate to upload something, waiting for someone to notice it stalled.

Queue time is the part you control.

Measure the gaps, not the checks

The first change is measurement. Most programmes track one number: initiation to report. That number tells you there is a problem and nothing about where it is.

Break the case into intervals and measure each one:

• Offer accepted → invite sent
• Invite sent → candidate submits
• Submission → first check dispatched
• Dispatch → source responds
• Response → reviewer clears or flags
• Insufficiency raised → candidate corrects

In most programmes we have seen, two of those dominate, and it is rarely the ones people expect. "Invite sent → candidate submits" and "insufficiency raised → candidate corrects" are the two that quietly eat a week, because both are waiting on a person who has other things to do and no clear prompt.

Until you can see the intervals separately, every improvement is guesswork.

Front-load the inputs the candidate controls

A check cannot start until it has an input. If the candidate provides everything at the start, every check starts on day one. If they provide it piecemeal, checks start on days one, three and six, and the case finishes when the last one does.

The practical version of this is a single structured intake that asks for everything the role's check package needs, validates format at the point of entry, and refuses to submit incomplete. Validating a PAN's format in the browser costs nothing and removes an insufficiency loop that otherwise costs three days.

The counter-argument is that a long form has worse completion. That is real, and it is why the form should be role-aware — ask for what this package needs and nothing else — rather than a single company-wide form that asks everyone for everything.

Run checks in parallel, not in sequence

Sequential dispatch is the most common structural cause of long turnaround, and it is usually accidental. A case is picked up, identity is dispatched, someone waits for it to return before dispatching employment, and the case takes the sum of its checks rather than the longest one.

There is exactly one dependency worth honouring: identity before anything that depends on the identity being right. A criminal record search against an unverified identity can return a confident clear on the wrong person, which is worse than no search. Everything else can start at once.

Sum versus maximum is the single largest lever in most programmes.

Chase insufficiencies automatically

An insufficiency — an unreadable document, a wrong UAN, an employer contact who has left — is not a failure. It is a normal state that a percentage of cases will always reach. What determines its cost is how quickly the candidate is told and how easy it is to fix.

Left to a person to notice and email, an insufficiency costs days. Detected on arrival, pushed to the candidate immediately with a specific message about what is wrong and a direct link to fix just that item, it costs hours. The specificity matters: "please re-upload your documents" produces another wrong upload. "The certificate number on your degree certificate is not legible in the scan — please photograph page 1 in daylight" produces the right one.

Escalate on a schedule, not on someone's memory.

Review by exception

If a reviewer opens every case, review is a queue with a fixed service rate and it will become the bottleneck the moment volume rises. Most cases have nothing to decide: every source returned, everything matched, nothing flagged.

Those should clear without a human, with the evidence retained so the decision is auditable after the fact. Reviewer attention should go to the cases with a discrepancy, an insufficiency that failed to resolve, or a source that returned something ambiguous.

This is where the fraud-exposure objection usually appears, and it deserves a straight answer: auto-clearing a case with no discrepancies does not lower scrutiny, because there was nothing to scrutinise. What lowers scrutiny is a tired reviewer approving their two hundredth identical case, which is exactly what a queue of clean cases produces.

Do not trade accuracy for speed

Speed obtained by shrinking the check package is not a turnaround improvement; it is a smaller programme reported as a faster one. The same is true of accepting a document in place of a source, or recording an unresolved check as a clear.

The changes above are all structural — measurement, parallelism, prompt automation, exception routing. None of them make a check weaker. That is the test worth applying to any proposed improvement: does this remove waiting, or does it remove evidence?

• turnaround
• operations
• high-volume hiring