How Recruiting Agencies Can Improve Applicant Review Without Migration

Diagnose one job, not the whole company

Choose a recent vacancy with a meaningful number of applications and follow 30 resumes from arrival to human decision. Observe where time is spent: file upload, extraction, duplicate handling, identifying role evidence, writing notes, asking for clarifications or creating a client shortlist. Do not count a slow sourcing day as an ATS failure if the real problem is an unrealistic job brief.

For each case, record the source CV, the job requirements that were approved before review, the existing pipeline status, the reviewers first assessment and any later correction. Sample both candidates who were progressed and those who were filtered or archived. A workflow cannot detect false negatives if it examines only the visible shortlist.

One simple test is to ask a second reviewer to find the evidence behind three shortlist decisions without calling the original recruiter. If they cannot see the relevant CV passage or do not know whether a skill was directly stated or inferred, you have an evidence design problem. Better notes or a lightweight review layer may help more than migration.

Keep the ATS as the system of record

The core principle is simple: candidate identity, applications, consent states and final disposition should remain governed by the authorized existing system. A review aid may read a permitted subset of resumes, record provisional findings and return a compact reviewed summary. It should not silently create a second version of the candidates identity or decide to reject applicants on its own.

Define one key for the candidate record and another for the application or job consideration. A candidate can apply for several different jobs. A report that counts people when it should count job applications can distort review throughput and error rates. Ashby documentation explicitly discusses this distinction in recruiting reporting.

Write down field ownership before connecting any tool: who maintains current contact details, where manual corrections are made, which status reflects a hiring decision and where the audit trail is stored. If the auxiliary tool cannot reliably write back or if the API permission is unavailable, a reviewed CSV attached to the authorized workflow can still be a legitimate first pilot. Do not promise a live two-way integration before confirming the capability.

Build a second-review lane, not a second CRM

A narrow pilot has four inputs: approved job requirements, source resumes, existing application identifiers and the review protocol. Its outputs are equally narrow: extracted evidence, material uncertainties, possible duplicate relationships and a short human-reviewed shortlist. Every item should include the original source reference, the reason it needs attention and the name or role of the reviewer responsible for the final disposition.

A sensible review queue has several distinct tasks. Parsing failures go to document correction. Duplicate warnings go to identity review and must never merge records automatically. Ambiguous requirements go back to the hiring manager. Candidates with relevant adjacent experience go into a recheck lane. Verification issues go through an appropriate authorized process and are not converted into unsupported accusations.

The hardest design decision is what happens when an automated result is blank. Treat it as missing information. For example, "employer not located through a web search" does not mean an employer was invented. Similarly, a missing skill keyword is not proof that a skill is absent. The auxiliary workflow should be trained to write "not established from current evidence," then provide a next action when that uncertainty matters.

A 30-resume pilot with a real success condition

Run the existing workflow and the improved review workflow on the same small, permissioned batch. Preserve original decisions so they can be compared fairly. Ask a trained reviewer to adjudicate a selected sample without simply inheriting the original decision or the new tool suggestion. Focus on material changes rather than raw counts of colorful alerts.

Measure the number of truly relevant candidates surfaced for review, the number of false suggestions, unresolved cases, parsing errors that changed a decision, and reviewer minutes per completed case. Define the cost of preparing the pilot, including manual data correction and approvals. Report the denominators and unknown cases; a percentage without them is not a quality metric.

For example, suppose the new workflow surfaces five overlooked CVs. If two are confirmed to meet the approved criteria, one is a false positive and two remain unclear, report exactly that. Do not say the AI recovered five qualified applicants. Do not calculate a placement return from those five without downstream evidence. This distinction makes the result credible enough for operations leaders to evaluate.

Connect only after the pilot demonstrates value

There are three reasonable implementation levels:

1. Manual, authorized export. An operator exports a small permitted set and imports only reviewed findings to the existing workflow. This is simple to audit and exposes data-quality problems early.
2. Read-only integration. A scoped API retrieves applications and source documents into a protected review process while leaving source records unchanged. Check permissions, attachment expiry and access logs.
3. Controlled write-back. After the first two levels work, authorized users can publish approved notes or tags back into the ATS. Use immutable identifiers, idempotent updates and clear error handling. Never let a failed write silently imply that a human disposition changed.

Greenhouse has Harvest APIs and recruiting webhooks, Workable documents candidate events, and Ashby supports reports and programmatic access. Actual endpoint availability, subscription tier, user permissions, regional requirements and vendor agreements must be checked before any implementation commitment. The interface can look integrated while the underlying permissions are not.

Eight failure cases that matter in production

Old version wins. A resume was updated in the ATS after the export. The external review still reflects the old copy. Require source version or retrieval time before showing a confident conclusion.

One person, two job applications. A note for a backend role gets attached to a data analyst application. Use application-level identifiers as well as candidate identifiers.

Unreadable PDF. The extracted text is empty, but the reviewer never sees the error. Surface a document exception rather than an empty candidate report.

Hidden auto rejection. An apparently harmless setting excludes applicants before the new review lane runs. Audit the upstream rules and sample disqualified records.

Duplicate contacts. Two systems independently email the same person. Retain communication ownership in the existing process.

Expired permission. The pilot exports historical resumes that no longer have a valid basis for this use. Check retention, notice and access policies before review.

Overly broad score. A model highlights an adjacent skill as proven production experience. Show source passages and uncertainty rather than promoting a synonym to competence.

Silent write-back failure. The second system displays "reviewed" while the ATS still displays an earlier decision. Queue a reconciliation task with an explicit failure state.

Measure outcomes by the workflow, not the vendor

The best test of a screening improvement is what changed in the agency: fewer repeat reviews, fewer missed candidates, clearer evidence for client submissions and less time spent rebuilding summaries. Metrics can include verified recovery from the rejected queue, percentage of cases needing source correction, time to prepare a client shortlist and human disagreement resolution time.

Vendor surveys can suggest where to look, but correlation between technology adoption and revenue growth does not establish that a particular feature caused the growth. A business case should be grounded in the agencies own baseline and pilot costs. Stop a feature that increases false confidence or client confusion even if it makes a dashboard look busy.

FAQ

Do we need to replace our ATS to improve screening?

Usually not before you identify the specific failure. Many improvements involve job criteria, review processes, data quality or a narrow evidence layer that can coexist with the current ATS. Migration may eventually be necessary, but it should follow a separate business case.

Can a review layer automatically reject candidates?

That should not be the default. Use the tool to surface evidence and uncertainty, with hiring decisions in the approved human workflow. Any automation with employment consequences needs a separate, context-specific legal and operational assessment.

How do we avoid creating duplicate work?

Assign one system to each field and action, start with read-only access, publish only human-reviewed findings and reconcile every write-back. Avoid building another communication and candidate-status tracker unless the original one is genuinely unusable.

Make the current system produce better decisions

A good recruiting operations project should feel smaller after the diagnosis, not larger. Preserve what the ATS already does, fix the weakest evidence handoff, and measure a limited second-review pilot. If the improvement survives a fair test on actual applications, then decide whether it deserves deeper integration. That sequence makes the agency more capable without forcing it to abandon the candidate history it already owns.