The Boomerang Rehire Playbook: Departure Export to a Timed Call Slate

This playbook is for the recruiter, sourcer, or founder who has one open req and an HRIS departure export and wants three answers before starting external sourcing: which former employees are worth calling, whether you are allowed to contact them, and who to call first. It takes you from that export to a ranked slate of 10 to 25 boomerang candidates in about two working days. Every name on the slate is cleared on rehire code, lawful basis, and severance terms, and every alum you leave off has a recorded reason. People who were finalists but never hired are a different job with a different procedure, so they are not covered here.

What does an alumni rehire pass produce, and who owns it?

An alumni rehire pass produces two things for one open req. The first is a ranked, timed call list of former employees, with five checked fields per person. The second is an exclusion log that explains everyone else. In most companies nobody owns this work, so it falls to the sourcer.

Three terms come up throughout:

• Boomerang: a former employee who is rehired by the same employer.
• Rehire code: the eligibility flag set in the HRIS when someone leaves, such as eligible, not recommended, or not eligible.
• Warm messenger: a former manager or peer who sends the first note, so the alum hears from someone they know instead of a stranger in recruiting.

Every name on the finished slate carries:

1. A rehire code that a person has checked, with the reason recorded.
2. A documented lawful basis for contacting them.
3. A current employer and role, taken from a dated public source.
4. A timing tag: now, later, or stale.
5. A named warm messenger.

Every alum who doesn't make the slate gets one row in the exclusion log, saying the stage where they dropped out and why.

Why the job falls to sourcers

Very few people hold a job title for running corporate alumni programs. In Refolk's index of professional profiles, the gap is large:

The five industries are software, IT, consulting, financial services, and accounting. Four of the five alumni-program profiles are titled "Alumni Relations Manager". Where an alumni function exists, it tends to run community and newsletters, not rehiring for a specific req.

Some large employers do run focused boomerang programs. Amazon Web Services ran one called "Swami's Boomerang Reengagement Initiative" to rehire people in AI and machine learning. Most teams don't have anything like that, so the procedure below assumes one sourcer working with an HRIS admin, an HR business partner, a privacy owner, and legal.

What do the published boomerang numbers tell you?

The widely quoted boomerang figures measure what share of a period's hires were returning employees. They do not tell you what share of contacted alumni came back. None of them is a yield target for your pass, and they disagree with each other by about tenfold.

How to read each one:

• ADP's 35% is a one-month snapshot of payroll data. It counts people who had previously been on that employer's payroll, left, and returned. It was up from 31% in the same month a year earlier. The same source puts the information sector at 68% of new hires. ADP also reports that boomerangs have made up only 2% of all active employees since 2018.
• Revelio Labs' 3.4% is the share of US new hires returning to a previous employer, up from 3.1%. Its definitions are not published in a form you can compare with ADP's.
• Visier's HR-system data agrees more closely with ADP: roughly one-third of external hires made between January 2019 and April 2022 were boomerangs.

Nobody has published the definitions, lookback windows, or handling of seasonal and hourly rehires side by side. One explanation is that payroll-ID rehires, such as seasonal staff or people returning after a short break, inflate the payroll-based figures. I could not verify that, so treat it as a hypothesis.

A published contact-to-hire rate for alumni outreach does not exist. The closest pool-based figure comes from a secondary write-up of Visier's layoff data, which says 5.3% of laid-off staff are rehired within 15 months. I could not check that against the primary report, so do not plan around it. Until you have your own rate, report the pass by slate size, clearance rate, and calls held.

Which former employees perform best after rehire?

Rank alumni first on pre-departure performance and on how much internal coordination the role needs. Both have strong evidence. Score the stability of the receiving team as a third input. Use the original exit reason only to judge the risk of a second exit, not as a performance score.

What the research found

Two large studies do most of the work here.

Arnold et al., "Welcome Back?" compared 1,318 rehired managers with 20,850 external hires and 8,546 internal promotions in a retail chain. Its findings:

• Boomerang managers' performance tended to stay the same after rehire, neither rising nor falling.
• In the first year they performed about as well as internal and external hires. After that, the internal and external hires improved more than the rehires.
• Boomerang managers were more likely to leave again, and those who left a second time tended to go for reasons similar to the first time.
• As Campion put it, "initial turnover reason was not a good predictor of rehire performance when controlling for initial performance."

Keller, Kehoe, Bidwell, Collings and Myer, "In with the Old?" compared 2,053 boomerangs with 10,858 new hires over eight years in a large health care organization. Its findings:

• The boomerang advantage was larger in jobs that need more internal coordination.
• It was also larger where the organization resisted external hires more.
• The gap shrank in work groups with many recent hires and less-tenured managers.

Read together, the studies say boomerangs skip ramp-up but bring the same ceiling back. They add the most value in roles that need impact in the first year, and in teams where knowing how things work internally pays off.

Turning the evidence into ranking weights

What each input proves, and when it misleads:

• Pre-departure performance shows the level the person is likely to come back at. It misleads when the person only ever had one rating, or when that rating came from a lenient rater.
• Coordination load shows whether their internal network will speed them up. It misleads when the old title matches the req but the coordination the work demands has changed since they left.
• Team stability shows whether that network is still there to reconnect with. It misleads when the team has turned over since the alum left, even if the team's name hasn't changed.

A common belief is that people who return to the same manager do best. Neither study tests that directly. The closest tested signal is a stable work group with a long-tenured manager, so score that and call it a proxy. Two other widely held beliefs are also unproven as performance moderators in the research I could find: that voluntary leavers outperform, and that a moderate time away helps. Use voluntary versus involuntary exit for timing and clearance, not for ranking.

What must be cleared before anyone is contacted?

Three things must be cleared:

1. A documented lawful basis that covers reusing the departure record for recruiting.
2. A rehire code with a recorded reason.
3. A check of any severance or settlement agreement for no-rehire terms.

All three come before the hiring manager sees a single name.

Lawful basis and retention purpose

The UK ICO's guidance on employment records is the clearest public source here:

• Consent: generally unsuitable in employment relationships, because of the power imbalance between employer and employee.
• Legitimate interests: often more appropriate. This is the lawful basis where you show the processing is necessary for a genuine interest that doesn't override the person's rights.
• New purposes: when you start using data for a new purpose, inform the individual and properly document the change. Recruiting a former employee back is a new purpose.
• Storage limitation: if keeping data for one purpose is justified, you cannot later use it for another purpose, particularly for decisions affecting particular individuals. A record kept to defend against liabilities cannot become a sourcing list.
• Retention periods: the ICO does not prescribe them. It expects employers to justify how long they keep each type of data.

Outside the UK I can't give you the rules from what I have. EDPB guidance specific to alumni recruiting, statutory retention periods in each jurisdiction, and California rules on employee data are not established in the sources behind this guide. Your privacy owner should confirm each jurisdiction on the slate and sign a note for it.

Rehire codes

A rehire code is one supervisor's view on the day someone left. Public-sector policies show the range of schemes and review routes:

Duke's policy adds that HR verifies rehire eligibility before activating an application. No published figure says how often codes are blank, left at a default, or set with no reason, so count it in your own export. A blank field that defaulted to "Eligible" and an unexplained "Not eligible" are both open questions to resolve, not answers to apply.

A rehire code is a supervisor's opinion on the day someone left, not a fact about them now.

No-rehire clauses

A no-rehire clause is a term in a severance or settlement agreement that bars the person from working for the employer again. Before 2020 it was common practice to include one when settling a former employee's claim, though no published figure says how common. In California, CCP 1002.5 changed this:

• No-rehire clauses are void in settlement agreements dated on or after 1 January 2020 for an "aggrieved person", meaning someone who filed a claim.
• Exception 1: the clause stays allowed where the employer made a good-faith determination that the person engaged in sexual harassment or sexual assault.
• Exception 2: no-rehire terms remain permitted in severance agreements unrelated to any claim the employee filed.

I can't speak to other jurisdictions from the sources here, so legal should check those. No published guidance covers restrictions that come from the alum's current employer, such as a non-solicit in a customer or partner contract with your company. If the alum now works for a customer or partner, ask legal before anyone reaches out.

