Describe your hiring process step by step, then turn each step into a requirement written as a task rather than a feature. Split the list into must-have, should-have and nice-to-have, keep it under roughly forty lines, and include data, security and reporting needs. Vendors answer a task list far more honestly than a feature checklist.
Because feature names mean different things to different vendors, and almost every vendor can answer yes to a feature word. Ask for interview scheduling and everyone says yes. Ask instead that a coordinator can propose three slots to a four-person panel across two time zones and have the candidate self-select without an email thread, and the answers separate immediately. Task phrasing also forces you to describe reality, which surfaces steps your team performs by habit and never documented. Write each line as who does what, in what situation, with what outcome. Keep the wording free of any product's terminology so you are not accidentally describing the system you already use. This is the single change that makes a requirements document useful rather than decorative when you start evaluating [applicant tracking software](/ats).
Five sections beyond the process itself. Data covers what you need to import, what must be retained and for how long, and how records leave the system if you exit. Security and access covers authentication, permission levels, and who can see salary or feedback. Integration covers the systems that must exchange data, such as HRIS, payroll, calendar, email and background checks, with the direction of flow stated. Reporting covers the specific questions leadership asks, written as questions rather than as report names. Scale covers your expected hiring volume, user count and locations over the contract life. Each section should carry a small number of hard requirements rather than a long wish list, because everything you mark as mandatory dilutes the ones that genuinely are.
Use three tiers and enforce them. Must-have means you would walk away from an otherwise excellent product, and that tier should be short enough to fit on half a page. Should-have means it changes your score meaningfully but not your shortlist. Nice-to-have means you would like it and will not pay for it. The discipline is in the first tier. If a third of your list is mandatory, you have not prioritised, and vendors will read the document as an aspiration rather than a specification. Test each must-have with a simple question: has the absence of this actually caused a problem in the last year? If not, demote it. Cross-check the result against [the capabilities most teams end up using](/ats-features) rather than the ones that sound impressive in a meeting.
Aim for three to six pages, with roughly twenty to forty numbered requirements. Longer documents get skimmed by vendors and answered generically, which defeats the purpose. Circulate the draft to the recruiters and coordinators who do the work daily, one hiring manager, and IT, and give each a specific brief rather than asking for general comments. Recruiters check that the workflow matches reality. Managers check that their part is described accurately. IT checks security, identity and integration lines. Then freeze it before the first vendor conversation and change it only deliberately, recording what changed and why. A requirements document that keeps shifting during an evaluation stops being a fair basis for comparison, which is the entire reason to write one.
Get a personalized walkthrough of Pitch N Hire on your own roles and workflow. No slides, no obligation.
Prefer to talk? Book a demo · View pricing
Free 1-user plan · No credit card · Talk to a real hiring expert
See your true cost-per-hire and how much Pitch N Hire could save you — our free Recruitment ROI Calculator gives you the numbers in under a minute. No signup required.
Open the free ROI calculatorPrefer a tailored walkthrough on your real roles? Drop your work email:
★ Free 1-user plan · No spam · Talk to a real hiring expert
