ATS requirements checklist: define what your team needs.

The downloadable CSV has starter requirements for pipeline ownership, candidate communication, applications, interview scheduling, post-interview feedback, permissions, reporting, data handling and connected systems. Open it in your preferred spreadsheet application. It contains editable text, no macros and no automatic scoring. No email address or sales call is required. The starter priorities are suggestions for a first rollout; replace them with the priorities your team approves.

Use one row for one observable requirement. Keep the requirement ID, business problem, priority, accountable owner, acceptance check, required package or dependency, evidence reference and open question together. Use your own evidence-status labels: not checked, demonstrated, documented, failed or deferred. Keep that status separate from priority. A supplier saying that a feature exists does not mean your team has seen the required workflow work.

For example, write “A replacement recruiter can identify the next action from the candidate record” rather than “Good collaboration.” Ask the supplier to demonstrate a handoff with a fictitious candidate, then record the screen or document reviewed and any unresolved limitation. This is an illustrative acceptance check, not customer evidence. Never put real candidate names, CVs, email addresses or sensitive interview notes into a worksheet that will be shared with vendors.

An ATS requirements checklist should describe the hiring process your team intends to operate. Begin with one current vacancy and follow the work from publication to an accepted offer. Ask the recruiter where information arrives, the hiring manager which decisions need their input, and the administrator which access or setup tasks must happen. Write down where the current spreadsheet, inbox or calendar handoff leaves someone uncertain.

For a company with 125 to 250 employees, record the actual recruitment workload separately from company size. Include expected open vacancies, recruiter accounts, occasional interviewers, locations, languages and any shared mailbox. These are scoping questions rather than an industry benchmark. A team hiring a few replacements may have different requirements from one opening a new department, even when both have the same headcount.

Define the first rollout and a later expansion column. The first rollout might cover one recruiting team with a named administrator and a limited vacancy set. Later expansion might involve another entity or an employee handoff. Set a review date for the later requirements so they remain visible without making every future possibility a launch condition. Ask Finance to confirm the budget boundary once the workflow scope is clear.

A must-have is a requirement whose failure prevents your agreed first rollout. Name the consequence and the person who can approve an exception. “The hiring manager can access only the relevant job” is testable; “enterprise-grade permissions” leaves both the scope and the acceptance decision open. Use your own access policy to decide which permission boundaries are mandatory.

A useful requirement improves a workflow that can operate with an accepted temporary alternative. Record that alternative, who owns it and how long it can remain. If the workaround needs daily manual reconciliation, count that work before calling the feature optional. A later requirement has a named future trigger, such as another entity joining or a specific integration becoming necessary. Future requirements should be dated rather than quietly discarded.

Company size does not determine whether a requirement is enterprise-only. Identity, access, contractual terms and data handling can matter to a small organisation. Place complex multi-entity configuration, custom reporting or a specialised connection into the later column only when the appropriate owner agrees. If Security requires a control before launch, keep it mandatory even if the supplier sells it in a higher package. Record the cost and dependency beside the requirement.

Write down the stages your recruiters use and what each stage means. Distinguish internal work from progress that candidates should see. Include who moves an application, who receives the next task and what should happen when a recruiter is absent. Ask for a demonstration using a vacancy that resembles the process you intend to configure, with fictitious records throughout.

Check the candidate record during a handoff. The receiving recruiter should be able to identify the current stage, accountable owner, recent activity and outstanding follow-up using the agreed workflow. Add an exception check for duplicate records, an archived application or an overdue task if these are real sources of work for your team. State whether the exception must be resolved during launch or can use an approved temporary process.

Keep candidate communication in its own requirement row. Demonstrate an outbound message and a reply, then inspect where the conversation appears and which users can see it. If the team uses a shared mailbox, check that exact mailbox arrangement instead of assuming that a personal-mailbox demonstration covers it. Confirm the supported connection, its permissions and the selected package with the supplier. Record any mailbox administration needed before the pilot.

Include the application flow in the requirements, alongside recruiter administration. W3C’s forms guidance recommends labelled controls, helpful instructions and clear feedback about completion or errors. Use those principles when preparing your application review. The guidance supports these checks; it does not establish that a particular vendor or your eventual configuration conforms to an accessibility standard.^[1]

Ask a reviewer to complete the proposed form with fictitious information on a phone and by keyboard. Check whether required fields are clear, an error explains how to fix the problem, and the success state tells the candidate what happened. Record a specific issue and the step where it occurs. Request appropriate accessibility evidence from the supplier and test the configured form; a successful demonstration alone cannot establish full accessibility conformance.

Separate essential application information from optional talent-pool choices. Ask which fields the team needs for the vacancy, which messages appear after submission and how candidates can correct prepared information where that feature is used. Confirm the intended terms and notices with the responsible internal owner. Avoid turning the requirements document into a copy of every question currently in a spreadsheet; review whether each question still has an approved purpose.

