ATS or Recruitment CRM: Two Different Jobs

TL;DR

• The core decision: whether your problem is managing people who applied or staying in touch with people who haven't.
• When doing nothing is right: when roles fill from applications and nobody is maintaining a list of interesting people anyway.
• What has to be true: somebody is actually going to contact the people you store, or the list is just storage.
• How the options split: by whether the record is attached to a role or attached to a person.
• Decision rule: if you can't name who will send the next message, you don't need a CRM yet.
• Outcome to expect: fewer good people lost between searches, and an honest answer about which roles you can fill from a pipeline.

The Candidate You Meet Two Years Early

Somebody excellent applies for a role and doesn't get it, because somebody else was slightly more suitable. Everybody involved agrees they were strong. The rejection goes out.

Eighteen months later, a role opens that they'd be ideal for. Nobody remembers them. Their record sits in the system attached to a search that closed, in a stage called rejected, alongside several hundred other people. Technically it's all still there. Practically it's gone, because nothing about how that data is organised makes it findable by anything other than the role they applied to.

Meanwhile a recruiter has a private spreadsheet of interesting people they've met at events, and a folder of conversations that never went anywhere because no role was open at the time. That list is real, useful, and lives entirely in one person's ownership.

Recommended Tools

Best tools for Applicant Tracking (ATS)

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

This is the gap a recruitment CRM is supposed to fill, and it's worth being precise about what the gap actually is, because the two products get described as though one is a more advanced version of the other.

An applicant tracking system organises around a role. Somebody applied to this thing, they are at this stage in that search, here is what happened. A recruitment CRM organises around a person. Here is somebody, here is every conversation anybody has had with them, here is what we know, here is when we last made contact.

Those are different shapes. Not different tiers. Attaching a person to a role makes the search manageable and makes the person disappear when the search closes. Attaching a history to a person makes the relationship durable and tells you nothing about where anybody is in a current process.

So the question is not which product is better. It's whether you have a problem the second shape solves, and whether anybody is going to do the work that shape assumes.

When You Genuinely Do Not Need to Act Yet

Your current setup is genuinely fine. Roles fill from applications, the people you want tend to apply, and nobody is maintaining a list of interesting people because nobody has needed to. A CRM with nothing flowing into it is an empty database with a subscription attached.

Friction is starting to show. Somebody strong was rejected and you wished you could find them again, or a recruiter mentioned a private list, or a role opened that you're fairly sure you'd met somebody for. These are genuine signals and the first fix is usually smaller than a purchase: a way to mark somebody worth revisiting, so they're findable by something other than the role they applied to.

It has become a real cost. Roles are genuinely hard to fill from inbound applications, you're paying repeatedly to reach the same population, or the same searches run every year and each one starts from nothing. Now there's a case, and the case is about relationships rather than storage.

The edge case that forces it. You hire into a market small enough that you'll encounter the same people repeatedly, or you plan roles far enough ahead that building interest before the opening is realistic. Both make a person-shaped record genuinely necessary. Note that holding data about people who never applied raises questions about basis and retention that differ by jurisdiction, so establish what applies where you operate with local advice before you start building a list.

Five Questions This Reader Asks at 11pm

What is a recruitment CRM, in plain terms? A record organised around a person rather than a role, holding every interaction anybody has had with them, whether or not they ever applied to anything. The point is durability: the record survives the closure of any particular search, so somebody you met two years ago is findable when a relevant role opens.

Isn't that just the talent pool feature in our ATS? Sometimes, and it depends on whether the feature is a tag or a relationship. A talent pool that lets you label rejected candidates and search the labels is useful and it's still role-shaped: the person is in your system because they applied. A genuine CRM lets somebody exist in the record having never applied, with a contact history that has nothing to do with a requisition.

Do we need both? Most organisations need one properly and a light version of the other. If almost all your hiring comes from applications, you need a tracking system and a way to revisit past applicants. If you're regularly approaching people who aren't looking, you need relationship management and you still need a pipeline for when they enter a process. What doesn't work is buying both and maintaining neither.

What do we do with rejected candidates? Decide deliberately, because the default is that they accumulate invisibly. The useful distinction is between unsuitable and nearly right, and most systems don't capture it unless you make them. Somebody rejected because the role wasn't a fit is a different proposition from somebody rejected because one person was marginally better. Separately, how long you may hold applicant data and on what basis differs by jurisdiction, so establish that locally.

