The headcount plan had been signed off. 200 roles across engineering, commercial, operations, and support — to be posted over the next six weeks as part of a planned expansion. The hiring managers had their briefs. The ATS was ready. The only thing standing between the plan and the first live postings was 200 job descriptions.
Claire, head of HR at a fast-growing technology company, had been through this before. The previous hiring wave — 60 roles over three months — had produced JDs that ranged from a tight, well-structured two-pager to a rambling list of requirements someone's manager had pasted from an old spec. Review cycles had taken weeks. The final outputs were inconsistent, and more than one candidate had mentioned that the job description hadn't matched what the role actually was.
This time she wanted every JD to follow the same structure, use the same tone, and be ready to post before the hiring managers had a chance to introduce drift.
The problem with writing JDs at scale
Writing a single job description isn't hard. Writing 200 consistently is. The challenge isn't the first ten — it's maintaining the same voice across engineering roles and support roles, the same structure across senior positions and junior ones, the same inclusive language guidelines when 12 different people have contributed requirements briefs.
The usual solutions — a copywriter, a template, a style guide — all break down at scale. Copywriters get expensive at 200 roles. Templates produce JDs that all sound like templates. Style guides only help if someone reads them before they write, which most hiring managers don't.
What Claire needed was something that applied the style guide automatically, to every row, with no variation in quality between role 4 and role 194.
Building the spreadsheet
She sent each hiring manager a simple four-column brief. No long-form writing required — just the facts.
| job_title | department | seniority | key_requirements |
|---|---|---|---|
| Senior Product Manager | Product | Senior IC | 5+ years product experience; B2B SaaS background; experience with data products or analytics tooling; strong stakeholder management; comfortable with ambiguity in a scaling environment |
| Customer Support Specialist | Customer Success | Junior | Previous customer-facing experience; strong written communication; Zendesk or similar ticketing tool experience helpful but not required; patient and empathetic approach; UK-based |
Keeping the brief to four columns made completion rates near-perfect. She'd tried longer forms in the past — a dozen fields, a box for "what does success look like in 90 days" — and half of them came back incomplete. Four columns that hiring managers could fill in 10 minutes got done. Everything else the model inferred from context.
Writing the prompt
The prompt carried the full style guide. This was the hour of work that paid for itself across 200 JDs — the time she'd previously spent correcting individual managers' drafts was instead invested once, in a prompt that applied the same rules to every row.
Prompt used:
You are writing job descriptions for a fast-growing B2B technology company. Write a complete, ready-to-post job description for the role described below. Use this exact structure:
About the role (2–3 sentences: what the role does and why it matters to the business)
What you'll do (5–7 bullet points: specific responsibilities, not generic tasks)
What we're looking for (5–6 bullet points: requirements from key_requirements, rewritten in plain language)
What we offer (3–4 bullet points: standard benefits — competitive salary, flexible working, equity, learning budget — adapted to the seniority level)
Style guidelines:
— Use "you" and "we" throughout — direct and conversational, not corporate
— No jargon: avoid "dynamic", "fast-paced", "rockstar", "ninja", "passionate about"
— Make requirements clearly distinguishable: use "essential" vs "helpful" rather than listing everything as required
— Use inclusive language: avoid gendered terms, remove age or nationality requirements unless legally required
— Senior IC and above: "What we offer" should mention equity; Junior: omit equity, emphasise mentoring and learning budget
— Length: 250–350 words total. No padding.
Output: the full job description only. No preamble, no metadata, no HTML.
Three decisions in the prompt that made a meaningful difference:
- The "essential vs helpful" instruction reduced the most common complaint from candidates — that JDs list 15 "requirements" and they can't tell which ones actually matter. The model consistently applied the distinction based on how the hiring manager had phrased each requirement.
- The word count ceiling prevented the model from padding. Without it, outputs tended to run long with generic filler sentences. 250–350 words is enough to be informative; anything more is usually noise.
- The equity/mentoring branch on seniority meant the "What we offer" section was calibrated to the candidate. Senior engineers expect to hear about equity; junior candidates respond better to development support.
Running the batch
200 rows on Claude Sonnet 4.6. The choice of model mattered here. Gemini Flash would have been cheaper — but JDs are tone-sensitive writing where consistency and naturalness of the prose genuinely affects candidate response. Claude Sonnet produced noticeably more varied, human-sounding output: adjacent roles in the same department didn't feel like they'd been generated from the same template even when they structurally were.
The batch completed in just under two hours. Total cost: under £3.
Review and iteration
Claire reviewed 20 outputs herself — roughly 10% — before releasing the full set to hiring managers. A few observations:
- The structure was consistent across all 200. Every JD had the four sections in the right order, the right length, and the right tone. The variation that existed was appropriate — a senior engineering role and a junior support role should feel different.
- Three JDs needed light editing: two where the key_requirements brief was thin enough that the model had to infer more than it should have, and one where the job title was ambiguous. She went back to the hiring managers for a one-line clarification and re-ran just those three rows.
- Hiring managers approved 194 of 200 without any edits. The remaining six had minor changes — a specific requirement the manager had forgotten to include, a preferred tool to name explicitly. None required a full rewrite.
What this saved
The previous wave of 60 roles had taken the HR team six weeks and a freelance copywriter to produce JDs that were still inconsistent at the end. This wave — 200 roles, higher quality, consistent format — took three days from data collection to approved drafts. The batch job itself ran overnight. The review happened in a morning.
The most durable saving wasn't the time. It was the consistency. Every candidate who reads a PromptMax job posting now gets the same quality of description, the same clarity about what's required, and the same tone — whether they're applying for a junior support role or a senior engineering position.