For scheduling, specify the participants, calendar arrangement, time-zone display and rescheduling path your team needs. Demonstrate an invitation, a changed time and the resulting candidate record. If self-scheduling is required, test the candidate-facing route with fictitious details. Calendar and meeting connections need confirmation for the selected provider and package; put these dependencies into the checklist before approving the pilot.

The US Office of Personnel Management describes structured interviews using predetermined questions and a common rating scale. That supports a consistent interview approach. For your ATS requirements, define how interviewers record evidence after the conversation and how the team identifies missing feedback. Software can store that feedback while accountable people conduct interviews, interpret the evidence and make the hiring decision.^[2]

Agree which feedback template applies to the role, when feedback is due and who owns the debrief. If your process needs independent feedback before reviewers see colleagues’ comments, ask the supplier to show that boundary with two reviewer accounts. Check a correction to submitted feedback and who can see the revision. Keep assessment or testing tools in a separate requirement if your company uses them; do not treat an ATS scorecard as a candidate test.

Give the access review to the person responsible for your organisation’s permissions. Describe the recruiter, hiring-manager, administrator and occasional interviewer roles with the records and actions each needs. Ask the supplier to demonstrate those boundaries using separate accounts. Record identity requirements and support-access conditions in the same review, then obtain the package and contractual details needed for the final decision.

Data questions need their own owner and evidence. Ask about configurable retention, candidate requests, export formats, deletion handling, storage scope and the controlling agreement. Use the company’s approved policies and qualified advisers to determine the requirements. This checklist does not prescribe a legal retention period or certify compliance. Leave unanswered questions visible and require the responsible owner to resolve them before approving a requirement that depends on them.

For migration, prepare a sample using fabricated records and agree which fields, files, status history and consent information belong in scope. Check whether the supplier imports each item, whether your team must transform it and which historical material remains elsewhere. Document duplicate handling and a way to reconcile sample results. This is a buying requirement; it does not imply that every vendor offers migration services or that CapoFine imports every historical field automatically.

Choose a small set of questions the recruitment owner needs to answer. Examples include which applications need follow-up, where a vacancy’s candidates are waiting and whether interview feedback is complete. For each question, specify the definition, time window, relevant records and who should see the answer. Review a sample report against known fictitious records so the team can explain the result.

For connected systems, name the source, destination, exact event and fields. “Integrates with our HR system” is incomplete. A clearer requirement states which accepted-candidate information should move, when it should move, who may trigger or approve it and how the owner notices a failed transfer. Confirm what is supported now, what is package-dependent and what needs a separate implementation agreement.

Ask who operates each connection after launch. Record the administrator, credential owner, error review and fallback process. If a connection is not needed for the first pilot, keep it as a dated later requirement with an explicit trigger. Avoid approving a supplier on a roadmap promise. Where the exact flow is unverified, label it not checked until your team has reviewed current documentation or an appropriate demonstration.

Consider a hypothetical team replacing a recruitment spreadsheet for one active vacancy. The recruiter’s problem is that a colleague taking over cannot see who owes the next action. The team creates requirement H01: “The receiving recruiter can identify the application stage, conversation and next owner during a handoff.” Talent Acquisition owns acceptance; launch priority is must-have.

The acceptance check uses a fabricated application, one recruiter message and one scheduled interview. A second recruiter signs in with their intended permissions and identifies the outstanding action without asking the first recruiter to explain it. The team records whether the information was visible, the account role used, the selected package and the evidence reviewed. The example defines a check rather than claiming a measured result or a universal benchmark.

If the demonstration leaves ownership unclear, record failed or not checked and name the unresolved question. A supplier may propose a configuration change; request another demonstration before changing the evidence status. The team may instead approve a limited workaround, but that decision needs an owner and review date. Once requirements are agreed, use the ATS comparison checklist to evaluate suppliers against the same scope and the ATS pricing guide to budget it.

CapoFine Hire manages vacancies, configurable hiring stages, candidate communication, interview scheduling and structured feedback after interviews. It is an ATS and candidate CRM. Use these workflow areas to prepare a focused product discussion, with one actual vacancy process and fictitious candidate records for demonstrations. Recruiters and hiring managers retain the hiring decisions.

Bring the requirements that affect the first rollout and the open questions that need specialist input. Ask for confirmation of package-dependent connections, identity controls and reporting scope in the proposed plan. Keep supplier evidence beside each requirement rather than marking every starter row accepted because a product overview uses similar language. Review the Hire overview for the recruitment workflow, then compare the relevant plans with the requirements you have approved.

Before the next supplier meeting, assign an owner to every must-have row, remove requirements with no current business purpose and prepare the sample records for the checks you want to see. Share the worksheet with the recruiter, hiring manager, People Systems and the internal reviewers responsible for access, data and budget. Ask each owner to confirm their acceptance check and the unresolved question they want the demonstration to answer.