Booking notifications: check them before switching on

Before you switch on automated booking messages, check that each one will say the right thing at the right moment. The usual trap is that an alert fires when the system learns of an event, not when it happened. Here most cancellations were typed in after the trip, so a cancellation alert would have told twenty-nine customers that a holiday they had already taken was cancelled. The first check is to compare the date each of your last fifty cancellations was entered with the date of the trip.

Here is how that looked at one car hire business, and what fixing it took.

You run a car hire business and you ask a fair question: what does a customer actually get told about their booking? When we checked for GOI Car & Taxi, a self-drive and taxi hire business in Goa, the answer was less than anyone assumed. A customer who booked months ahead heard nothing asking for their documents until the last week. A cancellation reached nobody. A refund landed without a word.

The obvious move is to switch every missing message on. Doing that blindly would have been worse than the silence. Only 6 of the 71 cancellations on the live system were recorded before the pickup date. The rest were entered afterwards, as bookkeeping, for trips that had already happened. A cancellation alert wired to every cancellation would have told twenty-nine people that a holiday they had already taken was cancelled.

What was actually going on

Three separate gaps, each measured rather than assumed.

The document reminder only started chasing when pickup was within seven days. Of 1,965 bookings over six months, 244 (12.4%) had been made further out than that, twenty of them between 63 and 233 days ahead. Fifteen bookings were sitting in that silent window on the day we looked.

Cancellations reached nobody, and the obvious fix had the trap described above: the system records a cancellation when somebody types it in, not when the customer cancels.

The third gap was refund details. The message asking a customer for their bank details fired only when a booking moved forward into Returned. It could not see a backlog that had already passed through. There were 121 bookings past drop-off with no bank details, 120 of them more than a week old. There was also no country or nationality field anywhere, so “Indian customers only” had to be decided from the shape of the phone number; 183 of 197 past-drop-off bookings matched.

What we changed

The owner chose two of the three to close first.

A booking-received message now also makes the first document request, sent exactly once, from the one place where a booking row is first created. That place runs once per booking. We wrote that down in three places, because moving the call to the place that handles updates would quietly message every customer every fifteen minutes.

The cancellation notice only goes out if the pickup is still ahead. Our first version had a second flaw that we caught before it shipped: a booking can arrive from the parent platform already cancelled, and the order of steps meant it would first have been sent “your booking is confirmed”. The notice is now gated on status as well as on the date.

The refund request carries its own cut-off by construction. It fires on the transition into Returned, so the 121 old bookings are not mailed about trips that ended in July.

Messages on WhatsApp must use templates pre-approved by Meta, so template approval, not code, was the slow part. Four of seven were approved within minutes and sent to the client’s own phone, where the two-button map layout worked on a real handset. A master switch, read on every send, let WhatsApp stay off in production until approval.

What it did not fix

A third gap was reported and left with the owner: payouts notify the office’s chat, so a customer is still not told when their deposit actually lands, which is the message they are waiting for.

The 65 cancellations entered after the trip are deliberately silent. That is the point of the gate, but it also means nothing tells those customers anything. And the 244 bookings that went silent before this change stay as they were.

How to check your own booking notifications

1. Pick your last fifty cancellations and compare the date each was typed in with the date of the trip. If many are entered afterwards, the event you are alerting on is bookkeeping, not news.
2. Check the reverse: which customers are told nothing because a rule starts too late. A seven-day reminder quietly excludes everyone who booked a month out.
3. Ask where in the system each message fires. A message sent once, where a booking is first created, is safe. The same message wired to updates would reach every customer every fifteen minutes.
4. Ask what a booking that arrives already cancelled is sent first. Here it would have been told “your booking is confirmed”.
5. Ask whether the customer is told when a refund or deposit actually lands, which is the message they are waiting for.

Where this ends up

Deciding when a message is true, not just when it is possible, is the core of how Sazinga Rentals sends booking and refund notices.