How to Write a Job Description for Better AI Matching

Take the same Operations Executive role and write it two ways. Version one lists twelve requirements as a flat bulleted block: Excel, vendor coordination, two years’ experience, a bachelor’s degree, SAP familiarity, willingness to travel, and six more, no ranking, no grouping. Version two takes the identical twelve items and splits them: three tagged must-have, nine tagged nice-to-have. Run the same 200-resume applicant pool against both, and the match-score spread isn’t a rounding difference — it’s the difference between a rank order that separates real candidates and one that doesn’t. Writing a job description for AI resume matching is mostly a structure problem, not a wording problem, and the must-have-versus-nice-to-have split is the single highest-leverage piece of that structure.

A flat list forces the matching engine to guess at weight

When every requirement in a JD carries equal visual and structural weight, a matching engine has to infer, on its own, which ones actually matter more. It can lean on cues like word order or repetition, but those are weak signals compared to an explicit tag. The practical result is a scorer that either treats all twelve requirements as roughly equally important — which under-penalizes a candidate missing something genuinely essential — or leans too hard on whichever requirements happen to have the most distinctive vocabulary, which has nothing to do with actual importance. Either way, the flat list pushes a decision that belongs to the hiring manager down onto the scoring layer, which is the wrong place for it to be made.

What tagging actually changes in the score

Once a JD’s structured rubric marks SAP familiarity, vendor coordination, and two years’ experience as must-haves, a resume missing even one of those three caps out well below a resume that has all three but is thinner on the nine nice-to-haves. Compare that to the flat-list version, where a resume strong on eight of twelve generic-weighted items can outscore a resume that nails the three items that actually determine whether someone can do the job on day one. The tagging doesn’t make the matching engine smarter. It gives the engine permission to be as smart as the hiring manager already is about what matters, instead of guessing.

The must-have discipline that makes tagging work

Tagging only helps if the must-have list is actually short and actually non-negotiable. SHRM’s guidance on business-driven recruiting frames a genuine must-have as something a candidate cannot do the job without — safely, legally, or at a baseline competent level — and treats everything else as negotiable by definition. A JD with nine items tagged must-have hasn’t actually prioritized anything; it’s relabeled the same flat list with an extra column. The discipline is uncomfortable precisely because it forces a hiring manager to admit that most of what feels important on a JD is actually a preference, not a requirement, and that admission is exactly what a matching engine needs in order to rank candidates the way a human reviewer actually would.

Where this shows up worst: the requirement that’s really two requirements

A common structural mistake compounds the flat-list problem: bundling two separate requirements into one line, like “3+ years in operations with SAP experience.” Guidance on writing job requirements that actually attract the right candidates makes the same point from the candidate-experience side — a bundled requirement forces an applicant to guess whether partial overlap on one half is even worth applying for, and the guesswork doesn’t go away on the matching side either. A candidate with four years in operations and zero SAP exposure, and a candidate with one year in operations and strong SAP experience, both partially match that single bundled line, and the matching engine scoring against one combined requirement can’t cleanly express that they’re missing different halves of it. Splitting it into two separate, individually tagged lines — years of operations experience as one requirement, SAP familiarity as a second, tagged independently — lets the engine score each candidate’s actual gap precisely instead of averaging two different kinds of partial match into one number that describes neither candidate accurately.

What this looks like for a role with almost no true must-haves

Not every role has three sharp must-haves. A generalist associate role might genuinely have one — a language requirement, say — with everything else meaningfully flexible. That’s fine, and it should be tagged that way rather than padded with false must-haves just to make the JD look more selective. Job postings that inflate requirements past what a role actually needs create a different problem — vague, aspirational language that produces an unreliable rubric regardless of how it’s tagged — but a short, honest must-have list with one real item is structurally sound even though it looks sparse. The goal of tagging isn’t to make a JD look rigorous. It’s to make the matching engine’s ranking logic match the hiring manager’s actual decision logic.

The same discipline matters even more at the extremes of the applicant pool. A niche technical JD benefits from must-have tags that name specific adjacent tools or techniques, since the matching engine has less shared vocabulary to lean on without them. A fresher-track JD benefits from the opposite move — keeping the must-have list honest about what a candidate with no paid work history could plausibly show, rather than importing must-haves written with a lateral hire in mind.

A worked comparison across the same applicant pool

Run 200 resumes against the untagged version of the Operations Executive JD, and the Strong Go band tends to fill with resumes that happen to check the most boxes overall — often candidates who are broadly experienced but not necessarily strong on the three things that matter most for this specific role. Run the same 200 resumes against the tagged version, and the Strong Go band narrows to candidates who clear all three must-haves, with the nine nice-to-haves acting as a tiebreaker among that smaller, more relevant set rather than as an equal-weight input from the start. The second version produces a shorter shortlist. It also produces one a hiring manager is far more likely to agree with on a spot check, because the ranking logic mirrors how they’d have prioritized the twelve requirements themselves, if asked.

Writing this into a JD without slowing down a campaign launch

None of this requires a rewrite of the JD’s prose — the twelve requirements can stay worded exactly as they were. The change is purely structural: grouping them into two visually and structurally distinct sets before the rubric gets built, and being willing to argue about which three or four genuinely belong in the smaller set. That conversation, same as reviewing a generated rubric before a campaign goes live, takes a hiring manager ten minutes the first time and closer to two on repeat roles, and it’s the highest-leverage ten minutes available before a campaign opens — cheaper by far than re-reading a Reject band later looking for a candidate the untagged version scored too low.

The take

A JD that lists twelve requirements with no weighting isn’t more thorough than one that tags three as must-have and nine as nice-to-have. It’s just less decided. The matching engine can only rank candidates as precisely as the JD tells it what actually matters, and a flat list is a hiring manager declining to answer that question before the resumes start arriving — which means the matching engine ends up answering it by default, usually less well than the hiring manager would have.

If your current JDs read as flat lists, we’ll walk through restructuring one against a real applicant pool so you can see the match-score spread change before your next campaign opens.