How to Write a Job Description That Attracts Top Talent

Choose the document that describes the actual work#

A job description explains an employment role: its purpose, responsibilities and required capabilities. A project charter explains a project’s objectives and authority; an agreed statement of work can specify a provider’s deliverables and terms. Start with the arrangement you actually need, then give the reader enough detail to judge it.

Step 1 Decide what you are actually buying#

Use a job description to recruit for a role. For an external project, agree scope, acceptance and commercial terms in the contract or statement of work, with a charter if useful for project coordination. Employees also deliver projects, and contractors can provide ongoing services; the document’s label does not determine worker status.

For U.S. federal employment-tax purposes, IRS guidance considers behavioral control, financial control and the parties’ relationship. That is one legal context, not a universal test. A charter cannot convert an employee into a contractor or override the actual working relationship.

Step 2 Draft outcome, scope, and terms#

For a project, define what will be delivered, what is excluded, what inputs you need and how acceptance works. Confirm where the binding fee, payment, cancellation and rights terms live. A short internal charter should not be mistaken for a complete services agreement.

Ask someone unfamiliar with the project to identify the deliverable, deadline and acceptance criteria from the draft. If they must guess, clarify the document before work begins.

• approval owner named
• included and excluded work written down
• one communication lane chosen
• one change-request path agreed before work begins

Write a job description candidates can evaluate#

Start with a recognizable title and a short explanation of why the role exists. Then describe its main responsibilities, reporting line, permitted work location, hours or overlap expectations and compensation information. State the employment arrangement accurately rather than leaving candidates to infer it from “remote” or “flexible.”

Define responsibilities and essential functions#

Describe the work itself, not a personality wish list. For example, “resolve billing questions and document recurring issues” is more useful than “be a rock star.” Under the U.S. ADA, essential functions are fundamental duties, and a description prepared before advertising or interviewing can be evidence of those functions; the actual work still matters.

Make qualifications job-related and distinguish true requirements from preferences. A tool that can be learned during onboarding need not become a mandatory multi-year experience screen. Review the criteria with the manager who will supervise the role.

Covered U.S. employers must avoid discriminatory advertising. The EEOC’s job-advertising guidance explains that preferences or discouragement based on protected characteristics can be unlawful. Describe required functions and provide a way to request appropriate application accommodations rather than assuming every candidate must perform the work in one particular way.

Check the rules for the hiring location, including any salary-range disclosures and required posting information. The example below is illustrative, not a salary benchmark or a statement that the same disclosure rule applies everywhere.

Worked example: a short role posting#

Illustrative role: “Customer Support Specialist — remote within the UK. Help customers resolve billing and onboarding questions, maintain useful help articles and escalate recurring product issues. Report to the Support Lead. Full-time employee role, Monday–Friday, with core collaboration hours of 10:00–15:00 UK time. Example budgeted salary: £32,000–£38,000 annually.” Replace those facts with the approved role, lawful terms and actual budget.

Then add a small set of requirements: clear written communication, experience handling customer questions and the ability to document resolutions. Mark familiarity with your particular help-desk tool as preferred if it can be learned. Explain the application route, requested materials and interview stages, and include an accommodation contact. Avoid promises about benefits or progression that the employer has not approved.

Before publishing, have the hiring manager confirm that responsibilities and requirements match the real role. Keep title, location, pay and application instructions consistent wherever you post it. A description may improve clarity; it cannot guarantee top applicants or successful hiring.

For project work, agree billing and change records#

A services agreement needs clear commercial terms as well as scope. Payment can be an advance, a milestone fee, hourly billing or a retainer. Specify the agreed trigger, due date and supporting record rather than making every invoice depend on final acceptance.

For private projects, use the payment structure the parties agree and the applicable law permits. Performance-work drafting can provide useful examples, but federal procurement rules do not automatically govern your client contract.

For each invoice, retain the relevant agreement version and the record supporting its trigger. That may be a signed agreement for an advance, time records for hourly work or acceptance for an agreed milestone. Records support a claim; they do not guarantee a dispute outcome.

Classification depends on the actual relationship and applicable law. If status is uncertain, resolve it with the appropriate adviser rather than rewriting labels to obtain a preferred answer; this guide covers the worker’s side.

Draft the charter so result, scope, approvals, and acceptance are clear#

For a project engagement, specify the result, scope boundaries, approvals and acceptance process. A charter may help coordinate the work, while the agreed contract or SOW should contain or incorporate the terms the parties intend to rely on.

Name the client contact authorized to approve scope and acceptance. State the intended result, deliverables, deadline and inputs needed from the client. Confirm who can agree commercial changes; the person giving routine feedback may not have that authority.

Use a deliverable, required components and deadline. Make the completion test something you can demonstrate rather than a business outcome you cannot control.

Separate baseline scope from change requests. Under each deliverable, add three lines: Included, Excluded, and Change trigger.

• Included: exact output, file types, review rounds, and any support already priced in.
• Excluded: adjacent work often assumed to be bundled (for example, net-new deliverables, extra stakeholder groups, post-acceptance support, or extra rounds).
• Change trigger: what moves work out of baseline scope (for example, new deliverables, delayed client inputs that shift timing, changed requirements, or extra approvals not named in the charter).

If a request changes the agreed scope, assess its timing and price before doing the added work. Hold the affected item pending agreement; unaffected work can continue where practical.

Identify the dependencies and approval records:

• Access owner: who grants required accounts, files, or credentials.
• Approval owner: who consolidates feedback and can accept deliverables.
• System of record: the authoritative source for files, data, and version history.
• Blocked dependency handling: what happens when access, data, or client inputs are late, including the escalation path.

Missing access or approval ownership can block work. Record the required input, responsible person and escalation date instead of silently assuming it will arrive.

Turn the charter into contract language you can verify later#

Keep contract terms specific enough to apply to the actual project. Confirm that the scope document and agreement use compatible definitions and do not impose conflicting deadlines.

Specify each billing trigger and its due date. Retain the appropriate supporting record; different payment structures need different evidence.

Example: a 3,000-unit onboarding-documentation project might bill 600 on signing, 1,200 on agreed first-draft delivery and 1,200 on accepted handoff, with a stated due date for each invoice. The signing invoice does not wait for acceptance, and first-draft delivery is different from final approval. Agree those triggers explicitly rather than assuming them.

Write change handling as a sequence with owners. Make the workflow explicit in order:

1. Log the request in the agreed channel.
2. Assess deliverables, timing, fee and dependencies affected.
3. Obtain approval from the authorized parties and record revised terms.
4. Start the added work after approval; continue unaffected work where practical.

State what happens to deliverable rights, pre-existing materials and third-party assets. If ownership transfer is agreed, specify when it occurs and what license applies before then. Source files and drafts are not automatically included merely because the client receives a final export.

Before signing, check the actual terms:

• Replace placeholders with agreed values and identify the parties.
• Check consistent scope, deadlines, acceptance, fees and payment dates.
• Resolve rights to final work, pre-existing materials and third-party assets.
• Record the change process and who can approve commercial terms.

Choose the document at intake, then record every change#

Choose the document for its purpose and the terms for the actual relationship. A clear job description supports hiring; an agreed project scope supports delivery. Keep both aligned with how the work will operate.

For hiring workflows, see How to Hire Your First Salesperson and applicant tracking systems for startups.