Recruitment CRM Systems vs ATS: Which Problem to Solve

Your last hire took eleven weeks and you have no intention of repeating that, so this quarter there is finally budget to "get a proper system". You open four vendor sites and the copy is close to interchangeable: pipelines, candidates, stages, automation, analytics, dashboards. One calls itself an applicant tracking system. One sells recruitment crm systems. One calls itself a talent platform and refuses to say which of the two it is. The fourth only reads and scores resumes and looks suspiciously narrow next to the others. By the third demo you cannot remember which product showed you which screen, and you are one step away from choosing on price and on whichever salesperson answered emails fastest.

Here is the short version before the detail. These are three different products solving three different bottlenecks, and which one you should buy is decided by which bottleneck you actually have — not by which category has the most features. A recruitment CRM exists because not enough of the right people know about your roles. An ATS exists because the people who did apply get lost between an inbox, a spreadsheet and a hiring manager who does not check either. A screening tool exists because too many people applied and nobody has the hours to read them at a consistent standard.

Buy the wrong one and nothing bad happens immediately, which is what makes the mistake expensive. You get a login, an onboarding call, a migration, and a quarterly invoice. Six months later the same problem is still there, and now it has a tool sitting next to it. This article is a category comparison and a buying guide: what each of the three actually does, how to diagnose which one your team needs from the symptom you are feeling, where the categories overlap and where "integration" quietly means "export a CSV", when a small team honestly needs none of the three, and what it costs when you buy a talent pool product to solve a pile of two hundred unread CVs.

What are recruitment CRM systems, and how are they different from an ATS?

That is the whole distinction in three sentences, but it is worth slowing down, because the difference is not a feature list. It is a difference in which population of people the software is built around, and everything else follows from that.

The recruitment CRM: built around people who have not applied

CRM stands for candidate relationship management, and the recruiting version borrowed the idea wholesale from sales. In sales, a CRM holds people who might buy something one day: leads, contacts, accounts, the history of every touch, and campaigns that keep you present in someone's mind until the moment they are ready. Swap "might buy" for "might join" and you have crm recruitment: the same machinery, pointed at people who might work for you one day.

The unit of work in a recruitment CRM is a person, not a vacancy. A record exists for a senior data engineer you met at a meetup in March even though you have no data engineering role open and might not until next year. The record accumulates: where you found them, what they work on, what they said about relocating, that they mentioned a two-year vesting cliff in November, which of your emails they opened.

The core capabilities that follow from that shape:

• Talent pools and segments. Groups of people organised by skill, seniority, location, language, or a past interaction such as "reached final round in 2025 and we hired someone else".
• Sourcing pipelines. Outbound stages that look like sales stages: identified, contacted, replied, in conversation, interested, converted to applicant.
• Nurture campaigns. Sequenced messages that keep a pool warm without anyone remembering to send them, plus the tracking of who engaged.
• Event and campaign attribution. Which career fair, referral push, meetup or content piece actually produced conversations.
• Re-engagement of past applicants. The silver medallists from previous rounds, which is the single most underused asset in most hiring functions.

The question a recruitment CRM answers is: who could we talk to about this role, and how warm are they right now? If nobody good is applying, this is the category that addresses the actual gap.

The ATS: built around people who already applied to one specific opening

The unit of work in an ATS is an application — a person attached to a vacancy at a point in time. The same human applying to two of your roles is usually two applications, and that is deliberate: the record has to be tied to an opening, because the decisions, the timings and the compliance obligations are all per-opening.

What follows from that shape is a container, a state machine and a record: applications collected in one place, statuses moving through stages, and an audit trail of who did what and when. That is the part regulators care about — consistent, job-related, documented selection procedures — and it is genuinely valuable even when it feels like admin.

We covered that category in depth in what an applicant tracking system actually does, so this article will not repeat it. The one line worth carrying forward is the honest limit: an ATS knows a file exists and where it sits. It usually does not know what is inside it beyond a few parsed fields.

The screening tool: built around one role's requirements

The unit of work in a screening tool is a judgement: this document, against these requirements, produces this score with this evidence. It does not care about your nurture campaigns and it is not trying to be the system of record for your hiring. It reads what is inside the file and forms a defensible view of fit.

A screening tool that is worth the name does four things: turns your job description into explicit criteria you can edit, applies weights you set rather than weights it invented, scores every candidate against the same criteria in the same sitting, and shows the line from the document that produced each score. Take away the last one and you have a random number generator with good manners.

