Most problems with hiring software are setup problems. The system is fine. Someone designed a process nobody could keep tidy, and a year later the reports mean nothing.
Stages and statuses are not the same thing
These get mixed up constantly, and they do different jobs.
- A stage is where someone is in the process. Applied, screened, interview, final, offer. Stages only move forward.
- A status is what is happening to them right now. Active, waiting on the candidate, waiting on an interviewer, on hold, rejected, withdrawn. A status does not mean progress.
Mix them and you get stages like "waiting on hiring manager". That ruins every report you will ever run, because now a percentage between two stages includes something that is not a step.
How many stages
As many as your process actually has, and no more. Five to seven is normal.
The test: could two recruiters looking at the same candidate agree which stage they are in, without discussing it? If not, your stages are not real.
The common mistake is adding a stage for an activity rather than a position. "Reference check" is usually a status inside the offer stage — nobody is being held there while a decision is made.
The most valuable field in the system
Rejection reasons. And the most neglected, because filling them in feels like admin at the exact moment the work is over.
Keep the list short — eight to twelve options — and make them mean something. "Did not meet requirement X" tells you something later. "Not a fit" does not.
This field is what makes the reporting in Module 10 possible, it is the first thing anyone asks for in a bias check, and it cannot be reconstructed afterwards.
Permissions, set up before you need them
| Setting | Why |
|---|---|
| Hiring managers see only their own jobs | Keeps candidate data to who needs it, and stops informal poaching between jobs |
| Scorecards lock once submitted | Makes independent scoring real rather than a request |
| Diversity data hidden from decision makers | They should not see it when deciding |
| History log switched on | You cannot show what happened without one |
| Only one or two people can delete | A deletion policy means nothing if anyone can wipe records |
What to automate on day one
- A confirmation when someone applies, with honest timings.
- Rejection at the applied stage, on a short delay.
- Interview confirmations and reminders.
- Nudges to interviewers who have not filled in a scorecard.
- An alert when a candidate has sat in one stage too long. This is the most useful automation in any hiring system, because it catches people quietly going cold.
Leave these switched off at first: anything that rejects without review, anything that messages candidates in a personal voice, and anything triggered by a score.
Designing something you will keep tidy
Staying tidy is a design question, not a discipline question. The processes that stay clean have three things: few enough stages that moving someone is one click, only the required fields that reporting genuinely needs, and a weekly review where anything stale gets moved or closed.
If you find yourself planning to "remind everyone to update the system", the design is wrong. People do not update things that are slow to update.
Before you configure anything
Write your process on paper first — the stages, who moves someone between them, and what has to be true to progress. Setting up the software before deciding the process means you inherit the supplier's assumptions about how you hire, for years.