Why ATS Implementations Fail (and How to Avoid It)

Research by Aptitude Research Partners found that 42% of companies report their ATS implementation did not deliver the expected efficiency gains within the first year. The reasons are almost never technical — they are organisational. Teams did not agree on processes before configuring the system. Historical data was migrated without cleaning. Hiring managers were trained once and never supported after go-live. The ATS was set up to mirror the old process rather than improve it.

The companies that get ATS implementation right share a common approach: they treat it as a process redesign project that happens to involve software, not a software installation project. The technology is relatively simple. The hard work is agreeing on how your team will recruit, what stages your pipeline will have, who is responsible for what action and what good looks like in terms of candidate communication. Do that work before you touch the platform and implementation becomes a matter of configuration rather than negotiation.

This checklist is divided into three phases: pre-implementation (the work you do before the system goes live), implementation (configuration, migration and training) and post-launch (the optimisation that most teams skip but that determines long-term success).

Pre-Implementation Phase: Steps 1–5

Step 1: Audit Your Current Recruitment Process

Before configuring a new ATS, document how recruitment actually works today — not how it is supposed to work, but how it actually works. Map every stage from role approval to offer acceptance. Note where decisions happen, who makes them and what information they rely on. Identify the three biggest pain points in the current process. This audit becomes the brief for your ATS configuration and ensures you are solving real problems rather than replicating existing inefficiencies in a more expensive system.

Step 2: Define Your Pipeline Stages

Agree on a standard set of pipeline stages that will apply across all roles. Typical stages include: Applied, CV Review, Phone Screen, First Interview, Technical or Competency Assessment, Final Interview, Reference Check, Offer, Hired, Rejected. Document what criteria move a candidate from one stage to the next and who has authority to advance or reject. This standardisation is what makes reporting meaningful — if every hiring manager uses stages differently, your pipeline data tells you nothing useful.

How Many Pipeline Stages Do You Actually Need?

Most teams create too many stages, which leads to confusion and inconsistent data. Research suggests five to seven stages produces the most consistent recruiter behaviour. Start with the minimum that meaningfully represents your process and add stages only where they produce distinct actions or decisions. You can always add stages later — removing them from live pipelines is messier.

Step 3: Identify All Integrations Required

List every tool that your ATS needs to connect with: job boards (eJobs, BestJobs, LinkedIn, Indeed), calendar systems (Google Calendar, Outlook), email providers, HR information systems, payroll software, background check providers. For each integration, identify whether it is available natively on the new platform, requires a third-party connector, or will need to be handled via CSV export. Integrations that seem minor at the audit stage — such as calendar sync for interview scheduling — create significant manual work if they do not function reliably at scale.

Step 4: Establish Your Data Migration Plan

Decide what data migrates and what does not. Active candidates in current pipelines must migrate. Hired employee records are valuable for quality-of-hire tracking and should migrate. Historical rejected candidates are lower priority — only migrate those from the past 12–18 months, and only if they hold valid GDPR consent for future contact. Avoid the temptation to migrate everything: a large database of outdated, uncleaned candidate data is a GDPR liability, not an asset.

Step 5: Define Roles, Permissions and Access Levels

Before go-live, configure who can see what within the system. Typical roles include: Super Admin (full access — usually one or two people in central HR), Recruiter (can manage all candidates in assigned roles), Hiring Manager (can view and score candidates in their roles, cannot see compensation data for other roles), External Collaborator (limited view for agency recruiters or interviewers). Getting this right before launch prevents awkward permission corrections after sensitive data has been accessed inappropriately.

Implementation Phase: Steps 6–10

Step 6: Configure Your Career Page

Your career page is the first thing candidates see when they apply. Configure it to reflect your employer brand accurately: company logo, colours, a brief culture description, photos of the team if available. Ensure the application form asks only for the information you genuinely need at the initial stage — excessive fields at the application step significantly reduce conversion. In Treegarden, the career page builder allows full customisation without developer involvement, typically completed in a few hours rather than the days required by legacy platforms.

Step 7: Set Up Automated Email Sequences

Configure automated emails for every stage transition: application received, CV under review, interview invitation, interview confirmation, rejection (after CV review), rejection (after interview), offer made. Personalise each template with candidate name, role title and next steps. Automated emails improve candidate experience dramatically — candidates who receive timely communication are 38% more likely to complete the interview process and accept an offer when extended. They also free your recruiters from repetitive administrative email tasks.

The Rejection Email Problem

Most companies send rejection emails that are generic, impersonal and unhelpful. This damages employer brand — rejected candidates talk about their experience publicly. Draft rejection templates that are specific to the stage (CV rejection vs post-interview rejection), acknowledge the candidate's time and effort, and where possible, give a brief reason. Candidates who feel treated with respect after rejection are more likely to reapply for future roles and recommend your company to peers.

Step 8: Migrate Your Data

Execute your data migration plan from Step 4. Import active candidates first and verify that pipeline positions are correct. Import historical records second. After migration, run a sample verification: manually check 20–30 records across different categories to ensure data integrity. Pay particular attention to consent flags on historical records — any candidate imported without valid GDPR consent must either be re-consented or deleted before the system goes live.

Step 9: Connect Job Board Integrations

