# The Search Brief Standard: When a Role Is Ready to Source

*You can grade any role brief pass or fail against explicit criteria and fix the failing parts before a single search is run.*

- Canonical URL: https://www.refolk.ai/guides/search-brief-standard
- Pillar: Recruiting and sourcing
- Format: Standard
- Published: 2026-07-31
- Last reviewed: 2026-07-31
- Reading time: 16 min

Every intake resource on the internet is a list of questions to ask the hiring manager. None of them tells you when the answers are good enough to start sourcing. This guide is for in-house recruiters, sourcers, talent leaders, and founders hiring for themselves, and it gives you a gradeable definition of done: pass/fail criteria plus a reproducibility test you can adopt as team policy, so you can grade any role brief and fix the failing parts before a single search runs.

## What "ready to source" actually means

A role brief is ready to source when two sourcers working from it separately would build the same shortlist. That is the whole standard. Everything else in this guide exists to make that sentence gradeable.

A brief is the recruiter-facing contract between you and the hiring manager. It is distinct from the public job description: it holds target companies, internal compensation bands, hiring manager preferences, and disqualifiers the job ad would never share. Published intake templates converge on a consistent field set, and they are useful. But a completed field set is not the same as a sourcing-ready brief, because a question list optimises for coverage, not for a pass/fail decision. You can answer all 28 questions and still hand two sourcers a document they would interpret two different ways.

The reproducibility test is the missing piece. It is not established anywhere in the published literature - most intake guidance stops at "reduce misalignment" without saying when you have. So treat this as a local test you run on your own briefs: hand the brief to two people who did not sit in the intake, ask each to describe the ideal candidate and draft a query, and see whether their shortlists would overlap. Where they diverge, you have found the ambiguous field. That divergence is the defect the rest of this guide teaches you to remove before it costs you four weeks.

> A completed question list is a meeting agenda. A reproducible shortlist is a definition of done.

## Why an unwritten bar fails: alignment is a decay problem

Misalignment is not a kickoff problem you solve once. It is a decay problem: an unwritten bar drifts once per interview, and by round three the standard has moved twice in different directions. This is why "we had a good intake call" is not a passing grade.

The numbers frame the stakes. HR.com's Future of Talent Acquisition 2025 report found that 34% of organisations cite misalignment with hiring managers as a core talent acquisition challenge. A 2026 AI and hiring alignment report found that 90% of teams rate the recruiter-manager relationship as good or excellent, yet 58% wish they could work around their counterpart - relationship warmth is not the same as a shared definition of the role. And one practitioner sets a clean diagnostic threshold: if hiring managers reject more than roughly 30% of well-prepared shortlists, the upstream signal is misaligned, not the sourcing effort.

The downstream cost is measurable, though the figures below are aggregated by a vendor blog attributing LinkedIn and Talent Board rather than primary sources, so treat them as attributed, not verified. Still, the direction is instructive.

| Metric | Aligned / well-run | Misaligned |
|---|---|---|
| Interview drop-off | 22% | 35% |
| Offer acceptance | 89% | 78% |

The point is not the exact percentages. The point is that a misaligned brief does not fail loudly at the start; it fails quietly at rounds three, four, and offer, where the work is already sunk. A structured, versioned brief resists the drift because there is a document to point back to.

> **Watch out:** A good intake call is not a passing grade
>
> A team can agree in kickoff and still be misaligned by round three. Only a dated, versioned brief resists the once-per-interview drift of an unwritten bar.

## The fields a brief must contain to be executable

A sourcing-ready brief carries five field groups, and every group has to be filled with concrete answers, not placeholders. Published templates run 25 to 28 questions, but you can collapse them into these groups without losing anything that changes a shortlist.

- **Role basics.** Job title and department, new position or backfill, the reason for the hire, who the role reports to, and the target start date.
- **Target candidate profile.** The persona the recruiter uses to write queries and outreach lists: title variations, seniority, years of experience, and the types of current company that produce the right people.
- **Compensation parameters.** Salary band, equity, and level. This is the field whose absence is invisible until the most expensive stage.
- **Process and timeline.** Interview stages, decision makers, and the pace both sides commit to.
- **Disqualifiers and constraints.** Visa requirements, location flexibility, non-compete restrictions, and anything that would rule a candidate out at the offer stage.

The last group is the one recruiters skip because it feels administrative. It is not. A hidden disqualifier that surfaces at offer stage destroys a search as completely as a missing must-have. Fill it with concrete rules, not the word "flexible."

**21,752 - US professionals with sourcing titles in Refolk's index**

Technical Recruiter, Sourcer, and Talent Sourcer titles, at employers including Experis, K2 Partnering, Google, Snowflake, and SpaceX.

