The Role-Family Resume Set, One Master to Routed Variants Without Drift

This playbook is for job seekers applying to two or three kinds of roles at once who need a small set of resume versions that never contradict each other. Work through it in order and you finish with one master file, two to four role-family variants, a written list of locked fields, a naming and freeze rule for sent files, routing rules for each employer and job board, and a weekly sync that pushes fixes into every live copy.

How many resume versions should I have?

Two to four variants, plus one master file that you never send. Each variant covers one role family, meaning a cluster of postings that ask for mostly the same evidence. Merge any two variants that share 70% or more of their content.

Published advice doesn't agree on the number:

• Two to three buckets, with one resume version for each bucket (Let's Eat Grandma).
• Three to five, on the grounds that more than five becomes hard to manage and fewer than three limits tailoring (Hireflow).
• Two at most (Resume Fox).

The merge threshold comes from a practitioner heuristic: "If 70% of your resume content stays the same, you don't need a new template." I use it as the merge line because it puts the decision on content, not on job titles.

I cap the set at four for two reasons. Each live variant adds work to every weekly sync. And four is the number of resumes LinkedIn stores at once, so a set of four or fewer fits entirely in your saved slots and nothing gets pushed out without you noticing.

How many postings to sample before you trust a family

No one has published a sample size for this. My own rule, which is a working rule and not a standard: collect at least 10 real postings per track before you settle the families, and keep adding postings until new ones stop bringing in requirements you haven't already tagged. If the tenth posting still introduces new must-haves, the track hasn't settled yet.

To score overlap between two candidate families, write out the bullets and skills each family's resume would need. Count the share that would be identical in both. At 70% or more, you have one family that happens to use two job titles.

Why do resume versions collide at the same company?

Most applicant tracking systems keep one candidate record per person for each employer and match it on your contact details. So every variant you send to one company lands on the same record, in front of the same recruiter. An applicant tracking system (ATS) is the software an employer uses to receive, store, and move applications. Its duplicate rules decide whether your two applications look like two people or one.

Greenhouse applies the Duplicate tag when a new person "matches any existing person on at least one enabled criterion." One shared phone number is enough. Merging then combines "separate candidate applications into a single candidate profile."

One thing isn't publicly documented for any vendor: exactly which earlier resume files a recruiter can open on a merged record. Assume they can see all of them. That is the only assumption that keeps you safe.

Refolk's index shows which systems recruiters actually work in. These figures are skill tags on profiles, so read them as a proxy for where your applications land, not as market share.

The practical point: at volume, most applications go into systems that remember you per employer. In the UK the picture is thinner in the same index, with 20 recruiter profiles listing Workday (among them people at GSK, UnitedHealth Group, and FTI Consulting) against 530 in the US. Don't read country market share into those numbers. The mechanism holds wherever you apply.

So, can you send a different resume for different roles at the same company? Yes, as long as both versions would survive being read next to each other. They can emphasise different strengths. They can't disagree on a single fact.

Which fields must be locked across every variant?

Lock every field that a duplicate matcher or a background check compares: legal name, email, phone, LinkedIn URL, employer names, verbatim job titles, month/year dates, and credentials. Only three things change between variants: the summary, the order of skills, and which bullets you include.

Here is why each layer is locked:

• Identity fields are the join key. Greenhouse matches on email, phone, and LinkedIn URL. Lever matches on email. Name variants such as a nickname versus your legal name split Workday records into two candidate profiles, and so does a plus alias like name+jobs@gmail.com.
• Record fields are what verification checks. HireRight describes discrepancies that range from innocent mistakes, "employment dates being wrong by a month or a job title not matching verbatim what the candidate provided", all the way to fabrication. Its benchmark reports say employment verification is the area most likely to turn up inconsistencies. In one year's report, employment-verification discrepancies were reported by 72% of respondents in APAC and 64% in EMEA.

So a variant that retitles you "Product Lead" while another calls the same job "Senior Product Manager" doesn't count as tailoring. It is a verbatim mismatch waiting for a verifier.

A limit worth stating: no primary source establishes that the summary, skills order, and bullet selection are safe to vary. That is practitioner consensus. It holds up because none of those fields is a matching key or a verified fact, but it's an inference, not a documented rule.

LOCKED FIELDS - every variant must match exactly

Legal name (as on ID, no nickname):
Email (one address, no plus alias):
Phone (one format, written identically every time):
LinkedIn URL (full, same casing):

Per role, oldest to newest:
  Employer name (exact legal or trading name you always use):
  Job title (verbatim as held):
  Start (month/year):
  End (month/year or Present):

Credentials (exact name, issuing body, date):

ALLOWED TO VARY
  Summary
  Skills order
  Bullet selection (from master only, never newly written in a variant)

The step-by-step procedure, from postings to routed variants

Run these nine steps in order. Steps 1 to 4 are setup, done once. Steps 5 to 7 happen on every application. Steps 8 and 9 recur. Each step has a done condition, so you know when to move on.

How long each part takes

What's documented:

• Tailoring from the closest variant: 15 to 30 minutes per posting.
• Routing: about 5 minutes per application, most of it the LinkedIn default swap, which one source puts at 4 to 6 minutes.
• A Workday application: one employer's FAQ puts it at about 10 minutes.

What isn't established publicly: how long it takes to set up a variant, or to run a weekly sync. Time your first sync and use that figure as your budget from then on.

Tailor from the master or from a variant?

Sources split. TheTailorCV starts every application "from a fresh copy of the master." Let's Eat Grandma tailors from the closest bucket variant. I tailor from the variant because it is already most of the way there, and that is what makes the 15 to 30 minute budget realistic. The non-negotiable part is the direction of flow: facts only ever come from the master. If you notice a better bullet while tailoring, write it into the master first, then pull it into the variant.

That direction is what Refolk enforces by default. It writes your resume from your own history and tailors it to each posting from that same source, so a tailored copy can't invent a title or date that the master doesn't hold.

Naming, freezing and logging: which resume did I send where?

Every file you send gets a name carrying the variant ID, employer, requisition number, and date, and it never changes after you submit. A six-field log entry records the send. Together they let you answer "which resume did I send where" in under a minute.

The freeze rule comes from a simple fact, put well in one practitioner guide: "It should never change again, because the recruiter is reading the version you sent." The platforms enforce it whether you like it or not. On Workday you can't change an application after you submit it, and LinkedIn's sent Easy Apply history can't be deleted. When a recruiter calls, the frozen file is what you prepare from, not the current variant.

No documented minimum set of log fields exists. These six are my minimum, because each one answers a routing question you will face later:

• Variant ID: which story this employer holds.
• Employer: the search key before every new application.
• Requisition: tells apart two roles at the same company.
• Date: tells you which master fixes the file predates.
• Channel: Easy Apply, a company portal, or a referral, so you know which default slot was involved.
• Outcome: what you'll use, carefully, in step 9.

FILE NAME
Lastname_Firstname_[VariantID]_[Employer]_[ReqID]_[YYYY-MM-DD].pdf

Example variant IDs
PM-v3    (product management family, third revision)
OPS-v2   (operations family, second revision)
DATA-v1  (analytics family, first revision)

LOG ROW
Variant ID | Employer | Requisition | Date | Channel | Outcome
PM-v3 | [Employer] | [ReqID] | [YYYY-MM-DD] | Company portal | Applied

Put the revision number inside the variant ID. When the weekly sync changes a variant, bump the revision. The log then shows exactly which sends went out before a fix, which tells you whether an old error is sitting on a live record.

Routing rules per employer and per platform default

Before every application, search your log by employer and set the platform's default resume to the variant you mean. It takes about five minutes. Routing per employer stops two contradicting stories from landing on one record. Routing per platform stops a recency-based default from sending the wrong file.

Per employer: what to send when they already have you

Repeat applications are costly, and the numbers show it. In Huntr's self-reported data, applying eight or more times at one company "cuts the per-application interview rate to 1.91%, less than a third of the rate for users who apply once (6.07%)."

The mechanism is my inference, not something the data proves: a recruiter opening your record sees every earlier application attached to it. Tailoring roughly doubles the rate. Spraying one employer cuts it by more than two thirds. The routing rule protects the first effect from the second.

Deciding which family a posting belongs to is where routing slows down at volume. Refolk scores how well you fit each posting, and that score is a quick first read on whether the posting is a strong-fit send or a skip before you spend the tailoring time.

Per platform: what each default slot does

Platform defaults go by recency, not by role. Whatever you touched last is what goes out next.

On LinkedIn, files must be PDF or Word and under 2MB. Trying to add a fifth asks you to delete one first, though one source says a fifth upload pushes out the oldest. Manage the slots directly at linkedin.com/jobs/application-settings. The older Settings & Privacy route was retired.

On Workday, a signed-in applicant chooses between "Use my last application" or "Upload a new Resume or CV." Choosing the first is fine only when the new role belongs to the same family. Otherwise, replace the document on the My Experience page before you submit.

How this goes wrong: failure modes and false positives

Most resume-set failures are silent. The wrong file goes out, the record splits, or a stale detail survives an edit, and nothing tells you. Each failure below comes with what it looks like and the check that catches it.

1. A stale LinkedIn default

What happens: your newest upload becomes the default with "no warning that the resume is 9 months old or aimed at a different function."

What it looks like: you tailored an operations file on Monday, and Tuesday's product management Easy Apply quietly sent it.

Check: open the resume step before every submit. Compare the channel column in your log against the variant ID.

2. Split identity at Workday

What happens: a plus alias like name+jobs@gmail.com, or the same phone number written in a different format, creates a second Candidate Home record at the same employer.

What it looks like: you can't find your earlier application in the portal and assume you never applied.

Check: use exactly one locked email and one phone format everywhere. If you find two records, the false negative is your log saying "new employer" when the employer has you twice.

3. Side-by-side variants at one employer

What happens: Lever shows a suitcase icon when you have several open opportunities, and Greenhouse merges profiles, so two different stories end up in front of one recruiter.

What it looks like: a screening call where the recruiter asks why your summary says one thing on one application and another thing on the other.

Check: search your log by employer before applying, and follow the matrix above.

4. "Use my last application" carries over the old variant

What happens: Workday prefills from your last application at that employer, including the old resume.

What it looks like: an analytics application that arrives with your operations variant attached.

Check: replace the document on the My Experience page whenever the family changes.

5. Leftover details from a previous edit

What happens: one practitioner guide calls this the riskiest failure: "a leftover company name or detail from a previous version's edit."

What it looks like: a summary line that names the last employer you tailored for.

Check: re-read the exported PDF, not the editing file, before every submit. Leftovers hide in the export, not in the draft you've been staring at.

6. Titles that drift between variants

What happens: one variant rounds a title up or down to suit the family.

What it looks like: a background check that reports a title "not matching verbatim what the candidate provided."

Check: diff the locked fields across all variants during every weekly sync.

7. Retiring a variant on noise

What happens: a variant gets no callbacks in its first few dozen sends and you drop it.

What it looks like: a confident conclusion built on a sample too small to support it. By the rule of three, zero callbacks in 50 sends is still consistent with a true rate of up to 6%, which is above the tailored average in Table C.

Check: read step 9's thresholds before deleting anything.

A resume set fails quietly: the wrong file goes out, and nothing ever tells you it did.

Weekly sync and retiring variants

Once a week, push every master fix into each live variant, re-run the locked-field diff, re-export, and reload the job-board default slots. Retire or merge variants based on content overlap and on which families you're still pursuing. Callback counts are too small to settle the question.

Running the sync

1. List every change made to the master since the last sync.
2. Apply each change to every live variant where it belongs. Corrections to locked fields go into all of them.
3. Diff each variant against the locked-field list.
4. Bump the revision in each changed variant ID and re-export.
5. Reload LinkedIn's saved slots and replace your Indeed file. Leave every sent file untouched.

Deciding when to retire or merge

No public standard exists for this. The arithmetic shows why: base rates in Huntr's data run from 2.07% untailored to 4.23% tailored. A standard two-proportion test at conventional settings needs about 750 sends per variant to tell 3% from 6%. Almost no search produces that many, so this decision rests on judgement. Use these triggers instead:

• Merge when two variants' content overlap reaches 70%, which often happens as master fixes pile up.
• Retire when you stop targeting a family, not when its callback count looks low.
• Revise rather than retire when a variant has a real problem you can name, such as a weak summary for the postings you're actually seeing.

Treat callbacks as a weak signal you note in the log, never as a verdict.

To keep the system current, re-check the platform behaviour itself every few months. Slot counts, default rules, and settings paths are product decisions that can change without notice. Open linkedin.com/jobs/application-settings and count the slots. Upload a test file and see which one becomes the default. Check how each Workday portal you use offers your last application. If anything has changed, update the routing table above before your next send.