How do we know if a CRM is working? By whether anybody is contacted, not by how many records exist. The failure mode is a well-populated database nobody opens, and it's common enough to be the default outcome. If nobody can name the last person they contacted from it, you have storage rather than relationship management.

What Each System Is Actually Modelling

The products differ because the underlying concepts differ. Seeing that makes most of the confusion disappear.

The last row is the one that determines whether a CRM survives. A tracking record is a snapshot of something that finished, so it doesn't decay in any meaningful way. A relationship record decays continuously: people change jobs, change what they want, and stop being reachable. A CRM that nobody touches for a year is a list of where people used to work.

The fourth row explains the original problem. When a search closes, the tracking system does exactly what it should and files everything under a completed search. That's correct behaviour and it's why good people become unfindable, because the organising principle is the role and the role no longer exists as a live thing.

Five Diagnostic Questions You Can Self-Assess Against

Can you find somebody without remembering which role they applied to? Try it. Think of a strong candidate from a search last year and see how quickly you can retrieve them. If the route involves remembering the role first, your data is role-shaped, which is fine and is the thing a CRM changes.

Does anybody keep a private list? Ask. Almost every recruiting team has one, and it's the clearest evidence that the official system doesn't hold something people need. The list also usually holds the interesting part: why this person mattered, what they said, when to try again.

Who would send the next message? This is the question that decides whether a CRM is worth anything. Relationship management is work somebody does, repeatedly, with no immediate reward. If nobody has capacity for it, the system will fill up and go quiet.

How many of your hires came from somebody who'd applied before? Check, because the answer tells you whether the population you're storing has ever converted. If people you rejected have gone on to be hired later, the pattern is real and worth building for. If none ever have, be honest about whether they would.

What's your basis for holding people who never applied? Not a technical question. Holding contact records about people who have no relationship with you raises questions about what you may keep, on what basis and for how long, and the answer differs by jurisdiction and has been changing in several places. Establish it with local advice before the list grows.

Six Ways Teams Try to Cover Both Jobs, Reviewed

Using the tracking system as a CRM by keeping rejected candidates

Tagging past applicants and searching the tags when a new role opens. It earns its place because it costs nothing, uses a system you already have, and addresses the most common version of the problem, which is losing people you already met.

Where it falls short is that the record stays role-shaped. The person is in your system because they applied to something specific, their record reflects that search, and nothing prompts anybody to maintain it. Tags also decay: whoever set the convention leaves, people tag inconsistently, and within a couple of years the labels mean different things to different people.

Worth doing, and worth being honest about its ceiling. It finds past applicants; it doesn't build relationships with people who never applied.

One refinement makes tagging considerably more durable: record the reason in the tag rather than a quality judgement. A label meaning strong is uninterpretable two years later, because you cannot reconstruct strong at what, compared with whom, for which role. A label naming the specific thing the person was good at survives, and it is also the thing you will actually search on when a role opens.

A separate CRM alongside the tracking system

Two systems, each doing its own job, with candidates moving from one to the other when they enter a process. It earns its place because each product is shaped for its actual purpose, and the CRM doesn't have to pretend a person is an application.

Where it falls short is the boundary. Somebody exists in both, the records diverge, and it becomes unclear which holds the current version of anything. The handover in either direction is where effort leaks: a candidate entering a process should carry their history, and frequently arrives as a fresh application with none of it.

If you run both, decide which is authoritative for contact details and history, and make the handover a deliberate step rather than a retype.

Decide the direction too, because both are defensible and only one can be automatic. Pushing from the relationship system into the pipeline when somebody applies is the common arrangement and it risks overwriting fresher information the candidate just supplied. Pulling the history across on demand keeps the application authoritative and requires somebody to remember. Neither is wrong, and the failure is having no answer and discovering it mid-search.

A combined platform claiming both

One product presenting both capabilities. It earns its place on the seam, which it genuinely removes: one record, no handover, no question about which system is right.

Where it falls short is that one side is usually thinner, and which one varies. A product built as a tracking system with relationship features added tends to treat a contact as an applicant who hasn't applied yet, which shows up in small ways: the record wants a role, the workflows assume a pipeline. A product built the other way round tends to have a weaker pipeline.

