01The Problem
Candidates were arriving from several directions at once — referrals, direct applications, sourcing — and each route landed somewhere different. A name could exist in a message thread, a personal spreadsheet and nowhere central, all at the same time.
The cost showed up as silence. Candidates went days without an update because nobody could tell whose turn it was, and the person who could have chased it didn’t know the candidate existed.
02The Old Process
- Candidate details typed into a form or message by whoever found them
- Re-typed into a personal tracker by the recruiter handling it
- Re-typed a third time into an update sent to the hiring side
- Status held in memory, or in a chat thread nobody else could see
- Weekly reporting rebuilt by hand from whichever files could be found
Three keystrokes of the same information, and a reporting task that could only be done by one person.
03The Objective
Capture candidate information once, make the current status visible to everyone who needs it without anyone being asked, and have the weekly report fall out of the same records rather than being assembled separately.
Two constraints: it had to stay inside the existing Microsoft 365 licence, and recruiters had to see their own candidates rather than everybody’s.
04My Approach
I mapped the real route a candidate took from first contact to onboarding, including the informal shortcuts. Then I looked for every point where the same fact got written down again — that list turned out to be the actual project.
The design decision that mattered most was direction. Personal trackers stopped being sources and became views: one master record holds the data, each recruiter works in a filtered slice, and information only ever flows one way. Two-way syncing sounds more helpful and is how you end up with two versions of the truth and an argument about which is current.
05The System
| Component | What it does |
|---|---|
| Intake form | Single capture point with required fields and controlled values, so a record cannot be created half-finished |
| Master tracker | One row per candidate, with stage, owner and timestamps — the only source everything else reads from |
| Recruiter views | Filtered slices so each recruiter sees their own candidates, kept in sync automatically |
| Stage notifications | Movement between stages triggers the message that used to be sent by hand |
| Follow-up prompts | Records sitting too long at a stage surface themselves instead of waiting to be noticed |
| Reporting layer | Reads the master directly, so the weekly view is current by definition |
Every write is timestamped. Nobody asked for that, and it costs nothing at build time — but the first time a record was disputed, the answer took ten seconds instead of a conversation.
06The Tools
| Tool | Role in the system |
|---|---|
| Microsoft Forms | Structured intake — the single capture point |
| SharePoint | Master record storage and the permission boundary between views |
| Power Automate | Synchronisation, timestamping, stage notifications and follow-up prompts |
| Microsoft Excel | Recruiter-facing views and the reporting layer |
| Outlook & Teams | Where the automated notifications land |
07The Workflow
What triggers what, in order:
- Form submitted → a master record is created with owner and stage set
- Record created → it appears in the assigned recruiter’s view, and they are notified
- Stage changed → timestamp written, next party notified automatically
- Stage unchanged past its expected window → the record is flagged for follow-up
- Any time → reporting reads the master, so it is never separately assembled
The loop guard matters here and is easy to get wrong: a flow that updates a record will re-trigger itself on its own edit. Each flow compares the new value against a stored copy of the last one and stops if they match.
08The Result
Candidate information is entered once. Manual reconciliation between trackers stopped being a task — nobody schedules it and nobody forgets it.
Status became visible without being requested, which removed the most common reason candidates went quiet. Weekly reporting stopped being something produced and became something looked at.
The clearest measure is what disappeared: a candidate is now entered once instead of three times, and the weekly report is opened rather than assembled.
09What this means for a CEO
You stop being a source of truth. Before this, knowing where hiring stood meant asking someone, and the answer was as current as their memory. Now the answer exists whether or not anyone is available to give it.
The practical version: your recruiters spend their week on candidates instead of on admin about candidates, and your weekly hiring picture arrives without anybody building it.
It also survives people leaving. The process lives in the system and the documentation, not in whoever set it up.