Hiring pipeline stages that are not project boards

Hiring pipeline stages are named states a candidate occupies from first application to hired or rejected. They often appear as columns that look like a Kanban board. That visual rhyme is why teams treat recruiting as a project board and then wonder why “cards” do not behave like delivery tasks. This page designs those hiring states. It is not a definition of applicant-tracking software — that stays on what an ATS is. It is not the week-by-week operating checklist — that stays on the recruitment hiring checklist. Commercial product context is Dayzen recruitment.

Dayzen PMS is a Project Management System for delivery work. It is not the recruitment pipeline. Do not park candidates on a project board because the columns look similar. Dayzen recruitment includes an interview pipeline with Kanban-style stages as hiring states. There is no AI ranking of applicants in that product claim. Humans move people between stages; the board records the state.

A stage is a candidate state, not a task

A project card usually means: work to be done, an owner, a due date, and a definition of done. When the work finishes, the card leaves the board. A hiring stage means: this person, for this job (or this application), is in a named decision state. The candidate is not “done” when they leave a column. They have been screened, interviewed, offered, hired, or rejected. The board is a map of where decisions stand, not a list of recruiter chores.

That distinction matters in three practical ways:

• Identity: the unit is a person linked to an application, not a work item you can clone for a sprint.
• Outcome: terminal states are hired or rejected (and sometimes withdrawn). There is no “deployed to production.”
• Time: ageing in a stage is a hiring-risk signal (someone stuck in interview), not a story-point burn.

If your team builds hiring on a project tool, you will still need a candidate identity, a job requisition, offer facts, and an audit of who changed the stage. A delivery board does not grow those objects by looking like columns.

A default stage set that Indian SME teams can actually run

Keep the number of stages small enough that every interviewer uses the same words. A workable default:

1. Applied — an application exists against a job. Screening has not started, or has not produced a decision.
2. Screen — recruiter or hiring manager has reviewed the application (CV, form, or portal fields) and is deciding whether to interview.
3. Interview — one or more scheduled conversations. You may subdivide later (assignment, panel) if volume forces it; do not start with eight interview columns.
4. Offer — the organisation has decided to offer, or an offer is out. Compensation and joining date now matter as facts, not as chat.
5. Hired — offer accepted and the person is the hire for that requisition. Handoff to onboarding is a different article.
6. Rejected — a terminal no at any earlier stage, with a reason you are willing to stand behind.

Withdrawn (candidate declined or went silent after a written timeout) can sit as a sibling terminal state if you do not want it mixed into rejected. The point is that every application has exactly one current stage for that job. A person applying to two jobs can have two applications and two stages. That is not a duplicate employee; it is two hiring processes. Duplicate employee records become a problem after hire if identity is messy — not something to solve by merging Kanban cards.

What each stage must contain besides the column name

A column without exit rules is interior decoration. For each stage, write:

• Who may move the candidate in and out (recruiter, hiring manager, a named interviewer).
• What evidence is required to leave (screen note, interview feedback, offer approval).
• What “stuck” means in calendar days, so ageing is visible.
• Whether the candidate is notified, and with what template, when they are rejected from that stage.

Do not invent a national SLA. Publish your own. Silence in Interview for three weeks is an operating failure even if nobody missed a “task due date.”

Why the board looks like Kanban and still is not a project board

Kanban, in delivery, visualises work-in-progress limits and flow of tasks. Hiring borrowed the visual because recruiters need to see volume per stage. The shared idea is limited WIP and visible flow. The object on the card is different.

	Hiring pipeline stage	Project Management System board
Unit	Candidate application	Delivery task or issue
Done	Hired, rejected, or withdrawn	Work accepted against a definition of done
Owner	Recruiter / hiring manager for a requisition	Assignee for a piece of delivery
Legal-ish payload	Identity, offer, documents	Usually none of that
Dayzen home	Recruitment interview pipeline	PMS for delivery