The way to tell is to ask what happens to somebody interesting when no relevant role is open. If the answer involves a placeholder requisition, it's a tracking system wearing a CRM's clothes.

A second question separates them just as quickly: can two people who both know somebody see each other's history with them. Relationship management assumes several people accumulate context about one person over time, and a product built around applications frequently attaches notes to a specific application rather than to the person, so the context fragments across whichever roles they happened to apply to.

A spreadsheet of interesting people

Somebody maintains their own list. It earns its place more than central teams admit, because it holds the thing the official system doesn't: why this person mattered, what they said, when to try again. It's also genuinely low-friction, which is why it survives.

Where it falls short is ownership and continuity. The list belongs to one person, goes with them, and is invisible to everybody else. It also sits outside whatever data arrangements you've designed, which matters because it's personal information about people who may not know they're on it.

Find these rather than banning them. Ask what each holds that the system doesn't, and treat that as the requirement.

Expect the answer to be about context rather than contact details. The sheet usually records why somebody mattered, what they were looking for, and when it would be sensible to try again, which is precisely the material the official record has nowhere to put. Contact details are the easy part and the part everybody assumes is the point.

A professional network used as the pipeline

Keeping track of people through whatever network they're on, using its own saving and messaging. It earns its place on reach and currency: the data maintains itself, because people update their own profiles, which is something no CRM achieves.

Where it falls short is that you don't own any of it. The connection, the history and the ability to reach somebody all depend on a relationship with a platform rather than with a person, and access terms and costs are outside your control. It also usually belongs to an individual recruiter, so it leaves when they do.

Use it as a place to find people. Don't let it be the only place their history lives.

The dependency becomes visible at the worst moment, which is when a recruiter leaves. Their connections, their message history and their sense of who is worth approaching all leave with them, and the organisation discovers it had no relationship with anybody, only an employee who did. Writing the context somewhere you own, even briefly, is the difference between a team asset and a personal one.

Doing no relationship building at all

Roles open, get advertised, and fill from whoever applies. It earns its place more often than the market suggests, because for a large number of organisations it works. If your roles attract enough suitable applications, building relationships in advance is effort with no return.

Where it falls short is at the edges: senior roles, scarce skills, or a market small enough that the same people keep appearing. In those cases the search starts cold every time, and the cost shows up as time-to-fill and agency spend rather than as a visible gap.

Be honest about which of your roles are which. Most organisations have a handful where this matters and a majority where it doesn't.

The useful exercise is to list the roles you filled in the last year and mark which ones took an uncomfortably long time or needed external help. That short list is your actual case for relationship building, and it is usually small enough that a proper list for those roles alone is achievable by one person without any purchase at all.

The Decision Table

The eighth row is the one to be honest about, because it's the most common reason these purchases disappoint. A CRM is a commitment to ongoing contact work that produces nothing measurable for months. If no named person has capacity for that, the system will accumulate records and go quiet, and the eventual conclusion will be that CRMs don't work here.

The second row is where most organisations actually are, and the fix is much smaller than the market implies. A convention for marking somebody worth revisiting, applied consistently, recovers most of the value for none of the cost.

The People Who Fall Between Them

Three groups sit awkwardly across both systems, and how you handle them is a reasonable test of whether your setup works.

The nearly-right candidate. Somebody rejected because one person was marginally better. They're the highest-value population you hold and most systems treat them identically to somebody who was never suitable, because the rejection captured an outcome rather than a reason. Recording the difference at the moment of rejection costs seconds and is almost never done.

The former employee. Somebody who left on good terms and might return. They exist in the employee record rather than the candidate record, which means recruiting never sees them, and nobody is maintaining a relationship because they're not a candidate. Whether you can approach former employees and on what basis is worth establishing, since obligations differ by jurisdiction and some arrangements carry terms.

The long conversation with no role attached. Somebody a hiring manager has known for years, or a contact from an event, or an introduction from a colleague. There's genuine relationship here and nowhere to put it, so it lives in one person's memory and their message history.

What these three share is that none of them is an applicant, which is why an applicant tracking system handles them badly. It's not a product failure; it's the data shape doing exactly what it's designed to do.

