Applicant Tracking on a Spreadsheet: The Exact Point Where It Breaks.
Every company hires on a spreadsheet at first, and the spreadsheet works. One sheet, one row per candidate, columns for stage, interviewer and notes. The office manager owns it. Twenty hires go through it without a problem, and the company concludes that applicant tracking is a solved problem it does not need to buy software for.
Then it breaks, and it does not break on volume. It breaks on a specific afternoon, and it is worth knowing exactly which one.
The afternoon it breaks.
A hiring manager interviews a candidate at two o'clock and decides to move them to the offer stage. She emails the coordinator. At the same time the coordinator, working from the sheet, which still says interview, schedules the candidate for a second interview with someone else and emails the candidate. The candidate now has an offer in one person's head, a second interview in their inbox, and a row in the sheet that says neither.
That is the break. Not two hundred candidates; two people acting on one candidate at the same time. A spreadsheet is a single record with a single state, and the moment a process has two actors, the state leaves the sheet and lives in email, and the sheet becomes a copy that somebody updates later, if they remember.
It arrives earlier than people expect. A company of forty with two open roles and a hiring manager who is not the coordinator has already crossed the line. The sheet looks fine because the breakage is invisible: it shows up as a candidate who went quiet, which gets blamed on the candidate.
What the break costs.
Three things, and only one of them is obvious.
Lost candidates. The one who got a second-interview email after a verbal offer, and took the other job. The one whose row said rejected because a column was sorted and the cells came apart. The one nobody followed up because the owner column was blank. In a market where the good candidates have three conversations running, a week of silence is a loss, and the sheet cannot tell you it happened.
Double work. Two people scheduling the same interview, two people chasing the same reference, the coordinator rebuilding the sheet from email every Friday. This is the cost that is paid continuously and never counted, because it is spread across people whose job is not hiring.
The question nobody can answer. Six months later, someone asks who was rejected for a role and why, and when. Perhaps a candidate asks. Perhaps a regulator does. The sheet has a stage column that was overwritten each time the stage changed, and the reasons are in email threads that have left with the people who wrote them. There is no log, because a spreadsheet does not keep one.
The fix is not an enterprise system.
The reflex is to buy an applicant tracking system, and for a company of forty that usually means paying for a product built for recruiting teams of ten, with a careers site, candidate relationship marketing and reporting nobody will open. It also means a new silo: the hire exists in the recruiting tool and is re-keyed into the HR system on their first day, with the same offer letter data typed twice.
The middle path is a candidate record in the suite the company already runs. Most mid-market companies on Zoho have a people application already, or a CRM whose record model does exactly what hiring needs: a record with stages, an owner, a log of every change, and notes attached to it rather than scattered through inboxes. Building a candidate module there takes days, not a procurement cycle, and it fixes the break directly.
The candidate has one record and one state, and both the hiring manager and the coordinator read and change that record. The stage moves through a defined sequence, applied, screened, interviewed, offered, hired, with the rule that a stage cannot be skipped, which is the same mechanism a sales pipeline uses. The owner is a field, so a blank is visible. The log is automatic, so the question six months later has an answer: who moved the stage, when, and the note they left.
We described the general case in the piece on replacing internal spreadsheets with tools; hiring is the sharpest instance of it, because the cost of the break is a person who does not join.
The handoff that decides whether it was worth it.
The reason to build the candidate record in the suite rather than beside it is what happens on the day the candidate says yes. In a stand-alone tool, the hire is exported and re-entered into the HR system, and the offer details are typed again, with the usual error rate. In the suite, the candidate record becomes the employee record: the same fields, carried across, with onboarding tasks created from the hire date. The person who accepted on Friday has a laptop order, an account request and a first-week plan on Monday, because the hire triggered them, and nobody re-keyed anything.
That handoff is where the people process stops being a spreadsheet problem and becomes part of the company's integrated operations. Zoho's people application handles onboarding well once the hire arrives as a record; the candidate module is what makes it arrive as one.
What to leave out.
The temptation, once the record exists, is to rebuild the enterprise product inside the suite: a careers page, automated screening, scoring, nurture sequences for past candidates. Leave all of it out at first. The break was concurrency and the missing log, and the fix is a record with stages, an owner and a history. A company that hires twelve people a year does not need candidate scoring; it needs to know, on any afternoon, which stage each of its nine open candidates is in and whose move it is. Add the careers form when the volume of applications makes copying from email the bottleneck, which is a different and later problem, and add nothing else until someone can name the afternoon it would have saved.
How to tell if you have already crossed the line.
Three questions. Do two different people change a candidate's state, in the same week, without talking? Has a candidate ever received two contradictory messages from the company? Can you say, for the last role you filled, who was rejected and why, from a record rather than from memory?
If the answer to the first is yes, the sheet is already a copy. If the answer to the third is no, the log you do not have is the one you will be asked for. Neither is a volume problem, which is why the companies that wait for volume wait too long.
The build is small: a candidate module with stages, owners and a log, the stage rule, and the handoff to onboarding. Discovery is no-risk: we read your current sheet and your people system, show you where the break has already happened, and you pay only if you go ahead.
Find out what one connected Zoho system would change in the way you run.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Comments