When do you need an ATS? Check the hiring handoffs.

You need an ATS when keeping candidate records, communication, interview feedback and next actions reliable requires coordination your current process cannot sustain. Company headcount alone does not settle the decision. A small team hiring repeatedly across several managers can have a harder coordination problem than a larger organisation filling an occasional vacancy. Start with evidence from your own hiring work.

CIPD frames recruitment as a process covering role definition, attracting applicants, managing applications and selection, and making the appointment. That is a useful boundary for your review: examine the complete route a person takes rather than counting applications in isolation. The diagnostic method below is an editorial recommendation, not a CIPD purchasing standard.^[1]

Choose a recent vacancy and a current one. Ask the recruiter and hiring manager to reconstruct what happened, using records they are authorised to see. Where was the latest candidate reply? Who owed feedback? Which next action had a date? Record the places where somebody had to search, ask a colleague or recreate missing context. Keep candidate details inside approved systems; your decision note needs the problem and its consequence.

Application volume tells you how much enters the process. It does not show how much work remains open at once. Record active vacancies, applicants awaiting an action, interview panels and people responsible for updates. Include the time spent checking whether an action has already happened. Repeated uncertainty is a different purchasing trigger from a single busy recruitment week.

Look at the next agreed hiring period as well as the recent past. Are several managers about to recruit at the same time? Will a recruiter cover another person's vacancies? Will a role require repeated interview handoffs? Describe the expected change and its evidence. A tentative growth plan should remain tentative in the business case rather than becoming a guaranteed workload forecast.

There is no universal application count at which this guide recommends an ATS. Set a local service expectation, such as an owner and next action for every active application, and check whether the team can meet it. If the process meets that expectation with little repeated administration, improving the existing workflow may be the proportionate next step.

A row marked interview does not tell a covering recruiter whether the invitation was sent, whether the candidate replied or who must resolve a scheduling conflict. Review a few active applications from the perspective of someone taking over tomorrow. They should be able to find the current stage, relevant communication, responsible person and next agreed action without interpreting a private shorthand.

First repair missing ownership in the process you already have. Define stages in plain language, assign responsibility for updates and agree when a handoff is complete. If those rules are understood but updates still require copying information between personal inboxes, calendars and trackers, record that as a possible software requirement. Show the failed handoff and the information an ATS would need to keep together.

Repeated missed follow-up can justify a pilot, but a reminder feature cannot resolve an undecided hiring process. Someone must own exceptions, absence cover and the final decision. Ask prospective suppliers to demonstrate how a colleague sees overdue work and what happens when ownership changes. Keep the demonstration tied to your scenario rather than accepting a tour of unrelated features.

When a debrief stalls, identify why. Feedback may be missing because interviewers cannot find the form, because nobody owns the deadline, or because the criteria are unclear. These require different remedies. A shared record and reminders can support collection; the hiring team still needs to agree what evidence it is seeking and how it will discuss conflicting observations.

OPM describes structured interviews using predetermined questions and common rating standards. Its guidance concerns selection practice, rather than ATS procurement. Use that limited principle when reviewing your process: decide the interview questions and feedback criteria before expecting a system to organise the resulting records. An ATS scorecard records post-interview feedback; it does not substitute for a job-relevant interview design.^[2]

Rehearse a simple case with synthetic information: two interviewers submit different observations and the hiring manager needs to understand each one. Can the team see the evidence, identify missing feedback and record its next decision? Do not treat an automatically calculated total as permission for software to choose a candidate. Human reviewers remain responsible for interpreting interview evidence.

Inspect how the team distinguishes a person from an application. One person may apply for two vacancies or return for a later role. If the current tracker treats every row as a different person, communication and context can split. Write down the record relationships you need before asking a supplier how duplicates, repeated applications and archived records are handled.

Check where attachments and candidate replies live. Can an authorised colleague find the original CV and latest message? Does changing a spreadsheet stage update anything else, or does someone repeat the work in an inbox? Count the systems touched during one ordinary update. Avoid copying private records into a procurement presentation to illustrate the problem; synthetic examples can show the same relationships.

A central system is useful only if the team agrees what belongs in it and who may access it. Include relevant hiring-manager access, record correction and withdrawal handling in your acceptance questions. Have the responsible internal owner define retention and access expectations for the locations in scope. Confirm supplier support separately; purchasing software does not establish that your own data practices are appropriate.

Choose one question a hiring owner needs answered. For example: which active applications are waiting for interview feedback, and who must act? Trace the fields required to answer it. If stage names are inconsistent or dates are overwritten, a dashboard will inherit those weaknesses. Agree field definitions and update responsibilities before treating reporting as a reason to buy.

