Running an agency
ATS vs CRM in recruitment: what is the difference?
The two acronyms describe two halves of the same job. An applicant tracking system answers "where is this candidate in this role". A CRM answers "what is going on with this client". The mistake is treating them as two purchases.
What an ATS does
An applicant tracking system is built around the candidate and the role. Its records are people, their experience and documents, the roles you are working, and the candidacy that joins a person to a role: which stage they are at, who owns it, what happens next, and why they were rejected or withdrew. Applications from job ads land in it, CVs are parsed into it, and search runs over it.Its unit of work is the pipeline. A good ATS makes the state of every open candidacy visible, keeps the stage history append-only so that a dispute six months later has an answer, and refuses to let a candidacy exist with no owner and no next action.
What a recruitment CRM does
A recruitment CRM is built around the client. Its records are the businesses you work with, the people at them, the opportunities they give you or that you are pursuing, the terms you agreed, and the timeline of every call, email and meeting with them. Its unit of work is the relationship: who you know, what they told you, what they are likely to need next, and who at your agency owns that.Two things confuse the term. A general sales CRM can hold clients and contacts, but it has no idea what a placement, a guarantee period or a split fee is. And some recruitment products use "CRM" to mean candidate relationship management, meaning talent pools and nurture campaigns, which is a candidate-side feature rather than the client-side system this article is about.
Side by side
| Applicant tracking system | Recruitment CRM | |
|---|---|---|
| Built around | The candidate and the role | The client and the contact |
| Core records | Candidates, roles, candidacies, applications, documents | Clients, contacts, opportunities, terms, activities |
| Question it answers | Where is this person in this role, and what is next? | What is happening with this client, and who owns it? |
| Unit of work | The pipeline stage | The relationship timeline |
| Feeds in | Job ads, applications, CV parsing, search | Business development, referrals, mailbox and calendar sync |
| What done looks like | A placement | A signed terms of business and the next role |
| Most used by | Consultants filling roles | Consultants and owners winning and keeping clients |
| What it cannot answer alone | Which clients pay on time, and what was agreed | Which candidate went to which role, and why |
| Where they meet | The placement: a candidacy that belongs to a candidate and an opportunity, with a fee that belongs to a client’s terms | |
Why an agency needs both
In-house recruitment teams can run on an ATS alone, because the client is their own employer and the relationship is not the product. An agency sells the relationship. A candidate with no role to go to is a cost, and a client with no candidates is a promise; the business is the join between them, and the join has a name: the placement. A placement is a candidacy, which is ATS territory, priced under a client’s terms, which is CRM territory. Neither half can describe it alone.
That is also why the fee so often lives in a spreadsheet. When the candidate is in one system and the client terms in another, the placement fee, the guarantee exposure and the invoicing status have nowhere natural to sit, so they end up in finance, disconnected from the records that explain them.
What goes wrong when they are two systems
Double entry, first. The same contact is created in both, drifts in one, and nobody knows which is right. Then split history: the call where the client said they would never hire from a competitor again is in the CRM, and the candidacy that was rejected for that reason is in the ATS, with no line between them. Then ownership: a consultant leaves, and the client relationship, the open roles and the candidates in play are reassigned in two places by two people, or in one place and not the other.
Then the ones with legal weight. A candidate asks under the Privacy Act what you hold about them and who you disclosed it to; the answer is spread across two databases and an email archive. A client disputes an introduction; proving who introduced whom and when requires a record that spans both systems. And when you eventually leave one vendor, the export from each describes half of every placement, and the relationship between the halves was never written down anywhere that can be exported.
The case for one record system
The argument is not that one product should have more features. It is that the records should be linked rather than integrated. A client record that lists its opportunities, each opportunity listing its candidacies, each candidacy pointing at a candidate whose record shows every role they have been considered for and every conversation about them: that is one graph, and the questions above become one query instead of a reconciliation. One timeline, one ownership model, one permission boundary, one export that describes the whole placement.
The test for any system that claims to be both is simple. Open a client. Can you see the roles, the candidates in each, the terms, and the last conversation on one screen? Open a candidate. Can you see every role they have been considered for, who at your agency owned each, and what the client said? Open a placement. Does the fee know which terms it was calculated under? If any of those requires a second tab in a second product, it is two systems with a connector between them.
Recruited is built as the one graph: candidates, clients, contacts, opportunities, candidacies and placements are linked records in one workspace on every plan, with the communications timeline on both the candidate and the client, and the fee, split and guarantee recorded on the placement in the Deal Desk. The applicant tracking system and the recruitment CRM pages describe each half; the point of this article is that they are halves.