Worked example
The best source you already pay for
Six records from an agency's own database against one live requisition. Nothing here was sourced again or paid for again — and two of these records look identical to a keyword search while meaning completely different things.
Job boards are getting worse. Postings that drew a hundred applicants now draw a thousand, profiles sit inactive for years, and every agency on the panel searches the same keywords and calls the same two hundred people. The subscription goes up regardless.
Meanwhile the database you already own holds people who have spoken to you, been placed by you, or turned you down for a reason somebody wrote down. It is the better list. Almost nobody uses it, and the reason is specific.
The bottleneck is not matching
It is that the data is unusable before matching begins. Records decay within months. Contact details rot at different speeds — a mobile number outlives a work email by years. Titles describe a job someone left. And the only genuinely valuable information, what a person actually wanted and why they said no, sits in free-text notes that no keyword search can reach.
Every vendor sells the matching layer. Almost none do the unglamorous structuring underneath, which is the part that decides whether any of it works.
The one to open first
Devon Ashworth turned down a role eighteen months ago. The note says why: five days onsite, young kids, would not commute — and that he would look again at anything fully remote. This requisition is fully remote at a rate above the one he named.
No job board can produce that, because no job board knows it. It is in your notes, and until somebody structures those notes it may as well not exist.
Try it
Six records, one requisition
Pick any record. You will see it exactly as the ATS holds it — thin fields, inconsistent tags, notes typed between calls — and then what could be structured out of it, what has decayed, and whether it is worth a call at all.
The role we are filling
Senior Data Engineer
REQ-5108 · Calder Freight Systems · Fully remote · $92/hr
- Python
- Snowflake
- Airflow
- AWS
Six records from the agency’s own database, none of them sourced or paid for again. The question is not who matches the keywords — it is who is worth a call today, and what about each record can no longer be trusted.
Your database
3 worth callingOrdered as the database returned them. Sorting by a score would hide the point, which is that two of these look identical to a keyword search and are not.
Devon Ashworth
On file as “Data Engineer” · came in via Referral from a placed contractor · last outcome: Declined offer
Verdict
Call now
Why this person, today
Reasons to pick up the phone, each traced to the note it came from. A job board can tell you someone exists. It cannot tell you why they said no last time.
The recorded title understates them
The record still says "Data Engineer", but a later note describes Python and Airflow ingestion at scale, and a Snowflake migration. A search filtered on job title would never return this person.
“runs their whole ingestion layer in Python + Airflow, moved them onto Snowflake last yr”
The reason they said no last time does not apply here
They declined over five days onsite. This role is fully remote at $92/hr. That is a reason to call — not a reason to assume they are interested.
“Turned it down, 5 days onsite was a dealbreaker, has young kids and won't commute.”
They already know us
Came in via Referral from a placed contractor. Last outcome recorded as "Declined offer", and someone here spoke to them on 2025-03-14. A call from a name they recognise is a different conversation from a cold approach off a job board.
The record, exactly as the ATS holds it
This is the material a keyword search works with. The structured fields are thin and mostly stale; everything of value is in notes typed between calls.
- Title on file:
- Data Engineer
- Skills field:
- Python, SQL, Airflow
- Record last updated:
- 2025-03-14
- Last actual conversation:
- 2025-03-14
- Email:
- d.ashworth@example.com
- Phone:
- (312) 555-0148
Tags
- python
- ETL
- contract
Notes
2025-03-14 · Dana Okafor
Spoke re: Calder req. Strong on the tech - runs their whole ingestion layer in Python + Airflow, moved them onto Snowflake last yr. Turned it down, 5 days onsite was a dealbreaker, has young kids and won't commute. Said would look again at anything fully remote. Wanted 85+.
What we could recover from it
Structured out of the notes above, each with the sentence it came from. Nothing here is asserted without a quote you can check against the record.
Reason declined
stated · 2025-03-14Five days onsite
“Turned it down, 5 days onsite was a dealbreaker, has young kids and won't commute.”
Work arrangement
stated · 2025-03-14Fully remote only
“Said would look again at anything fully remote.”
Desired rate
stated · 2025-03-14$85/hr or above
“Wanted 85+.”
Skills in use
stated · 2025-03-14Python and Airflow ingestion at scale, and a Snowflake migration
“runs their whole ingestion layer in Python + Airflow, moved them onto Snowflake last yr”
What has rotted
Different parts of a record decay at different speeds. Treating the whole thing as equally true is why reactivation lists produce dead numbers and awkward calls.
Contact details
aging560 days oldLast actual conversation 2025-03-14.
Role and seniority
aging560 days oldRecorded as "Data Engineer" and not updated since 2025-03-14.
Rate expectation
stale560 days old"$85/hr or above", from a note dated 2025-03-14.
Availability
unusableNot knowable from a record. Whatever the notes say, this has to be asked.
The call
Built only from what was recovered above. If there had been nothing to personalise with, there would be no opener here — a generated line that could have been sent to anyone teaches a recruiter the output is filler.
“Devon, we spoke in March 2025 about a Senior Data Engineer role and you passed because of five days onsite. I have one now that is fully remote — worth five minutes?”
Confirm on the call
- Are you on something at the moment, and when does it finish?
- Our note says $85/hr or above from 2025-03-14 — is that still roughly right?
- What have you been working on since we last spoke?
Audit trail
What was read, what was judged stale, and what the recruiter did next — so the record is better after the call than it was before.
- 2026-09-25Record readsystem1 note, 3 tags, 4 fields recovered from free text
- 2026-09-25Decay assessedsystemContact details: aging · Role and seniority: aging · Rate expectation: stale · Availability: unusable
- 2026-09-25GradedsystemCall now
Synthetic data. Every person, note and record here is invented — these are not anonymised real records — and the structuring is pre-computed for this page rather than produced by a model.
Being straight about it
What is real here and what is not
Real
- The decay model, and the thresholds behind each verdict
- Every rule, and the reason it fired
- The grading, and why a record with no notes is not promoted
- The opening line, assembled only from recovered fields
- The audit trail
Not real
- Every person, note and record — invented for this page, not anonymised from real records
- The structuring, pre-computed here rather than produced by a model
- Any connection to an ATS
The thing it will not tell you
Whether anyone here is available. No record of any age can tell you that, however recent, and a reactivation list that implies it burns a recruiter’s credibility on the first call. Availability is marked unusable on every record in this example, deliberately, and it is the first question on every call sheet.
This runs on the same engine as the screening, invoice and quoting examples — shared rules, exception model and audit trail, different policy on top. The thinking behind this one is in why your database beats your job board.
How much did your database cost you?
You have already paid for it once. If nobody has re-read it since, that is usually worth an hour of conversation before the next subscription renews.