The question it answers is: of the two hundred people in front of me, which twenty are worth an hour of a hiring manager's time, and can I explain why?

The three-way comparison, side by side

Put the categories in one table and the buying decision gets much less mysterious. Read the "what it cannot do" row first — that row is where most bad purchases are made, because nobody asks the question in a demo.

	Recruitment CRM	Applicant tracking system	Screening tool
What it answers	Who could we approach about this role, and how warm are they?	Where is every applicant right now, and what did we do with them?	Of the people who applied, who fits the requirements and on what evidence?
What it stores	People, talent pools, outreach history, campaign engagement, sources	Applications, files, stages, interview feedback, decisions, audit trail	Criteria, weights, thresholds, per-criterion scores, quoted evidence
Unit of work	A person, over years	An application, over one hiring round	One document against one criteria set
Time horizon	Before the role exists	From application to offer	The three days after applications close
What it cannot do	Tell you whether an applicant is any good; run a compliant selection record for one opening	Read inside a CV and form a view; find people who never applied	Store your pipeline, schedule interviews, keep your talent pool warm
Who it suits	Teams hiring for scarce skills, agencies, employers with a strong brand to maintain between roles	Any team with more than a handful of open roles, multiple reviewers, or compliance obligations	Teams facing high applicant volume per role, repeated roles, or several reviewers with different bars
Symptom it fixes	Too few of the right applicants	Applicants lost inside the process	Too many applicants, no time to read them

Notice that the three "what it cannot do" cells barely overlap. That is the strongest argument that these really are separate categories rather than three names for the same thing. A product can of course cover two of the three columns, and plenty do — but covering a column and being good at it are different claims, and the demo will not distinguish them for you.

Diagnose by bottleneck before you look at a single product

The reliable way to choose is to stop thinking about categories and start measuring your own funnel. You are looking for the one number that is embarrassing. Almost every hiring team has exactly one, and it points straight at the category you need.

Step 1: count the top of the funnel

For your last three closed roles, write down how many applications you received in total and how many of those were plausible on paper — not great, just plausible enough that you would have taken a call.

If the plausible count is small in absolute terms, you have a sourcing problem. No amount of process improvement downstream fixes an empty top. This is where recruitment crm systems earn their money, and also where a better job ad, a referral push, or a different channel might fix it for free.

Step 2: find where people stall

Take the same three roles and mark the date of every stage transition. Then find the longest gap. Not the longest stage — the longest gap where nothing happened to a candidate who was still in play.

If the biggest delays are people sitting untouched between stages, if candidates drop out saying they took another offer, if you have discovered someone was never contacted at all, or if two reviewers have different lists of who is still live, you have a process and record problem. That is an ATS problem, and it stays an ATS problem even if your ATS is technically a spreadsheet with good intentions. Measuring these gaps properly is its own discipline, which we went through in recruiting metrics that matter.

Step 3: count what nobody read

This is the uncomfortable one. For your last high-volume role, how many applications were genuinely opened and considered against a written standard, and how many were skimmed in ten seconds, or never opened at all because the shortlist was already full?

If the honest answer is that a large share of the pile was never really read, you have a screening capacity problem. It does not matter how good your pipeline hygiene is; the decision quality at the widest point of the funnel is close to random, and every downstream improvement is polishing a shortlist that was assembled by fatigue.

Step 4: check who disagrees with whom

Have two people independently screen the same ten CVs against your current standard, without talking. Compare the shortlists. If they overlap on eight or nine, your standard is real. If they overlap on three, you do not have a standard — you have two people with private preferences, and buying any software before writing the standard down just automates the disagreement.

The decision tree, in order

1. Are enough qualified people applying? If no — fix sourcing first. That means a recruitment CRM only if you are already doing outbound and losing track of it; if you are not doing outbound at all, a tool does not create the activity. Buy the habit before the software.
2. If yes, do applicants move through the process without stalling or vanishing? If no — fix the container. An ATS, properly configured, with someone accountable for stage hygiene.
3. If yes, is every applicant read against a written standard? If no — fix screening. Write the criteria and weights first, then decide whether the volume justifies a scoring tool.
4. If yes to all three, do your final shortlists actually produce good hires? If no, your problem is not tooling at all. It is that your criteria do not predict performance, and the fix is a rubric review with the hiring managers, not a purchase.

Run the tree honestly and most teams stop at step two or three. Very few teams that are struggling to hire are struggling because their candidate relationship management is weak — but that is often the software they buy, because it is the category with the most exciting demo.