Use the project system for opening a new office, building a product increment, or tracking an HR implementation project. Use recruitment stages for people you might employ. Mixing them produces orphan cards with no application ID and hiring managers who “move the ticket to done” when they merely finished a call.

Stage hygiene that prevents fake progress

Teams inflate boards when they are afraid to reject. Applied becomes a dumping ground. Interview becomes a parking lot for people nobody will schedule. Offer becomes “we are still thinking.” Hygiene rules:

• Applied is not a talent pool. If you are not screening, say so with a held-requisition or talent-community label outside the live pipeline, or close the job. A thousand Applied cards is not a pipeline.
• Screen must produce a yes, no, or hold with a date. “Looks interesting” is not a stage exit.
• Interview requires a scheduled event or a written reason it is waiting on the candidate. Do not keep people in Interview because the hiring manager is travelling unless you have a hold reason.
• Offer is not a vibe. There is a template, a CTC (or a written range the approver accepted), a joining date, and an expiry if you use one.
• Hired is not onboarding complete. Hired means this requisition is filled by this person. Activation work after that is onboarding, not another interview column.
• Rejected needs a reason code you can report (skills, compensation, culture add, duplicate application, incomplete form) without writing a novel in the card.

None of this is AI ranking. Ordering the Applied list by last updated, source, or a human screen score you typed is still a human process. Do not describe Dayzen recruitment as ranking candidates with a model. The pipeline records states; it does not choose your hire.

Requisitions, applications, and people — three objects

Confusion with project boards often comes from flattening those three:

1. A job / requisition is the opening (title, department, status open or closed).
2. An application is one person’s attempt at that opening.
3. A person / candidate is the identity that may have several applications over time.

Stages hang on the application (or on the candidate-for-this-job). If you only have people and no job, you cannot say which opening they are in Offer for. If you only have jobs and no people identity, you cannot prevent the same human sitting in Interview twice under two email spellings. An ATS is the category of system that holds those objects; the guide already defines it. This page only insists that stages attach to applications, not to anonymous sticky notes.

When the job is filled, remaining applications should leave the live pipeline: reject with a notice, or move to a closed-requisition archive. Leaving them in Interview because “we might need backup” without a named waitlist policy is how you ghost people.

Interviews as events inside a stage, not as extra boards

A common over-build is one Kanban board per interview round, plus a project board for “schedule panel,” plus a spreadsheet for feedback. Prefer one pipeline. Inside Interview, store:

• The scheduled time and interviewers.
• Feedback captured against the candidate, not in a private chat that never hits the record.
• The decision that exits Interview: advance to Offer, another interview you have actually named, or Rejected.

If you truly run a distinct assignment stage, add one column. Do not add a parallel project board for “send assignment” unless you are tracking internal operations work that is not the candidate’s state. Recruiter chores can live in a personal list. The candidate’s state must remain one field the hiring manager can trust.

What the hiring checklist still owns

Sourcing channels, who signs off a requisition, how you run a structured interview, background-check vendors, and the offer-approval ladder are operating steps. They belong on the recruitment hiring checklist. This article does not retell them. It only requires that each of those steps changes or confirms a stage instead of happening in a side channel that leaves the board lying.

Likewise, converting hired into an employee identity, documents, and day-one access is onboarding after handoff — not a seventh pipeline column called “joining formalities” that never ends.

A short working agreement for the board

Pin something this short next to the pipeline:

1. Every live application has one stage from the published set.
2. Only named roles move stages, and a move needs the evidence that stage requires.
3. Rejected and hired are terminal for that application.
4. We do not manage candidates on the Project Management System board.
5. We do not pretend a model ranked the list.

Dayzen recruitment is where those Kanban hiring states live as an interview pipeline. Dayzen PMS remains delivery. If the columns ever start to feel like sprint tickets, you have drifted: put the work tasks back in the project system and leave people in recruitment stages. The ATS guide stays the category definition; the hiring checklist stays the ops sequence. Use this page when the argument is what a column means.