TEMPLATE

Recruitment Project Template

A pipeline for the work before someone joins, from an approved role through sourcing, screening and interviews, ending the moment an offer is accepted.

Recruitment template
Role opened
Backend Engineer, req approved
Sourcing
Sr. Designer, 12 profiles sourced
Screening · 6 max
A. Kulkarni, phone screen Wed
Interviewing · 4 max
Sr. Designer, panel round, final
Offer
Sr. Designer, offer drafted

A card leaves this board the moment an offer is accepted. Onboarding starts on a different board from there.

Why most recruitment templates stop being used

A hiring pipeline is easy to draw and hard to keep current, because the information that should update it (a rejection, a scheduling delay, a candidate who's gone quiet) arrives scattered across email threads, a phone call and someone's memory of a hallway conversation. A board that only gets updated when someone remembers to open it stops being a source of truth within a couple of weeks.

Every open role competes for the same unlimited attention. Without a cap on how many candidates are actively in screening or interviewing at once, a hiring manager ends up with fourteen half-read resumes and three candidates waiting on feedback that never comes, and good candidates go elsewhere while they wait, often to a competitor who simply responded faster.

Interview feedback lives in someone's inbox. A panel member's notes, sent as a reply-all email, are functionally lost the moment the thread gets long. Feedback that isn't attached to the candidate's card doesn't inform the next round or the hiring decision, and two interviewers on the same panel can walk away with contradictory impressions that never get reconciled.

It quietly extends past the point where it should stop. Recruitment's job is to produce a signed offer, not to manage what happens after. Provisioning a laptop, running a first week, scheduling 30-day check-ins is a different process with a different owner, covered by the employee onboarding template. Templates that try to do both tend to do neither well, and the recruiter ends up chasing IT tickets long after their actual job on that hire is finished.

Rejected candidates disappear without a trace. A candidate who doesn't get the role this time but was strong is worth remembering for the next opening, and a pipeline with no record of past candidates means every search starts from zero even when a good near-miss from six months ago would have been a faster hire.

Multiple roles blur into one undifferentiated list. A hiring manager tracking three open roles in one flat list can't easily tell whether the backend engineer search is slower than usual or whether that's just how long backend searches take. Splitting roles onto their own cards, all moving through the same columns, is what makes that comparison possible at all.

What's inside

The structure, and why each part is there

Role opened

A card created only once a requisition is actually approved, not when a manager first mentions wanting to hire someone. This keeps the pipeline honest about which roles are real and stops the board filling with aspirational openings that never get budget.

Sourcing

Where candidates are gathered before anyone's spoken to them. A running count here is a useful early signal of whether a role is going to be hard to fill, well before the deadline everyone agreed to at the start makes that obvious.

Screening, capped

A limit on active screens per recruiter, so candidates get a timely first response instead of sitting unread behind whoever applied earlier. Slow first responses are one of the most common reasons strong candidates drop out of a process before it's really begun.

Interviewing, capped

A limit on how many candidates are in active interview loops at once, per role. Beyond the cap, a role's pipeline is deliberately deep rather than accidentally wide, and every candidate in it gets a real answer within a reasonable window.

A candidate page per hire

The built-in wiki holds interview notes and panel feedback next to the candidate's card, with page history, so a hiring decision has a written record instead of a memory of who said what in a debrief that happened two weeks ago.

An offer stage that ends the board

Once an offer is accepted, the card's job here is done. The new hire's onboarding starts as a fresh card on a different board. This template doesn't try to follow them past the offer into their first week.

One subscription across HR and every hiring team

Recruitment sits on the same account as engineering's, marketing's and operations' boards. One subscription, each team with its own template and vocabulary, rather than a separate tool bought just for hiring.

How to use it

  1. 01Open a workspace and load the recruitment template. A sample role is already moving through the columns, so the structure is visible before a real requisition is added. Free for up to five people, permanently.
  2. 02Only open a card once a requisition is formally approved. A pipeline full of roles that might get budget isn't a pipeline. It's a wishlist, and it makes real progress harder to see.
  3. 03Set screening and interviewing limits per recruiter, not per role. A recruiter handling four open roles at once needs a total cap across all of them, or all four degrade together while the number for any single role looks fine.
  4. 04Require panel feedback on the candidate's page before the next round is scheduled. Making the next step depend on it is the only way feedback reliably gets written down instead of summarised from memory a week later.
  5. 05When an offer is accepted, close the card and open one on the employee onboarding board. Carry over the start date and manager; nothing else needs to follow, and starting fresh keeps onboarding from inheriting recruitment's paperwork.
  6. 06Keep strong rejected candidates on a short list linked from the wiki, tagged by role type. The next opening in the same area starts with real leads instead of an empty sourcing column.

The structure works in any tool with columns and per-stage limits. It's written up here because the two failure modes are so common: pipelines with no cap that stall out under a busy hiring quarter, and pipelines that never formally end, quietly turning into an onboarding checklist nobody designed for that purpose. What actually changes when a hiring team runs this on ShipSprint is smaller than it sounds: the WIP limits stop candidates going unread, and the candidate wiki page means the panel's reasoning survives the two weeks between the debrief and the actual hiring decision.

If you take three things
  • Cap active screens and interviews per recruiter, or every candidate's response time degrades together
  • Keep interview feedback attached to the candidate, not scattered across email threads
  • This board ends at an accepted offer. Onboarding is a separate board that starts from there
FAQ

Common questions

It's a project board shaped for a hiring pipeline, not a dedicated ATS. There's no resume parsing or job-board posting built in. What it does give you is columns, WIP limits, candidate pages and a clean handoff to onboarding, all on the same subscription as every other team's boards.

Keep reading

Related pages

See it on your own work.

A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.

14-day full-access trial · sample project included · no card required