Review the administrative effort needed to produce that answer now. Record repeated reconciliation, duplicate checking and manual follow-up. Separate occasional setup from recurring work. Then describe the report you would accept in a pilot, including which records it covers and how you would check its accuracy. A persuasive chart cannot replace a traceable definition of the underlying data.

Avoid treating a better report as proof that hiring quality or speed improved. An ATS may make workflow information easier to inspect while interview design, manager availability or headcount approvals remain unchanged. Decide which operational measure you can actually observe and who will interpret it. Keep business outcomes as hypotheses until comparable evidence supports them.

Continue with the current workflow when hiring is occasional, the team can keep records within approved access boundaries, handoffs remain visible and reporting takes little recurring effort. Give one owner responsibility for the tracker, standardise the stage names and establish a routine for next actions. Agree a review date and a trigger for reconsidering software rather than buying for an unspecified future.

A short process repair is also useful when the main failure is an absent owner or undefined interview criteria. Test the repair on the next real vacancy. Record whether the problem recurs and what work is required to keep the process reliable. This produces a stronger buying brief than assuming every frustrating moment needs a new tool.

Use the ATS versus recruitment spreadsheet comparison when you are ready to compare operating approaches. This guide answers an earlier question: whether your team has a recurring problem worth evaluating at all. It does not rank suppliers, prescribe a company-size threshold or suggest that every growing organisation should replace its tracker immediately.

The following figures are hypothetical planning inputs, not customer results or industry benchmarks. Imagine a 150-person company reviewing four weeks of hiring across three vacancies. The recruiter records 12 occasions when they chase missing interview feedback, each taking an estimated 10 minutes, plus eight occasions when they reconcile candidate status across an inbox and tracker, each taking 15 minutes.

The arithmetic is 12 × 10 = 120 minutes for feedback chasing and 8 × 15 = 120 minutes for status reconciliation: 240 minutes, or four hours, across the observed four weeks. Count each task once. If a status check also included a feedback reminder, allocate that time to one category. Do not multiply the total into an annual saving without evidence that the workload repeats.

The team first agrees a feedback owner and deadline. It then observes the next four-week period. Suppose feedback chasing falls to six occasions while status reconciliation remains at eight. At the same illustrative durations, the total becomes 60 + 120 = 180 minutes, or three hours. The one-hour difference is an observation in this invented example; it is not a causal estimate of software value.

The unresolved status work becomes the pilot question: can an authorised covering recruiter find the current application, latest communication and next owner in one candidate record? Budget both internal setup and supplier costs before proceeding. If the team cannot name who will configure, maintain and use the system, resolve that ownership before scheduling a launch.

Write a short pilot brief in your existing project tool. Name the repeated failure, the people affected, the workflow in scope, the evidence needed and the person who can accept the result. Use a synthetic vacancy and candidate records for initial demonstrations. Agree separately when real data or real communication may enter an authorised pilot.

For the example above, ask a recruiter to receive a reply, find the associated application, update its stage and hand it to a covering colleague. Include a changed interview time and missing feedback. Ask the colleague to find the next action using their own permitted access. Record what was observed, what required supplier explanation and what remains unverified.

Use the ATS requirements checklist to capture mandatory checks before comparing suppliers. A feature label is weaker evidence than a demonstrated workflow. Record package dependencies, integration prerequisites and any work your team must perform. Keep unresolved checks open rather than assigning a favourable score because the interface looks familiar.

Compare the proposed recurring cost with the internal work needed to adopt the system. Allow for data review, workflow configuration, access approval, interviewer guidance and a person responsible for support. Separate one-time implementation work from recurring administration. Use supplier quotations for actual prices and label any planning assumptions clearly.

Review what must move and what can remain in a controlled archive. Historical candidate records, attachments and past interview notes may need different treatment from active applications. Follow the ATS migration guide when a supplier has been selected and the supported transfer scope is confirmed. A buying decision does not establish that every field or attachment can be transferred.

Agree a stop condition before the pilot begins. If a mandatory access boundary, candidate communication step or required record relationship cannot be demonstrated, keep the issue visible and decide whether to change scope or end the evaluation. A narrowly successful pilot can justify the next stage; it does not prove a complete rollout or an organisation-wide outcome.

Hire supports applicant pipelines, candidate communication, interview scheduling and structured feedback after interviews. Bring one unresolved hiring handoff to the Hire overview and ask to see that workflow. Keep the focus on the recruiter, manager and candidate context you need to preserve. Hire assists recruitment work; people remain responsible for hiring decisions.

Review Hire plans for the package and usage scope relevant to your team, then confirm integrations and implementation responsibilities for your proposed pilot. If your process review shows little recurring coordination work, retain the current approach and set a date to reassess. If it shows a repeated failure with an accountable owner, use the pilot brief to make the next product conversation concrete.