## Must-have vs nice-to-have: the test that grades the split

The cleanest way to separate must-have from nice-to-have is one forcing question, asked of every requirement: should we immediately disqualify a candidate who does not have this on their resume? If the honest answer is no, it is a nice-to-have. A must-have is a requirement that is absolutely necessary for a candidate to hold the job, and you cap the list at three to five items you must see to make a hire.

This cap is not arbitrary discipline. When must-haves and nice-to-haves are blurred, the pool shrinks and strong applicants decide not to apply. A brief with twelve unranked requirements looks thorough and is actually unsourceable, because no real person satisfies all twelve and no two sourcers would guess the same five that matter.

In job-ad language the labels are explicit, and you can use the wording as a spot-check when you read a brief or a JD back.

| Bucket | Job-ad markers |
|---|---|
| Must-have | required, must have, essential |
| Nice-to-have | preferred, nice to have, bonus |

There is a live disagreement about ordering. The intake-form tradition treats requirements as a standalone section you fill directly. The scorecard tradition, drawn from the "Who" method of mission plus 3 to 8 ranked outcomes plus competencies, argues you should write the outcomes first and derive requirements from them. The scorecard tradition is right for gradeability, and here is the mechanism: two graders can agree on "raise activation from 7.1 to 9.0 by December" but not on "strong communicator." Anchoring every must-have to a ranked outcome is what makes the split reproducible. If a requirement maps to no outcome, cut it.

> **Rule:** Every must-have maps to a ranked outcome
>
> Cap must-haves at three to five. Each one must trace to a specific, quantified outcome in the brief. A requirement that maps to no outcome gets deleted, not demoted.

## Translate requirements into searchable attributes

A requirement only counts as gradeable once it survives translation into something you can search for. The mechanics are standard: combine job titles, skills, and keywords with AND, OR, and NOT operators, include synonyms, exclude irrelevant profiles, and refine the string against results. A requirement for an Android developer becomes something like "developer AND android," expanded with the title and skill variants that real people actually use.

The trap is translating a requirement into a literal skill tag. People rarely tag their tooling. In Refolk's index of professional profiles, only 2 US professionals with the exact title "Talent Acquisition" explicitly list "Boolean Search" as a skill. If you search for the self-declared tag, you miss almost everyone who does the work. Translate through title variants, synonyms, and inferred signals instead.

**2 - US "Talent Acquisition" professionals who list "Boolean Search" as a skill**

In Refolk's index, explicit tagging of a core tooling skill is vanishingly rare, so requirements cannot be matched on a self-declared tag.

The second break point is proxy signals. If a query returns profiles that look qualified on paper but consistently fail to respond or get ruled out after contact, the string is selecting on visible profile signals that do not predict actual candidacy. High result counts read as a healthy pipeline and are not. What you actually need is roughly 40 candidates with the specific combination of skills, experience, and availability worth contacting - and the gap between 22,000 filtered results and those 40 is exactly what the query is supposed to close.

This is the point where translating a natural-language requirement into the right people stops being a Boolean exercise and starts being a matching problem. [Refolk](/) is built to close that gap directly: you describe the person in plain English and get the right people across public LinkedIn, the public GitHub graph, and the open web, without hand-tuning strings against proxy signals.

