Turning messy intake notes into a job description

Turning messy intake notes into a job description takes three passes: capture what the role must deliver in its first year, separate real requirements from the hiring manager’s wish list, and only then write, against a fixed skeleton. The notes from the call are raw material, not a draft. Most weak job descriptions exist because the recruiter skipped the middle pass and published the wish list with nicer formatting.

What should the intake call actually capture?

Hiring managers rarely describe a role; they describe a pain. The call opens with “we are drowning in tickets” or “nobody owns the data pipeline”, and your notes end up half symptoms, half adjectives, plus one Slack message that reads “senior, hands-on, self-starter”. None of that is publishable.

The call has one purpose: leave with outcomes, context and constraints. Outcomes are what the person must have shipped, fixed or owned at six and twelve months. Context is who they work with daily, who they answer to, and how the team operates in practice. Constraints are the salary band, the location policy and the real start date the budget supports.

Questions that reliably get you there:

• “What will this person have delivered after six months that is not happening now?”
• “Walk me through a normal week for whoever is doing pieces of this job today.”
• “If this role stays open for a quarter, what breaks?”
• “Which three skills would you personally test in an interview?”
• “What did the last person in this seat struggle with?” (for backfills, this question alone justifies the call)

Notice that none of these ask for a list of requirements. Requirements are an output of the conversation, not an input to it. When a manager arrives with a finished requirements list, treat it as a hypothesis to test, not a spec to transcribe.

How do you translate manager-speak into requirements?

This is the middle pass, and it is where the actual recruiting skill lives. A handful of phrases dominate almost every intake call, and each one has a question that converts it into something testable:

What the manager says	What to ask	What it usually means
“We need someone senior”	“What decision should they make alone that a junior would escalate?”	Autonomy on specific calls, not a year count
“A real all-rounder”	“Which two duties will fill most of their week?”	The role is not defined yet; define it before posting
“They need X, Y, Z, and ideally…”	“If a strong candidate had only X, would you still interview them?”	One or two must-haves, the rest is wish list
“Someone like Sarah”	“What does Sarah do that you most want replicated?”	A pattern match; keep the behaviour, drop the person
“We needed them yesterday”	“What start date does the budget and onboarding actually support?”	Urgency inflation that will pressure your screening bar later

Run every adjective in your notes through this filter. “Senior” becomes “has run a production incident without an escalation”. “Strong communicator” becomes “writes the weekly stakeholder update”. Anything that survives translation is a requirement; anything that does not is colour. The discipline of splitting the binding items from the merely desirable ones matters enough to get its own treatment in must-have versus nice-to-have skills.

What does a working JD skeleton look like?

Seven parts, in this order:

1. Title people search for. “Backend Engineer (Python)” beats “Digital Solutions Wizard II”. Internal grading labels stay internal.
2. Mission. One paragraph on why the role exists and what problem it owns. This is the symptom from the intake call, rewritten as purpose.
3. Outcomes. Three to five bullets describing what done looks like at six and twelve months. Candidates self-select on these far better than on duty lists.
4. Must-haves. Five items maximum, each one testable in an interview. If you cannot imagine the interview question, it is not a must-have.
5. Nice-to-haves. Explicitly labelled, so candidates missing them still apply.
6. How the team works. Stack, rituals, review culture, remote policy. Honest beats attractive; the truth surfaces in week one anyway.
7. Salary range and process. Stating the range is becoming a legal expectation across the EU, not a courtesy; see the EU pay transparency directive and job ads. Then list the steps and the expected timeline.

The skeleton is deliberately boring. The differentiation comes from the specifics you pour into it, and specifics are exactly what the translation pass produced.

What deserves pushback before you write?

Three patterns are worth a slightly uncomfortable conversation, because publishing them costs you weeks.

The unicorn list. Ten must-haves means the manager has not chosen. Do not argue item by item; price the list instead. Each additional must-have removes candidates, so ask which requirements they would trade for a faster, stronger shortlist. If the conversation stalls, run the full list against the market and show how few profiles survive it. Evidence moves managers that opinions cannot, and there is a longer playbook for this in managing unrealistic hiring manager expectations.

Vague seniority. “Senior” without a definition produces interviews where every panellist scores against a different bar. Pin it to decisions and scope during intake, or you will relitigate it at offer stage with money on the table.

The recycled template. A JD copied from the last opening, or from a competitor’s posting, reads generic because it is generic, and generic postings attract generic applications while quietly importing someone else’s biased phrasing. Before anything goes live, run it through the checks in is your job description too generic or biased.

How do you use an AI draft responsibly?

The honest division of labour: AI writes fast, you decide what is true.

A language model is genuinely good at the parts of JD writing that are mechanical. Give it your translated notes, the outcomes, the capped must-have list, the skeleton above, and it returns a clean, well-structured draft in seconds, in more than one language if you hire across borders. That is real time saved, and there is no virtue in typing the boilerplate yourself.

What it cannot do is the middle pass. It does not know that “senior” meant incident ownership, that the manager conceded two must-haves on the call, or that the team’s “flexible remote policy” is three fixed office days. Feed it a raw call transcript and it will confidently structure the wish list, adjectives and all. Garbage in, fluent garbage out.

So the working rule: structured notes in, first draft out, then an editing pass where you verify every requirement against what was actually agreed, reinsert the specifics only you know, and cut whatever sounds like every other posting in your market. Drafting used to be the slow part; now the edit and the pushback are the job. Spend your saved time there.

Where does Recruitifly fit?

Recruitifly is an EU-built ATS with one assistant, Fly, working across the whole platform on a propose-then-confirm basis: it prepares, you approve, nothing changes without your sign-off. For this workflow that means the unglamorous tail end gets fast. Once your JD is final, Fly prepares the posting for several job boards at once (Indeed, LinkedIn, StepStone and more) and publishes only when you confirm, then scores incoming applicants against the requirements you defined, which is a quiet test of whether your must-haves were actually testable. The same draft-fast, approve-with-judgment principle from the section above is how the entire product works, by design. We are in private beta; if you want to see an intake-to-posting flow on one of your live roles, talk to us.