Extend "Do not send if guest has already reviewed" suppression to Booking.com (review signal already available in UI and API)

Problem statement

The messaging rule setting "Do not send if a guest has already published a review" is currently labeled "Airbnb only" and does not prevent review-request messages from being sent to Booking.com guests who have already left a review — even though Hospitable already receives and displays the Booking.com review signal in both the UI and API.

Technical context

The Booking.com review-published signal is already fully surfaced inside Hospitable:

  • UI: The chat thread renders a system event ("[Guest] left a [N]-star review") inline between messages when the guest publishes.
  • API: GET /reservations/{id}?include=review returns a populated review object with reviewed_at timestamp, public review text, platform-original rating, and detailed sub-ratings.

The data the suppression logic needs is already consumed by the platform — it simply isn't being read by the messaging-rule evaluator at send time for non-Airbnb reservations. Likely an oversight that emerged as the BDC integration matured: the review event became available, but the corresponding guardrail in messaging rules was never updated to consume it.

Current workaround

Hosts must manually monitor which Booking.com guests have already reviewed and either:

  • Disable automated review-request rules entirely for Booking.com reservations, or
  • Accept that some guests will receive redundant review requests after they've already left a review

Impact

  • Guest experience: Guests who have already taken the time to leave a thoughtful review receive an automated request asking them to do what they've already done — creating confusion and undermining the impression of an attentive, well-run operation
  • Host credibility: Sends the message that the host isn't paying attention or doesn't have their systems properly configured
  • Operational friction: Hosts must either disable helpful automation or accept occasional embarrassing mistakes

Repro case

Reservation #6962107678 (Booking.com). Guest checked out May 16, 2026; published a 10-star review on May 17, 2026 (reviewed_at: 2026-05-17T16:51:42Z). Automated "Review Request BDC" rule with "Do not send if already reviewed" enabled still fired at T+3 days post-checkout, sending a review request to a guest who had already left a glowing public review.

Proposed solution

Extend the existing "Do not send if a guest has already published a review" suppression logic to evaluate the review-published signal for Booking.com reservations (and ideally all platforms where the signal is available). The review data is already consumed by Hospitable's UI (visible as system events in chat threads) and exposed in the reservations API — it just needs to be checked by the messaging-rule evaluator at send time.

Unlock

Hosts with meaningful Booking.com share — particularly those running automated review-request workflows at parity across channels — can rely on a single suppression rule rather than disabling automation per-channel or accepting occasional redundant sends. Closes the last meaningful gap in BDC ↔ Airbnb messaging-rule parity for review workflows.

Please authenticate to join the conversation.

Upvoters
Status

New

Board

💡 Feature requests

Date

2 days ago

Subscribe to post

Get notified by email when there are changes.