Booking Reminders on WhatsApp and Calendar Sync: How to Set Them Up

Booking reminders on WhatsApp and calendar sync work when you send 2 messages only, and when your system keeps proof that each message reached the customer phone.

Two conditions apply. Your WhatsApp Business number uses approved templates. Your booking page and your calendar read the same source of time.

One limit applies. This page explains the mechanism and the setup. It promises no attendance number, because that depends on your service and city.

At a glance

Question	Short answer
How many reminders do I send?	2 reminders: 1 day before and 1 hour before.
What proves a reminder arrived?	The delivered status, not the sent status.
What stops a double booking?	Two-way calendar sync.
Who creates the meeting link?	The booking system, with the calendar event.
Who moves an appointment?	The customer, through a self-service link.
What is a webhookWebhookAn automatic message one system sends to another the moment something happens, for example an incoming WhatsApp message.Open the glossary?	An automatic call from the booking system to yours.

What booking reminders on WhatsApp and calendar sync must prove

Most dashboards show 1 word: sent. That word hides failures.

The Meta status webhook reference for the WhatsApp Cloud APIAPIThe official door 2 systems use to exchange data, without anybody copying it by hand.Open the glossary, updated 21 May 2026, lists 5 status values. Four of them decide your reminder.

• sent: the message left the Meta server. WhatsApp: 1 check mark.
• delivered: the message reached the customer device. WhatsApp: 2 check marks.
• read: the message appeared in an open chat. WhatsApp: 2 blue check marks.
• failed: the message did not send or did not arrive. WhatsApp: a red triangle.

Think of a letter and a courier. The sent status is the moment the letter reaches the courier hand. The delivered status is the signature at the door.

The same document states that 1 outbound message can trigger up to 3 webhooks: sent, delivered, and read. The errors object appears only when a message fails, so the failure code lives there alone.

My rule: store all 3 statuses per message, not the last one. Without that order, a flat battery looks like a wrong number.

Four notification moments and the job of each

One booking needs 4 messages, not 7. Each message carries 1 job. A message with no job goes.

Moment	Send time	Job	Required content
Confirmation	Right after the booking	Prove the slot is recorded	Date, time, place, manage link
Reminder, 1 day before	24 hours before	Give room to move the time	Self-service manage link
Reminder, 1 hour before	60 minutes before	Get the person moving	Address or meeting link
Follow-up	After the visit ends	Close the visit	Summary and next appointment

The reminder schedule that works

The reminder 1 day before arrives while the person can still act. He can move the time or cancel without a loss for you.

The reminder 1 hour before carries a different job. It gets the person moving, so it holds an address or a meeting link.

A reminder 3 days before sounds safe, but people forget again before the day. It spends template quota and changes no decision.

This is an operating rule, not a measured result. Test it on 1 service first, then compare attendance before and after.

Why more messages make the result worse

WhatsApp scores each template. The Meta template quality document, updated 17 June 2026, lists 4 ratings: GREEN, YELLOW, RED, and UNKNOWN.

A rating falls for 2 reasons: negative feedback, or a low read rate. A template rated RED still sends, but it risks a pause. A template that loses its APPROVED status cannot send.

Here is the trap. You add messages so people do not forget. Recipients block or report, the rating falls, and the reminder that matters stops arriving.

Sending limits are real as well. The Meta messaging limits document states that a new business portfolio starts at 250 unique WhatsApp user numbers in a rolling 24 hours, outside the customer service window. It then rises to 2,000, 10,000, 100,000, and unlimited.

So your quota is small at the start. Spend it on messages that change behaviour.

Two-way calendar sync closes the double booking door

A double booking happens because you keep 2 records of time. The booking page holds 1, your calendar holds another, and neither sees the other.

Two-way sync joins them with a simple rule. One direction writes, one direction reads.

I recommend Termilo for this part. Termilo is booking infrastructure operated by PT Nafanesia Kebermanfaatan Indonesia in Bandung. Rama Digital recommends it and does not operate it.

I read the Termilo Google Calendar and Meet documentation to confirm the direction of the data. It states that Termilo writes 1 calendar event per booking, then reads your busy windows to filter out slots that clash.

It requests 2 permissions, and both are required. The read permission calendar.freebusy reads busy status, not event content. The write permission calendar.events.owned only touches booking events.

So your private appointments stay private. The system knows an hour is taken, not what fills it.

One more layer gets missed often. The Termilo documentation states that a slot on the page is a candidate only, and the system rechecks it under a lock when the booking is saved. Two people who press the same hour do not both win it.

If slot, service, and availability are new terms, read our introduction to booking systems and then how a booking system works.

The meeting link is created for you

For an online session, the meeting link should appear with the appointment, with no staff to create and paste it.

The Termilo documentation explains that a Google Meet link comes from the Google Calendar event, not from a separate Meet API. The system adds a conference create request with the event, so 1 Calendar connection already produces a Meet link.

One note matters: creating a Meet room through the Google Meet REST surface is marked preview and is not available. Do not build on that path today.

For Zoom, I read the Termilo Zoom integration documentation. Each online booking triggers 1 meeting on behalf of the connected host. The system stores the participant join_url, and that value goes to the customer.

The host start_url is stored encrypted and never shown. The rule is short: share the join link, not the host link. The host link hands over control of the room.

What a webhook is, in plain words

A webhook is an automatic call. The booking system calls yours when something happens. Without it, your system must ask each 5 minutes and almost always hear that nothing changed.

