How to Build an AI-Powered Candidate Follow-Up System with Make.com

An AI-powered candidate follow-up system uses Make.com to trigger personalized messages the moment a candidate status changes — routing by pipeline stage, generating context-aware copy with AI, and delivering across channels with zero recruiter intervention on routine touchpoints. The result: 60% faster follow-up and 150+ hours reclaimed per month across a three-person team.

Candidate follow-up is the highest-volume, lowest-judgment communication task in recruiting — which makes it the worst possible use of recruiter time and the best possible use of automation. This guide documents how a small recruiting team rebuilt their follow-up process from a manual queue into a structured system, following one architectural principle: deterministic automation handles the spine; AI fires only at the message-generation step.

The result is not a prototype. It is a production workflow that has processed thousands of candidate interactions without recruiter intervention on routine touchpoints — freeing the team for conversations that require human judgment. If you want to understand why automation-first sequencing beats AI-first approaches, this build is a clear demonstration.

Before building, it helps to understand what a Make scenario is and how it executes — the routing logic described below depends on that foundation. You should also review the seven questions to ask before automating anything to confirm the process is ready for automation before building.

What This Build Solves

Nick, a recruiter at a small staffing firm, was processing 30–50 active candidate pipelines simultaneously and spending 15 hours per week on follow-up administration alone. Across his team of three, that was 45 hours per week locked inside repetitive tasks — time that disappeared into copy-pasting templates, checking send status, and manually tracking which candidates had received which messages.

Three failure modes defined the baseline:

• Timing inconsistency: Follow-up messages sent whenever a recruiter had bandwidth — sometimes hours after a trigger event, sometimes days.
• Message uniformity: Saved templates produced identical language across different candidate stages, which candidates recognized and distrusted.
• Silver-medalist neglect: Final-round candidates who were not selected received a form rejection and were never contacted again — erasing a pre-qualified talent pool.

Research from McKinsey Global Institute confirms the pattern: knowledge workers spend 28% of their workweek managing routine communications. Asana’s Anatomy of Work research found that 60% of workers’ time goes to work about work rather than skilled tasks. For recruiters, the follow-up queue is the definition of work about work.

SHRM data links poor candidate communication directly to offer decline rates — meaning the manual process was not just slow, it was costing the team placements.

Step 1: Map the Six Touchpoints Before Touching Make.com

The first and most important decision is sequencing: map the process completely before building a single module. The team identified six discrete touchpoints where candidate communication was both expected and appropriate:

1. Application received — acknowledgment within minutes of submission
2. Stage advance — notification when moved to phone screen or interview
3. Interview confirmed — confirmation message with logistics and prep guidance
4. Post-interview follow-up — status update 24–48 hours after the interview
5. Decision communicated — offer or rejection with appropriate framing per stage
6. Silver-medalist re-engagement — outreach 60–90 days post-rejection for final-round candidates

Each touchpoint has a defined trigger condition, a required data payload, and a target delivery window. Only after mapping all six does scenario architecture begin. This is why an OpsMap™ audit before automating is the non-negotiable first step — building without this map produces fragile workflows that break at edge cases.

AI is introduced exclusively at step three of the scenario — after the trigger fires and routing completes. AI cannot reliably determine when to send a message or which candidate branch to activate. Those are deterministic decisions governed by data conditions, which Make.com’s routing and filter modules handle natively.

Step 2: Configure the Trigger Layer

The ATS webhook fires the Make.com scenario the moment a candidate status changes. The trigger module captures a complete data payload at the entry point:

• Candidate first name, last name, email address, phone number
• Job title applied for
• Current pipeline stage and previous stage
• Recruiter name and hiring manager name
• Last interaction date

Capturing all fields at the trigger — not mid-scenario — eliminates data-retrieval steps later and keeps the scenario linear. For teams without an ATS that supports webhooks, a scheduled Google Sheets polling module running every 15 minutes provides a reliable alternative. A dual-trigger architecture (webhook primary, scheduled poll as redundant) ensures no status change goes unprocessed even if the webhook delivery fails.

If you’re new to this pattern, building a Make scenario with Claude is a practical way to generate the initial module structure from a plain-English description of this trigger logic.

Step 3: Build the Stage Router

The router module reads the current_stage field from the trigger payload and branches the scenario into six paths — one per touchpoint mapped in Step 1. Each branch has a filter that evaluates:

• Does current_stage match this touchpoint’s expected stage value?
• Has a message for this stage already been sent to this candidate? (deduplication check against a Google Sheets log or ATS custom field)
• Is the candidate marked as active, not withdrawn or archived?

