Tie hiring to 6–12 month performance with a quality-of-hire system

Most recruiting orgs can tell you time-to-fill down to the day and cost-per-hire down to the dollar. Ask them which sourcing channel produced people who were still performing well nine months later, and the room goes quiet.

That gap is the whole problem. Everything upstream of the offer gets measured obsessively. Everything downstream — the part that actually tells you whether hiring worked — lives in a different system, owned by a different team, with no shared key to join it back.

A quality of hire system is the plumbing and the rules that close that gap. Not a single metric. A set of field mappings, joins, attribution rules, survey cadences, and decision thresholds that let you answer one question honestly: did the people we hired turn into good employees, and can we trace that back to how we hired them?

This is a build article. If you want the philosophy of quality-of-hire, this isn't it. We're going to walk through the data model, the joins, the SQL, the surveys, and the governance cadence — the actual artifacts you hand to your TA analyst and your finance partner.

Why quality-of-hire dies in the join

The reason so few teams have a working system isn't that they don't care. It's that the data lives in three systems that were never designed to talk to each other, and the identifiers don't line up.

Here's the pattern almost everyone hits:

1. 1
   The ATS knows the candidate, the requisition, the source, the recruiter, and the interview scores. It stops caring the moment the offer is accepted.
2. 2
   The HRIS picks up as a new employee record — usually with a brand-new employee ID that has no field pointing back to the ATS application.