The procedure: departure export to ranked slate

The pass takes eight steps over about two working days. Besides the sourcer, it needs an HRIS admin, an HR business partner, a privacy owner, and legal. I assembled the procedure from policy and regulator sources, because no single source documents it end to end. The durations are my estimates, not published figures.

How the two days fall

• Day one, morning: step 1, which takes about half a day. Ask only for the fields the pass uses: name, last role and team, departure date, exit type, rehire code and reason, the last performance rating, the last manager, and an agreement flag. The ICO expects data to be collected only where it is necessary for the purpose, so the field list is your evidence of that.
• Day one, afternoon: steps 2, 3, and 4 run in parallel, about half a day each. Step 2 has to be signed before step 5 starts. If a note from an earlier pass still covers the job family and jurisdictions, step 2 shrinks to a check.
• Day two: step 5 takes about a day. Steps 6, 7, and 8 take about four hours together: two for ranking, one for timing, one for messengers. Departure dates are in the export, so you can draft the timing tags during step 5 and confirm them afterwards.

If day two runs over, narrow the job family. Don't skip a gate.

Re-finding where alumni work now

Step 5 is the slowest step. Your HRIS shows where people were, and every slate row needs where they are now, from a source you can date. Doing this one name at a time across LinkedIn, GitHub, and company pages takes most of the day. Refolk lets you describe the cohort in plain English, such as former employer, former role, how long ago they left, and where they work now, and returns matching profiles from LinkedIn, GitHub, and the open web. You then check them against your cleared list.

Only run re-finds for alumni who have passed steps 2 to 4. Re-finding someone you will exclude is processing you didn't need to do.

How to read timing and brief the warm messenger

Tag each alum now, later, or stale, based on time away and exit type. Then pick a messenger who actually worked with them and give that messenger a short, honest first note that says where the contact came from.

Timing tags

People who resigned and people who were laid off come back on different clocks and on different pay terms:

• Resigners: Visier's data covered 3 million records at 129 companies. The typical boomerang returned 13 months after leaving, at an average 28% raise over their pay when they resigned. The chance of return drops sharply after 16 months.
• Laid-off staff: Visier's layoff study covered 2.4 million employees at 142 enterprise organizations. Returners came back after an average of 5.83 months, with a 5% pay increase against 2% for colleagues who stayed.

The likely reason for the difference is that resigners have tested the market, while laid-off staff are being recalled. That is why step 1 splits the export by exit type before any timing or pay assumption is made.

The cut-offs are my heuristic. They come from medians and averages and are not thresholds anyone has proven for individuals. If the req can't wait, call a strong "later" alum anyway and note why. A fresh trigger, such as layoffs at the alum's new employer, a change of tenure, or a vesting date, is a reason to reopen a stale record. It is not evidence that the person will accept, because no published work links those signals to acceptance.

Brief the hiring manager on pay before ranking. A resigner who has priced themselves in the market expects a market reset, not their old band. The often-repeated figure of "about 25%" has no primary source I could find, so quote the 28% with its source or don't quote a number.

The slate record

SLATE
rank | name | last role and team | departure date | exit type | rehire code | code reason checked (Y/N, by whom) | agreement check (none / void / enforceable, citation, date) | lawful basis note ref | current employer | current role | public source and date found | timing tag (now / later / stale) | recontact date | warm messenger | messenger relationship

EXCLUSION LOG
name | stage excluded (scope / basis / code / agreement / re-find / rank / timing) | reason in one sentence | decided by | date | review date if any

The warm messenger

Pick the former manager or peer who worked most closely with the alum and is still at the company. Ask before you name them. A messenger who hasn't agreed to send the note is not a messenger. The note should be short and say where the contact came from, because recruiting is a new purpose for that record and the ICO expects the person to be told.

Hi {first name},

It has been a while since we worked together on {team or project}. {Company} is hiring a {role} on {team}, and when we looked at who had done this work well, your name came up.

No pressure and no assumption that you want to move. If you would be open to a short call with {hiring manager}, I can set it up. If not, just say so and nobody will contact you about it again.

