The three prerequisites for an ATS your team will use

Plenty of applicant tracking systems start out fine, then quietly become databases nobody updates a year or two later.

You know the shape. The system technically holds every role and every candidate, but the real work happens somewhere else. Hiring managers chase recruiters for status updates instead of looking them up. Interview feedback lands in email, a Teams thread, or a hallway conversation. Decisions get made in a meeting and recorded in the system days later, if at all.

The ATS ends up as a record of what already happened rather than the place hiring actually happens.

When that happens, the instinct is to blame the people. They need training. They need a nudge from leadership. They need to be told, again, that the process matters. So the team runs another enablement session, sends another reminder, and waits for the habit to stick.

It rarely does, but that's not a people problem.

The difference between process and product

People route around a system that doesn't fit the work, however much you train them. That isn't stubbornness. If the system makes the right thing slower than the workaround, the workaround wins, every time, and no amount of enablement changes that.

So adoption isn't a training problem. It's an architecture problem. Whether your team uses the system is decided long before anyone runs a session on it, by how the system was built. And when I look at why a system gets used or gets abandoned, it comes down to three things working together: flexibility, control, and ease of use.

Each one matters. And you need all three at once, because each pair, on its own, leaves you somewhere short of a system people actually use.

Flexibility, control, and ease of use

• Flexibility determines whether the system fits the real shape of your hiring. And as I argued in the first piece in this series, no organization runs one shape of hiring. You're hiring desk-based and deskless, corporate and high-volume, one region and another, a graduate cohort and a senior leader, each with its own process, its own stakeholders, its own pace. Flexibility determines whether one system can hold all of that, or whether it fits one shape well and forces the rest into a mold that doesn't suit them.
• Control determines whether the organization can trust what's in the system. Permissions, structure, approvals, compliance steps, a clear record of who did what and when. It's what keeps the data consistent and clean as more people work in it, rather than letting it sprawl into something nobody can rely on.
• Ease of use determines whether a hiring manager who touches the system twice a month can do what they need without being trained, annoyed, or sending a message in Teams instead. It's the difference between a system people reach for and one they avoid.

Plenty of systems deliver two of these well. Almost none deliver all three.

Two of three isn't enough

Take flexibility and control without ease of use. You get a system that can model every shape of hiring and govern it tightly. You also get a system the hiring manager opens once, finds baffling, and never opens again.

Highly configurable systems often land here. They can do almost anything in the hands of an administrator who lives in them every day. Most of the organization doesn't. The capability is real, but the adoption never follows, so the workarounds start and the data thins out.

Take ease of use and control without flexibility. You get a system that's pleasant to use and tightly governed, but built around one shape of hiring. It works well until part of the organization needs something different. Then the spreadsheets appear, the point solutions arrive, and the picture starts fragmenting again.

Take flexibility and ease of use without control. You get a system people enjoy using and one that can accommodate almost any process. But without enough structure, records drift, fields become inconsistent, and confidence in the data erodes. People are active in the system, but the information coming back out becomes harder to trust.

Each combination solves a real problem. None solves all of them. That's why two out of three so often ends up looking like adoption while producing many of the same outcomes as no adoption at all.

Three together is what produces adoption

Put the three together and something different happens. A system flexible enough to fit every shape of hiring, controlled enough to stay clean as it scales, and easy enough that an occasional user reaches for it without a second thought, is a system the whole organization actually works in. Not because they were told to. Because it's the path of least resistance, which is the only kind of adoption that lasts.

And that's the part that matters beyond the obvious. Because adoption shouldn't be the finish line, it's having something that produces a complete, current, trustworthy record of how your organization hires, because the work is finally happening in one place instead of leaking into inboxes and spreadsheets.

I made the case in an earlier article that clean, comprehensive data is what automation and AI need to run on, and that you don't get that data by buying a cleverer model. You get it by getting the whole organization onto one system. These three prerequisites are how that happens. They're the difference between a system everyone uses and a system that records the leftovers.

Where adoption is won

If adoption is decided by whether the system fits the work, then it's decided most sharply at the place the work is hardest to capture: the hiring manager.

This is the bit most applicant tracking systems get wrong. Most ATSs treat hiring managers as stakeholders. People who need a notification, a link to approve, a status they can glance at. But they're not stakeholders in hiring. They're power users. The decisions that determine whether a hire is good, the read on a candidate, the comparison between two finalists, the reason one interview landed and another didn't, all live with them. If they don't do that work in the system, the system doesn't have a full picture of what's happening, and neither does anyone downstream relying on it.

That's exactly it. The recruiter can run the process beautifully and still only capture half the story if the managers aren't in the system, because the half that carries the judgment is theirs to record.

So the hiring-manager experience isn't a nice-to-have at the edge of the product. It's where adoption lives or dies, because it's where the most valuable and the most easily lost information sits. A system that an occasional, reluctant, busy manager will genuinely use is a system that captures the part of hiring everything else depends on.

Why all of this is worth getting right

So a system that delivers flexibility, control, and ease of use together isn't a collection of nice features. It's the precondition for a chain that runs all the way down. Get the three right and the whole organization uses the system. Because the whole organization uses it, you have a complete and accurate picture of how you actually hire.

Because you have that picture, you can put automation and AI on top of it and trust what they give you. And in a world where every talent team is being asked to do more with fewer people, that chain is the difference between leverage and a faster way to process an incomplete picture.

We think about this constantly, because building the ATS is the day job. We didn't set out to win on any one of the three. Most systems pick two, and you can feel where they compromised. We set out to deliver all three at once, because that's the only combination that earns the adoption everything else depends on.

You can't train your way out of an architecture problem. But you can choose a system that doesn't create one.