ATS vs CRM: where the overlap is real and where it is marketing

Anyone who has sat through a few demos knows the categories are blurring. That is true, and it is not a reason to ignore the distinction. Here is what the overlap actually looks like in practice.

Most ATS products now include a shallow CRM

Nearly every modern applicant tracking system will offer you tags, a searchable archive of past applicants, saved segments and some kind of bulk email. That covers the most valuable slice of candidate relationship management for a small team: re-engaging people who already applied. If your talent pool ambition is "email the six strong runners-up from March when the role reopens", your ATS almost certainly does that already, and buying a second product to do it is spending money to avoid learning a feature.

Where the shallow version runs out is genuine outbound at volume: sequenced multi-step campaigns, engagement tracking, source attribution across channels, and a person-centric record for people who have never applied to anything.

Most CRM products now include a shallow ATS

Symmetrically, sourcing-first products add stages, application forms and a status field, and can technically run a hiring round. What tends to be thin is the compliance side: structured interview feedback tied to a stage, immutable decision records, retention and deletion rules per opening, and the kind of audit trail you would want to produce if a rejected candidate asked how the decision was made.

Screening rarely lives properly inside either

Both categories now advertise "AI matching" or "smart ranking". Before you rely on it, ask one question: show me the sentence in the CV that produced this score. If the answer is a percentage with no traceable evidence, you are looking at keyword overlap dressed up. Keyword overlap rewards candidates who mirrored your job ad and punishes career changers and people who write plainly about the same work. The mechanics of what parsing can and cannot recover from a document are worth understanding before you trust any of it, which is what resume Parser vs Resume Screening: Extracting Text Is Not Ju goes into.

What "integration" usually means

Assume nothing from a logo on an integrations page. There are four common realities, and they are very different to live with:

• Real two-way sync. A person exists once; changes in either system appear in the other. Rare, and worth paying for.
• One-way push. The CRM can create an applicant in the ATS when someone converts. Usually enough, as long as you know which system is the source of truth for each field.
• Manual export and import. A CSV, run by a person, when they remember. This is where duplicate records are born.
• "Available via API". Means someone will have to build it, and that someone is you.

The duplicate record problem deserves a line of its own, because it is the standard failure of running two systems. A person is nurtured in the CRM for eight months, applies through the careers page, and becomes a fresh applicant with no history in the ATS. The recruiter, seeing a blank record, treats them as a cold applicant. Every hour of nurturing is thrown away at the exact moment it was supposed to pay off. Before you buy the second system, decide which one holds the identity of a person and how the other one links to it.

The data question that applies to CRMs and not to ATS products

There is one genuine legal asymmetry worth knowing. An ATS holds data that people handed you deliberately when they applied. A recruitment CRM often holds data about people who never asked to be in your database — sourced from public profiles, collected at an event, or added from a referral.

Under the GDPR, that difference matters. Article 14 sets out what you must tell someone when you obtained their personal data from somewhere other than from them, and there are time limits on doing so. Article 5(1)(e) limits how long you keep personal data to what is necessary for the purpose. A talent pool that has quietly accumulated five years of contacts nobody has spoken to since is a retention question waiting to be asked. None of that makes a recruitment CRM a bad idea; it makes "who is in this pool, on what basis, and for how long" a question you answer at setup rather than during an audit.

The cost of buying the wrong one

Abstract advice does not change purchasing decisions, so here is the arithmetic. Everything below is an invented example built to show the method — it is not data from any real team, and you should redo it with your own numbers.

Say you run one open role for four weeks. It attracts 200 applications. You keep a time log for the round and it comes out like this:

Activity	How it adds up	Hours
Writing the ad, posting, outbound outreach	Ad plus 40 outbound messages	4
Filing, chasing status, answering the hiring manager	Spread across four weeks	5
Reading and shortlisting	200 CVs at 6 minutes each	20
Scheduling	12 interviews, email ping-pong included	3
Interviews and write-up	12 interviews at 45 minutes	9
Total for the round		41

Now apply each purchase to that log and ask what it touches.

Buy the recruitment CRM. It addresses the 4-hour bucket, and it addresses it well: better lists, sequenced outreach, no more forgetting to follow up. But 4 hours is under a tenth of the round. Worse, a CRM is not a labour-saving device on day one — it is a labour-creating device, because someone has to build the pools, write the sequences and keep the records current. In the first quarter your total hours go up, and the 20-hour reading pile is untouched. Six months later the complaint that started the purchase — "hiring takes forever" — is exactly where it was.

