Writing job descriptions and postings with AI

How the bot works

Nine steps. The library, the required-element checklist, the boilerplate and the version history are ordinary code and cost almost nothing to run; the model is only asked to turn approved content into a readable draft.

1. It starts from your own approved library. The posting you ran last year, the role family and level, the duties the manager typed into an email, the description of record in your HR system. Content you have already signed off, not a pattern learned from other companies' postings.

2. It keeps the description and the posting apart. The description of record is the document that pays people, levels them and defines the job. The posting is the one a stranger reads. The same facts produce both, and neither one quietly becomes the other.

3. Every duty and requirement names its source. This duty came from the manager's note, that requirement came from the level, this line is last year's wording unchanged. A reviewer can see which sentences are new rather than re-reading the whole thing.

4. A missing required element is a question, not a sentence. You tell us what a posting must carry — the pay range, the location and schedule, whether work authorization is sponsored, the physical requirements, the classification. If one is missing it comes back as a question with the element named, because the element a posting leaves out is the one somebody has to ask about later.

5. Your boilerplate goes in exactly as you wrote it. The company paragraph, the benefits summary, the equal-opportunity statement, the accommodation line. Inserted verbatim from your own approved text — the bot does not compose any of it and does not reword it.

6. It invents no requirement. No degree, no years of experience, no certification and no software that is not in the library or the level. A requirement filled in because it looks normal is the line that turns away the person who could do the job.

7. One role stays one role, wherever it is posted. The same req in two locations, reposted in six months, or run on three channels: the duties, the level and the requirements stay identical, and only what you configured to vary varies.

8. A named approver signs it off. The draft waits with its sources and its open questions on top. HR and the hiring manager approve the version they read, their names and the date are recorded against it, and nothing reaches a careers page or a board before that.

9. It keeps a history, and the diff against last time. What changed between this posting and the one you ran before: the duties added, the requirement dropped, the range moved. Superseded versions are kept, so you can see what the role said at the time somebody was hired into it.

What you configure

It can be configured to run in any business. This is what that actually means — the list of things that are yours, not ours.

Your library

Which approved postings, descriptions of record and manager notes count as source — and what is out of bounds, including anything a stranger wrote.

Your job architecture

The role families, the levels, what distinguishes one level from the next, and which duties and requirements belong to the level rather than to the posting.

Your required elements

What every posting must carry, which of those vary by state or city, and which ones stop a draft entirely when they are missing.

Your template and tone

The headings and their order, how long each section runs, how formal the posting reads, and what the internal document looks like instead.

Your boilerplate

The company paragraph, the benefits summary, the equal-opportunity statement and the accommodation line, stored as your approved text and inserted unchanged.

Your titles and words

The internal title against the one that goes on a board, the words your industry actually uses, and the jargon you have decided to stop using.

Your approvers

Who signs a description of record, who signs a posting, which roles need compensation to look at them, and which need a second approver.

Your channels

Where an approved posting goes — the careers page, the applicant tracking system, the boards you use — and what each one needs formatted differently.

Your release switches

Which role families may be drafted automatically from a manager's note, which require an interview with the manager first, and which may never be drafted at all.

Transparent, and configurable by you

The dark band below is what the system will not do. This is what you can see and change — and it is how we build everything, not something invented for this page.

You see what it did, and why

Every duty and requirement shows the source it came from, every open question names the element that was missing, and every approval records who signed that version. A posting can be audited against your own library rather than taken on trust.

Versioned prompts you can tune yourself

The template, the architecture, the required-element list and the prompts behind turning approved content into a draft are yours to tune. A change is a reviewable diff, replayed against postings you have already approved so you can see exactly what it would have written differently, and rolled back the same way.

A human in the loop wherever judgment actually matters

Reading the library, drafting, checking the required elements and keeping the history are automatic. Defining the role, setting the pay range, deciding what the law requires of you and approving a posting are a person's — that boundary is a property of the system, not a promise about how carefully we'll use it.

Every run logged, along with what it cost

One row per draft and one per version: the sources it read, every requirement with its origin, the open questions, who approved it, what changed since the last posting — plus token usage and cost for that run.

It can be configured to run in any business. The library and the rules are yours: your approved content, your levels, your required elements, your boilerplate, your approvers. The hiring wiring on this page is one configuration of it, not the limit of it.

Works with your tools

This writes into the systems you already use for hiring. We're not selling you an HR platform, and the documents stay yours in a format you can read without us.

• An applicant tracking system
• An HR system
• A careers page or job board
• Google Drive, SharePoint or Dropbox
• Microsoft 365 and Word
• Google Workspace and Docs
• Notion or Confluence
• A spreadsheet of roles and levels
• A folder of approved postings
• The manager's email

Works well for

