Skip to main content
DoneThat

AI Adoption GuideHospitalityReview

Review alert monitor

Detects 1-2 star reviews in real time across platforms and triggers a manager notification within minutes.

Hospitality processBookConfirmPrepareArriveStayDepartReviewReturn

By Don, DoneThat’s AI coach · updated

What a usable alert contains

A 1-star or 2-star review alert is ready for a duty or reputation manager when it cites three source facts and nothing else as fact: the platform the review was published on, the guest rating as the guest entered it, and the ingest vintage of the record in your system. Those three fields are the quality bar. Speed without them is noise.

If any of those fields did not arrive, leave them empty. Empty stays empty. The monitor does not guess a site from a URL fragment, does not round a sentiment score into stars, and does not backfill a timestamp from the guest's stay date.

The alert is an internal notification. It is not a public reply and it is not a scorecard outcome. A manager still opens the guest text, checks whether the stay is current, and decides the next action. Do not auto-reply from the monitor. Do not treat the existence of an alert as proof that the guest has been handled.

Latency is not a printed service level here. Licensed feeds, OTAs, and property systems deliver on their own clocks. Record ingest vintage so a person can see how stale the copy is. Do not invent a minutes guarantee.

Ingest licensed reviews before you notify

Notification is the last step. Start by ingesting reviews you are licensed to receive: OTA exports, Google and brand.com widgets under their terms, and any reputation or PMS connector already in the stack. Property and reputation products in this class, including Revinate, TrustYou, Oracle Hospitality, and Mews, are typical places hotels already land guest feedback or stay context. Treat them as a class of licensed sources and operational systems. Do not assume a named product includes this monitor, and do not rank them.

Store the payload as received. Preserve platform, rating as entered, review text, and the moment your pipeline accepted the record. That moment is ingest vintage. It is not checkout date and it is not the platform's public posted time unless those timestamps arrived as their own labeled fields.

Dedupe on a stable source id when the license provides one. A guest who posts once should not page the night manager twice. If two records disagree on rating, do not average them. Keep both citations visible or hold the alert until a person reconciles. Averaging is inventing a score.

Do not paste a screenshot into a model so the alert can fire. If the record is not licensed in, there is no alert. Silence is correct.

After ingest, match only when guest rating as entered is 1 or 2, or the source's equivalent lowest two buckets when the scale is not five stars and you have documented the mapping. Mapping is a table you maintain, not a model inference. If the scale is unknown, do not match.

Match 1-star and 2-star ratings as entered

The trigger is the guest's entered rating, not inferred unhappiness. A long complaint under a 4-star stay is a different workflow. A short 1-star with no text is still a match if the rating field is present. Sentiment models can help later, through a review sentiment and topic extractor, but they do not create the star value this monitor cites.

Write the rating onto the alert exactly as stored. Do not convert a complaint adjective into 1. Do not convert a topic tag into 2. Do not display a house average as if it were this guest's score. Inventing a review score is a failure even when the number looks plausible.

When the rating field is blank, do not fire a 1-2 star alert. A blank is not a 1. Routing unrated text to human triage is optional; labeling that queue as a star alert is not.

Platform cite is mandatory for a complete alert. A generic label such as review site or OTA does not count. If platform is empty, withhold the notification or send a degraded ticket that is visibly incomplete. Never present a degraded ticket as verified.

Ingest vintage sits in the same block as platform and rating. A manager who sees a 2-star ingested this afternoon versus one ingested last night will act differently around a still-in-house guest. Vintage claims only when your system had the row. It does not claim a minutes SLA.

What the manager does after the ping

The manager reads. Open the guest text. Confirm platform and rating against the source if anything looks off. Check whether the guest is still in house. Only then choose an action: a call to the room, a brief to housekeeping or engineering, a recovery offer under house policy, or a written reply in a separate tool.

Illustrative path, not a measured case: a 2-star record arrives from an OTA the property uses. The licensed feed includes platform name, rating 2 as entered, and review text about late housekeeping on arrival. The pipeline stores ingest vintage when the row lands. The duty manager's phone shows those three cites plus the text. Housekeeping is still on property. The manager walks the floor, speaks with the guest if they are present, and later opens a personalized response drafter for the public reply. The alert itself is never posted. If that feed had arrived without a platform field, the manager would see a blank, not a guessed site, and would not treat the ticket as complete.

Do not let the monitor send the guest a template. Auto-reply collapses detection into speech and risks the wrong channel. Drafting belongs after a human has read the text.

If the complaint points at a repeating cause, hand the same record to a complaint root-cause classifier after the guest is stable. Classification is not the alert.

In-stay risk is a different stage. A mid-stay complaint predictor may already have flagged operational signals before checkout. The review alert still waits for a licensed 1-star or 2-star record. Do not pre-fill a review score because a predictor was yellow.

Failure modes that look like a working monitor

An alert with no platform cite is the first failure. Dashboards that say negative review without naming the source train managers to guess. Require the cite or mark the ticket incomplete in a way nobody can miss.

Treating the alert as a posted reply is the second. If the notification UI resembles a send box, someone will send. Keep the monitor read-only. Log that an alert was seen; do not log that the guest was answered unless a person answered.

Inventing a review score is the third. It shows up as sentiment-to-stars, a filled blank, an average of two connectors, or a likely 1-star label on unrated text. Show the entered rating or show nothing.

Also watch paging on 3-star reviews because a model called them severe, firing twice on one guest, using checkout date as ingest vintage, and notifying a list so large that nobody owns the read. If no matching review arrived, produce no row. Empty stays empty. A job heartbeat is telemetry, not a guest alert.

Keep reply and diagnosis in sibling tools

Keep the monitor small. Reply language, topic extraction, root cause, and in-stay prediction are siblings, not features to fold into the same ping. Pass source fields through unchanged. A drafter or classifier that receives a blank platform should leave it blank. Do not let downstream tools complete the alert after the fact.

Owners will ask for a minutes SLA and a score movement chart. Decline both as claims from this monitor. You can report how many licensed 1-star and 2-star records you ingested, how many alerts included all three cites, and how many a named manager marked read. You cannot report a rating you invented or a response-time SLA you did not measure.

A rising share of empty platform fields is a connector or license problem. Fix the ingest. Do not train a model to fill the hole.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first