HR
Spreadsheet, ATS, or custom hiring system: how to choose
A practical framework for choosing a spreadsheet, off-the-shelf ATS, configured platform, or custom hiring system based on workflow, roles, data, integrations, and risk.
The short answer: choose by coordination complexity, not resume count
A spreadsheet can be the right tool when one owner runs a simple process, only a few roles are active, and the team does not lose context between messages, interviews, and decisions. A growing candidate list alone does not prove that a new system is required. Ownership, history, and the path to the next decision matter more.
A change becomes justified when coordination fails: status versions diverge, feedback lives in chats, managers cannot see their next action, candidates answer the same questions twice, and reporting requires manual reconstruction. At that point, compare an off-the-shelf ATS, a configured platform, and a custom system against the workflow rather than the fashion of the moment.
Map the real hiring workflow first
Map the path from an approved hiring need to an accepted offer and handoff into onboarding. For every stage, record the input, decision, owner, expected time, required data, and exceptions. Mark every place where information is copied between a spreadsheet, email, calendar, chat, and the employee system.
Do not design around an ideal policy diagram. Observe how a role is actually approved, who schedules interviews, where a manager leaves feedback, and what happens when a candidate returns six months later. This reveals whether a platform is needed or whether the current spreadsheet and process simply need to be cleaned up.
When a spreadsheet is genuinely enough
Keep the spreadsheet when it has one owner, clear statuses, a shared data template, and a regular accuracy review. Access should be limited to people who genuinely participate in hiring, while resumes, notices, and notes should live in predictable locations. For occasional, uncomplicated hiring, this can be cheaper and clearer than introducing a heavy platform.
A spreadsheet should not pretend to be a complete system. Document where communication lives, who owns backups, how outdated records are deleted, how work is handed over during an absence, and how candidates learn about the use of their information. Missing answers point to a process and data-governance problem, not a formatting problem.
What an off-the-shelf ATS adds — and what it cannot fix
An off-the-shelf ATS can provide a shared candidate record, job stages, activity history, tasks, communication templates, reporting, and controlled access. Official Greenhouse and Microsoft documentation shows how mature recruiting products separate administrators, recruiters, hiring managers, and interview participants, with access that may vary by job.
An ATS cannot define hiring criteria, make a manager submit feedback on time, or remove unnecessary approvals. When stages have no owner or expected time, a digital pipeline simply reproduces the disorder more neatly. Agree on the minimum viable process first, then test how naturally a product supports it without elaborate workarounds.
A configured platform is often better than a ground-up build
There is a practical middle ground between a packaged ATS and a custom build: configure stages, fields, roles, templates, reports, and integrations in an existing platform. This works when the core process is standard and the company-specific differences can be expressed through configuration and a few reliable connections to email, calendars, a careers site, or an HRIS.
Compare critical journeys rather than feature counts in a sales deck. Create a test role, move a candidate through it, collect interviewer feedback, produce a report, restrict access, and delete the test data. If this works without manual workarounds, a custom system is probably premature.
When a custom hiring system may be justified
A custom system can make sense when hiring is part of a distinctive operating model: unusual candidate sources, specialized roles and approvals, high-volume workflows, proprietary portals, specific documents, local requirements, or deep connections to operational systems. The difference should affect business performance, not merely reflect discomfort with a packaged product’s interface.
Before building, estimate total ownership cost: discovery, design, integrations, migration, security, testing, infrastructure, support, regulatory changes, and user training. Configuration or a small integration layer is usually safer when it solves the real constraint. A custom build is justified when packaged products repeatedly fail in critical journeys and that failure already creates measurable operational loss.
Access control and decision history are core requirements
Candidate information should not be available to an entire company through one shared link. Define who can see contact data, assess an interview, move a stage, export records, and administer rules. Least-necessary access reduces accidental disclosure and separates interviewer judgment from administrative control.
The system should preserve an understandable history: who changed a status, when the change happened, which decision was made, what action is due, and which information moved downstream. This is not a reason to collect everything. History should support work and incident review, while sensitive information needs separate restrictions, a retention rule, and controlled deletion.
Design data and retention before migration
The ICO notes that recruitment involves personal and sometimes sensitive information, and that data must not be retained longer than necessary. The appropriate period depends on purpose, law, and organizational context. Before import, define the legal basis, candidate notice, data categories, access, review periods, and deletion process for each applicable jurisdiction.
Do not migrate an old folder or workbook in full merely because the tool allows it. Remove duplicates, separate active hiring from archives, verify the source and currency of contact details, agree on the target fields, and assign a data-quality owner. Legal requirements vary by market, so technical configuration does not replace advice on the law that applies to the organization.
Pilot one real role
Choose a role that follows a representative but not unusually risky journey. Capture a baseline: time to first response, feedback delay, manual data transfers, missed actions, report preparation time, and the share of candidates without a next step. Then run the same workflow through the proposed solution with a small real team.
The pilot should test the full loop rather than a polished screen: application, review, interview, feedback, decision, communication, reporting, permissions, and deletion of test records. Collect user friction and compare outcomes with the baseline. Scale only when the system reduces coordination cost without creating hidden manual work elsewhere.
Decision matrix: keep, configure, buy, or build
Keep the spreadsheet when hiring is occasional, simple, and controlled by one owner. Choose an off-the-shelf ATS for a standard pipeline, shared work, history, reporting, and role-based access. Configure a platform when the standard core fits but custom fields, rules, and a few integrations are required. Consider a custom system when distinctive critical workflows recur and the market cannot support them without permanent workarounds.
The decision should produce a short artifact: process map, mandatory journeys, roles, integrations, data model, retention requirements, pilot measures, ownership cost, and migration plan. This creates an equal basis for comparison and makes it possible to choose the simplest option that genuinely solves the problem.