3. 3
   The performance / PM system (whether that's a dedicated tool, ramp metrics in Salesforce, or manager ratings in a review platform) knows how the person is doing at 6 and 12 months, but has never heard of a "requisition."

So you've got three tables and no clean foreign key between them. In practice, this usually shows up as someone filing an analytics ticket asking "can you tell me quality-of-hire by source?" — and then the analyst spends two days doing fuzzy name-and-email matching across systems, lands at maybe a 70% match rate, and quietly decides the number isn't trustworthy enough to present.

That's the failure mode. Not lack of ambition — lack of a canonical identity join that survives the handoff from candidate to employee.

If your data ownership and schema situation is a mess before you even start, fix that layer first. The mechanics of who owns which field and how records get keyed across systems is its own project, and we've covered the schema and cross-system attribution groundwork separately. This article assumes you're ready to build the layer on top of it.

The canonical model: what joins to what

Before any SQL, you need agreement on a small set of canonical entities and the keys that connect them. Keep it deliberately small. Every extra field is a field someone has to maintain.

The core entities:

1. 1
   person — one real human, one stable ID, regardless of how many times they applied or how HRIS re-keyed them
2. 2
   application — a candidate's attempt at a specific req (ATS)
3. 3
   hire — the moment application becomes employment (the bridge record)
4. 4
   employment — the ongoing employee record (HRIS)
5. 5
   performance_event — a dated performance signal (PM / reviews / ramp data)

The whole system lives or dies on the hire bridge. That's the record carrying both the ATS applicationid and the HRIS employeeid. If you get nothing else right, get this: someone or something has to stamp the HRIS employee record with the originating application ID at the moment of hire. Do it manually in the first month if you have to. Automate it after.

Canonical field mapping

Here's the mapping we recommend as a starting point. Adjust names to your stack, but keep the roles.

Two fields quietly break everything: sourcechannel and hiredate.

A diagram of the canonical join and data flow can make this clear.

Source channel is a swamp in almost every ATS. You'll find "LinkedIn," "Linkedin," "LI-Recruiter," "linkedin.com," and "Referral - LinkedIn" all as separate values. Before any attribution means anything, build a normalization mapping table and apply it in your transform layer. Otherwise your "best channel" analysis is just measuring which spelling recruiters prefer.

Hire date disagrees between systems more often than you'd expect — offer-accepted date in the ATS, start date in HRIS, sometimes a "hire date" that's neither. Pick one as canonical (usually HRIS start date), document it, and stick to it. Every 6-month and 12-month window keys off that field.

Attribution rules: what counts as a "good hire" credited to what

You can't compute quality-of-hire until you decide, in writing, what attributes to a hiring decision and what doesn't. Most teams wave their hands here. Don't.

1. 1
   Attribution window. A hire is attributed to its source channel and recruiter permanently. Performance is measured at fixed windows: 6 months (±2 weeks) and 12 months (±2 weeks) from HRIS start date.
2. 2
   Regretted attrition rule. A voluntary or involuntary exit before 12 months, flagged regretted by the manager, counts as a negative outcome attributed to the hire. Non-regretted exits (restructure, role elimination) are excluded, not counted as failures.
3. 3
   Performance normalization. Because review scales change and departments grade differently, normalize perf_rating to a percentile within department and level before comparing across cohorts. A "3 out of 5" in one org is a top rating; in another it's a warning.
4. 4
   Minimum tenure for scoring. Anyone with less than the window tenure at measurement time is NULL, not zero. Excluding them is honest; scoring them as failures is not.
5. 5
   Composite definition. Define quality-of-hire per hire as a weighted blend — for example: 40% normalized performance percentile, 30% retention-through-window, 30% manager satisfaction (from post-hire survey). Weights are a policy decision, not a technical one. Write them down and version them.

The insight most teams miss: attribution rules are a governance artifact, not an analytics preference. If your analyst changes the regretted-attrition logic between quarters, your trend line is fiction. Lock the definitions, version them, and note the version on every report. This is the same discipline that makes any data-driven hiring system with enforceable decision rules actually hold up when someone challenges the numbers.

Sample queries

These are illustrative — schema names will differ — but they show the shape of the work.

Build the hire bridge (the join everything depends on):

CREATE TABLE hirebridge AS SELECT a.applicationid, a.requisitionid, src.normalizedchannel AS sourcechannel, r.recruiterid, w.employeeid, w.hiredate, w.department, w.managerid, w.terminationdate, w.termreason FROM atsapplication a JOIN atsrequisition r ON a.requisitionid = r.requisitionid LEFT JOIN sourcemap src ON a.rawsource = src.rawsource JOIN hrisworker w ON a.applicationid = w.originapplicationid WHERE a.status = 'hired';

That JOIN ... ON a.applicationid = w.originapplicationid is the whole ballgame. If originapplication_id isn't populated in HRIS, you're back to fuzzy matching. Get that field stamped at hire.

Quality-of-hire by source channel at 12 months:

SELECT h.sourcechannel, COUNT() AS hires, ROUND(AVG(p.perfpercentile), 2) AS avgperfpctile, ROUND(AVG(CASE WHEN h.terminationdate IS NULL OR h.terminationdate > h.hiredate + INTERVAL '12 months' THEN 1 ELSE 0 END), 2) AS retained12mo, ROUND(AVG(CASE WHEN h.termreason = 'regretted' AND h.terminationdate <= h.hiredate + INTERVAL '12 months' THEN 1 ELSE 0 END), 2) AS regrettedattrrate FROM hirebridge h LEFT JOIN perfnormalized p ON h.employeeid = p.employeeid AND p.perfeventdate BETWEEN h.hiredate + INTERVAL '11 months' AND h.hiredate + INTERVAL '13 months' WHERE h.hiredate <= CURRENTDATE - INTERVAL '12 months' GROUP BY h.sourcechannel HAVING COUNT() >= 8 ORDER BY avgperfpctile DESC;

Note the HAVING COUNT(*) >= 8. Small cohorts produce dramatic, meaningless numbers. A channel with three hires will look like your best or worst source purely by chance. Set a minimum-n floor and enforce it everywhere.

Post-hire surveys: timing and question sets

Manager and new-hire surveys are the qualitative half of quality-of-hire, and timing matters as much as the questions. Ask too early and you're measuring onboarding logistics. Ask too late and nobody remembers the hiring process.

1. 1
   Day 30 — new hire. Focus on whether the role and team matched what was sold during hiring. Catches expectation mismatches early, while they're still fixable.
2. 2
   Day 90 — hiring manager. First real read on whether this person can do the job. Short. Five questions max.
3. 3
   Month 6 — hiring manager. The core quality-of-hire signal. Would you hire this person again? Are they where a strong hire should be at this point?
4. 4
   Month 12 — hiring manager + new hire. Full-cycle read, feeds the composite score and the regretted-attrition context.

Keep question sets tight and consistent across cycles so you can trend them. A usable manager set at month 6:

1. 1
   Compared to a strong performer in this role, where does this person sit? (well below / below / at / above / well above)
2. 2
   Would you hire this person again knowing what you know now? (yes / no / unsure)
3. 3
   How accurate was the candidate assessment during hiring, in hindsight? (1–5)
4. 4
   Have there been any surprises — skill gaps or strengths — you didn't expect from the interviews? (free text)
5. 5
   Is this person on track to be a long-term fit? (yes / no / too early)

Question 2 is the money question. The percentage of "would hire again = yes" at month 6, sliced by source and by recruiter, is one of the cleanest quality-of-hire signals you'll get, and it's simple enough that finance can understand it immediately.

One operational note: survey fatigue is real. If managers are drowning in month-6 surveys for every hire, response rates collapse and your data skews toward whoever happens to have time. Keep surveys to five questions, pre-fill everything you already know, and route them through whatever tool the manager already uses daily rather than a separate survey platform.

Decision thresholds: when to actually do something

Data without an action rule is just a dashboard. The point of the system is triggering remediation. Set thresholds in advance so nobody has to argue about whether a number is "bad enough" to act on.

Example threshold framework (tune to your baseline):

1. 1
   Source channel review triggered when a channel with ≥8 hires shows avg performance percentile below 40 or regretted attrition above roughly 20% at 12 months. Action: pause or renegotiate spend on that channel.
2. 2
   Assessment recalibration triggered when "candidate assessment accuracy" scores average below 3.0 for a role family. Action: revisit the scorecard and interview loop for that role.
3. 3
   Manager onboarding review triggered when hires under a specific manager underperform across multiple cohorts. This is often a manager signal, not a hiring signal — an important distinction the composite can obscure.
4. 4
   Recruiter coaching triggered when a recruiter's hires trend below cohort median across two consecutive quarters with sufficient volume.

That last qualifier matters. Never trigger individual remediation on thin data. A recruiter who made four hires in a quarter can't be fairly ranked. Volume floors protect people from noise-driven conclusions.

When this system makes sense — and when it doesn't

When it's worth building: you're hiring at enough volume that cohorts reach meaningful size (roughly 100+ hires a year across role families), you have identifiable performance signals, and you're spending real money across multiple sourcing channels you want to compare.

When it's a bad idea: you're making a handful of hires a year. At that volume, every quality-of-hire number is dominated by chance, and you'd be making channel decisions off two data points. Talk to your managers directly instead — you'll learn more.

Who should not do this yet: teams whose ATS-to-HRIS handoff has no shared key and no path to one. Build the identity bridge first. Everything else is downstream of that join working.

A realistic build scenario

A mid-sized software company — around 180 hires a year across sales, engineering, and support — wanted to know why sales ramp was so inconsistent. Their ATS reporting showed two dominant sales sources: an agency and inbound applicants, roughly even on volume and cost-per-hire.

The problem: cost-per-hire looked nearly identical, so procurement saw no reason to change anything. Nobody had joined hiring source to 6-month quota attainment because HRIS employee records didn't carry the application ID.

They spent about six weeks doing three things: stamping originapplicationid on new HRIS records going forward, back-filling the bridge for the prior 18 months via email matching (landed at roughly 85% coverage, good enough), and normalizing the source-channel swamp down to about a dozen clean values.

What surfaced: agency sales hires were reaching around 60–70% of quota by month 6, while inbound and referral hires were closer to 90%+. Same cost-per-hire on paper. Very different outcomes six months in. Regretted attrition on the agency cohort was also running noticeably higher inside the first year.

The action was straightforward once the number existed — they cut agency spend for that role family and shifted budget into referrals and inbound nurture. The finance conversation, which had gone nowhere for a year on cost-per-hire alone, took one meeting once they could show quota attainment by source.

The lesson isn't "agencies are bad." It's that the decision was invisible until the join existed. The data had been sitting in two separate systems the whole time.

Governance cadence and rollout artifacts

A quality-of-hire system decays without a rhythm around it. Definitions drift, source mappings go stale, managers stop responding to surveys. Put a cadence in place from day one.

A workable governance rhythm:

1. 1
   Monthly — data quality check

   bridge match rate, survey response rates, unmapped source values. This is maintenance, not analysis.

2. 2
   Quarterly — cohort review with TA and finance

   quality-of-hire by source and role family, threshold breaches, remediation decisions logged.

3. 3
   Semi-annually — definition review

   are the composite weights and attribution rules still appropriate? Version-bump if they change, and annotate reports accordingly.

4. 4
   Annually — full spend reallocation review with finance, using the year's cohort data.

The artifacts you'll actually need to hand off:

1. 1
   A one-page definition doc — what quality-of-hire means here, the composite weights, the attribution rules, the current version number.
2. 2
   A field mapping spec — the canonical model above, filled in for your stack.
3. 3
   A source normalization table — living document, updated monthly.
4. 4
   A survey pack — the four surveys, question sets, timing, and routing.
5. 5
   A threshold-and-remediation matrix — what number triggers what action, and who owns the response.
6. 6
   A finance-facing summary template — quality-of-hire by source in the language finance uses, so quarterly reviews don't turn into methodology debates.

The finance artifact is the one teams skip and regret. TA and finance measure hiring in different currencies — TA in fills and speed, finance in cost and outcome. A quality-of-hire number that ties source and spend to 6- and 12-month performance is the rare metric both sides trust, but only if it's presented in finance's frame from the start.

The real point

Time-to-fill and cost-per-hire measure the cost of hiring. They say nothing about whether it worked.

A quality of hire system is how you finally connect the decisions you make in the ATS to what those decisions produced a year later in the HRIS and the performance data. None of this requires exotic tooling. It requires one durable join, a small set of written rules, a survey cadence that respects people's time, and thresholds that trigger real action.

The hard part isn't the SQL — it's the discipline to stamp that application ID at hire, lock your definitions, and hold the quarterly review even when the numbers are uncomfortable. Teams that do that stop guessing which sourcing decisions to repeat. Teams that don't keep optimizing time-to-fill while quietly hiring the wrong people faster.