Recruitment Screening & Placement Automation

I built the first version in December 2025, from the first lead-ads connection, then the AI and CRM side. In July 2026 I mapped and audited the live campaigns that had grown out of it; one of the defects the audit found was in my own first version.

The problem

Applicants arrive from paid social lead ads and need screening fast — right-to-work status, experience, qualifications, and whether they live within a workable distance of the depot. Doing that by hand doesn't scale across multiple concurrent role campaigns, and slow responses lose candidates.

What was built

A loop rather than a pipeline, which is the interesting structural choice:

A lead ad creates the applicant in the CRM.
A CRM workflow alerts the team and posts only the contact ID to the automation layer.
The automation pulls the full record back, normalises fields, logs to a sheet, and injects the campaign's depot constants.
It geocodes the postcode and computes distance to the depot.
Screening logic evaluates right-to-work, experience, distance and qualifications, and decides Qualified / Clarifying / Parked.
An LLM drafts tailored copy; a tag builder sets tags.
It upserts the contact and creates an opportunity in the corresponding pipeline stage.
That stage landing is itself the trigger for the CRM's messaging workflows to send the candidate's email and, after a delay, a WhatsApp nudge.

The automation layer never messages a candidate directly. It moves them into a state, and the CRM does the talking — which keeps messaging, consent and channel handling in the system that owns them.

The hard part

Making it reusable rather than bespoke per campaign. Cloning a campaign changes five things — the webhook path, the depot coordinates, the qualification logic, the target pipeline, and the copy. Everything else is identical, and that's documented as a blueprint rather than left as tribal knowledge.

The audit was the other substantial contribution: in July 2026, reading both live systems, including campaigns that had grown out of the first build, surfaced real defects: two coexisting email paths that could diverge or double-send; a published CRM workflow posting to a webhook whose counterpart appeared inactive; four delay nodes with no incoming connections in the first version, so an intended human-like delay never ran at all; contradictory depot defaults between two nodes; a test spreadsheet wired as production; and two different phone normalisations producing inconsistent formats — which breaks WhatsApp's strict E.164 requirement.

A client request to remove unsubscribe links was raised as a compliance concern rather than implemented quietly.

What can be verified

Two campaigns running end to end in production
the clone pattern documented such that a new campaign changes five values and nothing else
the audit surfaced the specific defects listed above.

The workflows

The n8n graph for the screening loop: a webhook receives a new lead, fetches the contact from the CRM, normalises the fields, attaches a depot, geocodes the applicant's outcode, screens them, updates the contact, and then a rules router splits the outcome three ways - qualified, clarifying and parked - each creating its own opportunity record.

The screening loop. The router at the right is the whole design: every applicant lands in exactly one of three outcomes, and each outcome creates its own opportunity record rather than leaving the lead in an ambiguous state. Select the image to enlarge it — a graph this wide is not legible on a phone.

The CRM-side capture flow: a Facebook lead form submission notifies two people and then fires a webhook into n8n, where the screening graph above takes over.

The other half, in the CRM rather than n8n. This is where a paid-social lead arrives and gets handed to the screening graph - the boundary between the two systems, in three steps.

One of the three outcome sequences in the CRM: two different entry conditions - lacking qualifications, and no experience - both feed a single wait step and a single clarifying email.

What one of the three outcomes actually does. Two distinct reasons for needing clarification converge on one wait and one email, rather than each carrying its own copy of the sequence.

A wide n8n graph: a new sheet row triggers a naming fix and a lead append, a switch routes to one of three depot paths which merge again, the postcode is validated and a distance calculated, screening logic runs and its results are written back, an AI agent drafts the email, a parser and tag builder feed a three-way qualified / clarifying / parked switch, and each branch waits a randomised interval before creating or updating a contact and an opportunity, then updates the status.

The whole screening loop in one view: depot routing, a postcode and distance check, the screening decision, an AI-drafted email, then a randomised wait before anything is written to the CRM. The three depot names are covered. Select the image to enlarge it — a graph this wide is not legible on a phone.