Recruiters across four clients were manually reading every CV and application that came in — up to 400 a day. There was no filtering, no scoring, no summary. A recruiter would open an application, read the CV, cross-reference it against the job description, make a judgement call, update the record, and move the stage. 30 minutes per application. Most of that time was spent on candidates who should never have been seen.
I designed and built a three-stage AI pipeline to sit in front of that process. The workflow triggers on new applications in Zoho Recruit, retrieves the CV from Google Drive, handles file conversion if needed, then passes the document through three chained Gemini LLM nodes — each feeding into the next. The first node extracts and summarises the CV. The second extracts structured information from the application. The third rates the application against the specific job description and generates reasoning for its score.
The workflow writes all of this back to the application record in Zoho — the CV summary, skills extracted, application rating, and the reasoning behind it. It then routes the application to the appropriate stage automatically: the bottom 40% that don't meet the minimum standard never reach a recruiter. The rest land in a reviewed queue with everything a recruiter needs visible in 10 minutes instead of 30.
- 30 min → 10 min per application review (67% reduction)
- Bottom 40% of applications filtered before any human review
- Team capacity: 10–12 roles/month → 30–36 roles/month (3× increase)
- Deployed across all four clients: Talent Shore, Teach Now, Flexy Support, Remote Choice
- Three chained LLM nodes — output from each feeds the next before writing back to Zoho
- Built from scratch in 3 weeks while still learning n8n and the Zoho API
The mehg_AI_n outbound AI calling bot was an existing system when I came to work on it. The infrastructure was in place — HeyReach triggering the workflow, Gemini handling conversation logic, HubSpot receiving the outcomes. The system was running but lead generation was low. I was not responsible for the original build.
What I identified was that the AI message responses were generic — the prompt design wasn't giving the model enough context about who it was talking to or what a qualified response looked like. I redesigned the prompts for the conversation response nodes, giving the model clearer persona framing, better qualification criteria, and more specific instructions for how to handle different response types from leads.
The workflow itself handles a significant amount of branching — different response paths depending on whether a connection is new, whether a conversation is already in progress, deal stage conditions in HubSpot, and various follow-up actions. My change was surgical: the prompt logic, not the plumbing.
- Lead generation: 3–6 per week → 25–32 per week (roughly 5× increase)
- Change was specifically prompt redesign — not a rebuild of the underlying system
- Deployed across Talent Shore and Remote Choice
The problem was straightforward: client and candidate emails were landing in individual staff inboxes and getting missed. There was no central visibility, no routing, no way to ensure the right team saw the right message. The goal was to ingest emails from multiple staff accounts and forward them to the appropriate team inbox automatically — without requiring staff to change how they worked.
The technical constraint was the interesting part. Google's standard OAuth2 flow requires each user to individually authorise access. For 11+ staff accounts, that's not practical in an automated system. The solution was Google Workspace domain-wide delegation — a Google Cloud service account granted authority to impersonate any user in the domain. I wrote custom JWT construction code in n8n: building the header and claim set, signing with RSA-SHA256 using the service account private key, exchanging for a short-lived bearer token, then querying each user's inbox as them.
The ingestion workflow runs 11 parallel lanes — one per staff account — each generating its own token, fetching unread emails since the previous run (with a Monday edge case to catch Friday's emails), decoding the Base64 MIME body recursively to handle nested multipart structures, deduplicating, and forwarding to the classification engine. The routing workflow receives each email via webhook, runs AI classification to determine department (IT/Support/HR/Finance/Other), retrieves the correct team signature, constructs a raw RFC 2822 formatted email, sends it via the Gmail API impersonating the original recipient, and marks the source email as read.
This system was not moved to production. The decision was made at a business level — not because the system didn't work. The build demonstrates domain-wide delegation, manual JWT cryptography in a code node, recursive MIME parsing, and a parallel multi-account ingestion pattern that I haven't seen documented anywhere in the n8n community.
- 11 parallel ingestion lanes, each with independent JWT auth against the Gmail API
- Manual RSA-SHA256 JWT construction — no OAuth library, built from scratch in a code node
- Recursive MIME parser handling nested multipart email structures
- AI classification routing to IT / Support / HR / Finance / Other team inboxes
- Monday edge case logic to catch emails from the weekend
- Not shipped due to a business decision, not a technical one
