Short answer: A recruitment software implementation is not finished on the day the new system goes live. At a staffing agency, the first 90 days decide whether every branch runs its intake in it and whether candidates move faster. Measure that per client and per branch, with candidate outcomes such as time to first contact, not logins.
Key takeaways
- Treat launch day as the start: the first 90 days decide whether the new system becomes how your branches work.
- Judge adoption by what happens to candidates: time to first contact, interviews completed, checks done before the offer and show up at the first shift.
- Report every measure per client and per branch. An agency average can hide one branch that got worse.
- Take a baseline from the old process before launch, or you cannot tell a real change from a seasonal swing.
- Settle the data and people questions early: which candidate data you move, what the old vendor deletes, and when to involve the works council.
On this page: What does recruitment software implementation involve after launch? · Why do new systems stall at agencies after launch? · What should you measure in the first 90 days? · What does a 90 day plan look like? · How should you handle candidate data when you switch systems? · Who has to be involved, and when? · How do you know your recruiters still make the decisions? · What changes when you hire frontline staff at volume? · What can a 90 day review not tell you? · How Radius helps · Frequently asked questions
What does recruitment software implementation involve after launch?
After launch, implementation means consistent daily use that improves candidate outcomes.
Whether you call it an ATS implementation or a move to a new recruitment platform, many plans end at launch: data moved, workflows configured, users trained. For an agency, the work that decides the investment starts that day: every branch running its daily intake in the new system, clients receiving candidates as they expect, and candidates getting a faster, clearer process. Still choosing a system? Start with ten questions to ask any provider.
Klein and Knight (2005) write that many teams and organisations fail to realise the expected benefits of innovations they adopt, and that a key reason is implementation failure: not getting the targeted employees to use the innovation with skill, consistency and commitment. They name a strong, positive climate for implementation, management support, financial resources and a learning orientation as helpful conditions.
You will often read that 70 per cent of software or change projects fail. Treat that number with care. A peer reviewed paper that traced five published sources of the "70 per cent of change fails" claim found no valid and reliable empirical evidence for it (Hughes, 2011). The useful point stands without the number: buying software changes nothing until people use it every day.
A number to treat with care
“70 per cent of change fails.”
It traced five published sources of the claim and found no valid and reliable empirical evidence for it.
Buying software changes nothing until people use it every day.
Why do new systems stall at agencies after launch?
They stall when the old way of working survives next to the new system.
Agencies have a few patterns of their own:
- Parallel running without an end date. The old spreadsheet, shared inbox or previous ATS stays open "for now". Candidates sit in two places, nobody sees the whole pipeline, and the new system looks slower than it is because part of the work never enters it.
- One owner at head office, none in the branch. The questions arise at 08:00 in a branch with twenty applicants waiting. Without someone in each branch who can settle small issues, recruiters build workarounds.
- Success defined as usage. Logins and records created show that people opened the system. They do not show whether applicants were contacted sooner or turned up for the first shift.
- Averages across very different clients. A logistics client with night shifts and certificate requirements behaves differently from a cleaning client with evening work. One agency figure blends them and hides where the new process fails.
- Training on clicks rather than on benefit. In two studies with 152 users and four applications, Davis (1989) found that how useful people judged a system to be was more strongly linked to their current and expected use of it than how easy they found it. So show each recruiter where the system saves work in their own week, such as fewer chasing calls, not only which buttons to press.
What should you measure in the first 90 days?
Measure what happens to candidates, per client and per branch.
Choose four to six measures, define them once and count them the same way every week. The table is a starting set for frontline roles.
| Measure | What it tells you | How to count it | Watch out for |
|---|---|---|---|
| Time to first contact | Whether applicants are picked up in the new process | Hours from application to the first two way contact; median per branch | Night and weekend applications; count them separately |
| Interview completion | Whether the invitation and format work for candidates | Interviews completed divided by interviews offered | Roles with different interview formats |
| Checks before the offer | Whether identity, right to work and required certificates are confirmed before a candidate is offered to a client | Candidates offered with all required checks done, divided by all candidates offered | Requirements differ per client; use each client's list |
| Show up at the first shift | Whether faster still means the right person | Candidates who started their first shift divided by accepted offers | Pay, travel and shift times also drive this |
| Work outside the system | Whether the old process survives | In a weekly sample of open roles, candidates handled in a spreadsheet or inbox | Look at branches and roles, not at named recruiters |
| Decisions on evidence | Whether a person decides on what was shown | In a weekly sample of five records per branch, decisions with a note that refers to the evidence | A note copied from a template is not a reason |
Two rules make these numbers useful.
Take a baseline before launch. Pull the same measures from the old process for the last 8 to 12 weeks, per branch. If the old system cannot produce them, sample by hand: one role per branch, followed from application to first shift. Our guide on how to audit your hiring process for one role in one hour shows a quick way to do that.
Report per client and per branch. That view is where you find a setup problem, a missing owner or a client whose requirements were never configured.
Illustrative example: one average, three branches
Illustrative example. The figures are invented to show the calculation and do not describe any real agency.
An agency moves three branches to a new system. Before launch, each branch contacted about 65 per cent of applicants within 24 hours. In weeks five to eight after launch:
| Branch and main client type | Applicants | Contacted within 24 hours | Interviews completed (share of applicants) |
|---|---|---|---|
| Branch A, two logistics clients | 400 | 340 (85%) | 220 (55%) |
| Branch B, one warehouse client | 250 | 200 (80%) | 140 (56%) |
| Branch C, one cleaning client with evening shifts | 150 | 60 (40%) | 45 (30%) |
| Agency total | 800 | 600 (75%) | 405 (51%) |
At agency level, contact within 24 hours rose from about 65 to 75 per cent. Per branch, two branches improved and one fell from about 65 to 40 per cent. The cause could be that Branch C still answers from the old shared inbox, or that invitations go out during the day to people who work evenings. Either way, the fix sits in Branch C, and the agency average would never have pointed there.
Applicants contacted within 24 hours, per branch
Illustrative agency moving three branches to a new system
What does a 90 day plan look like?
Three phases of about 30 days: stabilise, compare, then make it the standard.
Start with one branch, or one branch and two clients, before you move the rest. A staged start limits the damage of a setup error and gives you a rough comparison group.
| Phase | Goal | What to do | Decision at the end |
|---|---|---|---|
| Before launch | A fair starting point | Record the baseline per branch; name an owner per branch; decide which data moves; agree what candidates and clients will be told; set an end date for the old process | Is the first branch ready? |
| Days 1 to 30 | Stabilise | Short daily check with the first branch for two weeks; fix setup issues the same week; weekly figures per client; close the old process on the agreed date | Roll out further, or fix first? |
| Days 31 to 60 | Compare | Bring the other branches in; compare branch with branch and client with client; let recruiters from the first branch help colleagues | Which differences are setup problems, and which are real differences between clients or roles? |
| Days 61 to 90 | Make it the standard | Remove remaining workarounds; review every two weeks; confirm with each client what they receive; check that retention settings run as agreed | What is normal now, and which targets follow from your own figures? |
Running intake for several clients and branches at once? See how Radius is set up for staffing agencies.
How should you handle candidate data when you switch systems?
Move only the candidate data you need and are allowed to keep.
A switch is the moment to apply your retention policy. The GDPR requires personal data to be adequate, relevant and limited to what is necessary, accurate, and kept in identifiable form for no longer than necessary for its purpose (Article 5(1)(c), (d) and (e)). In practice:
- Apply retention before you migrate. Records whose retention period has passed should be deleted under your policy, not moved.
- Clean as you move. Merge duplicates and fix outdated contact details first.
- Test with a sample. Before the full import, check a sample of records per branch yourself, including notes, documents and the source of each application.
- Close the old contract properly. Under the GDPR, the contract with a processor must require it, at the controller's choice, to delete or return all personal data at the end of the service and to delete existing copies, unless Union or Member State law requires storage (Article 28(3)(g)). Get the export first, then ask for written confirmation of deletion.
- Check whether you need a DPIA. If the new system uses AI to evaluate candidates, a data protection impact assessment will in most cases be required before it starts. The GDPR requires one for a systematic and extensive evaluation of people based on automated processing, where decisions based on it have legal or similarly significant effects on them (Article 35(3)(a)), and the Dutch data protection authority's list of processing that requires a DPIA (2019) includes profiling.
Who has to be involved, and when?
A named owner per branch first, then recruiters, clients and the works council.
- Branch owners and recruiters. Give one person per branch the authority and time to settle small questions the same day, and involve a few recruiters in setup so they can show colleagues where the new process saves time.
- Clients. Tell each client what changes for them, such as how candidates are submitted and what evidence comes with them, and agree one contact for the first weeks.
- The works council. In the Netherlands, introducing a recruitment tool may require works council consent, depending on how it is used. The Works Councils Act requires consent for decisions on rules for recruitment policy and on systems aimed at or suitable for monitoring staff attendance, behaviour or performance (Works Councils Act, Article 27(1)(e) and (l)). Involve the works council early and take advice. This is one more reason to measure candidate outcomes per branch rather than activity per recruiter.
- AI literacy. If the new system includes AI, the EU AI Act has required organisations that use AI systems to take measures on AI literacy for the staff who operate them since 2 February 2025. Since the Digital Omnibus on AI took effect on 27 July 2026, the duty is to take measures that support that literacy, without having to reach a specific level for each person.
- Later duties for high risk AI. From 2 December 2027, organisations that use a high risk AI hiring tool take on further duties, such as assigning trained people with authority to oversee it and telling candidates that such a system is used. Our article on the EU AI Act and recruitment explains the timetable.
How do you know your recruiters still make the decisions?
Check the reasons behind decisions, not only the speed.
A system that presents information neatly can make people accept it too quickly. The EU AI Act names this risk. From 2 December 2027, the date set by the Digital Omnibus on AI (Regulation (EU) 2026/1744), high risk AI hiring systems must enable the people overseeing them to remain aware of the possible tendency of automatically relying or over relying on the output, known as automation bias (Article 14(4)(b)).
Each week, the branch owner opens five candidate records and asks: did the recruiter look at the evidence for each requirement, is the reason for the decision written down and tied to a requirement of the role, and would it make sense to the candidate or the client if they asked? A branch that got faster while its decision notes got thinner has not improved.
What changes when you hire frontline staff at volume?
Volume turns small delays into lost candidates, so speed per branch matters most.
Frontline applicants often apply from a phone, outside office hours, and may be weighing other work, so a day of silence can mean they start elsewhere.
Volume also raises the stakes of every check: a placement that needs a forklift certificate, a VCA certificate or a right to work check fails at the first shift if the check comes too late. Our article on which checks can happen before the offer covers the Dutch rules. Your 90 day figures will show whether the new system moved those checks forward.
What can a 90 day review not tell you?
It shows the direction of change, not proof that the software caused it.
- Small numbers. A branch with 20 applicants a week can swing by ten points by chance. Use four week totals.
- Seasons. Peak periods change applicant numbers and show up rates. Compare with the same weeks last year where you can.
- Factors outside the system. Pay, travel time and shift patterns also affect show up, and no software controls them. Read that measure with your client.
- No controlled test. A before and after comparison is not an experiment.
- Longer outcomes. Early leavers and quality of hire need more than 90 days. Our guide to measuring quality of hire in frontline recruitment covers the months after.
How Radius helps
Radius Hire is the AI hiring platform for frontline roles. Its AI Interviewer, Match and Radius Passport sit on one candidate record, and a recruiter makes every hiring decision.
- Next to your current system. Radius is built to run next to your existing ATS and to hand each hire on to your HR or payroll system, so adding it does not have to start with a full migration. Which systems connect is agreed in the demo. Agencies that want one system can use the Radius ATS.
- Structured interviews. The AI Interviewer invites applicants to a short, structured voice interview they can take on their phone, whenever it suits them, in the language set for the role.
- Evidence per requirement. For each requirement, Match shows whether it is backed by a document or a check, rests only on what the candidate said, or is still missing. Where the employer uses Radius Passport, identity and right to work are checked with a trusted verification partner and certificates are recorded with their expiry dates, so a recruiter can review the evidence before an offer. It does not replace the employer's own legal duty to check identity.
- A person decides. Radius never rejects a candidate on its own. A recruiter reviews the evidence and makes every hiring decision.
- Data. Candidate data is hosted in the EU and processed under a data processing agreement, and the employer sets how long it is kept. Details are on the trust page.
Radius is built for staffing agencies that recruit for several clients and sites. How clients, branches and permissions are set up is agreed in the demo. Radius is new, so this article explains how the product works rather than claiming results.
Frequently asked questions
How long does a recruitment software implementation take at a staffing agency?
There is no standard duration; it depends on your branches and your data. Plan a setup phase before launch, then at least 90 days of measured use, longer if branches start one after another. The project is done when every branch works in the new system and your candidate measures are stable.
Should we run the old and the new system side by side?
Only for a short, fixed period per branch. A few days of overlap can catch setup errors, but open ended parallel running splits candidates over two places. Set the end date before launch and keep it.
Do we need to replace our ATS to add AI interviewing?
Not necessarily. Some tools, Radius among them, are built to run next to an existing ATS. Before you choose that route, agree which system holds the master candidate record and who checks that data arrives in both.
Is login data a good measure of ATS adoption?
Only as a warning light. Low logins in a branch tell you to go and look, but high logins do not show that candidates are contacted sooner or start their first shift more often. Tracking activity per named recruiter can also raise works council questions in the Netherlands.
Conclusion
A recruitment software implementation succeeds when candidates feel the difference: a quicker first contact, an interview they can complete, checks done before the offer and a first shift they turn up for. Take a baseline before launch, give every branch an owner, close the old process on a fixed date and read your measures per client and per branch every week for 90 days. The software can carry the structure. The judgement about each candidate stays with your recruiters.
General information, not legal advice. Position as of 22 October 2026.
Sources
- Klein, K. J. and Knight, A. P. (2005). "Innovation Implementation". Current Directions in Psychological Science, 14(5), 243 to 246. https://doi.org/10.1111/j.0963-7214.2005.00373.x (checked 23 October 2026).
- Hughes, M. (2011). "Do 70 Per Cent of All Organizational Change Initiatives Really Fail?". Journal of Change Management, 11(4), 451 to 464, published 16 December 2011. https://doi.org/10.1080/14697017.2011.630506 (checked 23 October 2026).
- Davis, F. D. (1989). "Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology". MIS Quarterly, 13(3), 319 to 340. https://doi.org/10.2307/249008 (checked 23 October 2026).
- Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 5(1), 28(3)(g) and 35(3)(a). Official Journal of the European Union, L 119, 4 May 2016. https://eur-lex.europa.eu/eli/reg/2016/679/oj (checked 23 October 2026).
- Autoriteit Persoonsgegevens (2019). "Besluit inzake lijst van verwerkingen van persoonsgegevens waarvoor een gegevensbeschermingseffectbeoordeling (DPIA) verplicht is", Staatscourant 2019, 64418, category 15 (profiling). https://zoek.officielebekendmakingen.nl/stcrt-2019-64418.html (checked 23 October 2026).
- Wet op de ondernemingsraden (Works Councils Act), Article 27(1), version in force from 18 February 2023. https://wetten.overheid.nl/BWBR0002747/2023-02-18 (checked 23 October 2026).
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), Articles 4, 14 and 26. Official Journal of the European Union, 12 July 2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj (checked 23 October 2026).
- Regulation (EU) 2026/1744 (Digital Omnibus on AI), amending Regulation (EU) 2024/1689. Official Journal of the European Union, 24 July 2026, in force 27 July 2026. https://eur-lex.europa.eu/eli/reg/2026/1744/oj (checked 23 October 2026).