Applicant tracking built for a billing desk

The moment that decides whether a desk bills is the submittal, and in most systems it is a status change. Surhires treats a submittal as a record: which candidate, to which client contact, against which requisition, with which documents, at what rate or salary, on what date, and what came back.

That makes the two questions agency owners actually ask answerable. How many submittals did this desk send last week, and what is the submittal-to-interview rate per client? Both are reports rather than a spreadsheet somebody maintains on Fridays.

It also fixes the version problem. The formatted CV that went to the client, the rate that was quoted and the summary that was written are attached to the submittal rather than to the candidate, so a candidate presented to two clients at two rates has two accurate records instead of one that reflects whichever submittal happened last. When a client comes back three weeks later, what they were sent is retrievable exactly as it was sent.

When a candidate is rejected, the reason is recorded from a standard list: failed technical screen, salary above budget, a better-qualified candidate was selected, candidate declined, candidate accepted a counter-offer, position withdrawn. Free-text rejection notes are still allowed, but the coded reason is mandatory.

This is partly analysis and partly defence. Coded dispositions let you see that a particular client rejects on salary sixty percent of the time, which is a conversation about the brief rather than about the candidates. They also mean that if a hiring decision is ever questioned, the record reconstructs what happened rather than offering an empty field.

The list is deliberately short. A code list that grows to forty entries stops being a list and becomes free text with a dropdown, because nobody scrolls to find the accurate one and everything ends up under other. Agreeing on a dozen codes that the desk will genuinely use, before recruiters start working, is worth more than a comprehensive taxonomy nobody applies consistently.

Interview scheduling reads the panel's calendars, proposes slots, holds them, and sends the candidate a link. Reschedules update everybody rather than requiring a fresh email thread. Reminders go out at a configurable interval before the slot, through whichever channel the candidate agreed to.

Feedback is captured against a scorecard rather than in a reply. Structured feedback is the only kind that can be compared across a panel, and the only kind that supports a defensible decision later.

The case worth designing for is the reschedule, because it is the one that costs a desk placements. When a client moves a slot at short notice, the candidate has to be told, the panel hold has to be released, the new time has to respect a time zone nobody checked, and somebody has to notice if the candidate never confirms. Each of those is a small thing that gets missed on a busy afternoon, and the aggregate of missing them is a candidate who quietly goes cold.

The Placement Pipeline Command Centre shows submittals out, interviews booked, interviews slipped, offers live with acceptance risk, placements closed and revenue booked, and it highlights placements sitting inside a guarantee window where a drop-out would cost a rebate.

The value of the view is that it is derived from the working records rather than typed into a report. Nobody updates it on a Friday, so it does not go stale between Fridays.

That also changes what a management meeting is about. When the numbers come out of the records, the meeting is not spent establishing what happened, which is where most of the hour normally goes. It starts from an agreed picture and moves straight to the two or three requisitions that are in trouble, which is the only part of the conversation that changes an outcome.

Every stage change is immutable: who, when, from what to what, and with which disposition. Notes can be edited, but the stage history cannot be rewritten.

For agencies working with government, regulated or enterprise clients, that trail is frequently what procurement asks about. It is also what turns a disputed placement fee into a two-minute conversation.

Immutability has a cost worth stating plainly. A recruiter who moves a candidate to the wrong stage cannot make that disappear; they move it back, and both transitions stay in the history. That looks untidy and it is the point. A history that can be tidied is a history nobody can rely on, and the entire value of the trail comes from the fact that it was never editable.

Every team configuring a tracking system for the first time makes the same mistake, which is to model every nuance of every client. Fourteen stages later, half of them are never used and recruiters skip three at a time, which destroys the conversion reporting the stages existed to produce. The working test for whether a stage should exist is simple: a real decision happens there, and somebody would report on how many candidates got past it.

The order that works is to start from the vertical template closest to your desk, whether that is contingent permanent placement, retained executive search, contract and temp staffing, RPO delivery or in-house corporate talent, then configure one demanding client as a variant and run it for a fortnight before cloning anything. Two weeks of real use tells you which stages are load-bearing far better than a workshop does.

The disposition codes deserve the same fortnight. Agree them once, at desk level, before anyone starts working, because codes added later cannot be applied retrospectively to decisions already recorded. A gap in the middle of your first quarter of reporting is a small thing that becomes annoying every time somebody asks a year-on-year question.

It does not source. An empty pipeline is a sourcing problem, and a tracking system makes an empty pipeline extremely visible without making it any smaller. The same applies to a pipeline full of candidates who do not meet the brief: the board will show you the volume, and it will not tell you the requisition was mis-scoped unless the coded dispositions say so.

It does not make a client respond. A submittal that has been silent for nineteen days is surfaced, prioritised and attached to the client contact who has not replied, and then a human has to pick up the phone. Software can remove the excuse that nobody noticed. It cannot remove the call.

And it stops where the employment relationship starts. Surhires is recruitment software, not an HRIS, a payroll system, a background-check provider or an assessment platform. Tracking runs from requisition through to placement and the first invoice. Onboarding paperwork, timesheets, payroll and employee records live in systems built for that, and we would rather integrate with them than claim to replace them.