Vendors quote implementation in weeks: one to two days for a light system, several weeks for an enterprise one. Those numbers describe configuration work. They do not describe the thing that determines whether the system is used, which is what your own team does in the first week.
Implementations rarely fail technically. They fail because people keep working the old way.
Decisions to make before day one
Four, and none of them are software questions:
- Your stages. Four to six, with a clear meaning for each. Not a reproduction of whatever your spreadsheet status column accumulated.
- Your evaluation criteria per role family, with anchors — scorecards.
- Who has access to what. "Everyone sees everything" is not a permission model, and it is difficult to walk back later.
- Your retention periods. Configure them at setup. Retrofitting retention onto a populated system is significantly more work than setting it at the start: the framework.
The first week
Day 1 — configure the spine
Stages, roles and permissions, email templates, and the retention configuration. Resist the temptation to configure everything. A minimal setup that people use beats a complete one they avoid.
Day 2 — connect the calendar
Before anything else, because it delivers the most visible relief. Every interviewer connects their calendar; test self-scheduling with a real booking. See which integrations matter.
Day 3 — move one live requisition
One role, one recruiter, end to end. Every problem you will encounter appears here, at a fraction of the cost of encountering it across all roles at once. Fix what surfaces before going wider.
Day 4 — train by doing
Not a session walking through the interface. Give each recruiter a real candidate to advance, a real scorecard to complete, and a real rejection to send. Thirty minutes of doing beats two hours of watching.
Hiring managers and interviewers need less than people assume: how to find their candidates, how to submit a scorecard, and how to know when they are needed. Anything more will not be retained.
Day 5 — publish one role and watch it end to end
Post to your careers page and your boards, confirm the application flow works on a phone, verify the confirmation email arrives, and check the source is recorded. Then apply to your own role as a test. This catches more real problems than any checklist.
Where implementations actually fail
Running both systems
The most common and most predictable failure. Within two weeks the spreadsheet is authoritative again, because it is familiar. Set a cutover date, archive the old file read-only, and do not reopen it.
Over-configuring
Twelve stages, twenty custom fields and four approval workflows on day one. Every field somebody has to fill in is a reason to avoid the system. Start minimal and add only what people ask for.
Skipping the hiring managers
If they never log in, their feedback returns by email and the record fragments. Give them one thing to do in the system in week one — submit a scorecard — and make it easy enough that they succeed.
No named owner
Someone has to own configuration decisions after launch. Without one, every question becomes a group discussion and the answer is usually to keep doing it the old way.
The thirty-day review
Book it before you launch. Five questions:
- Which stages are not being used, and why?
- Which fields are empty most of the time? Remove them.
- Where are people still working around the system?
- Are scorecards being submitted before debriefs, or after?
- What does the funnel report say, and does anyone believe it?
The last question matters most. If the numbers are wrong, people stop trusting the system, and usage decays from there. Wrong numbers at thirty days almost always mean stage definitions do not match how people actually work — which is a configuration fix, not a data problem.
If you are coming from spreadsheets, the migration decisions are covered separately in from spreadsheets to an ATS.