What is an applicant tracking system?

What an ATS does

An applicant tracking system holds every open role, every candidate who has applied or been sourced for it, and the stage each candidate has reached. It records who moved them, when, and on what basis, and it gives the people involved in a hire, recruiters, coordinators, hiring managers and interviewers, one place to do their part of the work.

In practice that means four things. It publishes roles to the places candidates look, and collects the applications that come back. It organises those candidates into a pipeline of stages, so it is always clear where each person is and whose turn it is to act. It captures the evaluation, in the form of screening decisions, assessment results and interview feedback, against the candidate rather than in someone’s inbox. And it produces the offer, tracks the response, and hands the accepted hire on to whatever system owns employees.

The word “tracking” undersells it. A spreadsheet tracks. An ATS is the working record: the place where the decision to advance or reject a person is taken and written down, with a name against it.

What an ATS is not

An ATS is not a human resources information system (HRIS), and it is not a talent CRM on its own. The three are often bought together and sometimes sold as one, but they answer different questions and own different records.

An HRIS is the system of record for employees: positions, org structure, worker records, compensation, leave and payroll. It begins where the ATS ends, at the point a candidate becomes a pre-hire. An ATS that tries to be an HRIS ends up with two versions of the truth about the same person, and the HRIS always wins that argument because payroll runs from it.

A talent CRM manages relationships with people who are not currently in process for a role: past applicants, runners-up from earlier loops, referrals waiting for a matching opening, people met at events. An ATS only knows about candidates attached to a requisition, so once that requisition closes, a bare ATS forgets them. The CRM is what remembers. The two are compared in detail in ATS vs. talent CRM.

Core components of an ATS

A complete applicant tracking system has seven parts: requisitions, postings, a pipeline, scorecards, offers, reporting and integrations. A product missing any of them pushes that part of the work into email or a spreadsheet.

• Requisitions. The approved need for a person: how many openings, at what grade, in which cost centre, reporting to whom, by when. A requisition is the unit finance controls and the thing every candidate is attached to. See requisitions and headcount.
• Postings. The public face of a requisition on a careers site, job boards, referral portals and agency channels. One requisition may have several postings; a posting should never exist without a requisition behind it.
• Pipeline. The ordered stages a candidate passes through, such as screen, assessment, interview, debrief, offer and verification, with an owner and a time expectation for each. Different role families need different pipelines, so the system should support more than one.
• Scorecards. Structured interview feedback, written against named competencies on a defined scale, submitted per interviewer and collected for a debrief. This is the part of an ATS that most determines the quality of hiring decisions, and the subject of the guide on structured interviews.
• Offers. Compensation built from components, approved by the people policy says must approve it, issued from a template, signed electronically and tracked through acceptance or decline.
• Reporting. Funnel conversion by stage, time to fill, source of hire, offer acceptance and where candidates are ageing, computed from the same records the team works in rather than from an export.
• Integrations. Connectors to the HRIS, calendars, video conferencing, job boards, assessment providers, background verification vendors, e-signature and single sign-on, each stating what the other system continues to own.

How an ATS fits with an HRIS and a talent CRM

The cleanest way to think about the three systems is by what each one owns and, just as importantly, what it does not. The ATS owns the hire in progress; the HRIS owns the employee; the CRM owns the relationship before and between hires.

The boundaries matter most at the handoffs. Requisitions often originate in the HRIS, because that is where positions and budgets live, and flow into the ATS to be worked. Accepted hires flow back the other way as pre-hires, and the HRIS returns an employee ID that closes the loop. Between the ATS and the CRM the ideal is not a handoff at all but a shared record, so that a candidate rejected at the final round today is findable, with their full history, when a similar role opens next year.

What to look for when evaluating an ATS

The qualities that separate applicant tracking systems are governance and structure rather than the look of the pipeline board: approval chains on requisitions and offers, pipeline templates per role, structured feedback, an audit log, HRIS connectors and role-based access control. Most products can move a card from one column to the next. Fewer can prove, a year later, why it moved.

• Approval chains. Can a requisition be configured so that nothing posts until named approvers, at named levels, have signed off? Can an offer above the approved band automatically add an approver rather than relying on someone noticing? Look for timestamps, comments and an SLA per step.
• Templates per role. An engineering hire, a sales hire and a high-volume operations hire should not run the same stages. Check whether the system ships pipeline templates by role family and seniority, and whether each stage carries an owner and an SLA.
• Structured feedback. Are scorecards tied to a rubric with behavioural anchors, submitted per interviewer, and hidden from other interviewers until their own is in? Is there a debrief view that shows disagreement rather than an average?
• Audit log. Is every state change recorded append-only with actor, timestamp and before-and-after values, and can it be filtered and exported? A summary is not evidence; the row is.
• HRIS connectors. For the HRIS you actually run, does the connector move requisitions in and hires out, show the field mapping, and queue errors where someone will see them? Does the vendor say plainly which system remains the system of record?
• Role-based access control. Can a hiring manager see compensation on their own requisitions and nothing on anyone else’s? Is scoping enforced in the data layer rather than hidden in the interface? Does it map to your identity provider’s groups?

Two smaller tests are worth running. Ask to see how a rejection is recorded and who is named on it. And ask what happens to a candidate’s record when the requisition they applied to is closed.

Common mistakes

The most common mistake when adopting an ATS is treating it as a place to store résumés rather than as the place decisions are made. If interview feedback still travels by email and offers are still approved in chat, the system holds the paperwork but not the process, and its reports describe something that did not happen there.

Other mistakes recur across teams of every size:

• One pipeline for every role. A single generic sequence of stages fits no role well, so teams skip stages informally and the data stops meaning anything.
• Posting without a requisition. Job ads that were never approved create candidates for openings that do not exist, and finance finds out at offer stage.
• Free-text feedback. “Strong, would hire” from one interviewer and “not sure” from another cannot be compared, aggregated or defended.
• Letting the ATS become the HRIS. Editing worker data in the recruiting system guarantees two versions of the truth.
• Forgetting closed requisitions. Every runner-up from a closed loop is a pre-qualified candidate for the next one, if the system can still see them.
• Buying on the demo of the pipeline board. The board is the easy part. Ask about approvals, audit and access before asking about colours.

In Elevator