A job advert often begins as a collection of notes: what the last person did, what the manager hopes to change, and what someone remembers seeing in another company's posting. Those notes can be useful. They are not yet a clear description of the role.
Before polishing the language, sort the decisions behind it. Which tasks will this person actually handle? Which requirements support those tasks? Which experiences would be helpful but are not essential? The fictional office-coordinator example below shows one way to make those distinctions visible. It is an editing exercise, not a hiring recommendation or a compliance check.
Start with the work the person will actually do
Imagine an office coordinator who routes incoming requests, maintains a shared schedule and keeps colleagues informed when arrangements change. Start by writing those activities in ordinary language. Include enough context to explain the work: whose requests arrive, what information must be recorded, and who decides when priorities conflict.
Replace a phrase such as “excellent multitasker” with a description the manager can check. For example: “Records incoming requests, checks the shared schedule and refers competing priorities to the operations manager.” The sentence describes an activity rather than assuming a personality trait. Confirm that it reflects the role as planned, rather than adding duties because they sound useful.
Mark which requirements have a clear job-related reason
Next, place each proposed requirement beside the task it supports. A requirement to keep accurate records might connect to maintaining the shared schedule. A requirement to explain changes clearly might connect to notifying colleagues. Write the connection explicitly enough that another reviewer can understand it.
Treat uncertain items as questions. If the notes say “five years of experience,” ask what work that number is intended to represent. If nobody can explain the connection, leave it unresolved for the responsible reviewer. Do not substitute a different number just to finish the draft. The purpose of this step is to expose decisions that still need an answer, not to make those decisions automatically.
Give preferences their own place
Suppose the team currently uses a particular scheduling application. Familiarity with it may be helpful, but the manager needs to decide whether that familiarity is essential on the first day or something the person can learn. Keep the distinction visible in the working notes.
Use separate headings for approved requirements and helpful experience. Then read the introduction, responsibilities and application instructions for wording that contradicts those labels. An advert can call software experience “preferred” in one section while demanding it in another. Resolve the contradiction with the role owner before publishing. A preference should not quietly become a requirement because a copied sentence uses stronger language.
Read the advert for missing practical details
Once the tasks and criteria are organized, check the details an applicant would need to understand the arrangement. These may include the reporting relationship, work location, working pattern and application instructions. Use the organization's approved information for each detail. If a fact has not been agreed, mark it as missing in the internal draft.
For the fictional coordinator, “supports the office team” does not explain who sets priorities. “Flexible schedule” does not explain the expected working pattern. Ask the responsible person for the precise wording rather than filling a gap from habit. Compensation and other employment terms also need an approved source and the appropriate review. This worksheet does not determine legal requirements or certify that a posting meets them.
Keep an approved version before applications arrive
Save a dated version of the advert and the name of the reviewer who approved it. Keep the task-to-requirement notes with that version so the team can see why each criterion was included. Record open questions separately; an unresolved note should not accidentally appear as settled public copy.
If the role changes later, preserve the earlier wording and document what changed. Route the revision through the same responsible people instead of silently replacing a requirement in one working document. The aim is a readable record of the role the team intended to advertise.
Before handing the draft to its publisher, read it once as a complete document. Check that responsibilities, requirements, preferences and practical details tell the same story. That final read cannot promise a hiring result. It can identify places where the text still leaves the team's own decisions unclear.
A colleague who did not attend the planning discussion can also point out unexplained shorthand. Ask that reader to mark phrases they cannot interpret from the advert alone. Return those questions to the role owner, record the answers and revise the wording where needed. Keep the approved source beside the final copy.
Review the JD & Posting Optimization Pack and its included PDF.