Briefs arrive in two broken shapes. The first is three lines in an email: "Need a senior backend engineer, London, up to £95k, ASAP." The second is a four page job description written by committee, where a license, a preference and a fantasy all appear as bullet points of equal weight.
Both need the same work before you can recruit: converting whatever was sent into outcomes, requirements ranked by whether they actually block a hire, the context that shapes the search, and an explicit list of what nobody has answered yet.
Start with the outcome, not the requirement list
The single most useful intake question is not about skills. It is: what has to be true in six months for this hire to have worked?
Answers are specific in a way requirement lists are not. "The payments migration is finished and on-call is not just two people." "We stop losing mid-market deals because there is nobody technical on the call." Once you have that, half the requirement list explains itself and the other half turns out to be inherited from a previous job spec.
Sort requirements by what they block
A must-have is something you would not put in front of the client without. Everything else is a preference, however firmly it was stated. The test is simple: ask what happens if a strong candidate lacks it. If the honest answer is "we would probably still see them", it is a preference.
| As written in the brief | What it usually is | The question to ask |
|---|---|---|
| 8+ years' experience | A proxy for scope, not a real threshold | What should they have already run on their own? |
| Degree required | Inherited boilerplate in most cases | Has anyone been hired here without one? |
| Fintech background essential | Sometimes real, often domain comfort | Which part of fintech matters: regulation, scale or pace? |
| Strong communicator | Unmeasured until it fails | Who will they have to disagree with, and about what? |
Write down what you do not know
Every brief has holes. The mistake is carrying them in your head, where they turn into assumptions by week two. Keep an explicit open-questions list on the role: interview process, competing candidates, decision maker, flexibility on the band, what the last hire got wrong. It doubles as your agenda for the next client call.
Intake questions that change a search
- What has to be true in six months for this to have worked?
- Who did this before, and why are they no longer doing it?
- Which requirement would you actually waive for the right person?
- Who else is involved in the decision, and what do they care about?
- What has gone wrong in previous hiring for this team?
- What would make you move quickly on someone?
Where AI helps with intake
Structuring, not deciding. A model can read an email, a spec and a transcript together, propose outcomes, split requirements into probable must-haves and preferences, and list what the material never addresses. That last part is the underrated one: an honest list of unanswered questions is more valuable than a tidy-looking brief that quietly guessed.
What it should not do is invent the reasoning. If a requirement has no stated reason, the right output is a question for the client, not a plausible justification.
How Creo Align does this
Creo Align is the intake step in Creo Access. You give it what the client actually sent, in whatever state it arrived, and it returns an editable Role Blueprint: proposed outcomes, requirements split into must-haves and preferences, client context it picked up, and the questions the material could not answer.
The important part is what happens next. You edit it. You demote the requirements you know are aspirational, add the two things the client said on the phone that never made the spec, and delete the boilerplate. What you approve becomes Creo Role Memory, the context that Evidence, Capture, Actions, Ask Creo and the Prompt Generator all read from for the rest of the search.
From a messy brief to an established requirement
Select an item to see the wording in the source it came from.
Align separates what the brief established from what it only implied, and turns the rest into intake questions.
Read this figure as text
- Outcome: Outcome: cut month-end close from nine days to three. Client brief, 12 May, Close takes nine days and the board has lost patience. We want it inside three.
- Established: Owned a month-end close in a group finance function. Client brief, 12 May, They must have run a close themselves, not just reported into one.
- Preference: Has used the same ERP the group is migrating to. Client brief, 12 May, It would help if they had seen our new ERP, but we are not precious about it.
- Gap: Team size and who this role manages. Searched, The brief, the job description and the intake email say nothing about reports.
- Conflict: Seniority: Manager or Head of?. Job description, page 1, Finance Systems Manager, reporting to the Group Controller.
Creo Align
- Messy briefEmail, spec, notes or transcript
- Structured outcomesWhat success looks like at six months
- Requirements rankedMust-haves separated from preferences
Ten minutes of structuring at the start removes a surprising amount of the friction later, because everything downstream, including the search you run three weeks from now, is working from a role you actually agreed with rather than the advert.
Try it on your next brief
Turn the next client email into a Role you can recruit from
Paste what the client sent and see the structure and the open questions. Start free for 14 days. Then choose monthly or annual billing. Cancel anytime.
Start 14-day free trial