Hotels stop duplicate AI follow-ups by giving each intended message a stable identity, checking current guest and booking state immediately before sending, and reconciling uncertain delivery before retrying. Opt-outs must suppress queued work as well as future scheduling. A prompt saying “do not repeat yourself” cannot enforce these controls.
Find the sources of duplication
The same enquiry can enter through a website form and WhatsApp. A provider can repeat an event. A worker can time out after the message was accepted. Two scheduled jobs can pick up the same record. Each produces a different technical path to the same guest-visible mistake.
Begin by tracing one complaint from the guest's received messages back to the delivery records and scheduling decisions. Do not infer the cause from similar wording alone. Two different campaigns may each believe they have permission to send.
Use a send-decision ledger
| Field | Purpose |
|---|---|
| Property and recipient | Scopes the contact to the correct hotel |
| Journey and intended step | Distinguishes a reminder from another business purpose |
| Eligibility snapshot | Records why contact was permitted at send time |
| Stable operation identifier | Allows repeated work to resolve to one intended send |
| Provider identifier and outcome | Supports delivery reconciliation |
| Suppression reason | Explains why a queued message was stopped |
Check suppression at the last responsible moment
A guest can opt out after a reminder is scheduled but before it is sent. Check the latest state immediately before dispatch. Also suppress reminders when the enquiry is resolved, the booking is confirmed, the stay is cancelled, or the offer is no longer relevant.
The WhatsApp policy requires respecting opt-out requests. The practical implementation must therefore reach queued messages, not just a contact-list checkbox used by the next campaign.
Distinguish retry from a new message
If a provider confirms failure before acceptance, retrying may be appropriate under the channel's rules. If the outcome is unknown, first reconcile it. Sending again immediately can turn uncertainty into duplication. Retain the operation identity across retries so the system recognizes the same intended work.
A message that was delivered but not answered is not a failed delivery. Do not treat the absence of a reply as permission to retry the same notification indefinitely.
Test an opt-out race and a repeated event
In a test environment, schedule a reminder, record an opt-out, then let the worker run. The expected result is no outbound message and a visible suppression reason. Repeat the provider event several times and check that it does not create additional work.
Next, interrupt the worker after provider acceptance but before local completion. Recovery should reconcile the existing send or expose an uncertainty case; it should not silently resend. Include these scenarios in the pilot test pack.
Keep the operator explanation clear
Staff need to know whether a message was skipped, failed, delivered, or remains uncertain. A single “processed” status hides the difference. Alert on repeated failures and review unresolved delivery cases before increasing follow-up volume.
Oracle's event-integration documentation illustrates the event-driven context in which hotel systems operate. Duplicate prevention and contact suppression remain responsibilities of the actual workflow.
Connect these controls to Hotelary's workflow overview and the WhatsApp automation guide. The 24-hour follow-up article covers channel eligibility. Measure duplicate guest-visible sends, not just whether the scheduler completed its job.
Sources and further reading
Sources reviewed on September 14, 2026. Check current vendor terms and policies before implementation. Examples and checklists are editorial guidance unless explicitly identified as reported research.
- WhatsApp policy — business.whatsapp.com
- Oracle's event-integration documentation — docs.oracle.com
