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
- Copied into a personal tracker by the recruiter handling it
- Copied again 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
The same information kept moving by hand, and weekly reporting depended on one person assembling it.
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, not three times. Nobody reconciles trackers by hand any more.
Status is visible without anyone asking, which removed the most common reason candidates went quiet. The weekly report is opened, not assembled.
09What this means for you
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.
As your Executive Assistant
Here’s how the same thinking shows up on your desk.
Your hiring, in one view
Candidates, interviews and follow-ups kept in one place, so you can see where things stand at a glance.
Interviews that don’t slip
I coordinate times with candidates and your team, then chase the next step so nobody is left waiting.
A weekly update you don’t build
A short written summary of what moved, what’s stuck and what needs your decision.