Skip to content

Appointment reminders at noon, and a catch-up pass at six

Two Make scenarios message every patient booked for tomorrow at each site: a midday run that sends and logs, and an evening pass that sends only to bookings missing from that log.

Notifications & agent toolsFlow2026

Where this applies

Any appointment-based business (clinics, salons, therapists, repair shops) that wants next-day reminders without double-messaging anyone.

passes a day: noon and 6 PM
2
sites, one branch each
3
runs, recent scheduled runs all successful
74

The problem

Reminders cut missed appointments, but a reminder system has to survive the reality of a booking calendar: late bookings after the reminders have gone, calendar blocks that look like appointments, and contacts that the messaging system has not seen before.

It also must never message the same person twice for the same appointment, or the first useful reminder becomes the one that trains patients to ignore the next.

What we built

01

Tomorrow, per site

Each scenario reads a cached token, works out tomorrow's date and splits into one branch per clinic site, each fetching that site's appointments from the scheduling system and iterating them. A one-minute daily window makes each effectively a once-a-day run.

02

Filtering out what is not a patient

A filter drops calendar entries whose name is a placeholder (a block, a break, a site label) and a list of excluded practitioners, so reminders go only to real bookings.

03

Send, then log

Each reminder is an approved template with the patient's first name, the time and the practitioner. A row in a reminders log records the appointment id, times, practitioner, site, reminder type and send time.

04

A catch-up pass that never double-sends

The evening scenario runs the same pipeline but looks up each appointment id in the log and continues only if there is no row. It reaches the bookings made after midday and writes its own log row, so neither pass can repeat the other.

05

When the channel is not open

If a send fails because the contact has no open channel, an error route looks the patient up in the messaging system, creates the contact if missing and retries. If that also fails, a row goes to a manual-follow-up sheet (patient, phone, the full message and a click-to-chat link) and processing carries on, so staff can send it by hand.

The outcome

  • Across the two scenarios: 74 runs and 4,503 operations in Make's counters. The midday scenario has six errors, all manual test runs on one day (five authorisation failures and a 404), and the evening pass has two.

  • Recent scheduled runs are all successful: 40 to 120 operations and 40 to 110 seconds at midday, 58 to 74 operations and 30 to 40 seconds in the evening.

  • Every send is logged, every failure either retries or lands on a list a person works.

Where it stops

Neither scenario checks consent or opt-out, and neither filters by appointment status, so a cancelled booking is not explicitly excluded. The midday run has no deduplication of its own and relies on running once a day. The excluded-practitioner list is repeated in each branch and differs slightly between them, and in the evening scenario one site's failed retry is ignored without a manual-follow-up row. The token is refreshed by a separate scenario that is not described here.

Built with

  • Make.com
  • Airtable
  • Google Sheets
  • Make data store
  • HTTP API

Patterns used

  • Log as the dedupe key
  • Catch-up pass
  • Retry then manual list
  • One-minute daily window

Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy

Start here

Have something shaped like this?

If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.

Book a 15-minute callsaveez@skofi.tech

What happens on the call

  • 15 minutes, no deck
  • We map the process on the call
  • A written scope, or an honest no
Book a call