What this automation does
Hiring managers describe the job once, in a structured way, and get back a posting that is consistent, compliant with your own rules and ready for HR review.
- Intake. The hiring manager fills a short form: role title, level, team, the three or four outcomes expected in the first year, must-have skills, nice-to-haves, work location or remote eligibility, and travel or physical requirements.
- Assemble context. The workflow adds the leveling guide entry for that level, your approved company description, benefits summary, EEO statement and the pay range HR has set for the role.
- Draft. A model writes the posting in your house style: a short summary, outcome-focused responsibilities, requirements split into must-have and nice-to-have, and the fixed boilerplate inserted verbatim.
- Check. Code and a second model pass review the draft: pay range present where required, requirement count, degree requirements flagged for justification, gendered or exclusionary terms, reading level and length.
- Review. The draft and the check results go to the recruiter and HR as a Google Doc or Notion page with suggestions, not silent edits.
- Publish. After approval, the workflow creates or updates the job in your ATS, which handles distribution to job boards such as Indeed.
When it is worth building
It is worth it when postings are slowing down hiring. Common symptoms: hiring managers take a week to produce a draft, recruiters rewrite every one, the same role is described three different ways across teams, or a posting goes live without a required pay range.
At low volume, skip the workflow. A saved prompt and a shared template in Google Docs get you most of the benefit for no build cost. The workflow’s value is consistency and enforcement across many people, not the writing itself.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Intake | A form, such as Google Forms or a Notion form, writing to a database | Structured input produces better drafts than a pasted paragraph |
| Reference content | Leveling guide, boilerplate and pay ranges in Google Docs or Notion | HR owns these and can update them without touching the workflow |
| Orchestration | n8n | Straightforward form to model to document to ATS flow |
| Drafting model | Claude through the API | Writes clean, specific prose and keeps fixed text verbatim when told to |
| Checks | A code step with word lists and location rules, plus a model review pass | Location and pay rules must be deterministic; tone review benefits from a model |
| Review surface | Google Docs suggestions or a Notion page | Recruiters edit where they already work |
| Publishing | Greenhouse, Lever or Workable through their REST APIs | The ATS remains the source of truth for open roles |
How to build it
- Collect your best postings. Pick three to five job descriptions your recruiters consider strong. They become the style examples.
- Clean up boilerplate. Agree on one company description, one benefits summary and one EEO statement, reviewed by HR and counsel. These are inserted, never generated.
- Design the intake form. Ask for outcomes, not duties. “Reduce ticket backlog below one day” produces a sharper posting than “handles tickets”.
- Write the location rules. Keep a table of work locations that require pay ranges or other posting content, owned by HR and reviewed with counsel.
- Prompt with constraints. Tell the model to use only facts in the intake and reference content, to limit must-have requirements, and to leave placeholders when information is missing rather than invent it.
- Build the checks. Run deterministic checks first, then a model pass for tone and clarity that returns suggestions with reasons.
- Connect the ATS last. Only after a few rounds of reviewed drafts should the workflow be allowed to create jobs, and then as drafts or unpublished postings.
What breaks in production
- Invented perks. Without strict instructions, a model adds “unlimited PTO” or “equity” because similar postings mention them. Only allow benefits from the approved summary.
- Requirement inflation. Managers ask for every skill they can think of. Cap must-haves and push the rest to nice-to-haves, and question degree or years-of-experience requirements that the work does not need.
- Title drift. The model “improves” a title from Support Specialist II to Customer Success Manager. Lock titles to your leveling guide.
- Remote role pay rules. A remote role open to candidates in several states can trigger posting rules in each. The location table should list every eligible state.
- Stale boilerplate. Benefits change at open enrollment and the old summary stays in the reference folder. Date every boilerplate file.
- Mismatch with screening. If the posting and the screening criteria are written separately, candidates are assessed on things the posting never asked for. Use the same intake to write both.
Timeline and cost
A form-to-draft-to-review workflow is typically live in one to two weeks. Lumeor builds this in the range of $2,500 to $7,000, with the upper end covering the location rules table, the review pass and publishing into your ATS. Model costs per posting are a few cents to well under a dollar, depending on length and the number of review passes.
How to measure success
- Days from intake submission to posting live
- Recruiter edit rounds per posting
- Share of postings with a pay range where one is required, which should be every one
- Number of must-have requirements per posting, before and after
- Applicant volume and recruiter-rated applicant relevance per posting
- Hiring manager time spent on the posting
The intake that drives the posting is also the right input for criteria used in AI-assisted resume screening, so the job you advertise and the job you assess match. If you are still choosing a model for the drafting step, see our comparison of ChatGPT and Claude for business.