Candidate Discovery Retrospective Template

A candidate discovery retrospective is a short review of one completed sourcing episode. It asks what the team learned about the brief, search routes, evidence review and hand-off, then turns those observations into an owned next action. It is not a candidate score or a post-hoc justification for a hiring decision.

Use this template after a defined pass for one role, market and time period. Invite the brief owner, a reviewer and the next-step owner. Keep the discussion about the process and its evidence, not about whether an individual “looked like” a good hire.

Freeze the episode before reviewing it

Write the boundary before the meeting:

• role brief version and decision owner;
• market, location interpretation and search period;
• approved must-haves, nice-to-haves and exclusions;
• sources, channels, query variants or referral routes used;
• what moved to review, verification, outreach, hold or close.

Do not combine a paused search with a new one. If the role changed, preserve the old version and state which episode the retrospective covers. Learn from a known question, not a generalised market story.

Bring observations, not impressions

Collect the search log, samples of included and excluded records, source links or IDs, review notes and the hand-off record. Separate four things:

“Most results used one title variant” is an observation. “The market has no adjacent talent” is an unsupported conclusion. Write “adjacent title coverage is unknown” and assign a test if it matters. A repeated profile is a deduplication issue, not evidence for preference or rejection.

Review source freshness, attribution and contact status separately. Record whether those checks were owned and usable; do not invent an age rule or infer interest from a public profile. If a material source was unavailable, preserve that limitation.

Use four discussion questions

1. Did the brief describe the work?

Identify requirements that produced useful evidence and those that were vague, proxy-based or impossible to check. Note whether must-haves and preferences stayed separate. A must-have change belongs to the role owner, not a searcher’s quiet optimisation.

2. Which routes produced reviewable evidence?

Compare channels and query variants by the evidence they produced, not an invented yield benchmark. A route may be worth keeping for a useful work signal even if it produces few records; another may produce many names but little attributable context. Record what was tested and what remains untested.

3. Where did review or hand-off stall?

Look for recurring unknowns, duplicates, inaccessible pages, unclear ownership or missing criteria. Ask whether a reviewer can explain why each next action follows from the source. If the problem is contact history, data handling, compensation or assessment design, assign it to the responsible owner rather than extend discovery.

4. What should happen next?

Choose one action for each material learning: keep the rule, change one approved variable, stop a route or escalate a dependency. Name an owner and review date. The next person should be able to run the next pass without reconstructing reasoning from private messages.

Classify actions clearly

Use these four outcomes:

• Keep: the brief, route or review practice answered its intended question and remains approved.
• Change: one defined variable will be adjusted, with the expected signal recorded before the next pass.
• Stop: a route is out of scope, redundant or unable to answer the approved question; record the reason.
• Escalate: an unresolved legal, privacy, access, role or capacity question needs another accountable owner.

Do not use “improve sourcing” as an action. Write the exact change, owner and stop condition so the next pass is comparable. The role owner can still approve a new hypothesis.

When AI is part of the workflow, the ICO’s recruitment guidance, published 6 November 2024 and checked 2 September 2026, highlights lawful basis, transparency, responsibilities, fairness and data minimisation. This is general information, not legal advice. NIST’s AI Risk Management Framework is voluntary, not a hiring certification.

Copyable retrospective template

Copy this record into the team’s working document. It is a usable on-page template, not a downloadable file.

CANDIDATE DISCOVERY RETROSPECTIVE
Episode / role / market / search period:
Brief version / decision owner:
Meeting date / facilitator / attendees:

Approved question and success condition:
Sources, channels and query variants tested:
Records reviewed / held / contacted / closed:

Observation:
Evidence or source trace:
Interpretation (label as inference):
Unknown or contradiction:

Action: keep / change / stop / escalate
Exact action and expected signal:
Owner / due date / stop condition:

Next episode or hand-off:
Decision note location:

Where Talent Summoner fits

Talent Summoner is our product for role-based candidate discovery. Its candidate-sourcing workflow, checked 2 September 2026, starts from a role brief and searches LinkedIn, GitHub and other public professional sources across 200M+ profiles, returning a ranked shortlist with must-haves, nice-to-haves and plain-English reasoning. Bring the result and source context to the retrospective. It helps prioritise review; it does not replace evidence checks, outreach or the hiring decision.

For supplied CVs, candidate ranking is the separate workflow for organising existing material against a job description. Keep its report distinct from public-source discovery. Talent Summoner does not manage an ATS pipeline or send automated outreach. Check pricing for current Role options after the next search has approved scope.

Schedule one retrospective, attach the brief version and search log, and bring one observation from each of the four discussion questions. Record one keep, change, stop or escalate action with an owner before the next pass. Then start a focused candidate-sourcing search, or use candidate ranking for supplied CVs, and carry the decision note forward.