Almost every booking system sends reminders, and no-show rates stay stubbornly where they were. The usual conclusion is that reminders do not work. The actual problem is that a reminder is four decisions and most implementations get one of them right.
The four decisions
- Channel. Where the message arrives and whether it is read.
- Timing. When it is sent, relative to the appointment.
- Wording. What it says, and what it asks for.
- The reply path. What the person can do about it in one action.
The fourth is the one that changes the number, and it is the one most often missing.
Channel: read, not sent
The metric that matters is not delivery, it is attention.
Email is nearly free, holds detail well, and is the least likely to be read before the appointment. It suits confirmations and receipts rather than reminders.
SMS reaches every phone with no app and no account, which is its real advantage. In India it also competes with a great deal of noise, and links in messages are treated with suspicion.
WhatsApp is where most Indian customers actually read messages, and it supports buttons, which is what makes the reply path possible. It requires opt-in, template approval and a per-conversation cost. The mechanics of that are covered in what the WhatsApp Business API does and does not do.
A phone call is the most effective and the least scalable. It remains the right answer for high-value appointments and for customers who do not use messaging apps.
The sensible arrangement is not one channel. It is a preferred channel per customer, recorded when they book, with a fallback when the preferred one fails.
Timing: two messages, not one and not five
One reminder an hour before is too late to do anything about. One a week ahead is forgotten. The pattern that works is a confirmation at the moment of booking, so the appointment lands in their world at all, and a reminder the day before, early enough that the slot can be resold if they cancel.
A third, a couple of hours ahead, helps for appointments people travel to and irritates otherwise. More than that trains people to ignore your messages, which costs you the channel.
Two details that are easy to get wrong in code: send during waking hours, which means the job needs to respect a sending window rather than firing exactly 24 hours before a 7am appointment; and never send a reminder for an appointment that has been cancelled, which requires the job to re-check state at send time rather than at queue time.
Wording: short, specific, and one thing to do
A good reminder contains the date and time, the place, who they are seeing, and one action. It does not contain a paragraph of policy, a marketing footer, or three links.
Two rules worth applying strictly. Name the business in the first few words, because that is all that shows in a notification. And be discreet about the subject: the message may be seen by somebody else, so a clinic reminder says there is an appointment, not what it is for.
If there is a policy, one clause is enough: how much notice you need for a free cancellation. That single sentence produces more early cancellations, which is the outcome you want, because an early cancellation is a slot you can sell.
The reply path is the feature
This is where the number actually moves. A reminder that says “call us to reschedule” converts a customer’s mild inconvenience into a task they will do later and mostly will not.
What works is one tap: confirm, reschedule, cancel. Reschedule should open the available slots directly, not a general booking page where they start again. Cancel should be as easy as confirm, which sounds counterproductive and is not: a cancellation two days ahead is a slot you resell, and a no-show is revenue that never existed. Making cancelling difficult does not produce attendance, it produces empty chairs and no warning.
Deposits, used narrowly
A small prepayment changes behaviour more than any message. It also adds friction to booking, so it should be applied where a no-show genuinely hurts: long appointments, high-value services, first-time customers, and the slots that are hardest to refill. Applying it to everything costs you bookings you would have kept.
Whatever the rule, it has to be visible at the moment of booking and the refund path has to be as easy as the payment, or the policy generates more support work than the no-shows did.
The waiting list closes the loop
Reminders reduce no-shows. They do not eliminate them, and they create cancellations, which is the point. What turns a cancellation back into revenue is a list of people who wanted that slot and an automatic message the moment it frees up.
This is a small feature with a direct return, and it is the one most booking systems leave out. A slot released at 9am for a 2pm appointment is recoverable if somebody is told within a minute, and gone if the list is a note on the desk.
What to measure
Not open rates. Three numbers, before and after:
- No-show rate, by appointment type and by channel used.
- Cancellations received more than 24 hours ahead, which should rise when this is working.
- Slots refilled after a cancellation, which is the waiting list’s own number.
If no-shows fall and early cancellations rise, the system is working exactly as intended even though the total appointment count looks flat, and that is the result to explain to whoever authorised the work.
The engineering that makes reminders reliable
A reminder system is a scheduled job talking to an external service, which means it fails in the ordinary ways and each one has a customer-visible cost.
- Send from a queue, never from the request. A reminder triggered inside a booking submission ties the customer’s confirmation to a third-party API’s availability.
- Re-check state at send time. The appointment may have been cancelled, moved or already attended since the job was queued. Reminding somebody about an appointment they cancelled yesterday is worse than sending nothing.
- Make sending idempotent. A retry after a timeout must not send a second message. Record the send against the appointment and the reminder type, with a unique constraint behind it.
- Handle the failure honestly. A number that no longer exists should mark the contact detail as bad, not retry forever and not fail silently.
- Respect a quiet window in the customer’s own working hours, and hold anything that would land outside it until the window opens.
- Log what was sent, when, and what happened. The first support question is always “did you tell me”, and the answer has to be checkable.
Where this fits in the wider system
Reminders are usually the first automated messaging a business does, and they set the pattern for everything after: confirmations, follow-ups, review requests, recalls. Building the sending layer properly once, with the queue, the idempotency and the audit log in place, means each of those later additions is a template and a trigger rather than a new integration.
The reverse is also true. A reminder system bolted together in an afternoon becomes the thing every future message is bolted onto, and the cost of that shows up the first time somebody receives four messages about one appointment.
We build reminder and scheduling flows as part of our web application work, and the scheduling model underneath them is covered in what makes booking harder than a calendar. If your no-show rate is high and you already send reminders, tell us what you send and when and we will tell you which of the four decisions is the one costing you.