Candidate matching software: how AI matching works and how to evaluate it
By Drippay, Inc.Published 8 min read
Candidate matching software takes a job and returns a ranked list of people who may fit it, drawn from your own ATS, an external market of profiles, or both. Vendors rarely disclose exactly how the ranking is produced, so the useful questions are which pool it ranks, what inputs it uses, whether a recruiter can see why someone ranked where they did, and how it performs on your reqs.
This guide covers what matching does, the techniques vendors describe, what match quality depends on, a fair way to evaluate tools, and a checklist for the buying decision.
What is candidate matching software?
Matching sits between search and screening. Search returns records that satisfy a query, possibly ranked. Screening evaluates one candidate against a role, often with questions or an assessment. Matching takes a role and a candidate pool and orders the pool by estimated fit, so a recruiter reviews a short list rather than everything the query returned.
The category includes matching built into an ATS or CRM over the firm’s own records, sourcing platforms that also rank an external market, and rediscovery tools that match a new req against past applicants. Many products do more than one of these, so ask which pool a ranking came from before comparing rankings.
Related: Candidate rediscovery: re-engaging the candidates already in your ATSCandidate sourcing software: how to evaluate sourcing tools
Techniques vendors describe
Product pages describe inputs and outputs more than internals, and the same product may combine several approaches. The table lists what vendors say and what each approach implies for a buyer.
| Approach | What the vendor describes | Implication for the buyer |
|---|---|---|
| Search built from the job description | Bullhorn describes auto-building a search from the job description with a keyword library that suggests terms, returning top matches with relevancy scores | The req text is the query; a vague req produces a vague ranking |
| Joint analysis of profile and requirements | Loxo describes AI that analyzes candidate profiles and job requirements to surface matches; Spott describes semantic search matching | Likely handles synonyms and adjacent experience; ask how a single result is explained |
| Outcome-informed scoring | Alex describes relevance scores combining skills, experience, location, and performance data from past interviews | Uses history as a signal; ask what history is used and how it is refreshed |
| Continuous matching | Bullhorn describes finding and ranking candidates continuously, and Alex describes recommending candidates for other open roles | Results arrive as notifications; decide who reviews them and how outcomes are logged |
Vendor descriptions as of September 2026 from the pages linked under Sources. Embedding-based similarity is one possible technique behind semantic matching; vendors generally do not publish their architecture.
What match quality depends on
Both the product and the inputs matter, and only the inputs are under your control. Bullhorn’s Amplify guidance says matching performance improves significantly when candidate and job data is standardized and up to date, and recommends title and skill normalization, standardized employment history, starting with a small, high-quality pool of recently engaged candidates, and deploying matching first on repeatable roles and on jobs the team cannot prioritize.
Three things to check in your own workflow: how specific your reqs are as written, how consistent your titles, skills, and employment fields are, and whether interview and placement outcomes flow back into the tool at all. You can measure the data effect directly by running the same tool on a role family before and after a normalization pass.
How to evaluate matching tools fairly
Demos run on the vendor’s data. Run the test on yours, in two parts.
- Retrospective: pick several reqs you filled in the last year. Load each req as it was written at the time and rank records as they stood before the hire, without placement notes or post-hire updates the tool could not have seen. Treat the people you interviewed and placed as reference cases, not a perfect answer key; a highly ranked candidate you never spoke to may have been a real miss on your part.
- Independent relevance review: have a recruiter who did not work the req rate the top twenty for each tool blind, marking clear misses on location, credential, or seniority. Compare the ratings across tools, and check whether each tool can explain its misses.
- Prospective: run the shortlisted tools on live reqs for a few weeks. Count how many ranked candidates are submitted and interviewed, and how much recruiter time the ranking saves or costs.
A worked example: a clinical team tests two tools on filled travel-nurse reqs. One ranks the placed nurse highly on most reqs but surfaces candidates without the required state license; the other never misses a license because licensure is a hard filter, but its rankings otherwise look weaker in the blind review. The test has told you exactly what to ask each vendor: a license filter from the first, and a ranking explanation from the second.
Human review and job-related evidence
A ranking becomes a decision when it determines who a recruiter looks at. Keep a person between the ranking and any rejection, score on evidence tied to the job (credentials, experience, location, availability) rather than on proxies, document the criteria used for each req, and ask vendors what documentation they provide about how their matching is tested for fairness. Requirements for automated hiring tools vary by jurisdiction; confirm what applies in your markets with counsel.
Buying checklist
Take these into every demo.
- Which pool does it rank: our ATS, an external market, or both? Can we restrict to one?
- Can a recruiter see why a candidate ranked where they did, in terms they could repeat to a client?
- Which criteria can be hard filters, and which are scored?
- Where do results appear, and who reviews them?
- How do interview and placement outcomes flow back, and can the vendor demonstrate a ranking that changed because of them?
- What data leaves the ATS, where is it stored, and how is it deleted when we leave?
- What is the pricing unit, and what does it cost when the database doubles?
Discuss this workflow with dreach
dreach is a managed service for staffing firms, run by hand in the pilot. It watches the employers your firm knows and the ones it can reach through a warm path, such as a current or past client, a person your firm placed who now works at the hiring company, or a contact your team authorizes. It flags new openings with the source and date, confirms the hiring manager to contact, and shows the warmest way in. For a live role, it ranks people your firm already knows from its own ATS, past placements, and network your firm authorizes, and shows why. Your team makes every contact; dreach contacts no one. Scope, data access, integration requirements, and availability are confirmed before starting.
Want to test this against a real req? Bring one and we will walk through your existing records and what fit and relationship evidence actually holds up.
Discuss your candidate workflowCandidate matching software is a ranking layer whose quality depends on the product and on the reqs and records you give it. Test on your own filled reqs without post-hire leakage, add a blind recruiter review and a prospective run, insist on explainable results and hard filters for non-negotiables, and keep a person between the ranking and any decision.