The ATS Under Review: Why the System Question Is Never the First Question
- Marcus Fischer
- Aug 6
- 6 min read
An applicant tracking system rarely ages visibly. It ages by the organization starting to work around it. First, a spreadsheet appears on the side because a step in the system is too cumbersome. Then an email thread, because a sign-off moves faster by email than through an approval workflow. After a few years, most of the actual work happens around the software, while the system formally remains "in use." That's exactly the point where many organizations fall into the same reflex: the market gets scanned, demos get booked, a new vendor impresses with shiny features — and the old, unloved process quietly moves into the new system. Eighteen months later, the same symptoms are back, only now they come with a fresh implementation bill.
The thinking error behind this is common: the assumption that a new tool automatically fixes an old process problem. It doesn't. An ATS reflects exactly the process you give it. Anyone who migrates an existing, years-old workflow as-is buys it a second time — just with a new interface and a bigger invoice. The system question is answerable. But it's the second question, not the first.
How an ATS Really Ages
Four patterns together explain why a once well-implemented system eventually stops fitting.
First, the lived process drifts away from the system: spreadsheets, side agreements, and informal workarounds take over steps that should formally still run through the ATS.
Second, the configuration usually still reflects the state of the rollout year — new audiences, new countries, or new roles have been added, but the settings haven't.
Third, the market benchmark has shifted: what counted as a solid application process in 2018 is an abandonment trigger for many candidates today.
And fourth, the data quality erodes, because free-text fields and inconsistent definitions make every analysis vulnerable to challenge.
No single pattern on its own justifies a replacement — but when all four show up together, optimization alone usually isn't enough anymore.
What's easy to underestimate: this aging has a cost, even though it never shows up in any system budget. Every extra hurdle in the application flow lowers the number of completed applications. Recruiters spend time on workarounds instead of relationship-building and selection. Hiring managers build their own parallel processes because the system doesn't give them fast answers. And budget and channel decisions get made without reliable numbers, because nobody actually knows the real effort involved.
A Fortune 500 audit by InFlight, reported by SHRM, offers a benchmark worth pausing on: an average of 51 clicks before a submitted application, nine of them before the actual application form even starts, roughly five minutes of handling time on average — and at nearly half of the companies studied, the ATS vendor's logo shows up in the process instead of the company's own brand.
This benchmark is illustration, not proof, for any single company's situation. But it shows how easily a process drifts unnoticed — and why it's worth knowing your own numbers before you even start talking about a new system.
What You Actually Measure
A system isn't inherently good or bad. It either fits or it doesn't — fits a process that has to be defined first.
A solid evaluation therefore covers ten assessment fields: candidate experience, hiring manager experience, and recruiter experience on the experience side; process optimization, target audiences, and internal mobility on the process side; and talent relationship management, analytics and reporting, employer branding, and channel management on the impact side.
Together, these add up to nearly 80 individual checkpoints, each scored on a current-state scale from zero to four and weighted from one to three. The real pressure to act doesn't come from the score alone, but from the gap between weighting and current state: heavily weighted and poorly scored simply means — start here first.
The sequence matters: weight first, then score.
Otherwise the result ends up justifying whatever opinion already existed. Just as important is looking through four different lenses — candidate, hiring manager, recruiter, and organization — because these views regularly contradict each other.
Anyone who only asks recruiters ends up optimizing administration, not actual hiring outcomes. Across the maturity levels, the picture is usually uneven: a system can be well advanced on analytics while sitting at the lowest level on internal mobility, where it merely documents what's already happening anyway. That's exactly why the rating happens per field — not as a blanket score for the whole system.
A Factor That Now Also Decides
Since this summer, one more item belongs firmly on the checklist: the regulatory framework. AI-driven ranking and shortlisting in the application process count as high-risk under the EU AI Act, regardless of whether a human still makes the final call.
In late June 2026, the Council of the European Union pushed back the deadlines with the so-called Digital Omnibus package — but not the substantive requirements: prohibited AI practices have already applied since February 2025, transparency and labeling obligations kick in from August 2026, and the actual high-risk obligations for standalone systems follow in December 2027.
Anyone arguing internally with the old dates loses credibility fast. Logging, explainability, and documentation need to be built into the system, and the responsibility for that sits with the company using it — not solely with the vendor.
There's no acute time pressure, but there is a hard selection criterion: a system that has to prove compliance in 2027 should already be able to do it today, not retrofit it right before the deadline.
Four Options – and Five Decisions You Need to Make First
The evaluation points to one of four possible options — not automatically to replacement.
Option 1: Optimize
Optimize means configuration, process cleanup, and training at low effort — the right call when the gaps mostly come from usage and configuration.
Option 2: Extend
Extend adds specialized modules or add-on systems for individual fields — such as talent relationship management — while the core of the system holds up.
Option 3: Reconfigure
Reconfigure means: same product, but a complete rebuild of the configuration, when the product itself is a good fit but the grown setup can no longer be salvaged.
Option 4: Replace
Replace — a new system with a deliberately rethought process — is only the right answer once multiple fields are structurally unreachable, no matter how much you tweak the configuration.
Before any concrete system even enters the conversation, it's worth settling five decisions that the vendor would otherwise make for you:
How much standardization is actually wanted — one process for every country, or justified variants?
A single-vendor suite or specialized best-of-breed tools with integration effort?
How far should data migration reach — only active applications, or the entire talent pool?
Who owns ownership and governance for configuration and operations?
Where exactly does the line for automation run — which decisions can machines prepare, and which should they never make?
These five points are, regardless of which tool ends up chosen, the actual strategic core of the whole exercise. Leave them unresolved, and the vendor ends up deciding them by default — shaping the entire requirements list and, with it, the rest of the project.
An example makes the difference concrete: If the evaluation shows that candidate experience and recruiter experience are solid, but internal mobility and analytics sit structurally at the bottom, the obvious answer is rarely a full replacement. Often a targeted extension — a specialized module or a well-built reporting layer — is enough, while the proven core stays untouched. Only once several fields are structurally blocked at the same time — say, because the technical architecture doesn't allow for an open interface at all — does the picture shift toward replacement. That distinction between "uncomfortable but solvable" and "structurally unreachable" is exactly what surface-level manager frustration almost never captures cleanly.
What This Means in Practice
The cheapest way in isn't a tender, but a structured baseline assessment: gather the metrics, map the lived process, interview across all four perspectives — typically an eight-to-ten-week effort, with no commitment to a big system project. Only after that does the five-year math make sense, because the license price is the one line item that actually shows up in a quote — and usually not the biggest one. Implementation, data migration, change management, ongoing operations, and the productivity dip during the transition often add up to more.
As a rule of thumb from consulting practice, the license alone rarely accounts for more than a third of total costs over five years. That math should always include the counter-question: what does it actually cost to do nothing?
The system is rarely the actual problem. Most of the time, it's just the symptom of a process that has quietly drifted away from its own standard. In the end, the evaluation decides the right option — not the age of the software, and certainly not the last impressive demo.
Anyone who doesn't sort out their own process first ends up buying it a second time from the next vendor. The first small step stays the same: an honest, eight-to-ten-week baseline assessment, before any vendor name even comes up.
Sources
InFlight / SHRM – Audit of Fortune 500 application processes (51 clicks on average, 4:52 minutes of handling time, 48 percent with ATS vendor branding)
Appcast – Drop-off rate after clicking "Apply," reported by SHRM
Comments