TD
Key Takeaways
- Keyword-matching systems credit the exact string; semantic systems credit the meaning. Both are in use in 2026.
- You cannot tell which one is reading your application, so write for the stricter case.
- Use the posting's exact term for the two or three central requirements, and natural language everywhere else.
- Acronyms and full forms should both appear once, together, the first time.
- Never write two synonyms side by side to hedge - that is the pattern recruiters read as stuffing.
If a posting asks for "stakeholder management" and your resume says "client relationship management," does that count?
It depends entirely on which system is reading it, and you have no way of knowing. That uncertainty has a straightforward resolution.
The Two Kinds of Matching
String matching. The system looks for the characters in the posting. "Stakeholder management" and "client relationship management" are simply different text, and the second earns nothing against a requirement for the first. Older and simpler systems work this way, and plenty are still in service.
Semantic matching. The system has a model of meaning. It can recognise that "client relationship management" occupies similar conceptual space to "stakeholder management," and give partial or full credit. Newer AI-assisted screening works this way.
Two consequences follow. Semantic systems are more forgiving, so writing for them is easy. String systems are unforgiving, so writing for them is the binding constraint. Write for the string matcher and the semantic matcher will also be satisfied.
Why you cannot find out which one you face
Employers do not publish their screening configuration, and the same vendor's product behaves differently depending on how it was set up.
Even knowing the vendor tells you little, because matching behaviour is usually a configurable layer rather than a fixed property. This is part of why two checkers give you two different scores on identical inputs - they are making different assumptions about the same question.
The Rule
For the two or three central requirements, use the posting's exact words. These are the terms in the title, repeated across sections, marked required. Precision matters most where the stakes are highest.
Everywhere else, write naturally. Peripheral terms are not worth distorting a sentence for, and a resume written entirely in the posting's phrasing reads like the posting.
That is the whole approach. What follows is how to apply it without making the writing worse.
Picking the two or three
The central requirements are the ones surviving all three signals: position near the top, repetition across sections, and specific framing.
If you cannot identify them quickly, the reduction method in reading a posting like a recruiter wrote it gets an eighteen-item list down to four in about five minutes.
Using the Exact Term Without Damage
The fear is that matching the posting's vocabulary produces stilted prose. It does, if you paste the term in. It does not, if you rewrite the sentence around it.
Your original: Looked after our biggest clients, keeping them happy and fixing problems when they came up.
Term pasted in: Looked after our biggest clients (stakeholder management), keeping them happy and fixing problems.
Sentence rewritten: Owned stakeholder management for the eight largest enterprise accounts, resolving escalations and running quarterly reviews.
The middle version is what people produce when they treat this as keyword insertion. The third is what happens when you treat it as translation - and it is better writing than the original as well as better matched.
The rewrite pattern
Every one of these follows the same shape: strong verb, the posting's noun, the scale, the outcome.
Pasting the term in leaves the original weak sentence intact with a bracket bolted on. Rebuilding around the term produces a bullet that would have been better anyway - which is why turning duties into outcomes and keyword work are usually the same edit.
A Matching Decision Table
The rule covers the common cases. This covers the rest.
| Your wording | Posting's wording | What to do | Why |
|---|---|---|---|
| Client relationship management | Stakeholder management | Use theirs, rewrite the bullet | Central requirement, string risk |
| Postgres | PostgreSQL | Use theirs | Same tool, different string |
| Looker | Tableau (in a cluster) | Name Looker honestly | Cluster means one of these |
| SEO | Search engine optimisation | Write both once, together | Covers either matcher |
| Managed a team | People management | Use theirs if central | Common phrasing mismatch |
| Reporting | Business intelligence | Judge by the posting's level | Not always the same work |
| Customer success | Account management | Use theirs if central | Adjacent, often interchangeable |
| Data cleaning | Data quality | Use theirs | Same work, their label |
| Built dashboards | Data visualisation | Keep yours, add theirs once | Specific beats generic |
| Agile | Scrum | Use whichever you actually did | They are not synonyms |
| Machine learning | Applied ML / MLOps | Use the precise one | Overclaiming is visible |
| Vendor management | Procurement | Only if it genuinely was | Different accountability |
Where the two terms describe genuinely different work, the answer is never to write both. It is to write what you did.
Acronyms: Use Both, Once
Postings are inconsistent. One says "SEO," another "search engine optimisation." A string matcher credits only what it finds.
The fix is to write both, together, on first use:
Led search engine optimisation (SEO) across three product sites, growing organic sessions 40% in eight months.
One mention covers both forms. After that, use whichever reads better.
This matters most for terms with common short forms: SEO, CRM, ETL, KPI, API, CI/CD, P&L, QBR, SLA. It matters less for terms everybody writes the same way.
When to skip the expansion
Some acronyms are the only form anyone uses. Writing "structured query language (SQL)" reads as padding, because no posting searches for the long form.
The test is whether you have ever seen the expanded version in a real posting. If not, use the acronym alone - the same judgement that governs acronyms versus full terms generally.
What Not to Do
The tempting move is to hedge by listing both:
Managed stakeholder relationships / client relationships / customer accounts and stakeholder management across regions.
This is the single most recognisable stuffing pattern. It scores marginally better against a string matcher and tells any human reader that the resume was assembled for a machine.
Pick the posting's term. Use it once. Move on.
The variants that fail the same way
Slash pairs. "stakeholder/client management" is the compressed version of the same hedge and reads identically.
Bracketed synonyms. "client relations (stakeholder management)" - the bracket is doing keyword work, not clarifying work.
A synonym line at the bottom. A block of alternative phrasings under the skills section fools nobody, for the same reasons hidden keyword tricks fail.
When the Posting's Word Is Wrong for You
Sometimes the exact term would be a false claim. "Stakeholder management" for two emails to a colleague is an overstatement, and the interview will expose it.
In that case, do not use the term. Write what you actually did, accurately, and accept that this requirement is partially covered. A smaller honest claim survives questioning; a larger false one does not.
The test: if an interviewer said "tell me about your stakeholder management experience," would you have a real answer? If yes, use the term. If you would be reaching, do not.
Partial credit is a real option
People treat coverage as binary and it is not. "Coordinated with three external suppliers on delivery schedules" earns some credit against a vendor-management requirement without claiming ownership you did not have.
Stating the true extent is almost always better than either silence or overreach, and it keeps you on the right side of the line between framing and fabrication.
A Second Example: Two Roles, One Resume
The rule gets harder when you are applying across two adjacent job families, because the same experience needs different vocabulary each time.
A data analyst applying to (a) an analytics engineering role and (b) a business analyst role, from one set of facts.
The underlying work: Built and maintained the weekly revenue reporting pipeline; rebuilt four manual spreadsheets into an automated model; presented findings to commercial leads monthly.
For the analytics engineering posting, which names dbt, SQL, data modelling and pipeline ownership:
Owned the weekly revenue pipeline end to end, modelling four source systems in SQL and dbt and replacing a manual spreadsheet process with a tested, version-controlled model.
For the business analyst posting, which names requirements gathering, stakeholder reporting and commercial insight:
Rebuilt weekly revenue reporting with the commercial team, translating their requirements into an automated model and presenting monthly findings that informed pricing decisions.
Same facts, same person, no fabrication. Each version uses the vocabulary its reader searches for. This is what tailoring actually consists of - not rewriting your history, but naming it twice.
Edge Cases
British versus American spelling
Match the posting. "Organisation" and "organization" are different strings, and a strict matcher credits only what it finds.
Where the posting is inconsistent, follow the employer's country. This matters more than people expect for terms like "optimisation," "analyse" and "specialise."
The posting uses a term incorrectly
Use their version anyway if it is what their reader will search for, provided it is not a false claim about your work. You are writing to be found, not to correct their vocabulary.
The exception is where their misuse would make you claim something untrue - then write accurately and accept partial coverage.
Job titles as keywords
Your title line is the highest-weight text on the page, and it is the one string you cannot freely change. The bracket format covers both your real title and the market term without substituting one for the other.
This is the single highest-return application of the exact-match principle, and whether to use the posting's job title deserves its own decision. Where your internal title is genuinely meaningless outside the company, translating it to the market term matters more than any other matching work on the page.
The term did not register even though you used it
Sometimes you have matched exactly and a scan still reports the term missing. Before rewriting anything, check that the section containing it actually parsed - a term inside a text box or a sidebar frame never reaches the matcher at all.
That is a structural failure wearing a vocabulary costume, and the copy-paste test separates the two in about thirty seconds.
Plural, tense and word forms
Most systems normalise simple variations - "managed" and "management," "pipeline" and "pipelines." Do not write multiple forms to cover it; that produces the hedging pattern above.
The exception is a compound term where the forms genuinely differ in meaning, such as "data model" and "data modelling" - one is a thing you built, the other is a practice you have. Write whichever is true of your work.
The term appears only in the company's own jargon
Some postings name internal product names or house terminology. These are rarely search terms and usually not worth matching.
Cover the underlying capability in standard language instead.
What This Looks Like at Each Level
Fresher. Your evidence is coursework, projects and placements, so exact-match work happens mostly in your project descriptions. Name the posting's tools where you genuinely used them and let the project section carry the terms.
Two to five years. The standard case this article describes. Two or three exact matches in your top bullets, natural language elsewhere.
Senior. Exact matching matters less because your titles and systems do more of the work, and reading like the posting is a bigger risk. Use their terms for the central two and write the rest in your own voice.
Career changer. Exact matching matters most, because your history does not signal the target field on its own. Every transferable claim should be stated in the destination's vocabulary rather than your origin's.
Common Mistakes
Hedging with synonyms. Covered above, and it is the most common failure by a wide margin.
Matching peripheral terms exactly. Distorting a sentence to capture a nice-to-have from the bullet tail costs readability and gains almost nothing.
Assuming semantic matching everywhere. Newer systems handle meaning well; plenty of employers are not running newer systems.
Matching the term but not the level. "Machine learning" when you ran a tutorial notebook is a string match and an interview failure.
Writing the whole resume in the posting's language. A document that mirrors the posting reads as assembled, and generic-sounding resumes get detected precisely by that echo.
Forgetting the skills section normalises differently. A term in a comma-separated list is matched but unevidenced, so exact matching there is the weakest version of this work.
Frequently Asked Questions
Do modern systems really understand synonyms?
The newer ones handle them reasonably well. The problem is that you cannot tell which system a given employer uses, and simpler string-matching tools remain common.
Should I use British or American spellings?
Match the posting. If it writes "organisation," write "organisation." Where you are unsure, the employer's country is the better guide.
What if the posting uses a term incorrectly?
Use their version anyway if it is what they will search for, provided it is not an outright false claim about your work. You are writing to be found by their reader, not correcting their vocabulary.
Is it worth including both a job title variant and the posting's title?
Yes, where accurate - "Business Partner II (HR Business Partner)" covers an internal title and the market term without claiming a role you did not hold.
Does plural versus singular matter?
Rarely. Most systems normalise simple variations. Do not write both forms to cover it.
How many exact matches should one resume contain?
Two or three central requirements, matched precisely. Beyond that you are writing the posting back at the employer, which reads badly to the human reader who decides.
If a semantic system is reading me, does exact matching hurt?
No. A semantic matcher credits the exact term at least as highly as a synonym. Writing for the stricter case costs nothing against the more forgiving one.
What about matching terms in my cover letter?
The same principle applies, but the letter is read by a human first, so natural phrasing matters more. Cover the central terms once and write the rest as prose.
Should I match the posting's phrasing for soft skills?
Not in your skills section, where asserted traits are discounted. Demonstrate the behaviour in a bullet using their vocabulary for it.
Does this change if I apply through a referral?
Largely yes - a referral often means a human reads you first and the matching stage is a formality. The evidence still has to hold up, but referred applications change which reader you are optimising for.
Check Which Terms Registered
The quickest way to see whether your phrasing landed is to look at what a scan found and what it did not - a term you consider covered showing up as missing tells you the wording is not connecting.
Scan your resume against a posting and read the found/missing lists rather than the score. Anything you believe you cover but that comes back missing is a vocabulary problem, and it is fixed by rewriting the bullet where that work already lives.
If you would rather see the rewrite drafted in the posting's own wording, the tailoring tool works from the same comparison.
Related: where to place keywords so they count and acronym or full term.
See which keywords you are missing
Scan your resume against the posting and get the exact terms it did not find.
Drop your resume here or choose a file
PDF only. Max 2 MB.
We never share your data or use it to train AI models.
Where those keywords actually go
A layout with a real skills section gives the parser somewhere clean to find every term you just added.
Was this guide useful?
Be the first to rate it.
