I build DOS AI (dosai.pro), a platform where a small business sets up an AI assistant for WhatsApp, Instagram and Telegram. Booking is a core feature there, and the part that sounds trivial, "send a reminder before the visit", turned out to hold most of the rules.
None of this is about the model. The reminder texts are templates, not generated, and they cost the owner nothing. The work was deciding when not to send.
1. Night is a hard wall
Messages about a booking go out between 9:00 and 21:00 in the project's time zone. Two cases fall out of that:
- A reminder that would land at night is sent the evening before, at 20:30. A 9:30 visit with a "two hours before" reminder gets it at 20:30 the previous day, not at 7:30.
- A confirmation for a booking created at night goes out at 9:00. If the visit itself is before 10:00, the confirmation is skipped, because the reminder already covers it.
A confirmation arriving twenty minutes before the visit it confirms is noise.
2. Do not confirm what the customer already knows
A confirmation is for a person who has not heard from you yet. So it is not sent when:
- the bot made the booking itself (it has just written "you are booked" in the same chat);
- the chat was active in the last 30 minutes;
- the business's own system says it sends confirmations on its side.
Reminders still go out in all three cases.
3. Never write first to a stranger on WhatsApp
A reminder is a message the business sends first, with no fresh message from the customer. WhatsApp blocks numbers that write to people who never wrote to them. So the rule is: we only message someone who has already written to this WhatsApp number, and we check that at send time, not at booking time. If the customer writes between the booking and the reminder, the reminder goes.
For everyone else the booking shows the reason in plain words, "the customer has never written to your WhatsApp number", and a button that opens WhatsApp on the owner's phone with the text prepared. A human sends it. That is slower, and it keeps the number alive.
4. Each channel has its own window
Instagram does not take part at all. You may answer there only within 24 hours of the customer's last message, so a reminder a day ahead cannot get through. Telegram does take part: a chat with a bot exists only if the customer started it.
It is tempting to hide this behind a "send reminder" abstraction. We show it instead, because the owner needs to know why a given customer got nothing.
5. A reschedule must find the same booking
Moving a booking moves its reminders. Cancelling removes them. The hard part is knowing that two events are the same booking.
When a booking lives in an external system, we ask for its booking id and match on that. Without an id we fall back to a rule: a repeat booking by the same customer in the same conversation within 2 hours is a reschedule, a later one is a new booking. It is a guess, and the guide says so.
6. Every message has a visible fate
Each reminder in the list carries one of five labels: scheduled (with the time already adjusted for the night rule), sent, not sent with a reason, not delivered, removed. "Not sent" always names the cause: no WhatsApp connected, subscription ended, reminders switched off, customer never wrote.
Without such a list, "the customer says they got no reminder" has no answer. With it, the answer is one line to read.
What I would do first next time
Write the "do not send" rules before the "send" code. Sending a templated message at a given time is an afternoon. Night hours, strangers, channel windows and reschedules are where the design time goes, and each of them is a case of a real person getting a message they should not have.
The owner-facing description of all this is in our guide: confirmations and reminders.
Top comments (0)