A reminder should describe the appointment that still exists
The customer moves an appointment from Tuesday to Thursday. On Tuesday morning, the old reminder arrives anyway. The message may have been written well, but the workflow has lost track of the booking.
A useful appointment reminder system follows the current appointment, not just a timer created when the first booking arrived. It needs a booking identifier, current time, timezone, status and a way to handle changes.
Start with the scheduler's native confirmation and reminder features. Cal.com, for example, describes workflows triggered by booking events and time offsets. Check your provider's current features and plan before building a separate reminder service. Two systems sending the same message can create confusion.
Write an appointment contract
For each event type, define what the person is agreeing to attend. Include the purpose, duration, location or meeting link, timezone, preparation and a way to change the appointment.
Keep preparation proportionate. A short service consultation rarely needs a long questionnaire. If the customer must bring a document or arrange access, say so before the meeting rather than introducing a surprise in the last reminder.
Use one source for appointment details. If a workflow copies the location into several message templates, someone must update every copy when the location changes. Prefer verified values from the current event record where the provider supports them.
Start with a small message sequence
The following sequence is a starting design to test, not a proven attendance formula. Adjust it for lead time, customer preference and service type. Someone who books thirty minutes ahead should not receive reminders intended for next week.
| Moment | Message purpose | Check before sending |
|---|---|---|
| Confirmed booking | Explain the agreed appointment | Booking exists and is not awaiting a different approval |
| Before the appointment | Restate time, place and necessary preparation | Booking remains active with the current details |
| Reschedule | Confirm the replacement details | Old reminder jobs cannot send stale information |
| Cancellation | Acknowledge the cancellation | Further appointment reminders are stopped |
| After a missed appointment | Offer a useful next step if appropriate | Attendance status is verified and contact is permitted |
Do not make the first sequence complicated. Begin with confirmation and one reminder. Add another step only if your records show a problem it can address.
Use messages the customer can act on
Confirmation example: “You're booked for [service] on [date] at [time and timezone]. We'll meet at [location/link] for [duration]. Please [necessary preparation]. To change the appointment, use [reschedule/cancel link].”
Reminder example: “A reminder of your [service] appointment tomorrow at [time and timezone], at [location/link]. If your plans changed, please use [change link] so we can update the booking.”
Missed-appointment example: “We didn't connect for today's [service] appointment. If you'd still like help, you can choose another time at [link] or reply with a question.”
These are original examples, not measured winners. Verify that the missed-appointment message is accurate. A video link failure, host delay or manual attendance update can make “you didn't attend” an unfair assumption.
Handle the awkward cases before launch
Test a normal booking, a cancellation, a reschedule, a last-minute booking, a timezone change and a repeated provider event. Inspect both the scheduler and the outgoing message queue.
Check what happens when someone reschedules after a reminder is queued but before it sends. The send step should verify current state or the workflow should reliably replace the queued job. Document how your actual provider handles that case.
Assign failures to a person. If a reminder cannot be delivered, record the failure instead of marking the customer reminded. If the scheduler is unavailable, avoid inventing a time or booking status.
For WhatsApp delivery, use the permitted message type and applicable permission rules. A reminder's helpful purpose does not by itself establish that the channel permits it.
Measure attendance without hiding cancellations
Report bookings, cancellations, reschedules, attended appointments and no-shows separately. Define which appointments were due to occur during the reporting period and how late cancellations are handled.
Review reasons when customers provide them. Missing directions, a wrong timezone and a weak service fit need different fixes. More reminder volume cannot solve all three.
Compare similar appointment groups before and after a change, with the counts visible. Treat differences as observations; traffic, service mix and booking lead time can change too. Use Rainlight's booking blueprint to map the states before connecting messages across tools.