I read the Termilo webhook documentation. That page marks outbound sending as live, while the llms.txt map on the same site still labels the webhook line as preview. Incoming webhooks are marked planned and absent from the backend. I report both labels as written and treat incoming webhooks as not live.

The event names there follow a subject and action pattern: booking.created, booking.confirmed, booking.rescheduled, booking.cancelled, booking.completed, booking.no_show, and booking.expired.

• booking.created sends the confirmation and schedules 2 reminders.
• booking.rescheduled cancels the 2 old reminders, then schedules 2 new ones.
• booking.cancelled drops the reminders and frees that hour.
• booking.no_show tags the customer for a deposit next time.

Two details decide whether your setup holds up. First, sending is at-least-once, so 1 event can arrive twice. Store the event id and refuse repeats. Second, your endpoint must answer 2xx inside 10 seconds, and retries stop after 6 attempts.

A self-service link moves the appointment without a chat

Moving an appointment by chat spends staff time. The customer writes, staff reads, staff checks the calendar, staff replies. Four steps for 1 change.

A self-service link removes all 4. I read the Termilo authentication documentation to check its limits.

The manage token comes back when the booking is created, carries a signature, lasts 30 days, and binds to 1 booking. It holds 3 actions: read, cancel, and reschedule. It creates no login.

So the link is safe inside a WhatsApp message. Whoever holds it manages that booking and nothing else.

Put the link in the confirmation and the 1-day reminder. A customer reschedule locks the slot again and checks for an overlap, so 1 clean appointment remains.

Worked example: a dental clinic with dummy data

The numbers below are dummy data for a simulation, not a client result.

Starting condition. One dentist, 8 slots a day, a personal Google calendar, a live booking page, 2 approved templates.

Input. One booking arrives for Tuesday at 14.00. One private event sits on the dentist calendar on Wednesday, 10.00 to 12.00.

Steps that run.

1. The booking.created event sends a confirmation and manage link.
2. The system writes 1 calendar event for Tuesday, 14.00.
3. The private Wednesday event reads as busy, so 2 slots leave the page.
4. On Monday at 14.00, the 1-day reminder carries the manage link.
5. The patient moves the appointment to Thursday, 09.00, through that link.
6. The booking.rescheduled event cancels old reminders and schedules new ones.
7. On Thursday at 08.00, the 1-hour reminder carries the clinic address.

Observable output. Two reminders recorded as delivered, 2 Wednesday slots never shown, 0 messages about the abandoned Tuesday time.

Decision. If 2 reminders in a row stop at sent, pause sending that day and work through the next section. Never add messages to cover a failure.

When a reminder does not arrive, check this

Read top to bottom. Stop at the first row that matches.

What you see	Likely cause	Action
Status stops at sent	Phone off or no network	Wait, then read the status again
Status failed with a code	Wrong number or refused template	Read the error code, fix the number
No status at all	Your endpoint never answers 2xx	Fix the endpoint, then send again
The message arrives twice	One event arrived more than once	Store the event id, refuse repeats
Reminder names the old time	The reschedule event was ignored	Cancel old jobs when the time changes
A template stops sending	The quality rating fell	Rewrite the message, send less often
One hour sold twice	The calendar is not connected	Connect the calendar, check its status

Setup checklist

1. Approve 2 reminder templates before the first message.
2. Store the sent, delivered, and failed status of each message.
3. Schedule reminders 1 day and 1 hour before, then drop the rest.
4. Connect the calendar, then confirm a connected status.
5. Block an hour on your calendar, then watch that slot disappear.
6. Put the self-service link in the confirmation and the 1-day reminder.
7. Store webhook event ids and refuse an event you already handled.
8. Read template ratings each month, then rewrite what fell.

Connecting a booking to the ad that produced it

Reminders save bookings you hold, but they do not name the ad that produced them. For that, the click trail must reach the booking record. The steps sit in our guide to Click to WhatsApp ad tracking.

One limit: this link needs marketing consent, and the data covers only the people who gave it. To have me build it, see the attribution bridge service.

Questions I hear often

How many reminders should I send before an appointment? Send 2. One a day before, so the person can still move the time, and 1 an hour before, so the person leaves on time.

What is the difference between sent and delivered? The sent status means the message left the Meta server, 1 check mark. The delivered status means it reached the device, 2 check marks.

Does calendar sync read my whole calendar? No, when the permissions cover busy status and booking events only. The Termilo documentation names those 2 as minimum access.

Do I need to connect Google Meet separately? No. The Termilo documentation states that a Meet link comes from the Google Calendar event, so 1 Calendar connection is enough.

What do I do when a reminder never arrives? Open the status record first. If it stops at sent, wait and read it again. If it shows failed, read the error code and fix the number.

Can a customer move an appointment without an account? Yes. A self-service link carries 3 actions, which are read, cancel, and reschedule, and it binds to 1 booking.

Sources

• Termilo, termilo.id/docs/integrations/google: sync direction, permissions, Meet links.
• Termilo, termilo.id/docs/integrations/zoom: meeting creation, join link versus host link.
• Termilo, termilo.id/docs/webhooks: event names, signatures, retries, status labels.
• Termilo, termilo.id/docs/auth: the manage token and its 3 actions.
• Termilo, termilo.id/llms.txt: page list and preview labels.
• Meta: message status webhook, updated 21 May 2026.
• Meta: messages webhook reference, the statuses array.
• Meta: template quality rating, updated 17 June 2026.
• Meta: messaging limits, the 250 and 2,000 figures.