How to Write a Job Description That Attracts Talent

Why most Indian SMBs get job descriptions wrong

If you want to know how to write a job description that actually pulls in the right candidates, start by accepting an uncomfortable truth: the JD sitting in your Drive right now was probably copied from a competitor, edited for ten minutes, and posted without anyone asking what success in the role actually looks like. That's the default at most Indian SMBs and early-stage startups, and it causes a lot of downstream pain — irrelevant applications, ghosting, offer rejections, and hires who are technically qualified but wrong for the job.

A job description is not paperwork. It's the first product spec of a hire. It sets what you're buying, what you're paying, who you're targeting, and how you'll know six months later whether it worked. Get it right and every stage after it gets cheaper: screening is faster, interviews are more consistent, onboarding has a plan, and the first appraisal has something to measure against.

This guide is for founders, HR generalists and hiring managers running lean teams in India — where the person writing the JD is often also doing the interviews, the offer letter and the payroll. Two complete templates are included, plus a quality checklist.

Job description vs job posting vs hiring scorecard

The biggest structural mistake in SMB hiring is treating three different documents as one. You need three artefacts, each with a different reader.

• The internal job description (JD) is the source of truth — complete, boring, precise, including things you'd never put in an ad: internal band, reporting lines, approval status, budget code.
• The external job ad (job posting) is marketing, written for someone scrolling on a phone. It sells, compresses, leads with what's interesting, and drops anything that doesn't help a person decide to apply.
• The hiring scorecard is the evaluation instrument. It converts the JD's outcomes into gradable criteria so four interviewers assess the same things, and you compare candidates rather than impressions.

Most companies write only the second one, half-heartedly, then wonder why interviews feel arbitrary.

Write the JD first. Derive the ad from it, and the scorecard from the same outcomes. Do it the other way — ad first, JD never — and the role definition exists only in the hiring manager's head, changing shape every time a new candidate impresses them.

Before you write a job description, run an intake meeting

Never write a JD alone from a template. Book 30–45 minutes with the hiring manager and interrogate them. If you're the founder and also the hiring manager, do this with a co-founder playing the sceptic. Without an intake meeting you get generic verbs ("manage", "coordinate", "handle") and inflated requirements ("5+ years, MBA preferred").

The intake question list

1. Replacement or new role? If replacement, what did the last person do well and badly?
2. What breaks if we don't fill this in three months?
3. Who does this work today, and what will they stop doing once this person joins?
4. Is this genuinely one full-time role, or two half-roles stapled together?
5. Twelve months from now, what makes you say this hire clearly worked?
6. What are the three most important results in the first 90 days?
7. What number does this person own, and what can they decide without asking you?
8. Walk me through a typical week. Which tools will they live in, and who do they work with?
9. Which skills must exist on day one, and which can be learned in a quarter?
10. If a brilliant candidate had everything except the degree, would you hire them? If yes, the degree isn't a requirement.
11. What background have you seen fail in this role before?
12. What's the approved range, the variable structure, and what can we stretch to?
13. Location, days in office, travel, shift timings?
14. What's the honest downside of this job that we should be upfront about?
15. Who interviews, in what order, assessing what — and who signs off?

Question 14 is the one people skip and the one that saves the most money. Every role has a downside — a legacy codebase, a demanding client, months of cold calling before the pipeline warms up. Naming it costs you some applicants and saves you the ones who'd have quit in month four.

Then write the intake up as a one-page brief and send it back for confirmation before you draft. Half the time the hiring manager says "actually, that's not quite it" — exactly the correction you want before you've screened forty CVs against the wrong criteria.

Define outcomes, not just responsibilities

Here's the shift that improves JD quality more than anything else: stop listing what the person will do and start defining what they must achieve. Responsibilities describe activity, which is easy to fake in an interview. Outcomes describe results, which aren't — and outcomes are what you'll judge the person on at their first review anyway.

The strong column gives candidates something to self-assess against. Someone who has never closed books to a deadline reads that line and self-selects out; someone who has thinks "I can talk about that." Both are good for you.

Keep it to three to five outcomes, ranked. List ten and none are real priorities. Then add a short "what your week looks like" section with the actual activities and rough time split.

Requirements triage: the cost of inflated criteria

Requirements inflation is the most expensive habit in SMB hiring, and it's almost always unintentional. Someone copies a JD from a large company, keeps "MBA from a Tier-1 institute preferred" and "5–7 years of experience", and quietly shrinks the qualified pool — including the people who'd have been great and affordable.