Buy the ATS. It addresses the 5-hour admin bucket and the 3-hour scheduling bucket. Call it 8 hours of the 41, and the record quality improvement is real and permanent. If the round had 40 applications instead of 200 this would be the right purchase by a distance. With 200, the reading pile is still there, and the pile is where the decision quality lives.

Buy the screening tool. It addresses the 20-hour bucket, which is both the largest single line and the one where the standard degrades most as you get tired. It does nothing for scheduling, nothing for your talent pool, and nothing for your compliance records. If your bottleneck is that only 20 people applied, this purchase is close to worthless.

The chart makes the failure mode obvious. If reading is your tallest bar and you buy a product aimed at the shortest bar, the most optimistic outcome is that you removed a tenth of the work. The realistic outcome is worse, because the wrong purchase carries three costs that never show up on the invoice.

The first is migration and setup, paid in your own hours: importing history, configuring stages, training people, and the weeks where half the team uses the new thing and half still uses the old one.

The second is the false sense that the problem is handled. Once there is a system with the problem's name on it, the problem stops being discussed at the leadership level. Nobody reopens the question for a year, because reopening it means admitting the purchase was wrong.

The third is budget crowding. Most small teams get one tool purchase per year through approval. Spending it on the wrong category does not just fail to fix the bottleneck; it removes your ability to fix it until the next budget cycle.

So the practical test before signing anything: write down the number of hours per round the purchase should remove, or the number of extra qualified applicants it should produce, and how you will check in ninety days. If you cannot write that sentence, you have not identified the bottleneck yet.

When a small team needs none of the three

This section will not be in any vendor's deck, so here it is plainly. There is a real range where buying anything is the wrong move.

You probably need none of the three if all of these are true:

• You hire fewer than roughly six people a year, in ones and twos rather than in bursts.
• Each role draws a few dozen applications, not a few hundred.
• One person owns hiring end to end, so there is no handoff to lose things in.
• Nobody has ever asked you to reconstruct why a specific candidate was rejected.

In that situation a shared folder, one spreadsheet with a fixed set of columns, and a written scoring rubric will beat most software, because the overhead of a system exceeds the coordination it saves. A person with a written rubric can screen forty CVs in an afternoon at a perfectly consistent standard, and no product will improve on that judgement.

What you should do instead of buying is the part everyone skips: write the standard down anyway. Eight to sixteen criteria per role, sorted into must-have, important, preferred, basic and flexible, each with a weight, and a pass threshold agreed before anyone reads a file. That artefact costs an afternoon, it makes your manual screening consistent immediately, and it is also the exact input any screening product will ask for later. Teams that write the rubric first and buy second get value in week one. Teams that buy first spend three months discovering that the software cannot tell them what "good" means for their role.

The honest warning signs that you have outgrown the folder-and-spreadsheet setup: two or more people screening in parallel, a role that reopens every quarter, a single round breaking a hundred applications, or the first time somebody asks a question about a past decision that you cannot answer from your records. Any one of those is a real trigger. "We feel unprofessional without a system" is not.

A buying process you can run in two weeks

If the diagnosis says buy, run it like this. The order matters more than the speed.

1. Days 1–2: write the bottleneck sentence. One sentence, with a number in it, naming the stage that is broken. For example: "For our last three roles we received an average of 180 applications and read fewer than 60 against any written standard." If you cannot put a number in it, go back and measure.
2. Days 3–4: write the criteria for one live role. Groups, weights, pass threshold, consideration band. Do this before any demo, because it turns vague demo questions into specific ones.
3. Day 5: shortlist by category, not by brand. Pick the category your bottleneck sentence points at. Look at three products inside that category and none outside it. This single rule prevents most misfires.
4. Days 6–8: demo with your own data. Bring one real job description and ten real CVs, including one scanned file and one badly formatted one. A demo on the vendor's sample data tells you nothing. Ask them to show you the evidence behind any score, live.
5. Days 9–10: ask the exit questions. Where is candidate data stored, who at the vendor can access it, what happens to files when you cancel, can you export everything including scores and criteria, is your data used for training anything, and what is the deletion path when a candidate asks.
6. Days 11–12: define the ninety-day check. Which number should move, by how much, measured how. Put it in the same document as the bottleneck sentence.
7. Days 13–14: run one role end to end before you sign the annual deal. One real opening, start to shortlist, on a trial or a monthly plan. Everything you learn in that round is worth more than every demo combined.

