
Post: Slash No-Shows: Build Automated Reminders with Make.com
Every no-show costs your team an interviewer hour, a delayed hire, and in competitive markets, a candidate who signed elsewhere while you waited. A four-touch Make.com reminder sequence — booking confirmation, 24-hour reminder, morning-of, and one-hour heads-up — cuts no-show rates in half. Build time: under two hours.
No-shows cost recruiting teams more than rescheduling time. Each missed slot represents a wasted interviewer hour, a delayed hire, and in tight labor markets, a candidate who accepted an offer elsewhere while you were waiting for them to show up. A structured reminder sequence is one of the highest-ROI workflows you can build in Make.com — and one of the fastest to deploy.
This guide walks through every step: auditing your baseline, mapping your tools, building each reminder module, adding conditional logic, and verifying the workflow fires correctly. By the end, you have a live scenario that runs automatically on every new booking without recruiter intervention.
Before You Start
Gather these before opening Make.com so the build goes in one sitting.
- Scheduling tool access. Calendly, Acuity Scheduling, HubSpot Meetings, or Google Calendar — any tool that fires a webhook on new bookings. You need admin access to configure the trigger.
- Email platform credentials. Gmail, Outlook, or a transactional email service — whichever your team uses for candidate-facing messages.
- SMS provider account. Twilio or a comparable provider with a Make.com native module. Have your account SID, auth token, and sender number ready before you start.
- Make.com account. Any paid plan works. Estimate your monthly operations: four reminder messages × average monthly interview volume = minimum operations needed.
- 90 days of interview data. Pull no-show counts by stage. This is your baseline. You cannot measure improvement without it.
- Build time. 90–120 minutes for a clean first build. Add 30 minutes for testing.
- Test discipline. Test with real but non-live bookings before activating. A misconfigured delay field sends reminders at the wrong time. Catch that in testing, not in production.
Step 1 — Audit Your No-Show Baseline
Before building anything, establish what you are solving. Pull 90 days of interview data and calculate your no-show rate by stage: phone screen, first-round, technical, final. The highest no-show rate is almost always at phone screen — the lowest-commitment stage with the least time between booking and interview. That is where a four-touch sequence delivers the most immediate impact.
Document these four numbers:
- Total interviews scheduled per stage
- No-shows per stage
- Average days between booking and interview date (your lead time shapes the reminder cadence)
- Current reminder method — manual email, single automated email, or nothing
Teams with zero automation or single-confirmation-only workflows run no-show rates two to four times higher than teams with structured multi-touch sequences. McKinsey Global Institute research on workflow automation confirms that structured, rules-based processes eliminate the variability that causes service failures — including missed appointments. Your baseline gives you the before data you need to demonstrate impact after the workflow goes live.
Step 2 — Map Your Tool Stack and Choose Your Modules
Identify which Make.com modules you will use at each point in the scenario before you open the builder. The core stack is one trigger module and four action modules.
| Workflow Point | Module Type | Common Option |
|---|---|---|
| New booking detected | Trigger (webhook or native) | Calendly > Watch Invitee Created |
| Instant confirmation | Email action | Gmail > Send an Email |
| 24-hour reminder | Sleep + Email action | Tools > Sleep → Gmail > Send an Email |
| Morning-of reminder | Sleep + SMS action | Tools > Sleep → Twilio > Send an SMS |
| One-hour reminder | Sleep + SMS action | Tools > Sleep → Twilio > Send an SMS |
If your scheduling tool does not have a native Make.com module, use a custom webhook. Configure your scheduling tool to POST booking data to the webhook URL Make.com generates — you get the same data with one extra setup step.
If you are newer to Make.com workflows for HR operations, the post on how the Make MCP changes automation work for HR teams covers the broader context before you build.
Step 3 — Build the Trigger Module
Open Make.com and create a new scenario. Add your scheduling tool as the trigger.
For Calendly, select Calendly > Watch Invitee Created. Connect your Calendly account, select the event type you want to monitor, and run a test booking so Make.com captures a real data payload. You need a sample payload before you can map fields in later modules.
For any tool without a native module, select Webhooks > Custom Webhook. Make.com generates a URL. Paste that URL into your scheduling tool’s webhook configuration. Trigger a test booking. When Make.com receives the payload, click Determine data structure so it recognizes the fields automatically.
Fields you need to map from the trigger payload:
- Candidate name
- Candidate email address
- Candidate phone number (for SMS)
- Interview date and time
- Interview type or stage name
- Interviewer name (for personalization)
- Meeting link or location
Confirm these fields are present in your test payload before moving to the next step. If a field is missing — phone number is the most common gap — fix the data collection in your scheduling tool before building the SMS modules.
Step 4 — Build the Confirmation Message
The first action fires immediately when a booking is created. Add a Gmail or Outlook module directly after your trigger. No sleep delay — this sends the moment Make.com receives the webhook.
Configure the email:
- To: map candidate email from trigger
- Subject: “Interview Confirmed — [Role Name], [Date]”
- Body: candidate name, interview date/time, format (video, phone, in-person), meeting link or location, interviewer name, and a single clear instruction — what to do if they need to reschedule
Keep the body under 150 words. Candidates read confirmation emails once, quickly. The goal is to confirm the details and give them a rescheduling path — not to sell them on the opportunity again.
Name this module clearly in Make.com. “Send Confirmation Email” is better than “Gmail 1.” Every module in the scenario should be named for what it does, not what it is.
Step 5 — Build the 24-Hour Reminder
Add a Tools > Sleep module after the confirmation email. Set the delay to calculate the time between now and 24 hours before the interview. Make.com’s Sleep module accepts a duration in seconds — compute the correct interval using the interview timestamp from your trigger payload.
The formula: interview timestamp (in seconds) minus current timestamp minus 86,400 seconds (24 hours) = sleep duration.
After the Sleep module, add another email action. This message is shorter than the confirmation. It restates the time and location, includes the meeting link, and gives the candidate the rescheduling link again. Subject line: “Tomorrow: Your Interview at [Company], [Time].”
Adding a rescheduling link to every reminder is intentional. A candidate who knows they cannot attend and has a one-click path to reschedule will reschedule. A candidate with no easy path will disappear. Give them the exit that keeps them in your pipeline.
Step 6 — Build the Morning-Of SMS
Add another Sleep module. This one fires at a fixed time on the morning of the interview — 8:00 AM in the candidate’s time zone. Compute the sleep duration from the booking timestamp to 8:00 AM on the interview date.
After the Sleep module, add a Twilio > Send an SMS module. Keep the message under 160 characters so it sends as a single SMS, not a split message:
“Hi [First Name] — reminder: your interview with [Company] is today at [Time]. Join here: [Link]. Reply STOP to opt out.”
The opt-out language is required under TCPA regulations for SMS outreach. Include it on every SMS, not just the first one.
Name this module “Send Morning-Of SMS” and add a note in Make.com documenting the time zone logic. Anyone who opens this scenario in six months needs to understand the timing without reverse-engineering the formula.
Step 7 — Build the One-Hour Reminder
Add a final Sleep module timed to fire 60 minutes before the interview start time. Follow it with another Twilio SMS module.
This message is the shortest of the four:
“[First Name] — your interview starts in 1 hour. Join here: [Link]. See you soon.”
One hour is short enough that the candidate is either on track or already knows they are not attending. The goal of this touch is to surface the meeting link at the exact moment they are preparing to join, not to remind them for the first time.
Step 8 — Add Conditional Logic for Edge Cases
A live scenario encounters situations a test build does not. Add a Router module after the trigger to handle the two most common edge cases before the reminder sequence runs.
Route 1 — Short-notice bookings. If an interview is scheduled less than 25 hours from now, the 24-hour reminder would fire after the interview. Add a filter: if the time between now and the interview is less than 25 hours, skip directly to the morning-of reminder. Use a Make.com filter condition on the Sleep module’s computed duration.
Route 2 — Cancellations. If your scheduling tool fires a webhook on cancellation events, add a scenario that stops the reminder chain when a cancellation comes in. The cleanest approach: use a Make.com data store to log active bookings by a unique booking ID, and check that store before each Sleep module fires. If the booking ID no longer exists, stop the scenario.
Most teams skip the cancellation handler in the first build and add it after the first false-alarm reminder goes out. Build it now. It takes 20 minutes and saves you the candidate complaint email.
Step 9 — Name Every Module and Add Notes
Before testing, audit your scenario for unnamed modules. Every module should describe its function: “Watch New Bookings,” “Send Confirmation Email,” “Sleep — Wait Until 24H Before Interview,” “Send 24H Email Reminder,” “Sleep — Wait Until 8AM Day-Of,” “Send Morning-Of SMS,” “Sleep — Wait Until 1H Before,” “Send 1H SMS.”
Add a Make.com note to any module that contains a formula or a non-obvious configuration. The sleep duration calculations qualify. Document the formula in the note so the next person who opens this scenario — or you six months from now — does not need to reverse-engineer it.
If you want a framework for deciding which automations to build first before you expand this sequence, the OpsMap™ discovery process gives you a structured way to map and prioritize the right workflows before you build them.
Step 10 — Test Before Activating
Run a complete test with a real but non-production booking. Use a test calendar event with your own email and phone number as the candidate. Walk through every message:
- Confirmation email arrives immediately after booking
- 24-hour email arrives at the correct time
- Morning-of SMS arrives at 8:00 AM on the interview date
- One-hour SMS arrives 60 minutes before the test interview time
Check three things on each message: delivery time is correct, all mapped fields render properly (no blank [First Name] fields), and the meeting link resolves. Fix anything that fails before activating the scenario.
For teams newer to the Make.com build-and-test cycle, the post on how non-technical HR teams build their own automations with Make and AI covers the testing discipline in more detail.
Step 11 — Activate and Measure
Turn the scenario on. Set it to run immediately on every new webhook event — not on a schedule. Reminder sequences that run on a polling schedule introduce timing gaps. Webhook-triggered scenarios fire within seconds of the booking.
Pull your no-show data again after 30 days. Compare it against your 90-day baseline from Step 1. Most teams see measurable improvement within the first two weeks. The four-touch sequence addresses the two leading causes of no-shows: candidates who forgot and candidates who had a conflict but no easy path to reschedule.
If your numbers do not improve, check three variables before assuming the workflow is the problem: message delivery (check Twilio and Gmail logs for bounces or failures), timing accuracy (confirm the Sleep module formulas are calculating correctly), and candidate data quality (phone number opt-in rates and email accuracy upstream in your ATS).
What to Build Next
A reminder sequence is the highest-impact starting point, but it is one piece of a larger recruiting automation picture. Once this scenario is stable, the natural next builds are:
- Post-interview follow-up sequence. A thank-you email and next-step message sent automatically after the interview end time — no recruiter action required.
- Candidate no-show triage. If the one-hour SMS goes unanswered and the candidate does not join, trigger an automatic notification to the recruiter with a one-click reschedule link to forward.
- Stage-specific sequences. Different reminder copy and cadences for phone screen vs. final-round vs. technical — because a 45-minute technical assessment deserves more preparation framing than a 20-minute phone screen.
Each of these builds on the foundation you laid in this scenario. The trigger logic, the Sleep module patterns, and the conditional routing you built here carry forward directly.
For teams evaluating where to invest automation hours across the full recruiting operation, the post on fixing broken hiring processes for HR teams covers the broader process gaps that automation solves — and the ones it does not.
The no-show problem is solvable. The workflow is not complicated. The only thing standing between your current no-show rate and a better one is the two hours it takes to build this scenario.

