Automated Résumé Screening & Scoring

Actual n8n workflow

Applicant Scoring Rubric

Every résumé is scored the same way, so the result is consistent no matter who runs it. Each candidate gets a 0–3 score on eight virtual-assistant roles, each with a one-line justification.

The eight roles (always scored in this order):

1. Recruiter - sourcing, screening, interviewing, pipeline/ATS management, offers.
2. Scheduler - shift and appointment coordination, calendars, dispatch, staffing coverage.
3. Admin - general admin and EA work, data entry, documentation, office operations.
4. Customer Support - inbound and outbound support, ticketing, client communication.
5. HR - onboarding, compliance documents, employee records, policy, benefits.
6. QA - quality auditing, call and chart review, process-compliance checks.
7. Biller - invoicing, claims, accounts receivable, payroll-adjacent billing.
8. Medical VA - clinical and home-care domain work: EMR/EHR, care coordination, medical terminology, healthcare admin.

The scale is the same 0–3 for every role:

• 0 - nothing in the résumé for this role.
• 1 - some exposure or a transferable skill.
• 2 - solid, direct experience.
• 3 - strong, lead-level experience.

The rule that makes it work: score the skill, not the industry. A scheduler from trucking or logistics still earns a real Scheduler score; it is never lowered just because the experience came from outside healthcare. Healthcare exposure is captured only by the Medical VA score, so a strong non-healthcare scheduler comes out as Scheduler 3, Medical VA 0. The skill is visible, and so is the domain gap, without one hiding the other.

The problem

Every résumé that came through the careers form landed in a shared Google Drive folder, and a recruiter opened them one at a time to judge whether the candidate fit any of eight virtual-assistant roles.

The backlog had grown to 385 résumés. Manual review was slow, inconsistent between reviewers, and easy to get wrong. The same candidate could be rated differently depending on who opened the file and when.

The goal: a workflow that watches the intake folder, reads each résumé, scores the candidate against a defined rubric, and writes a structured result, with no human in the loop and no per-candidate cost.

What I built

A 21-node n8n workflow that runs end to end without supervision.

• Intake → routing. Two entry points feed one processing chain: a Drive trigger for live uploads, and a scheduled sweep for the existing backlog. A switch routes each file by type: PDFs to direct text extraction, Word documents down a conversion path, everything else to a skip lane.
• Text extraction, including scans. Text-based PDFs are read directly. Word files and image-based (scanned) PDFs are converted to Google Docs and exported as plain text, which uses Google's own OCR, so there's no third-party OCR service and no added cost.
• AI scoring against a fixed rubric. The extracted text goes to an LLM with a constrained prompt: score the candidate 0–3 on all eight roles and return one short, evidence-based justification per score, as strict JSON.
• Structured output. Results are formatted into a .txt file and uploaded to a separate results folder: eight role scores plus a written reason for each.
• A self-draining queue. After scoring, the source résumé is moved out of the intake folder, so each scheduled run sees only unprocessed files. No repeats, no duplicate output, and the backlog measurably shrinks every night.

The rubric decision that made it work

The rubric encodes a call the client and I worked through directly: score the skill, not the industry. A scheduler from trucking earns a real Scheduler score; a lack of healthcare background shows up in a separate Medical VA score rather than dragging the others down. Without that rule, every strong candidate from outside healthcare would have been scored down and quietly lost.

In the demo below, pick a sample résumé (including one submitted as a phone photo that needs OCR) and watch it run the pipeline, then read the scorecard it produces.

Engineering decisions worth noting

• Cost: $0/month. The workflow runs entirely on a free-tier LLM. Rather than asking the client to upgrade, I measured actual token use per résumé, calculated the daily ceiling, and built a scheduled batch (capped per run, scheduled off-hours) that clears the backlog inside the free allowance. Steady-state intake sits far under the limit indefinitely.
• Resource contention. The client already ran a separate production workflow on the same LLM provider, and free-tier quotas are shared per account. I scheduled the résumé batch into a window when the live system is idle and the quota has reset, so a background job can never starve a customer-facing one.
• Failure isolation. Early versions stopped the whole batch when a single file failed. I rebuilt with per-node error branches so a corrupt or unreadable file is set aside and the run continues; retry-with-backoff handles transient API errors.
• Observability. Skipped files aren't silently dropped. Each is logged to a Google Sheet with a timestamp, filename, and the reason it failed, then moved to a review folder. That turned an invisible failure mode into a reviewable queue, and it's how I traced one class of failures back to a truncated folder ID in a single node.
• Robust matching. Duplicate detection originally lived in a Drive query string, which broke on names containing apostrophes. I moved the matching into JavaScript so any name (quotes, accents, anything) is handled structurally instead of by escaping.

Why it matters

A hiring pile is really a queue of decisions waiting on a human's attention. Turning it into a pipeline means every candidate gets the same eight-role read with written reasoning, a recruiter can triage from the output alone instead of reopening files, and the pile clears itself overnight, on infrastructure that costs nothing to run.