For transparency: your name came from {company}'s former-employee records, which HR reviewed for this one role.

{messenger name}

How does an alumni rehire pass go wrong?

Most failures come from treating something as settled when it isn't. That covers a borrowed benchmark, a code nobody explained, an exit reason read the wrong way, an archive that can't be reused, a clause that may be void, a job title that means two different jobs, and a date that has gone stale. Each one below has a check you can run in minutes.

1. Headline share used as the target

What it looks like: the team sets the alumni yield target at 35% because a payroll study said so, misses it, and stops running the pass.

Why it is wrong: 35% is a share of hires, not a conversion rate.

Check: compute your own past rehires divided by alumni contacted, for each job family.

2. Rehire code taken as truth

What it looks like: either a blank code that defaulted to "Eligible" goes through without review, or an unexplained "Not eligible" removes a strong candidate.

Check: require a documented reason before applying any code in either direction. Duke's policy, which assigns the decision to supervisors and has HR verify it, is the model. Anything without a reason goes to "under review".

3. Exit reason weighted as performance

What it looks like: alumni who left after a conflict or a pay dispute get excluded on that basis alone.

Why it is wrong: in the rehired-manager research, turnover reason did not predict performance once initial performance was controlled for. It did predict the reason for the next exit.

Check: ask whether the original reason still exists in the receiving team. If the same manager, pay structure, or workload is still there, record the risk and discuss it with the hiring manager. Don't silently cut the person.

4. Archive repurposed

What it looks like: the sourcer builds the list from a records store that was kept to defend against claims.

Why it is wrong: under the ICO's storage limitation principle, data kept for one purpose cannot be used for decisions about individuals under another.

Check: confirm each record's retention purpose before step 5. If the purpose doesn't allow recruiting use, exclude the record and log it.

5. No-rehire clause misread

What it looks like: either a California settlement clause that is void gets enforced, or a valid severance clause unrelated to any claim gets ignored.

Check: look at the agreement date (on or after 1 January 2020), whether the person had filed a claim, and whether the harassment or assault exception applies. Outside California, legal decides.

6. Title collision during the re-find

What it looks like: you search for an alum by their old title and match someone in a different function who shares the name and title. In Refolk's index, "Sourcing Specialist" also returns procurement and admin staff:

The off-target profiles included titles such as Procurement Specialist and Professional Services Category Lead. The same title can mean different work in a different market, and the smaller UK pool makes the noise a bigger share of results.

Check: confirm the current employer's industry and the role's function before accepting a match. When I run alumni re-finds in Refolk, I put the industry or function in the query itself ("now work in industry", "at another SaaS company") so the collision is filtered out at the start.

7. Stale timing scored as "now"

What it looks like: an alum who left two years ago is tagged "now" because they were great, with no new reason to expect interest.

Check: compare the departure date against the 13 to 16 month window for resigners, and against the shorter clock for laid-off leavers. Past the window, the tag is "stale" unless you record a fresh trigger.

Keeping the alumni queue current

An alumni pass is not a one-off list. Rerun it for each req, recheck "later" and "stale" tags on their recontact dates, and fix rehire codes as people leave, not when you next need them.

Habits that keep the next pass short:

• Fix codes at departure. Ohio's rule has the code set at separation and noted in the employment record. Ask HR to require a reason field when the code is set, so the next audit has less to do.
• Audit rehires on a cadence. Boise State audits newly hired employees once per pay period to catch rehire activity that broke policy. A lighter version, a monthly check of new hires against the exclusion log, catches the slate leaking into hires nobody cleared.
• Keep the exclusion log. Review dates on "under review" codes and on waiting periods turn today's exclusions into next quarter's candidates.
• Track your own yield. After each pass, record alumni contacted, calls held, offers, and hires by job family. After a few passes you will have the conversion rate no published source gives you.
• Recheck the rules. Retention periods, lawful basis guidance, and no-rehire law change by jurisdiction. Have the privacy owner and legal confirm their notes at least once a year, and whenever the slate includes a new jurisdiction.