One extra rule that saves teams from themselves: do not buy two categories at once. If your funnel has both a sourcing gap and a screening gap, fix the one with the bigger number first, run it for a quarter, then reassess. Two simultaneous rollouts means neither gets configured properly, and when the results are ambiguous you will not know which purchase to blame.

When a screening tool earns its place

Assume you ran the diagnosis and the tallest bar was reading. Here is what to demand from the narrow category, because "AI screening" covers a wide range of quality.

It should start from your job description and turn it into criteria you can see and edit, not a hidden model of what it thinks the role is. It should let you set the weights, the pass threshold and the band where a candidate is worth a fifteen-minute call rather than a rejection. It should read every file you actually receive, including scans and images, and mark the ones it genuinely cannot read instead of scoring them zero and burying them. It should score each criterion separately with the line from the document that justified the score. It should compute the total from your weights on the server, rather than trusting a number a model wrote in a sentence. And it should let a missing must-have override a high total, because a weighted average will otherwise let charm on soft criteria compensate for a hard requirement the person does not have.

That is the specification Orova Recruit was built to: you upload the JD as a PDF, Word file or plain text, or paste it, and the AI extracts eight to sixteen criteria across five groups — must-have, important, preferred, basic and flexible — each with a weight from 1 to 10 and a suggested pass threshold, all of which you edit before anything is scored. Then you upload CVs individually, in bulk, or as a whole folder, up to 500 per position and 10MB per file, in PDF, Word, text or image formats. Each one comes back with a 0–100 score per criterion, the evidence quoted from the file, the extracted name, contact details, years of experience and most recent role, and a verdict of pass, consider or no fit. The total is computed by the server as a weighted average, a must-have below 50 forces a no-fit whatever the total says, and files that cannot be read are flagged as unreadable rather than guessed at.

Because the assessment layer sits where it does — after the tracker's job and before the decision — it also carries the pieces that fall between a CRM and an ATS in practice: interview questions written per candidate with their own scoring lines and weights, live note capture during the interview, an interview score on the same 0–100 scale as the CV score, a room calendar that refuses clashes, and status-driven candidate email sent from your own mailbox. Access is granted per position rather than per workspace, so a company running four openings across three departments keeps each shortlist to the people hiring for it.

Two guardrails matter more than any feature, and they apply to every product in this category, not just one. First, the tool ranks and you decide — nothing here should be allowed to send a rejection by itself, and the regulatory direction is clear on that: New York City's Local Law 144 requires bias audits and candidate notice for automated employment decision tools, the EU AI Act treats recruitment and selection as a high-risk use, and GDPR Article 22 restricts decisions based solely on automated processing. Second, keep the criteria job-related and the evidence visible, because a score you can trace is a score you can challenge, and a score you cannot trace is decoration.

The third category nobody puts in the comparison table: the assessment layer

Almost every CRM-versus-ATS comparison presents two boxes. A recruitment CRM manages relationships with people before they apply; an applicant tracking system manages applications after they arrive. Pick according to whether your problem is pipeline or process. It is a tidy framing, and it leaves out the work that actually consumes the week.

There is a third category, and it is defined by a different question. A CRM answers "who do we know?". An ATS answers "where is everyone?". Neither answers "who is worth our time, and how do we know?". That is the assessment layer, and it is missing from most comparison tables because it is newer and because it does not fit the storage-and-workflow mental model the other two share.

How to tell which of the three you actually need

The diagnosis is easier than the vendor conversation suggests. Ask which of these three sentences describes your last bad week.

"We could not find enough decent candidates." That is a sourcing problem. A CRM — or better targeting, or a referral scheme — is the answer. Buying an assessment tool here means buying a faster way to read the same insufficient pile.

"We lost track of someone, or two people contacted the same candidate." That is a coordination problem, and it is what an ATS exists for.

"We had plenty of applications and no defensible way to choose." That is an assessment problem, and neither of the other two categories addresses it. Both will happily store the applications; neither will tell you which are worth an hour of your time or leave a record of why.

Most teams over a certain size have all three problems to some degree, which is why the buying decision should start with which one is currently costing the most, not with which category has the nicest interface.

What an assessment layer must do to be worth having

Four requirements, and they are strict because this is the category where a bad product does real damage — it produces confident numbers about people.

The criteria must be yours and editable. A tool with fixed built-in criteria is selling you someone else's hiring standard.

