Executive search
Executive Search Software Pilot: Success Criteria for One Live Assignment
A copyable pilot agreement and evidence scorecard for testing an AI workspace on one live search, measuring review and rework as well as useful output.
A useful pilot of executive search software tests one bounded task on one live assignment, run alongside the CRM you already use. Before anyone opens the tool, write down who reviews the output, which inputs are allowed and what "useful" means. During the pilot, record every correction. At the end, make a plain continue, change or stop decision.
Measure the human effort the output still needs, not just whether the draft reads well. A polished draft that a partner rewrites line by line is not a success. Below is a copyable pilot agreement, an evidence scorecard, a synthetic worked example built around a client update, and the failure cases most likely to distort the result.
TL;DR
- Pilot one recurring task, such as drafting a client status update, on one live assignment. Keep your existing CRM as the system of record.
- Agree the task boundary, baseline artifact, reviewer, allowed inputs, success evidence and exit handback in writing before starting.
- Log every correction by type. Judge the pilot on review and rework effort as well as usefulness of the final output.
- Assess the workflow, never the candidates. The tool can help draft and organise, but it should not rank, score or screen people.
The pilot agreement: a copyable template
Copy the three sections below into a shared document. Fill them in with the partner who owns the assignment before any input goes into the tool. Wherever a field is blank, the pilot isn't ready to start.
Section A: Scope
| Field | What to write |
|---|---|
| Assignment | Internal code name only, e.g. "Search 14 – finance leadership" |
| Task boundary | One task, stated as a verb and an artifact, e.g. "Draft the recurring client status update" |
| Explicitly out of scope | Tasks the tool must not touch, e.g. candidate assessment, shortlisting decisions, outreach messages |
| Baseline work artifact | The most recent comparable artifact produced the current way, saved unchanged |
| Owner | The consultant who will use the tool and remains accountable for the work |
| Reviewer | The person who approves the output before it leaves the firm; use someone other than the preparer where practical |
Section B: Inputs and review
| Field | What to write |
|---|---|
| Allowed inputs | A named list, e.g. "status notes exported for this assignment; the agreed update format; the kickoff brief" |
| Prohibited inputs | E.g. references, compensation details beyond what the client already holds, other assignments' notes, anything a candidate shared on a confidential basis without agreement for this use |
| Input preparation | Who selects and redacts inputs, and where the selected set is stored |
| Review method | How the reviewer marks changes, e.g. tracked changes against the draft |
| Correction record | Where corrections are logged (see the log template below) |
| Release rule | Output leaves the firm only after reviewer approval, through the usual channel |
Section C: Decision and exit
| Field | What to write |
|---|---|
| Useful outcome | What a good result looks like in the firm's own terms, e.g. "update needs only judgement edits, not factual fixes" |
| Pilot end condition | An event, not a calendar promise, e.g. "after the agreed number of update cycles on this assignment" |
| Continue if | The evidence you would need to extend to a second assignment |
| Change if | The evidence that suggests adjusting inputs, task boundary or review method |
| Stop if | The evidence that ends the pilot, e.g. a prohibited input used, or factual corrections not declining |
| Exit handback | What returns to the CRM and what gets deleted or archived from the pilot workspace, and who confirms it |
The kickoff stage is the easiest place to fill this in. If your firm already uses an executive search mandate kickoff checklist, add the pilot agreement as an extra page. Then the client brief and the pilot boundary are agreed in the same conversation.
The evidence scorecard
The scorecard records what happened, not what the tool promised. Complete one row per output cycle.
Per-cycle scorecard
| Evidence | What to record | Source |
|---|---|---|
| Inputs used | Exactly which allowed inputs were supplied | Owner's input log |
| Baseline comparison | Is the draft at least as complete and accurate as the baseline artifact? Yes / partly / no, with a note | Reviewer |
| Factual corrections | Count and description of wrong names, dates, statuses or attributions | Correction log |
| Judgement edits | Changes of emphasis, tone or interpretation that a partner would always make | Correction log |
| Omissions | Material information missing from the draft | Reviewer |
| Boundary breaches | Any content outside the task boundary, e.g. an unrequested opinion about a candidate | Reviewer |
| Review effort | Reviewer's plain description: light read, moderate edit, substantial rewrite | Reviewer |
| Usefulness | Did the approved version get used as the client communication? Yes / with heavy edits / no | Owner |
Correction log
| Cycle | Location in draft | Type | What was wrong | What it should say | Likely cause |
|---|---|---|---|---|---|
| 1 | Paragraph 2 | Factual | Status shown as "interviewed" | "Interview scheduled" | Notes not updated before export |
Use four correction types and keep them separate: factual, judgement, omission and boundary. Factual errors and boundary breaches are about trust. Judgement edits are often healthy, because the partner's voice belongs in the update. Lumping them together hides the signal you need for the decision.
There is no time-saving target here, and that is deliberate. Your firm's baseline is your own. A pilot that lowers rework on a recurring artifact is worth knowing about. A pilot that shifts the effort from writing to checking may not be. The correction log is what lets you tell the two apart.
Filling in the fields that matter most
Task boundary. Pick a recurring artifact with a known shape and a clear reader. The client status update is a good candidate. It recurs, it has a structure and it already gets reviewed before sending. If you don't have a stable format yet, start from a client update template so the baseline and the pilot output can be compared section by section.
Baseline artifact. Save the last update produced the current way before the pilot begins. Don't tidy it. The comparison only works if the baseline reflects normal work.
Allowed inputs. Name inputs individually rather than by category. "Research notes for this assignment" is better than "relevant notes". Notes written under a consistent structure are easier to select and redact. If yours vary by consultant, the guidance on candidate research notes helps standardise them before the pilot. Exclude material from other assignments, even where it seems relevant. Pulling prior candidates back into a search is a separate, human-led process covered under candidate rediscovery. It should not happen as a side effect of a drafting pilot.
Reviewer. Choose someone who would sign off the update anyway, usually the lead partner. A reviewer who has never written for this client can't tell a judgement edit from a factual fix.
Exit handback. Decide now what happens to pilot material. The approved update already exists in your usual records once it's sent. The open questions are working drafts, selected input sets and correction logs. Decide whether each is archived, kept for the decision meeting, or removed from the pilot workspace, and name who confirms it.
Synthetic worked example: a client update for a fictional search
Everything in this example is synthetic and fictional. The firm, client, role, candidates and notes were invented for illustration. They don't describe any real engagement, and the example shows no results.
The setup
Northgate Search Partners (fictional) is running a CFO search for Halvern Foods (fictional). The lead partner, called Partner R here, agrees to pilot one task: drafting the fortnightly client status update in an AI workspace alongside the firm's existing CRM.
The completed Section A and B fields:
| Field | Synthetic entry |
|---|---|
| Task boundary | Draft the status update covering market response, candidate pipeline status and obstacles |
| Out of scope | Any assessment, comparison or ranking of candidates; outreach; reference content |
| Baseline | The previous update, written manually by the associate |
| Owner | Associate M |
| Reviewer | Partner R |
| Allowed inputs | This search's status notes since the last update; the kickoff brief; the agreed update format |
| Prohibited inputs | Reference notes; compensation expectations; notes from other searches |
The inputs (synthetic)
Associate M exports and lightly redacts the status notes. Candidates are referred to by code:
- Candidate A: first interview with client held; client feedback pending.
- Candidate B: declined to proceed for relocation reasons; agreed we may tell the client the reason in general terms.
- Candidate C: initial conversation held; interested; wants confidentiality maintained until a client meeting is confirmed.
- Market note: several approached executives cited the client's recent reorganisation as a concern.
- Obstacle: client panel availability is delaying second interviews.
The draft and the review
The first draft follows the agreed format. Partner R reviews it with tracked changes, and Associate M logs the corrections:
| Cycle | Location | Type | What was wrong | Correction | Likely cause |
|---|---|---|---|---|---|
| 1 | Pipeline, Candidate A | Factual | Described as "progressing to second round" | "First interview held; awaiting your feedback" | Draft inferred progress not in the notes |
| 1 | Pipeline, Candidate C | Boundary | Added "strong fit for the role" | Removed; status only | Draft added an assessment outside scope |
| 1 | Market response | Judgement | Reorganisation concern stated bluntly | Reframed as a point to address in the client's narrative | Partner's client relationship |
| 1 | Obstacles | Omission | No proposed next step on panel availability | Added a request for two panel dates | Notes didn't record the proposed fix |
Partner R records the review effort as a "moderate edit". Candidate C's confidentiality request has not yet been checked against this audience or this pilot use, so Partner R holds that entry back. The approved version without it is sent through the firm's usual email channel. Nothing goes to the client from the pilot workspace.
Reviewing the synthetic example
Read the log by type, not by total:
- The factual error and the boundary breach hold this cycle for review. Both came from the draft going beyond its inputs. Partner R checks the agreed stop conditions before deciding whether another cycle is appropriate. A possible change is an instruction to "describe status only as written in the notes; no assessments"; that instruction still needs testing.
- The judgement edit is expected. Partner R's framing of a sensitive market message is part of the job. It doesn't count against the pilot.
- The missing next step needs an owner. The notes did not record a proposed fix. The reviewer can add one as a proposal and obtain the right approval; the draft must not present an inferred action as an agreed commitment.
- Candidate C needs a separate sharing check. A code and status can still identify someone from context. Partner R must confirm what information may be shared with this audience; coding the name does not establish permission. Hold that entry until the check is complete.
In this synthetic scenario, the next decision is held until the sharing check and the agreed stop conditions have been reviewed. The partner might then choose change: tighten the instruction and record proposed fixes before another agreed cycle. A material breach can justify stop immediately. Continue to another assignment requires the agreed evidence, rather than confidence that one instruction will fix the problem.
Failure cases and how to recover
The pilot quietly expands. The draft works, so someone asks it to "also tidy the longlist" or "suggest who to prioritise". Recovery: return to Section A. Any new task gets its own boundary, baseline and reviewer. Candidate prioritisation stays a human judgement and is out of scope for this kind of pilot.
An input slips in that shouldn't have. A reference note or another search's file ends up in the input set. Recovery: stop the cycle, record it as a boundary breach in the log and remove the material in line with the exit handback. Then review how inputs are selected. Candidate confidentiality matters here. AESC's Candidate Bill of Rights sets member-firm standards on confidentiality of candidate interest and information, including sources and references. It's a useful prompt for deciding what belongs on the prohibited list.
The draft reads well but the reviewer rewrites it. Fluent output can hide heavy rework. Recovery: use the correction log to investigate inputs, instructions and unsupported model inferences. Good inputs can still produce a wrong draft. If edits concern judgement, ask whether this task needs the partner's hand. Describe the actual cause and remaining review effort honestly.
The pilot duplicates what the CRM already does. Some systems already produce status views. Clockwork's documentation, for example, describes status reports that show candidate status with pertinent profile data and recent notes for firm and client users. That describes Clockwork only. The lesson is general: before piloting, check what your existing system already does, and pilot the gap, not the overlap.
Client communication quality drops. A tidier update can still say less. Recovery: check each cycle against what the client relationship requires. AESC's Client Bill of Rights describes member-firm expectations of written clarity, confidentiality and ongoing communication about market response, candidates and obstacles. Those headings make a sensible completeness check for any status update, member or not.
No baseline was saved. Without it, "better" is a feeling. Recovery: pause, reconstruct a baseline from the most recent update sent before the pilot began (not a pilot-assisted one), and don't count earlier cycles in the decision.
The exit is messy. Drafts and input sets linger after the decision. Recovery: run the handback as written. Confirm the approved artifacts live in your usual records and that pilot materials have been archived or removed as agreed.
Using public frameworks without overclaiming
Some firms want an external reference point for structuring an AI evaluation. The NIST AI Risk Management Framework is a voluntary framework supporting trustworthiness considerations across AI design, development, use and evaluation. It doesn't certify any product or prove that a pilot is safe.
The NIST AI RMF Playbook offers suggested actions across Govern, Map, Measure and Manage, and says it isn't a checklist to complete in full. A small firm might borrow only a few ideas from it, such as naming who is accountable, or describing what will be measured before measuring it.
For generative tools specifically, the NIST Generative AI Profile, published July 26, 2024, is a cross-sectoral companion to the framework. It's a reasonable further read if your pilot raises questions the scorecard doesn't cover.
The pilot agreement in this article is an original, practical adaptation for search firms. None of these bodies has reviewed or endorsed it.
Where Laisy fits
Laisy offers personally supported early access for specialist executive-search firms, starting with an agreed task alongside current tools. You review client updates before sharing through your usual channel. Applications are individually reviewed; access is not promised.
The agreement and scorecard above are manual workflows. You can use them with any tool your firm already permits. To test them on a live assignment with Laisy, you can describe your assignment and apply for early access. The pilot boundary, inputs, review and stop point are agreed with you before any work starts.
Frequently asked questions
Should we pilot on a live assignment or a closed one?
A live assignment gives realistic notes, real deadlines and a real reviewer. That's what the scorecard needs. A closed search can be useful for a dry run of input selection, but it won't tell you how review effort holds up when an update actually has to go out.
Who should be the reviewer if the partner is too busy?
Choose whoever would normally approve the client update. If that's the partner, keep the partner. A reviewer who doesn't normally sign off can't reliably separate judgement edits from factual corrections, and the decision depends on that separation.
Can the tool help us decide which candidates to present?
Not in this pilot. The scope is a drafting workflow. Candidate assessment, comparison and shortlisting stay with consultants and the client. If a draft contains an unrequested judgement about a candidate, log it as a boundary breach and remove it before review continues.
What if the evidence is mixed at the end?
Apply the agreed stop conditions first. If none is met, choose "change" and name the specific adjustment: narrower inputs, a clearer instruction or a different task. Set a new end condition and keep logging. If the same correction type keeps recurring after a change, treat that as stop evidence rather than extending indefinitely.