Everything recruitment software has to do, and why

An ATS is requisition-centric. A job opens, applications arrive, candidates move through stages, somebody is hired, the requisition closes. The unit of work is the job, and the system is measured on how cleanly it moves an application from arrival to decision. This is the right shape for a corporate talent team, which typically has one employer, one approval chain and a fixed definition of a stage.

Recruitment software is person-centric and account-centric. The candidate record outlives the job it was created for. The client record accumulates every requisition, every submittal, every rejection reason and every invoice. The unit of work is the relationship, and the system is measured on whether it can tell you who to call today.

Agencies need both, which is why the categories collapsed into each other commercially. But the underlying data models are different, and a product that started as one and grew the other usually shows a seam. The ATS-first products tend to have thin client-side records. The CRM-first products tend to have vague stage handling. Find the seam during evaluation, not during month three.

Every few years a firm decides to run recruitment on a general-purpose sales CRM, because the licences are cheaper and somebody already knows how to configure it. It works for about a quarter, and then it does not, and the reason is structural rather than a matter of configuration effort.

A sales CRM models one deal with one account and a set of contacts attached. A recruitment desk has a candidate who is live on three requisitions at two clients, and a requisition holding twenty candidates, and the placement requires both sides to close at the same time. That is a many-to-many relationship with financial consequences on both edges, and it does not survive being flattened into an opportunity object.

The second thing that breaks is the candidate lifecycle. In sales, a lost deal is dead. In recruitment, a candidate rejected in March is the best person you have for the role that opens in November, and the system has to keep the record warm, consented and searchable through the interval.

Feature lists are close to useless for comparison because every vendor lists everything. What is useful is knowing why a capability exists, because that tells you what a weak implementation will fail to do.

Resume parsing exists to make the database searchable in structured terms rather than as a keyword grep. A weak parser produces a text blob and a job title; a strong one normalises skills apart from languages, separates seniority from tenure, and captures notice period and salary expectation with their currency. Duplicate detection exists because two recruiters will source the same person within a fortnight, and a database with silent duplicates gives two different answers to the same search. Sequencing exists because the reply you get is a function of how many times and through how many channels you asked, and because manual follow-up is the first thing to be dropped in a busy week.

Reporting exists to answer a small number of specific questions: which desks are converting, which clients are rejecting on salary, and where in the pipeline time disappears. If the reporting cannot answer those without an export, it is decoration.

A vendor demo is a rehearsed path through clean data. It proves the software can do the thing once, which was never in doubt. The evaluation that predicts your experience is a trial loaded with a slice of your own mess.

Take a hundred real candidate records, including the ones with three resumes attached and a phone number in the notes field. Take two live requisitions, one straightforward and one that has been open for months. Then run your actual week: source, screen, submit, schedule, chase a client who is not answering, and produce the report you show on Monday. Time it, and count the places where you had to leave the system to get something done.

Ask the vendor the questions that are awkward to answer: what happens to our data if we leave, what does the export actually contain, which of these features is generally available today versus on the roadmap, and what is the minimum seat count. Write the answers down, because a roadmap commitment made in a sales call has a habit of becoming a misunderstanding later.

The software is configured in days. The data takes weeks, and it is where implementations succeed or fail. Before anything is imported, somebody has to decide what the firm's fields mean: whether availability is a date or a text note, whether rate is hourly or daily, whether a candidate belongs to a recruiter or to the firm.

Then comes the part nobody schedules. Legacy databases carry duplicates, dead email addresses, records with no consent basis, and notes whose author left in 2022. Importing all of it faithfully reproduces the mess in a more expensive system. Importing selectively means writing rules for what to drop, and getting the owner to agree to them.

Plan for a period where both systems are live, decide explicitly which one is authoritative during that window, and set a date when the old one becomes read-only. Ambiguity here is what produces the six-month tail where half the desk never moved.

The first failure is buying for the owner and rolling out to the desk. The dashboards are excellent and nobody enters the data that feeds them. The fix is to make capture faster than the alternative, not to send reminders about compliance.

The second is over-configuration. A firm that has never had structured stages designs nineteen of them, each with mandatory fields, and the desk routes around the whole thing. Start narrower than feels right and add stages when a real question demands one.

The third is the migration that was never reconciled. Records came across, nobody counted them, and eight months later someone discovers that attachments from before a certain date are missing. The fourth is treating adoption as a training problem when it is an incentive problem: if commission is calculated from a spreadsheet, the spreadsheet is the system of record no matter what the software says.

Set the measures before you buy, because afterwards you will grade generously. Useful measures are behavioural rather than aspirational: what proportion of submittals were logged in the system on the day they went out, how many candidate records created this quarter have a consent basis, how many searches per week actually return a candidate the desk then contacts.

Then one commercial measure, chosen honestly. Rediscovery rate, meaning placements sourced from your existing database rather than from new sourcing spend, is the cleanest one, because it is the specific thing a CRM is supposed to change and it is hard to fake.

If those numbers have not moved, more training will not move them. Something in the capture path is too slow, or the incentives still point elsewhere.