Every extra requirement reduces volume, filters out non-linear career paths, and raises the salary expectation of everyone who does apply. That last one is the killer. Requirements are a price signal: ask for seven years and an MBA and you'll get people who expect to be paid for seven years and an MBA.

Replace years with capability statements

"3–5 years of experience" tells a candidate almost nothing and your ATS filter even less. Try instead: "You've run at least one full recruitment cycle end to end, including closing offers." "You've owned a monthly revenue number, not just contributed to one." Harder to write, much better at filtering, and they hand the interviewer the exact question to ask.

Then apply the "would you interview them anyway?" test: if a candidate showed up without this one thing but everything else, would we still interview them? If yes, it isn't a must-have. That single test removes about a third of the requirements from a typical SMB JD.

Salary: say the number

Here's where I'll be most opinionated. Publish a range. Not "salary as per industry standards", not "best in industry", not "commensurate with experience". Real numbers.

The objections are weak. Your team roughly knows already, and if publishing creates a problem, you have a pay equity problem the JD didn't cause. Competitors can get the same number from one phone call to any candidate you've interviewed. And you lose far more negotiating room by spending six weeks interviewing someone whose expectations sit 60% above your band. What actually happens is that total volume drops and relevance rises.

How to do it well:

• Give the range for the specific level, not the whole band. ₹4–15 LPA is not information.
• Split fixed and variable, especially in sales. "₹6–8L fixed + up to ₹3L incentive at 100% of target" is honest; "up to ₹11 LPA" is not.
• Be explicit about CTC components if yours includes employer PF, gratuity provision or insurance value. Indian candidates are used to being surprised at offer stage — don't be that company.
• Don't make current CTC a mandatory field. It anchors your offer to a previous employer's decisions. Ask for expectations, and share your range first.
• If you truly can't publish, at least state the band level ("this sits at our Associate level").

How to write a job description, section by section (JD format)

This structure works for almost any role, and the order matters because candidates read top-down on a phone and abandon fast.

1. Job title — plain, searchable, level-clear.
2. Snapshot block — location, work mode, type, salary range, reporting line, team size.
3. Why this role exists — 3–5 sentences of context, not company boilerplate.
4. What you'll own — 3–5 ranked outcomes.
5. What your week looks like — the actual work, with rough proportions.
6. What we're looking for — must-haves as capability statements.
7. Nice to have — labelled optional, shorter than the must-haves.
8. About the team — specific, no hype.
9. Compensation and benefits — range, structure, what's included.
10. How we hire — stages, timeline, who they'll meet.
11. How to apply, and a brief, genuine equal opportunity statement.

Put the snapshot block high — location, type, salary, reporting line, team size, in five scannable lines. Candidates decide on location, mode and money before they read your mission statement.

Writing the opening lines

The first two sentences do more work than the rest of the JD combined. No throat-clearing — "we are a fast-growing, dynamic organisation looking for a passionate professional" says nothing and signals the rest will too. Lead with the problem rather than the company, be concrete, and address the reader as "you". Like this:

We've grown from 3 to 22 clients in 18 months on referrals alone. That stops scaling next quarter. We're hiring our first full-time Sales Executive to build an outbound motion from scratch — with a working product, warm case studies, and a founder who'll do calls with you for the first month.

Describing the company without hype

Candidates in India have read a thousand versions of "we're a fast-growing startup disrupting the X space." It's invisible. Replace adjectives with facts:

The concrete column filters. "Priorities change monthly" will lose you candidates who need stability — good, they'd have left in six months anyway.

For the week section, write as if describing the job to a friend: "Roughly 50% of your week is outbound. About 25% is demos, usually 3–5 a week once you're ramped. The rest is CRM hygiene, proposals, and a Monday pipeline review." That's worth more than fifteen bullets starting with "Responsible for." And publish your hiring process — it signals competence — but only if you'll honour it. A broken published process is worse than none.

Inclusive job descriptions and Indian bad habits

A lot of JD language in India carries habits from an earlier era of hiring. Most of it isn't malicious, it's copy-paste. But it narrows your pool and damages your employer brand. Keep the principle simple: ask only for things that relate to the ability to do the job.

Strip these out as a matter of practice:

• Age limits and phrasing — "candidates below 30 years", "young and energetic team". If the real requirement is stamina for field travel, state the travel requirement.
• Gender preferences — "male candidates preferred for field roles", "female candidates for front-office". Where a role involves specific conditions such as night shifts with transport, describe the conditions, not the gender.
• Marital status, family questions and photograph requests. "Unmarried candidates preferred" is not a job requirement, and requiring a photo invites bias into screening for no benefit.
• Caste, religion, region and mother tongue. Ask about the languages the job requires — "conversational Marathi for the Pune territory" — never the community.
• Tier-1 college filters, a proxy for capability that mostly filters on family income and coaching access.
• Appearance requirements ("presentable", "good personality") unless there's a genuine describable standard.
• Disability-excluding defaults. Don't list "must be able to lift" or "must have own two-wheeler" unless genuinely essential.
• Nationality and visa boilerplate copied from foreign templates for an India-only role.

Language-level fixes that widen the funnel:

That last one deserves a note. "Immediate joiners only" is everywhere in Indian job ads and it filters out almost everyone currently employed at a decent company, since standard notice periods run 30–90 days. Otherwise you're advertising to people who are between jobs — a much smaller pool than you think.

A genuine equal-opportunity line costs nothing and matters to some readers. Keep it human: "We hire on the basis of what you can do. If you need any adjustment to the interview process, tell us and we'll arrange it."

Titles, ATS parsing and SEO

Your title is the most important string in the document — it's what people type into search boxes and what job boards match on. Use the term a candidate would actually search ("Sales Executive", "Accountant", "Backend Engineer") rather than "Growth Ninja", and signal the level clearly, since ambiguous titles create mismatched applications in both directions. Avoid inflated titles you'll regret: "VP Sales" at a 20-person company is cheap to give and expensive to fix. Put a real filter in the title where one exists — "Accountant — GST & Compliance" beats a generic title plus a buried requirement. Keep it under about 60 characters, and match your internal band title.

Two machines read your JD before a human does: the ATS and the search engine. Writing for them isn't keyword stuffing — it's not accidentally hiding information.

For ATS and job board parsers:

• Use standard section headings ("Responsibilities", "Requirements", "About the role"). Parsers are trained on convention.
• Keep skills as plain text, never inside images or posters. Avoid multi-column layouts and text boxes in uploaded documents; they scramble parsing order.
• Spell out acronym and expansion once: "GST (Goods and Services Tax)", "SDR (Sales Development Representative)". Use common variants where they differ: "React / React.js", "Tally / TallyPrime".
• Fill the structured fields your board offers — location, employment type, salary, experience. These drive filters far more than free text.

For SEO on your careers page:

• Page title as [Job Title] – [Location] | [Company], with a clean slug like /careers/sales-executive-bengaluru.
• Put the role keyword and city naturally in the first 100 words. Indian job search is location-first.
• Give each role its own page. One "Careers" page listing eight roles ranks for nothing.
• Add job posting structured data if your site supports it — that's what makes listings eligible for Google's job results.
• Keep posting dates fresh and remove filled roles; stale listings hurt ranking and candidate trust.

Don't write for the algorithm at the human's expense. A page stuffed with "sales executive jobs in Bengaluru sales executive vacancy Bengaluru" reads like spam, and candidates treat it that way.

Formatting for mobile applicants

Assume mobile. A large share of Indian applications come from a phone on a patchy connection. Front-load location, salary and the one-line pitch into the first screen. Keep paragraphs to two or three lines. Skip tables in the external ad, since they collapse badly. Hold the whole thing to 250–450 words.

Keep the application under two minutes: name, contact, CV or profile link, location, notice period, expected salary, and at most two short questions. Don't require account creation before someone can see the form, and test the flow yourself on a phone on mobile data before publishing. Two or three short free-text questions filter better than any keyword rule: "Tell us in 3–4 lines about a project you closed end to end — what was your specific part?" Candidates who write two thoughtful lines are almost always worth a call.

JDs for blue-collar and field roles vs knowledge roles

Most JD advice assumes an office knowledge worker. If you're hiring delivery riders, machine operators, warehouse staff, technicians or housekeeping, the same principles apply but the emphasis flips.

Publish in-hand pay, not CTC ("₹19,000–₹22,000 in hand per month, plus overtime at ₹X/hour"), because a worker compares what lands in the bank account. State the shift precisely — "general shift, 9:30am–6:30pm, Monday to Saturday, second Saturday off" beats "flexible timings". List what's provided: uniform, tools, safety gear, canteen, transport. Say what documents to bring. Name PF, ESI, insurance and the salary credit date. And give a phone number and a name; web-only applications lose a large share of this pool.

