How Spott’s AI Matching Actually Works: From Intake Call to Ranked Shortlist
TL;DR
AI candidate matching is the process of ranking the people already in your database against a role, based on meaning rather than keywords. Spott builds the search criteria from your intake notes, scans every candidate record, and returns a ranked shortlist with a written reason for each result.
Spott reads more than the CV. Interview notes, call summaries, meeting transcripts, emails, imported profiles and manual notes all feed the same index.
Candidates come back ranked by score and rated criterion by criterion against a scorecard, from very strong down to weak.
Every result is explained in plain language, including the negatives. If someone is overqualified, it says so.
Keyword and Boolean search still exist. Matching is the alternative, not the replacement.
The recruiter still decides. Matching produces a longlist worth reading, not a hiring decision.
Why "AI matching" needs a definition
Almost every recruiting platform on the market now advertises AI matching. Very few of them mean the same thing by it, and a good number mean "we added a synonym list to our keyword search."
The distinction that matters is what the system is searching. Traditional recruitment databases are relational: rows, columns, tags, and a search box that looks for the string you typed. If a record says "soccer coach" and you search "football," you get nothing. If your consultant tagged someone as a "Business Development Manager" four years ago and you search for "Account Executive," you get nothing, even though it is obviously the same person you want.
That failure mode has a well-known consequence. Recruiters stop trusting the database, and they go back to LinkedIn to refind people the firm already knows. One agency director we spoke with put it bluntly: the researchers' first port of call when a search comes in is LinkedIn, not the CRM the firm pays for. He described it as backwards, and he is right.
Spott approaches it differently. Candidate records are vectorized, meaning they are indexed by meaning rather than by exact string. You describe what you need in ordinary sentences and the system reasons about the whole record. That is the mechanism underneath everything below.
Step 1: The criteria are built from the intake, not from a blank box
Matching starts before anyone types a search.
When you run an intake call with a hiring manager, Spott's note taker joins the meeting, records and transcribes it, and produces a structured intake summary in whatever template your firm uses. That summary attaches to the job and the client contact automatically.
When you then open the matching tool, Spott proposes the search criteria for you, drawn from the job description and that intake conversation. You get a set of natural-language criteria on screen, not an empty search bar.
From there it is yours to edit. You can rewrite any criterion, add ones the system missed, delete ones that turned out not to matter, and change the weighting so that, for example, sector experience counts for more than seniority. This is the part that gets skipped in most demos and it is the part experienced recruiters care about most: the search is built from sourced criteria you can see and change, not from a hidden prompt.
Step 2: Describe the role the way you would describe it to a colleague
The criteria are plain English sentences. Something like:
"Software engineer with at least three years of hands-on Java and Python experience, currently based in Belgium, working in B2B software."
Or four or five sentences describing a leadership profile in the nuanced way an executive search consultant would actually brief a researcher.
You can layer hard filters on top for the things that genuinely are binary: location, availability, right to work, salary band. Semantic search handles the judgment; hard filters handle the facts.
What you no longer do is construct Boolean strings. Boolean search is still available in Spott for the cases where it is the right tool, and plenty of recruiters keep using it for quick lookups. But for "find me the people in our own database who could do
this job," describing the role beats assembling a query.
Step 3: The scan reads everything attached to the person
This is where the depth comes from, and it is the part that is hardest to replicate if your platform was built on a relational database fifteen years ago.
When the scan runs, Spott looks at every piece of context attached to a candidate record:
- The CV or resume, parsed into structured experience and education
- Profile data imported when the candidate was first added
- Interview notes and manual notes written by any consultant in the firm
- Call summaries and meeting transcripts captured by the note taker
- Email correspondence held against the record
- Enrichment data pulled onto the profile
All of it passes through the same index. So a detail a colleague captured in a screening call two years ago, one that never made it into a structured field because nobody had time, is still searchable today. That is the practical difference between a database and an institutional memory.
Step 4: A ranked longlist, graded criterion by criterion
The scan returns your database ranked against the criteria, each candidate carrying an overall score and a separate rating for every criterion on the scorecard, from very strong down to weak.
That second part is what makes the list readable. A single blended score tells you almost nothing, because two candidates on 75% can be 75% for completely different reasons. Seeing the criteria as columns tells you immediately which one is strong everywhere and which one is carrying a serious gap behind a decent average.
A few things are worth understanding about how to read that list.
A weak match is still a match. It is not a failed result, it is a candidate who satisfies part of the brief and not the rest. For hard-to-fill roles that bottom half of the list is often where the interesting conversations start.
The list is re-rankable. If you look at the top of the list and realize you have mis-specified the brief, which happens constantly on real searches, you adjust a criterion or a weighting and re-run. The loop is fast enough to be iterative rather than a one-shot query.
It searches your database, not a scraped pool. Spott does not sell you a bought-in dump of profiles. The premise is that the firm's own network, properly indexed, is the asset that is currently going to waste.
Step 5: Every result explains itself
This is the feature that decides whether a matching tool gets used or quietly abandoned.
Click any candidate and Spott shows you, in plain language, why the system ranked them where it did. It goes criterion by criterion through the scorecard: strong on this, moderate on that, and here is the specific evidence in the record that supports each judgment.
Crucially, it tells you the bad news too. If a candidate has eleven years of experience for a role scoped at five, the explanation says they may be overqualified. If they meet the technical bar but the sector is adjacent rather than exact, it says that.
There is no black box, and that matters for two reasons beyond recruiter trust. First, you are going to have to justify a shortlist to a client, and "the algorithm liked them" is not a justification. Second, an explanation that shows its evidence is an explanation you can catch being wrong.
Step 6: Accept, reject, move on
From the results view you accept candidates into the pipeline for that job or reject them, with the reasoning panel on one side and the full profile on the other. Accepted candidates enter the workflow stages your firm configured. From there you move to outreach, screening and presentation.
The design intent across the whole flow is narrow: get the recruiter to a defensible shortlist quickly, so the time goes into the conversation with the candidate rather than the search for them.
What AI matching does not do
Worth being straight about the limits, because inflated claims are how this category lost credibility in the first place.
It does not decide. It ranks and it explains. A recruiter reads, judges, and picks up the phone. The explanation exists precisely so that the human can overrule it.
It is only as good as the context it has. A firm that migrates in a database of bare name-and-email records will get a thinner result than a firm with years of interview notes attached to profiles. This is the honest catch with any AI layer on top of recruitment data, and it is why the note taker matters as much as the matching engine. One feeds the other.
It does not replace sourcing. If the right person for the role has never spoken to your firm, they are not in your database and no amount of semantic search will conjure them. Matching answers "who do we already know," which is a different question from "who exists."
See it on your own database
The claims above are testable in one meeting. Book a 30-minute Spott demo, bring a live role, and watch the longlist come back ranked and explained against your own records.
, bring a live role, and watch the longlist come back ranked and explained against your own records.