Set up integrations with your priority job boards and test them end-to-end before going live. Post a test role, verify it appears correctly on each board, submit a test application and confirm the candidate appears in the correct pipeline stage in the ATS. Test the data that flows back — name, email, CV, application source. Broken integrations discovered after launch create urgent manual work to recover candidates who applied but were not captured correctly in the system.

Step 10: Train Your Team

Run separate training sessions for recruiters and hiring managers — their day-to-day interactions with the system are fundamentally different and combining them in a single session results in neither group getting what they need. For recruiters: full pipeline management, candidate advancement, email templates, reporting. For hiring managers: reviewing candidate profiles, leaving feedback and scores, accepting or declining interview invitations. Record the sessions. Create a short written guide with screenshots of the three to five most common tasks for each role.

Treegarden Implementation Timeline

Most Treegarden customers go live within 5–10 business days. Day 1–2: account setup and pipeline configuration. Day 3–4: career page, email templates and job board connections. Day 5–6: data migration and verification. Day 7–8: team training sessions. Day 9–10: parallel running, final checks and go-live. This is dramatically faster than enterprise platforms that require months of implementation, without sacrificing the configurability that makes the system useful for complex recruitment operations.

Go-Live Phase: Steps 11–12

Step 11: Run a Parallel Period

For one to two weeks before fully cutting over, run both systems simultaneously. Post new roles in the ATS but continue managing existing candidates in the old system until they close. This allows you to identify configuration issues under real conditions without risking active candidates. Document every problem encountered during the parallel period and resolve them before the hard cutoff date. The parallel period also gives your team time to build confidence in the new system before it becomes the only option.

Step 12: Communicate the Cutover Date Clearly

Set a specific date after which the old system will no longer be used and communicate it clearly to all stakeholders. Ambiguity about when the old process ends causes people to continue using familiar tools indefinitely, which means you have two systems running in parallel permanently rather than temporarily. The cutover date creates the necessary urgency for adoption. After that date, if a candidate is not in the ATS, they do not exist for reporting purposes — make this explicit.

Post-Launch Optimisation: Steps 13–15

Step 13: Review Your First Month of Data

After 30 days of live operation, pull your first pipeline reports. Look at where candidates are dropping out of your funnel, which stages have the longest average duration, and which sources are producing the most applicants. This first data review will almost certainly surface configuration issues — stages that are being used inconsistently, email templates with errors, or integration sources that are not tagging candidates correctly. Fix these quickly before they compound over subsequent months.

Step 14: Gather Team Feedback and Iterate

At the 30-day mark, run a brief feedback session with recruiters and hiring managers separately. What is working well? What is taking too long? What feels unnecessary? ATS configuration is not a one-time event — it is an ongoing process. The pipeline stages that seemed logical in design may need adjustment once they are tested against real recruitment cycles. Email templates that seemed complete may need refinement based on candidate responses. Budget time for this iteration in your implementation plan.

Step 15: Set Quarterly Review Checkpoints

Schedule a formal ATS review at the three-month, six-month and twelve-month marks. At each review: assess adoption rates (are all hires being managed in the system?), review pipeline reporting for data quality, evaluate whether your configured stages still reflect your actual process, and identify new features or integrations that could improve efficiency. Most organisations that struggle with their ATS over time do so because they configured it once and never revisited it — treating software as a static tool rather than a system that should evolve with the business.

Signs Your ATS Implementation Needs Attention

Watch for these warning signs at the 30 and 90-day marks: hiring managers are still sending candidate information via email rather than using the ATS, less than 80% of active roles have complete pipeline data, your reports show high numbers of candidates in early stages with no recent activity, or team members are creating workarounds rather than using the configured workflow. Each of these signals a specific problem — adoption resistance, incomplete migration, pipeline maintenance neglect or configuration mismatch — that has a specific solution.

Frequently Asked Questions

How long does ATS implementation typically take?

Implementation time varies significantly by platform and company complexity. Enterprise platforms like Greenhouse or Workday typically require 8–16 weeks including configuration, data migration, integrations and training. Modern platforms like Treegarden are designed for rapid deployment, with most companies going live within one to two weeks. The biggest variable is data migration complexity — how much historical candidate data you need to import and how clean that data is. Companies migrating from spreadsheets to an ATS for the first time typically move faster than those migrating from one ATS to another, where data structure differences add complexity.

What data should we migrate from our old system to the new ATS?

Prioritise active candidate pipelines, current open roles and hiring manager accounts. For historical data, consider migrating hired employee records (useful for quality-of-hire analysis over time), candidates who progressed to final stages in the past 12 months (potential future hires), and any talent pool contacts who have given explicit GDPR consent for future contact. Avoid migrating all historical data indiscriminately — it creates noise and potential GDPR violations for candidates who applied years ago without consenting to long-term data retention.

How do we get hiring managers to actually use the new ATS?

Adoption failure is the number one reason ATS implementations underdeliver. The key is making the system easier than the alternative, not just mandating its use. Run role-specific training sessions that show hiring managers exactly what they need to do — reviewing candidate profiles, leaving scores, accepting interview invitations — in under 15 minutes. Identify internal champions in each team who can support their colleagues. Set a hard cutover date after which candidates will only be managed in the ATS. And make sure early wins are visible — show the team the time they saved compared to the old process within the first month.