On language generally: write the JD in the language the work is done in. If your sales team sells in Hindi and Marathi, an English-only ad filters on a skill you don't need. Keep English simple, avoid idioms that don't travel, and if you publish multilingual versions, keep salary, timings and location identical across them.

Job description template 1: Sales Executive (India)

Edit the bracketed parts and use it. This is the external ad version; the internal JD would add band, budget code and approval trail.

---

Sales Executive — SMB Accounts (Bengaluru)

Location: [Koramangala, Bengaluru — 4 days in office] Type: Full-time Salary: ₹6,00,000 – ₹8,00,000 fixed CTC + up to ₹3,00,000 incentive at 100% of target Reports to: Founder (moving to Sales Lead once the team is 4+) Experience: Typically 1–4 years in B2B sales; we care more about what you've closed than the number

Why this role exists

We've grown to [180] paying SMB customers almost entirely through referrals and inbound. That's a good problem, but it's flattening. We're hiring our first dedicated Sales Executive to build a repeatable outbound motion — with a product that works, live case studies, and a founder who will do calls alongside you for the first six weeks.

What you'll own

1. Pipeline. Build and maintain a qualified pipeline worth at least 3x your quarterly target, updated in the CRM the same day.
2. New revenue. Hit a monthly new-business target, ramping from [₹2L] in month three to [₹5L] by month six.
3. A repeatable playbook. By month six, the outreach sequences, objection handling and demo script you develop should be usable by the next two hires.
4. Clean handover. Every closed account moves to onboarding with a written summary of what was promised.

What your week looks like

Around half your time is outbound — calls, email sequences and LinkedIn on a list you help build. About a quarter is demos, typically 4–6 a week once you're ramped. The rest is CRM hygiene, proposals, and a Monday pipeline review.

What we're looking for

• You've sold to businesses and carried an individual number, not just supported someone else's.
• You're comfortable making first contact with people who don't know us, and following up without being annoying.
• You can run a product demo yourself after training — no pre-sales support here.
• You write short, clear emails in English and can hold a sales conversation in Hindi or Kannada.
• You keep a CRM current without being chased.

Nice to have: selling to HR, finance or operations buyers; SaaS experience; familiarity with [Zoho CRM].

About us

We're [34] people building HR and payroll software for Indian SMBs. Profitable since [last quarter] and growing without external funding, so we're careful with money and honest about targets. The hard part of this job: we're not a known brand yet, so most first conversations start with explaining who we are.

Compensation and benefits

₹6–8L fixed, plus incentives paid monthly with a quarterly accelerator above 100%. Health insurance for you and immediate family, PF as per statute, [18] days of paid leave, and a ₹[25,000] annual learning budget.

How we hire

Application → 20-minute recruiter call → 60 minutes with the founder → a live mock discovery call → references → offer. Around 12 working days, and we reply to everyone.

To apply

Send your CV to [careers@company.com] with three lines on a deal you closed end to end. If you need any adjustment to the interview process, tell us and we'll arrange it.

---

Job description template 2: Junior Software Engineer

---

Junior Software Engineer — Backend (Pune)

Location: [Baner, Pune — hybrid, 3 days in office] Type: Full-time Salary: ₹6,00,000 – ₹9,00,000 fixed CTC Reports to: Engineering Lead Team: 6 engineers, 2 of them backend Experience: 0–2 years. Graduates and career-changers with real projects are welcome.

Why this role exists

Our backend team is two people supporting a product used daily by [400+] field agents on low-end Android phones and unreliable networks. That constraint shapes everything we build. We need a third engineer so the team can ship features without every change queuing behind the same two people.

What you'll own

1. Shipped features. Within your first quarter, independently ship small-to-medium API features to production inside sprint commitments.
2. Quality of your own code. New modules come with tests and don't generate repeat bug reports.
3. Support rotation. From month four, take your turn on the weekly rotation and resolve or correctly escalate issues.
4. Documentation. Anything you build that another engineer will touch gets a short written explanation.

What your week looks like

Most of your time is writing and reviewing code. There's a 15-minute standup, sprint planning every second Monday, and roughly one pairing session a week with a senior engineer. Your first month is a structured onboarding: local setup, a guided first pull request, then progressively larger tickets.

What we're looking for