Every score must carry its evidence. A number without a quoted line cannot be checked, and anything that cannot be checked eventually stops being believed — usually at the worst moment, when a decision is challenged.

The arithmetic must be transparent and not performed by the model. If the totals are asserted rather than computed from your weights, the total can contradict the parts it came from.

It must stop before the decision. Ranking, scoring, evidence: yes. Automatic rejection: no. Not because machines score badly, but because accountability cannot be transferred to something you cannot cross-examine.

Where it sits alongside the other two

These categories are not competitors so much as neighbours. The natural arrangement is a CRM feeding candidates in, an assessment layer deciding who is worth pursuing and recording why, and a tracker keeping everyone's position straight. Small teams frequently find that the assessment layer plus a spreadsheet outperforms an ATS plus manual reading, simply because the expensive thing in a small team is attention, not organisation. Larger teams usually need all three, and should make sure the assessment layer is not an afterthought bolted onto whichever system they bought first.

Frequently asked questions

Can one product be both an ATS and a recruitment CRM?

Yes, and many are marketed that way. The useful test is to look at which half was built first. A product that started as an ATS usually has strong stage management and thin outbound sequencing. A product that started as a sourcing tool usually has strong pools and thin compliance records. Neither is wrong; you just want the strong half to be the half that matches your bottleneck, with the weak half as a bonus rather than the reason you bought it.

Do we need a recruitment CRM if we only hire a few people a year?

Almost certainly not as a purchase. The value of candidate relationship management scales with how much outbound you do and how scarce the skill is. If you hire four people a year for roles that attract plenty of applicants, a tagged archive inside whatever system you already use will cover the re-engagement case, which is the part of the CRM idea that pays off fastest for small teams.

Is a screening tool the same as the AI matching in my ATS?

Sometimes, and sometimes not. Ask to see the evidence behind one score. If the product can point at the sentence in the CV that produced it, and if you can edit the criteria and weights it used, it is doing the same job. If it returns a match percentage with no traceable basis and no editable criteria, it is a ranking heuristic, and you should treat the number as a sorting hint rather than a judgement.

Which should we buy first if we genuinely have all three problems?

Take the funnel in order and fix the earliest broken stage, with one exception. If very few qualified people apply, nothing downstream matters and sourcing comes first. If enough apply but they get lost, fix the container. The exception: if applications are piling up unread right now, fix screening first regardless of the order, because unread applications are decisions you are already making badly today.

What happens to our talent pool data if we stop using the CRM?

Ask before you sign, not after. You want a full export that includes the person records, the interaction history and the source of each contact, in a format you can actually import elsewhere. Also ask how long the vendor retains data after cancellation and what the deletion process is, because you remain the controller of that personal data whether or not you are still paying the invoice.

Can we start with a spreadsheet for the CRM part?

For pools of tens of people, yes. A sheet with name, source, skill, last contact date, next action date and a link to their profile will run a small talent pool competently, and the discipline of updating it is the actual hard part in any tool. The point where a sheet breaks is sequenced outreach and engagement tracking — the moment you need to know who opened what and who is due a follow-up this week, manual tracking collapses.

Does buying tools reduce bias in hiring?

Not by itself. Any system inherits the bias of the criteria it is given: weight a prestigious employer heavily and you have encoded a preference regardless of whether a person or a model applies it. What structure does improve is consistency and inspectability — the same criteria applied to every candidate, with visible evidence you can challenge. That is a precondition for reducing bias, not a substitute for examining your criteria.

What to do this week

Do not open a single vendor site until you have done these four things.

One. Pull the numbers for your last three closed roles: applications received, applications genuinely read against a standard, days from application to first contact, and how many candidates dropped out mid-process. Half an hour of digging, and it will settle an argument your team has been having for months.

Two. Write the bottleneck sentence with a number in it. One sentence. If you cannot write it, you are not ready to buy, and the measuring is the work.

Three. Take your busiest open role and write the criteria: eight to sixteen items, sorted into groups, weighted from 1 to 10, with a pass threshold and a consideration band agreed before anyone reads a CV. Do this whether or not you end up buying anything, because it improves manual screening immediately and it is the input every screening product needs.

Four. Have two people screen the same ten CVs against that rubric, independently, and compare. The overlap tells you whether your standard exists or whether you have been running on taste.

Then, and only then, look at products — one category only, the one your bottleneck sentence points at. The three categories in this article are not competing for the same job. They are competing for your attention, which is a different thing entirely, and the way to stop losing that competition is to know which of the three problems you actually woke up with this morning.