All three conditions must pass before the branch executes. This prevents duplicate messages when an ATS fires multiple webhooks for the same status change — a common failure mode in production that the deduplication check eliminates entirely.

The silver-medalist branch has additional routing logic: it checks whether the candidate reached the final round, flags the record in the ATS with a silver-medalist tag, and schedules a delayed module to trigger re-engagement outreach at the 60-day mark. Make.com’s native scheduling handles this without external delay services.

Step 4: Wire the AI Message-Generation Module

Each branch routes to a Make.com HTTP module calling an AI API. The prompt is structured, not open-ended. A well-constructed prompt for the interview-confirmation branch looks like this:

You are writing a candidate communication for a recruiting team. Write a professional, warm interview confirmation message for [candidate_first_name] who is interviewing for [job_title] at [company_name]. The interview is scheduled for [interview_date] at [interview_time] via [interview_format]. Include a brief note of encouragement. Keep the message under 120 words. Do not use corporate jargon. Sign from [recruiter_name].

Key prompt engineering decisions:

• Word count constraint: Prevents AI from producing messages that feel like essays. Candidates read short messages. They skim long ones.
• Jargon prohibition: Generic AI output defaults to phrases like “we value your candidacy” — candidates flag these immediately as automated.
• Named recruiter sign-off: Preserves the relational layer even in automated messages. Candidates respond to a name, not a department.
• Variable injection at generation time: All candidate-specific fields are passed from the trigger payload — the AI sees real data, not placeholders.

For teams wanting to build HTTP modules without native connectors, feeding API docs into Claude to build Make HTTP modules reduces this step from hours to minutes.

Step 5: Insert the Human Review Checkpoint

Not every message goes straight to delivery. The scenario includes a conditional checkpoint for high-stakes communications:

• Final-round rejection messages
• Offer communications
• Re-engagement outreach to silver-medalist candidates

For these touchpoints, the scenario routes the AI-generated draft to a Slack message directed at the responsible recruiter. The recruiter sees the draft, the candidate name, the stage, and two action buttons: Approve (sends immediately) or Edit (opens the draft in a linked form). The scenario waits on a webhook response from the Slack interaction before proceeding.

For routine touchpoints — application acknowledgment, stage advance notification, interview confirmation — no human review is required. The scenario routes directly to delivery after generation. This is the distinction that makes the system scalable: human judgment applies only where judgment is actually needed.

This pattern is documented in detail in 5 automation tasks AI handles well and 5 it gets wrong — the review checkpoint exists precisely because final-round rejections fall in the latter category.

Step 6: Configure Multi-Channel Delivery

The delivery layer reads the candidate’s preferred contact method from the ATS payload and routes accordingly:

• Email: Gmail or Outlook module, with the AI-generated body and a plain-text fallback
• SMS: Twilio module for time-sensitive touchpoints (interview day-of reminders, same-day confirmations)
• ATS note: Every message, regardless of delivery channel, is logged as a candidate note via the ATS API — creating a complete communication record without manual data entry

The ATS note module runs in parallel with the delivery module, not sequentially. This means the record is created even if the candidate delivery fails — preserving the audit trail regardless of delivery outcome.

After delivery, a final module updates the Google Sheets deduplication log with the composite key, completing the loop and preventing re-sends on subsequent webhook fires for the same status.

How to Know It Worked

Measure these four signals in the first 30 days:

1. Median follow-up response time: Time between ATS status change and candidate message delivery. Target: under 10 minutes for routine touchpoints. Baseline for this team was 4–6 hours.
2. Recruiter time on follow-up administration: Track weekly. Nick’s team went from 45 hours per week across three recruiters to under 5 hours — a 150+ hour monthly reclaim.
3. Candidate response rate by stage: If AI-generated messages are landing well, response rates hold or improve. Declining response rates signal a prompt engineering problem, not an automation problem.
4. Duplicate message count: Should be zero. Any duplicate indicates a deduplication logic gap that needs immediate patching.

The silver-medalist pipeline has a longer measurement window. Track re-engagement response rate at 60 days and placement rate from re-engaged candidates at 120 days. The team activated 14 re-engagements in the first quarter after launch — candidates who would otherwise have been silently lost to the pipeline.

Common Mistakes

Mistake 1: Adding AI Before the Routing Logic Is Stable

Teams that wire AI to the trigger directly — skipping the router layer — produce a system that generates messages for the wrong stage. The router is not optional. It is the system. AI is one step inside it.

Mistake 2: Using Open-Ended Prompts Without Constraints

Unconstrained prompts produce verbose, jargon-heavy output that candidates identify as automated immediately. Every prompt needs a word count limit, a tone specification, and an explicit prohibition on generic phrases. Writing a structured brief for AI-assisted Make builds applies the same discipline to prompt construction.

