Recruitment Operations Pipeline
n8n, DeepSeek, Google Sheets, Gmail, Google Drive, Google Calendar/80 nodes
Not deployed with a client, no usage metrics.
01
The problem
Screening is the part of recruitment everyone automates. It is also the easiest part.
The harder problems sit around it. Who decided what good means for this role, and is that definition written down anywhere a machine could apply consistently. Whether the candidate screened on Thursday was judged the same way as the one screened on Monday. What happens to the eighty percent who are not hired, which for most agencies is nothing, and the database decays. Whether anyone can explain a rejection six weeks later. Who is chasing the calendar back-and-forth to book a phone screen.
A screening automation solves one step and leaves the rest manual.
02
The solution
The whole flow, from a hiring manager opening a role to an interview appearing in a calendar, with an outcome recorded for every applicant. Four entry points, because a hiring process does not start in one place.
Screenshot 1 of 3
03
Architecture
The rubric is generated once, at requisition time
When a role opens, the requirements are turned into a weighted scoring rubric. Must-haves carry three times the weight of nice-to-haves, and each entry includes a note describing what genuine evidence in a CV would look like, so a real match can be distinguished from a keyword match.
Every candidate for that role is scored against that same stored rubric. This is the structural reason the comparison holds up.
Intake is defensive
Disposable email domains are rejected. The PDF is checked. Prior applications from the same address are looked up, and a 90-day reapply window distinguishes a duplicate from a returning candidate, which is useful signal rather than noise.
Nothing reaches a candidate without approval
Generated questionnaires go to the recruiter through an email approval gate with a 48-hour timeout before the candidate sees anything.
Scheduling is arithmetic
Working days, business hours, a configurable buffer between interviews, and a 48-hour minimum notice. Three slots are computed, the first is booked and the other two are offered as alternatives.
Every applicant gets an outcome
Strong candidates progress. Near misses go to a talent pool with a 90-day revisit date. Uncertain cases go to a human with the specific disagreement stated. Rejections carry a written reason.
The four triggers
- 1
Requisition form
Hiring manager opens a role. Requirements are validated, an advert is drafted, and the weighted rubric is generated and stored.
- 2
Application form
Candidate applies. Validation, duplicate check, CV archive, text extraction, redaction, scoring against that role's rubric, then banding into strong, maybe, review or reject.
- 3
Questionnaire form
Candidate answers questions built from what their CV left unclear. Answers are assessed and combined with the CV score at 60/40. Pass that and the system books the interview.
- 4
Weekday schedule
Nobody triggers this. At 8am it reads yesterday's activity, counts it in code, then has the model write it up.
04
The AI components
Eight model calls, each narrow: draft advert, build rubric, score CV, generate questionnaire, assess answers, draft invitation, draft rejection, write digest.
| Call | What it does | What bounds it |
|---|---|---|
| Draft advert | Turns validated requirements into a job advert | Schema on the output parser |
| Build rubric | Turns the same requirements into a weighted rubric with evidence notes | Schema, with the weighting applied in code |
| Score CV | Judges redacted CV text against the stored rubric | Schema, and the weighted total is recomputed in code |
| Generate questionnaire | Builds questions from what the CV left unclear | Schema, then a recruiter approval gate before sending |
| Assess answers | Reads the questionnaire responses | Schema, then combined with the CV score in code at 60/40 |
| Draft invitation | Writes the interview invitation | The slot is already chosen by the scheduling arithmetic |
| Draft rejection | Writes the rejection note | The outcome is already decided by the banding logic |
| Write digest | Writes up yesterday's activity | The counting happens in code first |
Every one is bounded by a schema or by surrounding code. The model never decides an outcome, never picks a time, and never sees raw data it could misread. In the digest, the counting happens in code first and the model only writes it up.
05
What I changed from the starting template
The template was a 30-node job posting flow using OpenAI, Airtable and an AI agent with a calendar tool attached.
- Removed agent-driven scheduling. The original let the model decide when to book meetings. Replaced with four nodes doing deterministic slot selection, plus a failure path when nothing is free.
- Added the rubric layer. The template scored against a free-text job description.
- Added the approval gate. Nothing candidate-facing sends automatically.
- Added a hard-fail rule. Any must-have marked not met caps the candidate regardless of total score.
- Added the talent pool and revisit dates. The template discarded everyone it did not shortlist.
- Added the daily digest.
- Moved off Airtable and SMTP onto Google Sheets and Gmail, so the system runs on credentials a small agency already has.
- Swapped OpenAI for DeepSeek throughout, converting single-message nodes into chains with attached models and structured parsers.
Design decision worth defending
Slot selection is arithmetic, and the model is not involved
A language model deciding when to put a meeting in someone's calendar is a bad idea. It has no reliable concept of a working week, it cannot be trusted to respect a buffer, and when it gets it wrong the failure is visible to a candidate.
Slot selection is arithmetic, and the model is not involved. It writes the invitation after the time has already been chosen.
06
Expected impact
Unmeasured. No live pipeline.
- Consistency by construction, one rubric per role applied to everyone
- A defensible record for every applicant, including the rejected ones
- The unhired eighty percent stop being lost, landing in a pool with a revisit date and a note on what was strong
- Coordination time removed, which is the part recruiters describe as the grind
- Human judgement kept where it belongs, with approval before contact and escalation on uncertainty
07
Technical notes
- Four independent triggers in one workflow, converging on shared logic
- Weighted scoring with a hard-fail override on unmet must-haves
- Blended score, 55% model and 45% evidence coverage, with a 25-point disagreement threshold routing to a human
- Combined CV and questionnaire scoring at 60/40, with a low-effort cap
- Slot selection with buffers, lead time and a five-day search horizon
- Approval gate with a 48-hour timeout that fails closed
- Nine code nodes handling validation, deduplication, redaction, scoring arithmetic, slot maths and digest aggregation
- Retries on every external call, no silent failures
08
What I would add next
- Interview feedback capture, closing the loop on whether scores predicted anything
- Calibration reporting, rubric scores against actual hires over time
- Multi-interviewer scheduling with availability intersection
- Candidate-facing status page instead of email-only updates
- Persistent audit log, since Sheets is convenient rather than robust
- Bulk reprocessing when a rubric is revised mid-role
Have a process worth automating?
Book a free 30 minute call. Talk me through the steps your team repeats every week and I will tell you what is worth automating and what should stay manual.