Choosing an applicant tracking system starts with your own hiring process, not a vendor shortlist. Write down the workflow you actually run, separate genuine must-have requirements from preferences, then make every vendor perform your steps live in their product. Test data export, integrations and permissions before discussing price, and pilot on real roles before signing a multi-year contract.
Decide four things first, because whatever you leave undecided, the vendor decides for you. First, the problem statement in one sentence: what is broken now, and what does fixed look like six months from now. Vague problems produce demos of features nobody will ever use. Second, the buying group: who evaluates, who approves budget, who holds a veto, and who has to live in the system every day. Coordinators and hiring managers belong on that list, not only the head of talent. Third, your current process mapped stage by stage as it actually runs, including the ugly manual steps, because those are exactly what surfaces during migration. Fourth, a budget range and a decision date, so the evaluation can end. Adoption at the top of the market is close to universal: 97.8% of Fortune 500 companies use an ATS according to the Jobscan 2025 ATS Usage Report. The question is almost never whether to run one. It is which one fits the process you already have. Write all four on one page and reread it before every demo, because evaluations drift quietly.
A must-have is something whose absence ends the conversation. Everything else is a preference, and preferences should be weighted rather than listed. Build the requirement list from your process map instead of from a downloaded template, then score each item as must-have, high or nice. The discipline lives entirely in being ruthless about the first category. Genuine must-haves usually fall into a few groups: a data or legal requirement you cannot waive, an integration to a system you are not replacing, a workflow specific to how your team hires, permissioning a client contract or regulator demands, or a candidate-facing capability tied to your brand. Almost everything else belongs lower down the list. Take it to three vendors and watch what happens when a must-have is missing: if you catch yourself negotiating with yourself, it was never a must-have. Read the published ATS features of each shortlisted product before the demos, so those sessions get spent on fit rather than on inventory. Circulate the finished list to everyone in the buying group before the first demo, so nobody introduces a new must-have in week five.
Feature grids converge; the real differences show up in a handful of questions vendors answer differently. Ask how you get your data out, in what format, including attachments and interview notes, on demand and without a fee. Ask how much of the careers page and application form you control without engineering help, and what the resulting URLs look like. Ask which integrations are native, which run through a middleware connector, which need the API, and what the API rate limits are. Ask how granular permissions get: can an agency see only its own submissions, can a hiring manager see only their own roles, can salary be hidden from an interviewer. Ask whether reporting means fixed dashboards, a report builder, or direct access to your own data. Ask what happens to candidates from three years ago: is that database searchable, and does the system charge by stored record. Those six sort products faster than any comparison matrix. Ask each vendor to answer them in writing before the demo, since a written answer is easier to compare and harder to soften later in the process.
Ask what goes in, what comes out, and who can overrule it. Most recruiting AI sits in four buckets: parsing structured data from resumes, ranking or matching candidates against a role, generating text such as job ads and outreach, and summarising interviews or notes. Each carries a different failure mode and a different risk profile, so evaluate them separately rather than as one feature. The questions worth asking are specific. Does it rank, filter or auto-reject, and can auto-reject be switched off entirely. Is your candidate data used to train the vendor's models. Can a recruiter see why a candidate scored the way they did. Is there an audit log of automated decisions. Has the system been independently reviewed for adverse impact. Expectations across the profession run high, with 61% of recruiters expecting AI to change how they hire according to LinkedIn's Future of Recruiting 2025 report, which is precisely why vague answers should not pass. Treat AI recruiting tools as a workflow decision with legal implications, and involve counsel wherever automated screening is regulated. Get those answers in writing, since AI claims move faster than documentation.
Send a scenario in advance and decline the standard deck. A workable script uses one real requisition, three anonymised resumes, and a named list of steps performed live in the product: create the requisition through your approval flow, publish it to a careers page and two boards, screen the three resumes, schedule a panel across three calendars, capture scorecard feedback, move to offer, and pull a pipeline report. Then ask for the parts vendors tend to skip: the administrator screens, permission setup, bulk actions, and what recovery looks like when something is configured wrongly. Give every vendor the identical script so sessions are comparable, and keep the same people in the room for all of them. Score immediately afterwards while it is fresh, against the requirement list rather than against impressions. Watch the click count on tasks your team performs fifty times a day, because a workflow costing three extra clicks costs a coordinator hours every week. Record who attended each session and what they scored, because a decision defended three months later needs more than a shared memory of who seemed impressive.
The headline per-user price is rarely what lands on the invoice. Pricing models differ in kind rather than only in amount: per recruiter seat, per employee in the company, per open requisition, or a platform fee with modules attached. A model that looks cheap at your current size can be expensive after one growth year, so model the cost at projected headcount rather than today's. The usual additions are implementation and data migration fees, a charge for a sandbox environment, single sign-on placed on a higher tier, API access gated behind an enterprise plan, minimum seat counts, premium support, and renewal uplifts with no cap. Ask for the three-year total in writing. Free and open-source paths are legitimate at the small end: free ATS software tiers, including the Free Forever plan for one user that Pitch N Hire offers without a credit card, will run early hiring, and open-source applicant tracking systems trade licence cost for hosting and maintenance you provide yourself. Compare both honestly against paid ATS pricing at the size you expect to reach. Then confirm the total in writing before any pilot begins.
The technical migration is usually the easy part. Risk concentrates in three places: what you choose to bring across, how fields map, and whether people actually switch. Decide early whether you are migrating active candidates only, the last year, or the entire historical database, and have each option quoted separately. Field mapping is where the hidden work lives, because legacy free-text fields rarely map cleanly to structured ones and somebody has to make judgement calls across thousands of records. Consent and retention matter here too: moving old candidate records is a data decision rather than a purely technical one, requirements vary by jurisdiction, and counsel should confirm the approach before any bulk import. Adoption is the failure most often blamed on the software. Name an internal owner with time genuinely allocated, run a parallel period on a small set of roles, train by job role rather than by feature, and set a switch-off date. Realistic ATS implementation plans run in weeks for a small team and months for a complex one. Budget time for the parallel period rather than assuming it happens alongside a normal week.
A pilot only works with live requisitions and a pass mark written before it starts. Pick two or three real roles that differ from each other, ideally one high-volume and one hard to fill, and run them end to end in the new system rather than in parallel in both. Include everyone the workflow touches: a recruiter, a coordinator, a hiring manager, and whoever produces reporting. Define success in specifics beforehand: a panel scheduled without an email chain, a scorecard completed by every interviewer, a pipeline report you can hand to a department head without editing, an export that opens cleanly. Give it enough time to reach an offer, because most of the friction in any system lives after the interview stage rather than before it. Then decide against your criteria on the date you set. Pilots that drift for a quarter tend to end with the incumbent staying by default, which is a decision, just not one anybody made on purpose. Write the findings down while the team still remembers them, including what annoyed people, since irritation in week two becomes non-adoption by month six.
See how Pitch N Hire handles the parts of this that eat a recruiter's week — posting, screening, scheduling and keeping every decision in one place.
Prefer to talk? Book a demo · View pricing
Free 1-user plan · No credit card · Talk to a real hiring expert
See your true cost-per-hire and how much Pitch N Hire could save you — our free Recruitment ROI Calculator gives you the numbers in under a minute. No signup required.
Open the free ROI calculatorPrefer a tailored walkthrough on your real roles? Drop your work email:
★ Free 1-user plan · No spam · Talk to a real hiring expert
