Executive search
Executive Search Handover Checklist: Transfer a Live Mandate Without Losing the Next Decision
A handover packet and acceptance checklist for moving a live search between researcher and consultant: version, criteria, promises, restrictions, access and readback.
Handing over a live search goes well when the receiving consultant can name the next decision, who owns it and by when, without opening the outgoing person's inbox. Losing that is the main risk. Wasted effort is a secondary problem.
This article gives you a suggested handover packet and an acceptance step. The receiving consultant reads the packet back and checks access. Until the transfer is accepted, keep an available owner named; if the outgoing person is unavailable, appoint an interim owner with the necessary authority and existing permitted access.
TL;DR
- Hand over decisions, not history. The packet records the assignment version, the approved criteria, the open question on each live candidate, contact restrictions, promises already made, permissions, and a named next owner and date.
- Separate confirmed from unresolved. Every line is marked confirmed or unresolved. Nobody should inherit an assumption that looks like a fact.
- Acceptance means readback plus access. The receiving consultant restates the packet in their own words and proves they can open the records. If either fails, ownership does not move.
- Plan the fallback before you need it. If access is missing, keep an available owner accountable and give blocked work a named escalation. Do not announce an incoming contact as ready before they can do the work.
The handover packet: copy this first
Fill in one section at a time. Each table is short so it can sit in a shared document, a project note or an email body in whatever tool your firm already permits. Use a status column throughout, with Confirmed (checked against a record or with the person concerned) or Unresolved (believed but not checked, or still open).
Section 1: Assignment identity and version
| Field | Entry | Status |
|---|---|---|
| Assignment name and internal reference | ||
| Brief version in force (number and what changed last) | ||
| Where the current approved brief lives | ||
| Client decision-maker and day-to-day contact | ||
| Outgoing owner / receiving owner | ||
| Handover type (leave cover, partner transition, researcher to consultant) | ||
| Expected return or end of cover, if any |
The version line matters most when a brief has changed mid-search. A receiving consultant working from an older version can run a perfectly good search for the wrong role. If you used a mandate kickoff checklist, point to it here. Don't rewrite it. The packet should record what has changed since kickoff.
Section 2: Approved criteria
| Criterion | Linked to which task or outcome | Must-have or preference | Approved by / where recorded | Status |
|---|---|---|---|---|
The second column is an adaptation. OPM's job analysis guidance frames analysis as linking job tasks to required competencies. That is federal assessment guidance, not an executive-search rule. Borrowing the habit helps a receiving consultant see why a criterion exists, so they can judge edge cases without phoning the person on leave.
Section 3: Live candidate questions
| Candidate (internal reference) | Stage | Open question | Who must answer it | Next action and date | Status |
|---|---|---|---|---|---|
One line per live candidate, with one open question each. If a candidate has three open questions, write down the one that blocks the next step and point to the rest. The detail belongs in your candidate research notes, so the packet should point to them rather than copy them.
Section 4: Source and decision pointers
| Decision or claim | Where the evidence lives | Who made the decision | Status |
|---|---|---|---|
This section answers "why did we do that?" Examples include why a target company was dropped, why a candidate was paused, or why the compensation range moved. You only need pointers here.
Section 5: Contact restrictions and promises already made
| Type | Detail | Applies to | Source of the restriction or promise | Status |
|---|---|---|---|---|
| Restriction | ||||
| Restriction | ||||
| Promise | ||||
| Promise |
Restrictions include off-limits companies, people who asked not to be contacted at work, and anything a referee or source shared on condition. AESC's Candidate Bill of Rights sets expectations for member firms about keeping candidate interest, information, sources and references confidential. It is useful context for why these lines must survive a handover.
Promises include anything a candidate, source or client was told to expect: a call by a certain day, feedback after an interview, a shortlist date. Unrecorded promises are the ones most likely to break during a handover.
Section 6: Permissions and access
| System or folder | Receiving owner can open? | Can edit? | Checked how | Status |
|---|---|---|---|---|
"Checked how" should describe something the receiving consultant actually did, such as opening the project, viewing a candidate record or seeing the notes. "I've added you" is not a check.
Section 7: Next owner, next date, readback
| Field | Entry |
|---|---|
| Next decision on this assignment | |
| Owner of that decision | |
| Date | |
| Readback completed (yes/no, date) | |
| Mismatches found in readback | |
| Handover accepted (yes/no) | |
| If not accepted: who remains owner, and until when |
The acceptance checklist
A handover is accepted only when every item below is ticked by the receiving consultant. The outgoing person can't approve their own handover.
- I have opened the brief version named in Section 1 and it matches what is described.
- I can explain the reason behind each must-have criterion without asking.
- For each live candidate, I can state the open question, who answers it and the next date.
- I have read every contact restriction and know which lists or sequences it affects.
- I have read every promise and accept ownership of each one, or have flagged the ones I can't keep.
- I have opened, not just been sent, every system in Section 6.
- I have completed a readback and the outgoing owner has marked any mismatches.
- Every item marked Unresolved has a named person and a date to resolve it.
How to run the readback
The readback is a short conversation or a written reply. The receiving consultant restates the packet in their own words, without reading it out:
- The brief version and what changed last.
- The criteria they would screen out on.
- Each live candidate's next step and date.
- The restrictions they will apply.
- The promises they now own.
- Anything they cannot open.
The outgoing owner listens for drift. A paraphrase that loses a qualifier ("must have led a refinancing" heard as "finance transformation experience") is a mismatch, even when it sounds close. Record mismatches in Section 7, fix the packet, and repeat only the parts that drifted.
Confirmed versus unresolved: why the column matters
An unresolved item is fine. Every live search has open questions. The danger is an unresolved item written in the same tone as a confirmed one. "Client is flexible on location" might be something the client said in writing last week, or something the researcher picked up in a hallway conversation. The receiving consultant can't tell those apart unless the packet says so.
Some practical rules:
- Confirmed means checked against a record you can point to, or confirmed directly by the person concerned.
- Unresolved means believed but not verified, or still waiting on someone.
- Every unresolved line needs a name and a date. An unresolved item without an owner is a gap, not a status.
- Don't upgrade an item to confirmed during the handover meeting because everyone agrees it's probably true.
Worked example: a changed brief during leave cover
Everything in this example is synthetic. The firm, client, people and candidates are fictional, and it shows how the packet works, not any real outcome.
Situation. Fictional boutique Harrow & Vale is running a CFO search for Northline Freight, a fictional regional logistics business. Priya, the researcher who has run day-to-day candidate work, starts two weeks of leave on Friday. Tom, a consultant, takes over. Midweek, the client changed the brief from version 2 to version 3: the role now requires experience leading a debt refinancing, and the client has asked that nobody be approached from its main lender.
Section 1 (excerpt).
| Field | Entry | Status |
|---|---|---|
| Brief version in force | v3: refinancing experience added as must-have; lender added to off-limits | Confirmed by outgoing owner: client email in restricted client-email folder |
| Handover type | Leave cover, Priya returns after two weeks | Confirmed |
Section 2 (excerpt).
| Criterion | Linked to | Must-have or preference | Approved by | Status |
|---|---|---|---|---|
| Led a debt refinancing | Refinancing expected in first 18 months | Must-have | Client CEO, v3 email | Confirmed |
| Sector background in logistics | Operating-cost model | Preference (was must-have in v2) | Verbal, partner call | Unresolved: Tom to confirm in writing with client by Tuesday |
Section 3 (excerpt).
| Candidate | Stage | Open question | Who answers | Next action and date | Status |
|---|---|---|---|---|---|
| Candidate A | Interviewed by firm | Has she led a refinancing, or supported one? | Candidate A | Tom calls Monday | Unresolved |
| Candidate B | Shortlisted under v2 | Still eligible under v3? | Tom, from notes | Review by Monday | Unresolved |
| Candidate C | Early conversation | None blocking | n/a | Wait for availability reply | Confirmed |
Section 5 (excerpt).
| Type | Detail | Applies to | Source | Status |
|---|---|---|---|---|
| Restriction | No approaches to employees of client's main lender | Whole target list | v3 client email | Confirmed |
| Restriction | Candidate C: personal phone only | Candidate C | Priya's call note | Confirmed |
| Promise | Candidate A told she'd hear about next steps "early next week" | Candidate A | Priya's memory | Unresolved: not in notes |
Section 6 (excerpt).
| System | Can open? | Checked how | Status |
|---|---|---|---|
| Project in firm's search system | Yes | Tom opened Candidate B record | Confirmed |
| Shared folder with client emails | No | Tom got an access-denied message | Unresolved |
Readback. Tom restates the brief as "CFO with finance transformation and refinancing exposure, logistics preferred." Priya flags a mismatch: v3 requires having led a refinancing, and "exposure" would let Candidate B through without scrutiny. Tom also lists the lender restriction but doesn't mention that two names on the target list work there. Priya adds both names to Section 5.
Reviewing the example
The packet did its job by making a few weak spots visible:
- The promise to Candidate A was unrecorded. Section 5 makes it visible. An available owner must explicitly accept the Monday call; it does not transfer to Tom while his access check remains incomplete.
- The sector criterion was softened verbally. Marking it unresolved stops Tom from screening candidates in or out on something the client hasn't confirmed in writing.
- The readback caught a qualifier drift. "Exposure" versus "led" decides whether Candidate B stays on the shortlist.
- Access to the client-email folder failed. That folder holds the only written record of v3, so the handover is not accepted on Friday. The rollback section below shows what happens next.
The example does not judge which candidate is stronger, and it doesn't present the handover as a success. It only shows that the next decision on each line has an owner.
Failure and recovery cases
Access is missing at the checkpoint: the rollback
What happens. The receiving consultant can't open a system the packet depends on.
Fallback. Keep an available owner named. In the example, a partner with existing permitted access covers while Tom's access issue is resolved; the process must not depend on Priya working during leave. Specifically:
- The interim owner explicitly accepts Candidate A's Monday call, the other recorded promises and the Tuesday written confirmation with the client. Client- and candidate-facing lines that name Tom are reassigned until his access is confirmed. Confirm any revised timing rather than assuming someone will cover.
- The client is not told about a change of contact yet. Announcing a new owner who can't see the brief creates the confusion the handover is meant to prevent.
- A named person, usually the partner or whoever administers access, fixes access and Tom re-tests by opening the record himself.
Some systems manage project membership explicitly. Clockwork's documentation on adding and removing project team members describes this for that tool. Whatever your system, a forwarded packet is not access. Confirm that the incoming colleague can actually get in.
The receiving consultant works from an old brief version
What happens. Outreach goes out against v2 criteria after v3 was approved.
Recovery. Pause new outreach on the assignment. Compare contacts made since the change date against v3. For anyone approached on the old basis, decide whether a correction is needed and who sends it. Then stamp the version on the packet and on any search sequences.
A promise surfaces after the handover
What happens. A candidate emails asking why they haven't heard back by the date they were given.
Recovery. The receiving consultant replies promptly and honestly, without blaming the colleague on leave, and gives a new date they can keep. Add the promise to Section 5 and ask the outgoing owner, briefly, whether there are others. For member firms, AESC's Client Bill of Rights sets expectations of written clarity, confidentiality and ongoing communication about market response, candidates and obstacles. Promises to clients deserve the same logging.
An internal note is forwarded with the wrong visibility
What happens. In a hurry, the outgoing owner forwards or shares a note intended for the team, and it reaches the client.
Recovery. Alert the responsible partner, contain further sharing and record what was exposed and to whom. Follow the firm's incident procedure; the responsible owner determines necessary communications. Clockwork's internal project notes documentation describes separate note-visibility and client/team notification controls. Check your tool's actual settings before sharing.
Work is duplicated that the system already holds
What happens. The outgoing owner retypes candidate statuses into the packet, and they drift from the system within a day.
Recovery. Point to the system and keep the packet for things the system doesn't hold, such as open questions, verbal promises and unresolved criteria. For example, Clockwork's status reports overview describes candidate status views with profile data and recent notes for firm and client users in that product. If your system holds statuses, link to them rather than copying.
A restriction gets lost in rediscovery
What happens. The receiving consultant reruns a search of past candidates and someone from the off-limits lender reappears on the list.
Recovery. Apply Section 5 restrictions before outreach, not after. If you use a candidate rediscovery workflow, add the assignment's restrictions as a filter step and note in the packet that this was done.
What the handover packet is not
It's not a kickoff document. Kickoff defines the search, and the handover records where it stands. It's also not a client progress report. The packet is internal and will usually contain unresolved items and source pointers that shouldn't reach the client. When the receiving consultant sends the next client update, they can draw from the packet and then use a client update template to write something suitable for the client. Review it before sending, as usual.
Trying this on one live assignment
The packet and checklist above are manual workflows. You can run them in whichever documents and systems your firm already permits.
If you'd like help on a real mandate: Laisy's public homepage describes early access for specialist executive-search firms: personal setup, one task alongside current tools, inputs and steps discussed beforehand. Applications are reviewed individually, with no promised access or response date; its workflow examples are illustrative.
In practice, that means discussing one live search assignment with you, such as an upcoming handover, before anything starts. Together we would agree which permitted inputs to use, how outputs will be reviewed, what evidence would show the work was useful, and the point at which you continue or stop. No full migration is involved, and any pilot work is agreed and reviewed rather than provided automatically. If that fits, you can apply to discuss an assignment.
Frequently asked questions
How long should a handover packet be?
Keep it short enough for the receiving consultant to find the next decision without searching. Each section holds decisions, open questions and pointers. Move detailed history into the permitted source system and leave a pointer in the packet.
Who should sign off that the handover is complete?
The receiving consultant, by completing the acceptance checklist and readback. The outgoing owner marks mismatches but doesn't approve their own handover. On partner transitions, a third person, such as the managing partner, can confirm that access was tested.
What if the outgoing person leaves before the readback happens?
Treat the handover as not accepted. Name an interim owner who can open every system, usually a partner, and schedule the readback for the first possible moment. Meanwhile, the interim owner keeps all logged promises and pauses anything that depends on unresolved items.
Should the client be told about the handover?
Usually yes, once the handover is accepted. Tell them who the new day-to-day contact is and when the next update will come. Don't announce the change before access is confirmed, and keep internal packet content, such as unresolved items and source pointers, out of the client message.