• You've written code someone else had to read — a college project, internship, freelance work or open source all count.
• You're comfortable in at least one backend language ([Python, Node.js or Java]) and understand how HTTP APIs and relational databases work.
• You can use Git without being nervous about it.
• You can explain your reasoning in writing — we do a lot of asynchronous review.
• You ask questions early rather than getting stuck silently for two days.

We don't require a computer science degree or a specific college.

Nice to have: [PostgreSQL], Docker or any cloud platform; anything you've shipped that real people used; experience writing tests.

About the team

Two levels between you and the CEO. Code review is mandatory and kind — we review the code, not the person. Priorities shift roughly monthly and we re-plan every two weeks, so things do get dropped. We don't expect messages after 7pm or on weekends except during our two annual release weeks.

Compensation and benefits

₹6–9L fixed CTC (inclusive of employer PF — we'll show you the full breakup before the offer). Health insurance for you and immediate family, [18] days of paid leave, a hardware budget, and a ₹[25,000] learning allowance.

How we hire

Application → 30-minute technical screen → a take-home exercise capped at 3 hours, discussed live → 45 minutes with the Engineering Lead → 30 minutes with a founder → offer. Roughly 2–3 weeks.

To apply

Send your CV or GitHub link to [careers@company.com] and tell us one thing you built and one thing about it you'd do differently now. If you need any adjustment to the format, tell us and we'll arrange it.

---

Approvals and version control

The JD is a commitment about money, headcount and title. Treat it like one.

• One owner. Usually the hiring manager drafts and HR edits, or the reverse. Two owners means no owner.
• Three sign-offs before posting: hiring manager (accuracy), HR (language, band consistency), budget owner (headcount and range).
• Version the file. SalesExec_Bengaluru_v3_2026-07 beats JD final final (2).docx. If your HRMS has a role library, keep the master there rather than in someone's Drive.
• Log what changed and why. When you raise a range or drop a requirement mid-search, note it. Six months later, when someone asks why two people at the same level sit at different bands, you'll want the record.
• Archive, don't delete, and set a review date and owner for every live JD.

Using the JD downstream: interviews, offers, onboarding, reviews

This is the payoff, and where most companies leave value on the table. A JD written properly is reusable four more times.

1. Interview plan and scorecard. Map each outcome to a stage and an assessor. Nobody should be improvising questions in the room.

Write rating anchors — what a 1 looks like, what a 4 looks like — before the first interview. Ten minutes of work, and it removes most of the arguing in debriefs.

2. Offer and appointment letter. Title, level, reporting line, location, work mode, probation, notice and compensation structure all flow from the JD. If the offer differs from the ad, you've created a trust problem on day zero.

3. Onboarding plan. The first-90-days outcomes are literally the new hire's 90-day plan. Hand them the JD on day one and walk through it.

4. Probation confirmation and performance reviews. Review against the outcomes you published. If the role has drifted, that's a real finding — update the JD rather than pretending otherwise. This is where a JD stored in your HRMS beats one in a folder: attached to the employee record, versioned, visible to whoever runs the review.

5. Pay bands. A library of well-written JDs mapped to levels is the foundation of a salary structure. Without it, your bands are a spreadsheet of whatever you happened to pay people.

Refreshing stale JDs

Roles drift. Signs the JD is stale: the current holder's work doesn't match half the document; the tools listed have been replaced; the reporting line changed and nobody updated it; the range is below what you last actually paid.

Sensible cadence: review before every posting, review all live-role JDs annually, and rewrite from scratch whenever the reporting structure or the outcomes materially shift. A rewrite is a 45-minute intake meeting, not a project.

Common mistakes to avoid

1. Copying a competitor's JD. You inherit their level, band expectations and org structure — none of which match yours.
2. The two-jobs-in-one JD. "Content Marketer who also runs performance ads and manages the website." You'll hire someone mediocre at all three or lose a good one in six months.
3. Twenty bullets of responsibilities. Nobody reads past eight.
4. Requirements written as a wishlist, and hiding the salary. Both cost you time and applicant quality.
5. Vague titles and adjective-driven company sections. "Business Associate", "dynamic, passionate, vibrant". Delete them.
6. Never naming the downside. Guarantees a surprise in month three.
7. Publishing a process you don't follow, or a long broken application form.
8. Copy-pasted foreign boilerplate — visa clauses, at-will language, US-specific EEO paragraphs.
9. No owner and no version. The JD nobody maintains is the one that misleads everybody.

The JD quality checklist

Accuracy - [ ] Written after an intake meeting, confirmed by the hiring manager - [ ] Reporting line, team size and location correct today; range approved by the budget owner

Content - [ ] 3–5 ranked outcomes and a "what your week looks like" section with real activities - [ ] Must-haves survive the "would you interview them anyway?" test; nice-to-haves labelled and shorter - [ ] Honest downside stated; company section has facts, not adjectives

Money and terms - [ ] Range published, fixed and variable separated, CTC components explained - [ ] Work mode, days in office, shift timings and travel stated precisely; no current-salary gate

Language - [ ] No age, gender, marital status, caste, religion, photo or college-tier requirements - [ ] Gender-neutral throughout; jargon, idioms and "immediate joiners only" removed - [ ] Local language version published where the role needs it

Discoverability and experience - [ ] Title is what a candidate would search, level clear, under 60 characters - [ ] Standard headings, acronyms spelled out, board fields filled, own page with a clean URL - [ ] Under 450 words, tested on a phone; form under 2 minutes; process and timeline published

Downstream - [ ] Scorecard drafted from the same outcomes, stages mapped to assessors - [ ] Version saved with a date and owner in the role library

FAQ

How long should a job description be?

Two answers, because there are two documents. The internal JD can run 500–900 words — it's a reference, so completeness beats brevity. The external ad should be 250–450 words. Over 700 and you've published the internal version by mistake.

What's the difference between a job posting and a job description?

The job description defines the role; the job posting sells it. The JD is internal, complete and neutral. The posting is external and persuasive, leads with location, money and the interesting problem, and drops anything that doesn't help someone decide to apply. Write the JD first, then cut the ad out of it.

Should we really publish the salary range in Indian job postings?

Yes, and it's still uncommon enough to be a differentiator. Total applications usually drop and relevant ones rise. Publish a tight range for the specific level, separate fixed from variable, and be explicit about what your CTC includes. If you can't publish, state the band level and ask for expectations rather than current salary.

How do I write a job description for a role we've never had before?

Work backwards from the problem: what's going wrong today that this hire is meant to fix, and what would be visibly different in twelve months? Then check how two or three similar-sized companies scope it — not to copy, but to sanity-check level and range. Write your first version deliberately narrow; it's easier to expand a role later than to un-hire someone you scoped as three jobs.

What is a hiring scorecard and do small teams need one?

A scorecard turns each JD outcome into a criterion with rating anchors, assigned to a specific stage and interviewer. Small teams need it more than large ones, because they have fewer interviews to average out a bad judgement call. Twenty minutes to build, and it turns debriefs from "I liked them" into a comparison of evidence.

How do I make a JD work for both ATS parsing and SEO?

Use conventional section headings, keep skills as plain text rather than inside images, spell out acronyms once, and fill in the structured fields your job board provides. For SEO, give each role its own page with a clean URL, put the role and city in the page title and first paragraph, add job posting structured data, and remove filled roles promptly.

What language should we avoid in Indian job descriptions?

Anything unrelated to the ability to do the job: age limits, gender preferences, marital status, photo requirements, caste, religion, region, college-tier filters. Replace "excellent communication skills" with the specific requirement — writes client emails unsupervised, handles support calls in Tamil. Also reconsider "immediate joiners only", which filters out most currently-employed candidates.

How often should job descriptions be updated?

Review before every posting, refresh the role library annually, and rewrite whenever the reporting line changes or the outcomes shift. If more than half of what the current role holder does isn't in the JD, that's not a refresh — it's a new intake meeting.

Bringing it together

Learning how to write a job description well is less about wording and more about thinking clearly before you write: a proper intake meeting, outcomes instead of verbs, ruthless requirements triage, an honest salary range, and language that doesn't quietly exclude good people. Do those five things and the document nearly writes itself — and the ad, scorecard, offer letter, onboarding plan and first appraisal all come from the same source.

The constraint for most Indian SMBs isn't knowing this. It's that JDs end up scattered across Drive folders, WhatsApp threads and half-finished docs, so none of that downstream reuse ever happens.

CozyHR keeps your role library, JD versions, hiring pipeline, offer letters, onboarding checklists and performance reviews in one place, so the outcomes you wrote in the JD are the same ones the new hire sees on day one and the same ones you review against at year end. If your hiring documentation currently lives in twelve places, it's worth a look — try CozyHR and set up your first role library in an afternoon.