The practical response doesn't require buying anything. Decide where each group lives, make sure somebody other than one individual can find them, and record enough context that the record still makes sense in a year. A name with no note is not a relationship, it's a contact detail, and contact details go stale faster than anybody expects. The note does not need to be long. What they do, what they said they wanted, and roughly when it would make sense to speak again is enough to make the record usable by somebody who was not in the conversation.

One caution about the second group. Re-approaching former employees is one of the highest-yield things most organisations don't do systematically, and it's also the one where people are most likely to be uncomfortable being contacted. Whether and how you hold their details for recruiting purposes is a question with a local answer, so establish it rather than assuming the employee record covers you.

There is a practical wrinkle too. The useful information about a former employee is what their manager thought and whether anybody would want them back, and that is exactly the material nobody writes down at departure because the conversation is awkward. A single line recorded at the time, noting whether the organisation would re-employ somebody, is worth more than any amount of contact data collected later.

Where This Goes Wrong

The first row is the failure that makes this whole category look worse than it is. A CRM is a habit with software attached, and buying the software without establishing the habit produces a visible, expensive, empty database. The habit can be started without any purchase, which is the honest sequence.

The fourth row costs the most in practice. When somebody from the relationship side enters an actual process, everything anybody knew about them should travel with them. In most setups it doesn't, so the interviewer reads a fresh application from somebody the organisation has been talking to for a year.

What to Put in Writing

The second row is the cheapest high-value change available here, and it's the one to make even if you buy nothing. A rejection that records whether somebody was unsuitable or nearly right converts a dead record into a findable one, and it takes no longer than the rejection already takes.

Questions to Ask Before You Commit

On the work. Who sends the next message? A bad answer is the team.

On shape. What happens to somebody when no role is open? A bad answer involves a placeholder role.

On rejections. Can you tell the nearly-right from the unsuitable? A bad answer is by reading the notes.

On the boundary. What travels when a contact applies? A bad answer is their CV.

On decay. When was that record last touched? A bad answer is at creation.

On basis. Why are we allowed to hold this person? A bad answer is that they are interested.

On habit. Which system gets checked when a role opens? A bad answer is neither.

What Getting This Wrong Costs

The first cost is the search that starts from nothing every time. Organisations that hire repeatedly into the same market meet the same people across years, and without a durable record each search begins as though none of that happened. The cost appears as time and as external spend, and it's rarely attributed to the absence of a list, because nobody can see the alternative.

The second cost is the strong candidate who was almost right and is now unreachable. That person was assessed, was nearly good enough, and would in many cases take a different role or the same role later. Losing them isn't a failure of assessment; it's a failure of filing, and it happens because a rejection is recorded as an outcome rather than a judgement.

The third cost is the database that becomes a liability rather than an asset. A CRM full of contact records about people with no relationship to you, held on no stated basis and never reviewed, is personal data accumulating outside whatever arrangements you designed. What you may hold, for how long and on what basis differs by jurisdiction and by how the contact was obtained, so this is a question with a specific local answer rather than a general one.

So before considering a product, answer two things. Whether anybody will actually do the contact work, because a CRM without that is storage. And whether your rejections currently distinguish the nearly-right from the unsuitable, because if they don't, the population you'd be storing is already indistinguishable and a new system won't fix it.

A third question is worth adding if you are already running both systems: which one does somebody check first when a role opens. If the honest answer is neither, and the search starts with an advert every time, then the relationship work is not feeding the process regardless of what is stored, and the gap is a habit rather than a tool.

When You Are Ready to Go Further

None of this needs a purchase to start. A convention for marking somebody worth revisiting, a note at rejection saying which kind of rejection it was, and one person who spends an hour a fortnight contacting people from that list will tell you within a quarter whether relationship building works in your market.

If it does, the case for a real CRM builds itself, because you'll be able to point at the specific thing your current system can't hold. If it doesn't, you've learned that cheaply and you should keep the tracking system and stop reading about the other one.

The step after that, if you do run both, is the handover. Make sure that somebody entering a process carries everything anybody knew about them, because the moment a relationship becomes an application is exactly when the history is most useful and most likely to be dropped.

HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling actually supports here, our comparison work is one place to start.

Frequently Asked Questions

One system files people under a role. The other files a role under a person. Pick for the problem you actually have.

And if nobody will do the contacting, neither one helps.