Mistake 3: Skipping the Deduplication Check

ATS platforms fire multiple webhooks on single status changes — this is not a bug, it is normal behavior. Without deduplication, a candidate receives the same message three times in five minutes. This is worse than no automation at all.

Mistake 4: Applying Human Review to Every Message

Routing all AI-generated output through human review eliminates the time savings that justify the build. Review applies only to high-stakes touchpoints. Routine communications — application acknowledgment, stage advance — require no review. The distinction between the two is the architectural decision that determines whether this system scales.

Mistake 5: Not Logging to the ATS in Parallel

Teams that skip the ATS note module create a communication record gap. When a recruiter or hiring manager asks what was sent and when, there is no answer. The parallel logging module costs two minutes to configure and prevents audit failures that take hours to reconstruct.

Extending the System

Once the six-touchpoint spine is stable in production, three extensions are straightforward to add:

• Non-responder re-ping: A scheduled module checks the ATS for candidates who received a stage-advance message but did not respond within 72 hours, and sends a single follow-up nudge.
• Hiring manager digest: A daily scheduled scenario aggregates all candidate communications sent in the prior 24 hours and sends a formatted summary to the hiring manager — replacing ad hoc status update requests.
• Referral acknowledgment: A separate Make.com™ scenario triggers when a candidate marks “employee referral” as their source, routing a personalized thank-you to the referring employee via Slack or email.

Each extension uses the same four-layer architecture: trigger → router → AI generation → delivery. Once the pattern is internalized, new touchpoints take hours to add, not days. For teams ready to take on more complex builds, 10 automations that are now easy to build with Make and AI covers the full range of what this architecture unlocks.

For teams evaluating whether to build this internally or work with a specialist, the DIY vs. Make partner decision framework covers when each approach produces better outcomes.

Frequently Asked Questions

Does this require a specific ATS?

No. Any ATS with webhook support works directly. For ATS platforms without native webhooks, a Google Sheets polling trigger running on a 15-minute interval is a reliable substitute. The routing and AI layers are ATS-agnostic — they read from the data payload, not the source system.

How long does this take to build?

A two-person team with Make.com familiarity builds the core six-touchpoint spine in two to three days. The deduplication logic and human review checkpoint add half a day each. The silver-medalist delayed trigger adds one additional day of configuration and testing. Total: one focused week for a production-ready system.

What happens if the AI generates a bad message?

For routine touchpoints, the answer is: review the prompt, not the AI. Bad output on consistent inputs is a prompt engineering problem. Tighten the word count constraint, add explicit prohibitions on flagged phrases, and re-test. For high-stakes touchpoints, the human review checkpoint catches problems before delivery — this is exactly why the checkpoint exists.

Can this system handle multiple job roles simultaneously?

Yes. The job title is passed as a variable in the trigger payload and injected into every AI prompt. A recruiter managing 30 active pipelines across 10 roles generates messages that reference the correct role for each candidate without any additional configuration.

Does automation like this create compliance risk?

The system creates a more complete audit trail than manual follow-up, not a riskier one — every message is timestamped and logged to the ATS automatically. The human review checkpoint for rejection communications ensures a recruiter approves all final-round rejection language. EEOC AI compliance requirements for HR teams covers the compliance layer for AI-assisted recruiting communications in detail.

Additional Reading

• What Is Automation-First? Why You Should Automate Before You Add AI
• 7 Questions to Ask Before You Automate Anything (The OpsMap Checklist)
• How to Run an OpsMap Audit Before Automating Anything
• What Is a Make Scenario? The Plain-English Guide for Zapier Users
• How to Build a Make Scenario With Claude: A Step-by-Step Walkthrough
• 5 Automation Tasks AI Handles Well — and 5 It Still Gets Wrong
• How to Write a Brief for Claude That Produces a Production-Ready Make Scenario
• How to Feed API Docs Into Claude to Build Make HTTP Modules Without Native Connectors
• 10 Automations That Are Finally Easy to Build With Make + AI — No Developer Needed
• DIY Automation vs. Hiring a Make Partner in 2026: When to Do Each
• How to Evaluate a Make Scenario Built by AI Before It Goes to Production
• 9 EEOC AI Compliance Requirements HR Teams Must Meet in 2026
• How Nick Cut 6 Manual Handoffs From Proposal Generation With One Make Workflow
• How HR Can Fix Broken Hiring Processes: Reducing Candidate Frustration Without Slowing Down the Business
• HR Firm Saves 150+ Hours Monthly with AI-Powered Resume Automation