Choosing an applicant tracking system that can carry twenty clients at once

In-house applicant tracking software is built around a company hiring for itself. There is one careers site, one approval chain, one interview process, one offer template and one set of stage names. Reporting answers the question a talent director asks: how is our funnel performing this quarter.

An agency has a different client every few rows. One wants a formatted CV with a written summary and nothing else. One wants three candidates presented together or none at all. One wants a video introduction. One has a procurement portal you have to key the submittal into by hand. Their stages differ, their SLAs differ, their rejection reasons differ, and their contacts change without telling you.

Force that onto a corporate ATS and you get the same workaround every time: the client becomes a tag, the requisition becomes a job with the client name typed into the title, and the difference between clients lives in the recruiter's head. It works until the recruiter leaves, and then it does not work at all.

The moment that decides whether an agency bills is the submittal: this candidate, presented to that contact, against that requisition, with those documents, at that rate or salary, on that date. In most corporate tracking systems, a submittal is a status change on an application. That is enough for a talent team and nowhere near enough for a desk.

Ask any agency owner what they measure and you get two numbers: submittals out per recruiter per week, and submittal-to-interview conversion per client. Both are trivial when the submittal is a record with its own fields and history. Both become a Friday spreadsheet when it is not, and a Friday spreadsheet is always three days stale and quietly optimistic.

When you evaluate a system, open a candidate who has been sent to three clients for four different roles and see what the record looks like. If the history reads as one flat list of stage changes with no way to tell which client each belonged to, the model underneath is a corporate one and you will be fighting it for years.

For a temp or contract desk, the placement is a financial object. There is a pay rate, a charge rate, the difference between them, an on-cost assumption, an agreed uplift for overtime, an end date, an extension history and sometimes a conversion fee if the client takes the worker permanently. A tracking system that stores none of that has handed your margin calculation to a spreadsheet nobody reconciles.

For a permanent desk the equivalent is fee basis, percentage, invoice trigger, guarantee window and rebate terms. The guarantee window in particular is the thing that quietly costs money: a placement that drops out in week seven is a rebate, and you want a system that knows which placements are still inside the window today rather than finding out when the client emails.

You do not necessarily need the tracker to do the billing. Plenty of firms run pay and bill in a specialist system and that is a reasonable architecture. What you need is for the commercial terms to live on the placement record, so the pipeline view and the invoice are describing the same reality.

A contractor whose assignment ends in three weeks is the cheapest available candidate in your market and the one you are most likely to forget about. The corporate model has no concept of this, because a corporate hire does not finish and become available again. An agency system should be surfacing every assignment ending in the next thirty days as a working list, with the contractor's rate history, the client feedback and the reason the last assignment ended attached.

The same logic applies to the runners-up. Every requisition produces a shortlist of people who were good enough to submit and did not get the job, and their value does not expire when the job closes. If your system cannot produce that list against a new brief in under a minute, you are paying for sourcing you already did.

This is the deepest difference between corporate and agency software, and it is why the category is called recruitment software rather than an ATS. In a corporate system the candidate exists because a job exists. Once the job is filled, the record is archive. In an agency, the person you screened for a role in March is the person you place in September, and the notes from March are the reason you win in September.

That has structural consequences. Skills, seniority, location, notice period and salary expectation have to be normalised fields rather than sentences in a note, or the search cannot express a brief. Consent basis and retention have to be on the record, because holding candidate data for future roles is exactly the processing that data-protection regimes ask you to justify. Ownership has to be explicit, because rediscovery raises the question of whose candidate it is.

Judge a system on the search, not the pipeline. Take a real brief with four constraints, run it against a demo database, and see whether the answer respects all four or just returns everyone whose resume contains the words.

The market divides more cleanly than the marketing suggests. Agency recruitment platforms are built on the many-client model and treat candidates as long-lived relationships; this is the category that fits most staffing firms and it is where Surhires sits. Corporate applicant tracking systems are excellent at what they do, which is a structured internal hiring process with approvals and scorecards, and awkward the moment you have more than one employer. Lightweight trackers are cheap and genuinely useful for a small desk with simple needs, but they run out of room at the point where submittal analytics and margin start to matter. Sourcing-led platforms lead with outbound contact discovery and sequencing and often sit alongside another system rather than replacing it.

Surhires is a full recruitment software with the ATS workflow inside it: candidate management, submittals, the placement pipeline through to the first invoice, AI matching and resume parsing on the working plan rather than as an upgrade, and WhatsApp as a first-class candidate channel. The three-seat minimum is deliberately lower than the five-seat floors common in this category.

It is not the right answer for everyone. If your requirement is pay and bill for a thousand weekly timesheets, if you need a VMS integration to a specific programme, or if procurement requires a completed SOC 2 Type II report today, we are not the fit, and the honest version of that is on our trust page rather than buried in a call.

Run the trial on your data, not on the demo tenant. Load two hundred real candidates with their real mess, including the duplicates, and see what the import does with them. Take three live requisitions from three different clients whose processes actually differ and configure all three. Then send five real submittals through the system end to end and look at what the client received.

Ask the commercial questions in writing rather than on a call. What is the seat minimum, and is there an annual escalator. Is the CRM in the tier you are quoted or a higher one. Are AI features metered, and what happens when the credits run out mid-month. What does an export of everything actually contain, and can you run it yourself without asking support. How is a migration scoped and priced, and by whom.