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.
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
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.
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.
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.
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.
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
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.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no