A role opens, forty applications arrive over nine days, and the hiring manager asks for a shortlist by Friday. Somewhere in that pile are four people worth interviewing, six who need a short conversation first, and thirty who deserve a reply that will never be sent. The tracking part is not the hard part of hiring. It is the part that quietly determines whether the hard part gets done well.
Search for applicant tracking and most of the results explain what an applicant tracking system is, written by the companies that sell them. Those pages are accurate and incomplete in the same way a description of a car is incomplete as an answer to the question of how to get to work. The useful question is what applicant tracking consists of as work, and which parts of it software actually performs.
The phrase belongs to two different readers
Worth clearing up first, because it changes which advice applies. Applicant tracking is searched by two groups with opposite interests.
Candidates search it to find out how their application is read, and specifically whether a resume needs reformatting to survive parsing. A good deal of the advice aimed at them is folklore, and the parts that are not amount to using plain headings, avoiding text inside images and matching the words used in the posting.
Employers search it to work out what to do about a pile of applications. The two readerships want different things, and pages that try to serve both end up describing a system rather than a job. Everything below is the employer side: what has to happen to every application that arrives, and where that work can live.
The overlap is worth naming once, because it affects a decision employers make early. Parsing is the weakest part of most hiring software. Any process that leans on automatic extraction of experience from a document will misread some applications, and the fix is not better parsing. It is asking the three or four things that matter as form fields, so the answer arrives as data rather than as a paragraph somebody has to read.
Applicant tracking is six obligations
Strip away the software and the same six things have to happen to every application, in every organisation, from a two person studio to a bank.
Receipt has to be acknowledged. Not out of politeness. An applicant who receives no confirmation does not know whether the application arrived, so they apply again or write to ask, and both create work.
Every application needs one owner. Not a team, not a shared mailbox. One named person whose job it is to decide the next step. Applications with no owner do not get rejected, they get postponed until they age out.
Every application needs a state. Where it is now, in a small vocabulary everybody uses the same way. Without shared states, two people describe the same candidate differently and the count reported to a manager is wrong.
Silence has to be visible. The number that predicts a bad hiring outcome is not how many applications arrived, it is how long the oldest untouched one has been waiting. That is only visible if the date of last contact is recorded.
Decisions need a reason attached. One line is enough. The reason matters at the moment somebody asks why a particular candidate was not progressed, which may be weeks later and may be a formal question.
Records have to be kept, and then not kept. Retention obligations for recruitment records vary by jurisdiction and by the size of the employer, so the specific period is a question for whoever advises the organisation. The operational point is that it is a period, with a start and an end, and neither a shared mailbox nor a personal folder has any concept of one.
Every honest comparison of hiring tools is a comparison of how much of that list is handled without somebody remembering to do it.
What applicant tracking software genuinely does
Four things, and they are worth stating plainly because they are real.
It gives each application a record with a state and an owner, so the pipeline has one version rather than one per person. It keeps the correspondence with the candidate attached to that record, so the answer to what was said does not depend on who is at their desk. It lets several people work the same pipeline without overwriting each other. And it produces the counts and time in stage figures that make a hiring bottleneck visible, which is nearly impossible to see from inside a mailbox.
Larger systems add things that matter at scale: publishing one posting to several job boards, structured interview scorecards, a careers site, and controls over who can see which candidates for which role. If hiring is continuous and involves several recruiters and many managers, those features earn their price without much argument.
The point of listing them is that all four of the first group are properties of the record, not intelligence about candidates. A tool that gives every application an owner, a state, a thread of replies and a clock is doing the substantive part of applicant tracking, whether or not it was built for hiring. That is why a small team can get most of the benefit without buying a hiring system, and why buying one does not help a team that has not yet agreed what its states mean.
What it does not do
Three gaps are consistent, and each one is a place where teams expect help and do not get it.
It does not decide anything. Ranking, scoring and matching features produce an order, and the order reflects the words in the application rather than the suitability of the person. Treated as a reading aid it saves time. Treated as a filter it removes candidates for reasons nobody wrote down, which is both a hiring mistake and, in some jurisdictions, a compliance exposure.
It does not write the replies. The rejection backlog is the most common visible failure in hiring, and it exists because writing thirty individual messages is unpleasant work that nothing forces. Software can send the message, and only after somebody has decided what it says and that it will be sent to everyone.
It does not create the states. A tool ships with a default pipeline, and a default pipeline is a guess about a process that has not been agreed yet. Teams that install a system before defining what screening means end up with the same ambiguity, now with dropdowns.
Covering the same ground with what is already in the building
For a team hiring for one or two roles at a time, the six obligations can be met with a form, a list and a set of prepared replies. The configuration that works looks like this.
Applications arrive through a form rather than by email to an address. This single change does more than anything else on the list, because it makes every application structurally identical, captures the three or four decisive facts as fields, and produces an acknowledgement automatically. Attachments go to one folder per role, named by candidate, with the record holding a link.
Each submission then needs an owner, a state, a date of last contact and somewhere for the reply to live. If those four live in a spreadsheet, the arrangement works for one person and starts colliding as soon as a second joins, because a name in a cell is a label rather than an assignment and nothing keeps the correspondence with the record. If they live in the response view of the form tool itself, the arrangement holds for several people, which is the practical difference response management makes.
| Setup | Covers | Does not cover |
|---|---|---|
| Inbox and folders | Receipt, if somebody replies | Owner, state, silence, retention |
| Form plus spreadsheet | Receipt, state, silence | Owner in any real sense, the replies |
| Form with response management | All six, for a small team | Job board posting, scorecards, careers site |
| Full applicant tracking system | All six, plus scale features | The decisions and the wording of replies |
Volume metering is the thing to check before features, because hiring is spiky. Jotform's free Starter tier allows 5 forms, 100 submissions a month and 500 stored submissions in total. Cognito Forms allows 100 entries a month on its free single user tier. Typeform's Basic plan is 39 dollars a month with 100 responses a month. One well advertised role can exceed those in a fortnight, which is why a tool that leaves forms and responses unmetered and prices by the number of people doing the hiring suits this shape of work better than one priced by application.
The number that actually matters
If only one measure is tracked, track the age of the oldest application with no recorded contact.
Not time to hire, which is mostly determined by how long managers take to give feedback and is therefore a measure of something else. Not the number of applications, which measures the advertising. The oldest untouched application is the only number that detects the failure that damages the organisation outside its own walls, which is people who applied and heard nothing.
It is also the number that responds fastest to a change in routine. A five minute review, twice a week, of every application whose last contact is more than four days old will close a rejection backlog within a fortnight without any new software. Nothing else on the usual dashboard has that property.
Two related habits are worth adopting at the same time. Write the rejection message once, before the role is advertised, so that sending it is a decision about a candidate rather than an act of composition. And set a date at which anything still in screening gets closed, so that postponement has an end.
When buying a system is the right call
Three thresholds, any one of which is a reasonable trigger.
More than one recruiter, or more than about five open roles at once. Beyond that, keeping a shared view accurate becomes a job in itself, and the tooling pays for itself in coordination alone.
A need to publish to several job boards from one place. This is genuine drudgery, it is not solvable with a form, and it is what many teams are actually buying when they buy an applicant tracking system.
A formal obligation to demonstrate what happened. If the organisation is large enough, or regulated enough, that it must show who was considered, by whom, and on what recorded grounds, then per record history stops being a convenience.
Below all three, the honest answer is that an intake form with owners, states and replies in one place covers the obligations, and the remaining gap is the wording of the messages and the discipline to send them. The questions people ask most about intake tools are mostly versions of this one.
What to change first
Find the oldest application with no recorded reply and note how many days old it is. Then move intake to a form so every application arrives identical and acknowledged, and give each one an owner, a state and a date of last contact. Write the rejection message before the next role goes live. Halict can be tried against a live posting before anybody commits to a hiring system.
Q1. Is an applicant tracking system necessary for a small team?
Not for one or two roles at a time. What is necessary is that every application has an owner, a state, a recorded date of last contact, and replies stored with the record. A form with response management covers that. A dedicated system becomes worth it past roughly five concurrent roles, or when postings need publishing to several job boards from one place.
Q2. What does an applicant tracking system not do?
It does not decide who to progress, it does not write the replies, and it does not define what the pipeline stages mean. Ranking features produce an order based on the words in an application rather than on suitability, and using that order as a filter removes candidates for reasons nobody recorded. The judgement and the wording stay with people.
Q3. Can a spreadsheet be used for applicant tracking?
For one person, yes. It breaks when a second joins, because a name typed in an owner column is a label rather than an assignment, two people can overwrite the same row silently, and the correspondence with the candidate lives in somebody's sent folder. Those are structural gaps, so adding columns does not close them.
Q4. What is the single most useful metric to track?
The age of the oldest application with no recorded contact. Time to hire mostly measures how fast managers give feedback, and application volume measures the advertising. The oldest untouched application is what detects a rejection backlog, and it responds within a fortnight to a twice weekly review of anything silent for more than four days.
Q5. Should applications be collected by email or by form?
By form. Email produces applications in a different shape every time, with the decisive facts buried in a document that somebody has to read, and no automatic acknowledgement. A form makes every application structurally identical, captures the three or four facts that drive the first decision as fields, and confirms receipt without anybody typing.