Writing Job Descriptions

Automation handles the first, most labor-intensive version of a job description: from the hiring manager brief to a draft ready for editing. A rough draft appears in minutes, not half a day, and arrives already in the format accepted by the career site CMS and HRIS. The recruiter becomes an editor, not the first author.

What automation does

1. Accepts a structured brief from HR or the hiring manager: role title, level (junior/middle/senior/lead), key responsibilities, requirements, benefits, tone of voice.
2. Generates a job description draft using the corporate template — with sections "About the role", "What you will do", "What we expect", "What we offer".
3. Checks the draft for tone of voice compliance: aligns phrasing against a reference set of previously published job postings.
4. Generates versions for different channels: a full-length text for the career site, a shortened version for job boards, an internal version for HRIS.
5. Sends the draft to the CMS and HRIS with a "pending review" status, without publishing automatically.
6. The recruiter or hiring manager makes edits and clicks "publish" — the text is distributed across channels.

What automation does NOT do

• Does not publish job postings without human review — final control remains with the recruiter or hiring manager.
• Does not define role requirements or decide what skills the team needs — that is the hiring manager's responsibility.
• Does not source candidates, screen resumes, or handle communication with applicants — those are separate processes.

The solution suits companies with a volume of 5–20 job openings per month, where writing descriptions takes a disproportionate share of the HR team's time and text quality depends on who happens to write it. Automation does not change hiring policy or replace interviews — it removes the routine workload at the publication preparation stage.

The process is built around a single prompt template, two integrations, and a mandatory human review point before publishing. No background publishing without approval — this is a deliberate constraint, not a technical limitation.

Technical flow

1. HR or the hiring manager opens the brief form — typically a web page or an internal HR tool.
2. The form collects structured fields: role title, level, department, key responsibilities (3–7 items), requirements (must-have / nice-to-have), benefits, team specifics.
3. The data is sent to an LLM with a prompt template configured for the corporate tone of voice.
4. The LLM generates a draft in markdown or rich text format with standard sections.
5. The draft goes through validation: section length, presence of required sections, compliance with the prohibited phrasing dictionary (if configured).
6. The finished draft is placed as a draft in the careers site CMS and as a record in the HRIS.
7. The recruiter receives a notification, edits the text, and publishes manually.

Key components

Implementation steps

1. Collect 10–20 of the best existing job postings as a reference for tone of voice and structure.
2. Define a list of sections that every job posting must include — typically 4–6.
3. Configure the input form with required and optional fields.
4. Build the prompt template: instructions for the LLM, examples (few-shot), length constraints.
5. Connect the connectors to the careers site CMS and HRIS — via native APIs or no-code integration platforms.
6. Run a pilot on 2–3 real roles from different departments, compare the generated texts against the reference ones.
7. Calibrate the prompt and templates based on editorial edits — whatever the recruiter changes every time goes into the LLM instructions.
8. Roll out to all postings, keeping a human at the publishing checkpoint.

Technically this is a no-code build: a form, a no-code workflow with an LLM node, two connectors to existing systems. Prompt template development and calibration are the most substantive part of the work, because that is where the corporate voice is captured.

The automation relies on the existing job archive and active accounts in the CMS and HRIS. Without reference texts, the LLM will not be able to reproduce the corporate tone of voice — the result will be an impersonal draft.

Data and access

• An archive of 10–20 quality job descriptions published over the past year, as a style reference.
• A tone of voice guideline — if available; if not, it is derived from the reference archive.
• A list of required job posting sections and their order.
• Access to the careers site CMS with permissions to create draft records.
• Access to the HRIS with permissions to create/synchronize job postings.
• A list of 'prohibited' formulations or template phrases the company avoids (optional).

Team readiness

• An HR specialist or recruiter as the automation product owner: responsible for content and editing.
• Hiring managers willing to fill out a structured brief instead of free-form text.
• IT or an external integrator for connecting connectors to the CMS and HRIS.

Timeline

Complexity — weekend. The basic MVP (form + prompt + manual export to CMS) is assembled over a weekend. Full integration with CMS and HRIS, prompt calibration, and a pilot on 2–3 roles — 1–2 weeks. If multiple languages or a complex tone of voice need to be supported from the start, add another 1–2 weeks for calibration.