I ran this search: `Talent acquisition leaders in the US who have built a sourcing function from scratch at a Series B startup.` - [see the full result list](https://www.refolk.ai/s/c3qmqvxb6f).

*Returns named TA leaders with founding-function experience at that stage, so you can pressure-test whether your brief's persona actually exists in the market before you write a single Boolean string.*

## The procedure: from intake to a graded brief

Run these eight steps in order. The first six build the brief, step seven grades it, and step eight makes it durable. The order-of-operations disagreement between outcomes-first and requirements-first is resolved here in favour of outcomes-first, for the gradeability reason above.

#### Intake to a sourcing-ready brief

1. **Prep with market data** - Before intake, pull comp benchmarks, comparable postings, and the likely trade-offs the hiring manager may need to accept, such as speed versus seniority or budget versus experience. Done when you have a one-page pre-read of market reality so the meeting starts from clarity, not assumptions.
2. **Run intake as a working session** - Hold a 45 to 60 minute structured conversation aligning on role, success criteria, candidate profile, process, and market expectations. Done when raw answers are captured for every required field, not just the ones the hiring manager volunteers.
3. **Write the mission and ranked outcomes** - Draft the mission and 3 to 8 outcomes, ranked by importance. Done when each outcome is quantified and ordered, not a vague trait.
4. **Force the must-have and nice-to-have split** - Apply the disqualify test to every requirement and cap must-haves at three to five. Done when each requirement is labeled and none is left unranked.
5. **Translate must-haves into searchable attributes** - Map each must-have to title variants, synonyms, skills, and exclusions rather than a literal skill tag. Done when a draft query returns a manageable, relevant set instead of tens of thousands.
6. **Pressure-test against reality** - Compare the brief to peer scorecards and to the pool the draft query actually returns. Done when no requirement combination asks for something the market cannot supply.
7. **Grade the brief pass or fail** - Run the checklist field by field before any outreach and fix every failing field. Done when every field is present, unambiguous, and the reproducibility test would hold.
8. **Version and store the brief** - Store the dated, version-controlled brief in the ATS or a shared workspace with both parties signed off. Done when there is a single source of truth that resists drift.

#### Where the reproducibility test sits

1. **Intake** - Capture raw answers for every required field
2. **Outcomes** - Rank 3 to 8 quantified outcomes
3. **Requirements** - Split must-have from nice-to-have and cap at five
4. **Translate** - Map must-haves to searchable attributes
5. **Grade** - Run the checklist and the two-sourcer test

*The grade happens after translation and pressure-testing, so you fail a brief on paper instead of at interview five.*

Notice that a structured intake is not overhead. One vendor claims structured intake produces 15 to 30% faster time-to-fill plus a lower interview-to-offer ratio. Treat the exact range as a vendor claim, but the mechanism is sound: the time you spend making the brief reproducible is time you do not spend recalibrating for the next four weeks.

## Why a brief is only as good as the pool it returns

A brief that looks complete can still fail on the numbers, because brief quality is only meaningful relative to the pool your query returns. The same requirement set is executable in one market and impossible in another, and the gap can be enormous.

| Market | Title set queried | Count | Named employers in pool |
|---|---|---|---|
| US | Technical Recruiter / Sourcer / Talent Sourcer | 21,752 | Experis, K2 Partnering, Google, Snowflake |
| UK | Sourcer / Talent Sourcer / Sourcing Specialist | 411 | Deloitte, HSBC, Capgemini |
| Derived | US-to-UK ratio | ~53x | - |

In Refolk's index, US sourcing-title supply outnumbers the UK equivalent by roughly 53 times. The title lists queried are not identical across the two rows, so treat the ratio as directional rather than exact - but no rounding makes it small. A brief that is trivially sourceable in the US market may be a multi-month search in the UK for the same role, and neither number is visible from the brief alone. This is why the pressure-test step is not optional: a requirement combination that the market cannot supply is a failing brief no matter how carefully it is written.

#### Grading a brief on completeness and supply

Horizontal axis runs from Requirements vague or blurred to Requirements ranked and translated. Vertical axis runs from Market cannot supply the combination to Market supplies a contactable pool.

| Quadrant | What it means |
| --- | --- |
| Unsourceable and unclear | Rewrite from outcomes; do not source |
| Clear but unsupplied | Loosen a must-have or reframe the market |
| Sourceable but ambiguous | Two sourcers will diverge; fix the labels |
| Ready to source | Grade passes; start outreach |

*A brief passes only in the top-right; a complete brief the market cannot fill is still a fail.*

## How this goes wrong: the failure modes

Most bad briefs fail in one of eight recognisable ways. Each has a false positive - a reason it looks fine - and a check that catches it. This is the part of the standard worth memorising, because a brief passes not by hitting every field but by surviving every one of these.

- **The "rockstar" brief.** The hiring manager asks for ten years, a PhD, and an entry-level salary, and then rejects every candidate because "they just don't feel right." The false positive is a brief that sounds ambitious. **Check:** every must-have maps to an outcome; unmapped requirements are cut.
- **Blurred must/nice list.** Twelve unranked requirements shrink the pool and deter strong applicants. The false positive is a brief that looks thorough. **Check:** count must-haves; if more than five, re-run the disqualify test.
- **Proxy-signal query.** The string returns paper-qualified non-responders. The false positive is a high result count read as a healthy pipeline. **Check:** sample ten profiles against the outcomes before any bulk outreach.
- **Volume mistaken for progress.** Tens of thousands of results feel like coverage. **Check:** a passing query returns a contactable shortlist of roughly 40, not a headcount of 22,000.
- **Comp discovered late.** A candidate finishes the process and the offer lands 15% below expectation, and four weeks evaporate. This is the most expensive brief defect because the missing comp field is invisible until the last stage. **Check:** salary band, equity, and level are in the brief before sourcing.
- **Order-taking intake.** The recruiter writes a one-paragraph spec from a 20-minute call, and by interview five the bar has drifted twice. **Check:** the brief is dated, version-controlled, and signed off by both parties.
- **Hidden disqualifiers.** Visa, relocation, or non-compete constraints surface at offer stage. **Check:** the disqualifier field holds concrete rules, not the word "flexible."
- **"Culture fit" as a pass criterion.** It is subjective and non-reproducible, so two graders never agree. **Fix:** define "culture add" as observable behaviours and work preferences, not feelings.

> **Tip:** Test the two most expensive defects first
>
> Late comp misalignment and a hidden disqualifier both destroy a full search at the offer stage. Confirm the comp band and the disqualifier rules are concrete before you spend time on the elegant parts of the brief.

## The pass/fail checklist and keeping it current

Run this checklist before any outreach. Treat it as binary: a brief that fails any line is not ready, and the failing line names exactly what to fix. This is the artifact you adopt as team policy.

#### Grade before you source

- [ ] Role basics are complete: title, department, backfill or new, reason, reporting line, and target start.
- [ ] The brief lists 3 to 8 outcomes, each quantified and ranked by importance.
- [ ] Must-haves are capped at three to five, and every one maps to a ranked outcome.
- [ ] Every requirement is labeled must-have or nice-to-have; none is left unranked.
- [ ] Compensation band, equity, and level are stated before sourcing begins.
- [ ] Disqualifiers are concrete rules, covering visa, location, and non-compete, not "flexible."
- [ ] Each must-have is translated into title variants, synonyms, and exclusions, not a literal skill tag.
- [ ] A draft query returns a contactable shortlist, not tens of thousands of results.
- [ ] No requirement combination asks for something the market demonstrably cannot supply.
- [ ] The brief is dated, version-controlled, and signed off by both the recruiter and the hiring manager.
- [ ] Two sourcers who did not attend intake would describe the same ideal candidate from this brief.

A brief is not a document you write once. It is a standard you keep current, because alignment decays across a search. Re-run the last checklist line whenever the shortlist gets rejected: if managers are turning down more than roughly 30% of well-prepared shortlists, the brief drifted or was never reproducible, and you fix the field that would make two sourcers diverge rather than sourcing harder. Version the brief every time a requirement changes, and make the new version the one both parties point back to.

**Requirement labeling line**

```
Requirement: <the skill, trait, or experience>
Maps to outcome: <which ranked outcome it serves, or "none - cut">
Disqualify if missing?: <yes = must-have / no = nice-to-have>
Searchable as: <title variants, synonyms, skills; not a self-declared tag>
```

*One line per requirement. If the disqualify answer is "no," it cannot be a must-have. Paste this block into the brief and fill every row.*

Store the graded brief where the whole team can run against it. When you can hand it to two sourcers and get one shortlist back, the role is ready. Until then, you have a meeting agenda, not a standard.

## Frequently asked questions

### What questions should a recruiting intake form include?

A sourcing-ready intake covers role basics (title, department, backfill or new, reason for hire, reporting line, target start), the target candidate profile (title variations, seniority, years, current company types), compensation parameters (band, equity, level), process and timeline, and disqualifiers (visa, location, non-compete). Published templates run 25 to 28 questions. But the number of questions is not the standard: a brief passes only when its answers are specific enough that two sourcers build the same shortlist.

### How do I separate must-have from nice-to-have requirements?

Ask the hiring manager the forcing question for every requirement: should we immediately disqualify a candidate who does not have this? If the honest answer is no, it is a nice-to-have. Cap must-haves at three to five items you must see to make a hire, and anchor each to a ranked outcome. In job-ad language, must-haves read as required or essential; nice-to-haves read as preferred or bonus.

### Why do good-looking briefs still produce rejected shortlists?

A brief can be complete on paper and still fail on the numbers. Blurred must-have and nice-to-have lists shrink the pool, and the same requirement set is executable in one market and impossible in another. Brief quality is only meaningful relative to the pool your query returns, so a brief that has never been tested against real supply has not been graded, only written.

### When is a role brief actually ready to source?

It is ready when every field is present and unambiguous, every must-have maps to a ranked outcome, the must-have list is capped at five, comp and disqualifiers are stated as concrete rules, and a draft query returns a contactable shortlist rather than a headcount. The final test: two sourcers working from the brief separately would build the same shortlist. If they would not, fix the field that would make them diverge.

### Can I match candidates by searching for a skill like Boolean search directly?

No. In Refolk's index, only 2 US professionals with the exact title Talent Acquisition explicitly list Boolean Search as a skill. People rarely tag tooling skills, so a brief that translates a requirement into a literal keyword-tag match will miss almost everyone. Translate requirements into title variants, synonyms, and inferred signals instead of self-declared tags.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/search-brief-standard*