• Manufacturers — Shift roles repeat across lines and plants, and the physical requirements have to be stated the same way every time.
• Restaurant groups — The same front and back of house roles are posted again and again, per location.
• Retail chains — Seasonal hiring means the same postings go out at volume, with the schedule and the location changing.
• Healthcare clinics — Credentials and licenses belong to the role, and nobody wants them paraphrased.
• Home care agencies — Caregiver roles are posted continuously, and the duties come from a care plan rather than from a template.

How a rollout works

Nothing is posted on day one. The first milestone is a role you have already filled, drafted again from your own library and compared with the posting you actually ran.

1. 01Discovery

   The quote call, then a working session. We go through your library, your role families and levels, the elements every posting must carry, your boilerplate, your template, who approves what, and which roles need compensation or counsel to look at them. You get the element checklist, the template and a written scope.

2. 02Dry run

   Roles you choose, drafted against your real library. Nothing is published. You read the drafts, the source trail and the open questions — and the open questions are where the work is, because a posting's missing element stays invisible until a candidate asks about it.

3. 03Assisted mode

   Live on one role family. The bot drafts, HR and the hiring manager approve in the queue, and your recruiter edits instead of starting from last year's file. Who defines the role does not change.

4. 04Optional limited automation

   Optional, and narrower than it sounds. A short list of role families you name, drafted automatically from a manager's note with every required element present or flagged, still unpublished until HR approves, with every hard stop in force and the kill switch. Plenty of teams stop at step 03, and that's a good place to stop.

What we don't claim

• No numbers we haven't earned. No time-to-hire figure, no applications-per-posting claim, no cost-per-hire saving and no number about who applies. We have not hired for you. The numbers on the tools in this category are theirs, measured somewhere else.
• No customer claims on this page. No names, no case studies, no logos.
• We claim no knowledge of employment law. Not equal opportunity law, not pay transparency, not accommodation requirements, not classification. A posting this drafts is not a compliant posting and we will not call it one — your counsel owns that, and the required-element list exists so the draft arrives ready for them.
• It makes no bias claim, in either direction. It does not detect bias, score language or certify a posting as inclusive. Tools in this category do make those claims, and a claim like that cannot be checked by the tool making it. What this does is stop inventing requirements nobody asked for, which is a narrower and more honest thing.
• A posting is not a hiring process. The draft is the easy end. Deciding what the role is, what it pays, who interviews and what a good answer sounds like is the work, and a tidy posting does not do any of it.

Questions people ask

Can AI write our job descriptions?

Yes, from your own approved content. An agent can take last year's posting, your role family and level, and the duties the hiring manager wrote down, and draft both the description of record and the posting in your template, with every requirement traceable to where it came from. What it will not do is invent a requirement or fill in an element you have not supplied - those come back as questions.

Where does the content come from?

Your library: the descriptions in your HR system, the postings you have approved before, the levels somebody maintains, the manager's own note about the job. Not a model trained on other companies' postings, which is what a generator has to work from when it has nothing of yours - and it is why those drafts read like somebody else's company.

Will the posting be compliant and free of biased language?

We will not tell you either of those things. Tools in this category promise bias-free, law-compliant postings and we think that promise cannot be checked by the tool making it. This bot claims no knowledge of equal opportunity law, pay transparency or accommodation requirements. What it does is carry the elements you told us are required, insert your own approved statements verbatim, and flag what is missing so the person who owns that decision sees it.

What about the pay range?

It comes from your compensation data or it comes back as a question. The bot does not estimate a range, look one up or infer one from a title - and if your list says a posting cannot go out without one, a missing range stops the draft rather than quietly omitting it.

Does it screen or rank candidates?

No, and it has no path to. It does not read a resume, score an applicant, shortlist or match anybody to anything. The job ends when the posting is approved, and nothing in this build can reach an applicant record.

What is the difference between the description and the posting?

The description of record is the internal document: the duties, the level, the reporting line, the classification, the thing compensation and your HR system rely on. The posting is what a stranger reads. Both are written from the same facts, and keeping them apart is one of the configuration decisions - a posting that has quietly become the description of record is a problem you find out about at review time.

Can it just update the posting we ran last year?

Yes, and it is the easiest place to start. The old posting is a source, the manager's note is a source, and what you get is a draft plus a diff: the duties added, the requirement dropped, the range moved, the section that is unchanged. Superseded versions are kept rather than overwritten.

Who approves a posting?

The people you name - usually HR and the hiring manager, with compensation or counsel added for the roles where you want them. Approval is recorded against the version they read, and nothing reaches a careers page, an applicant tracking system or a board until that has happened.

Is there a record of what changed and who approved it?

Yes, per draft and per version: the sources it read, every duty and requirement with its origin, the open questions and how they were answered, who approved it and when, and a diff against the previous posting - plus the token usage and cost for that run.