Skip to main content
DoneThat

AI Adoption GuideHospitalityReview

Personalized response drafter

LLM generates platform-appropriate review responses with tone matched to sentiment and brand voice guidelines.

Hospitality processBookConfirmPrepareArriveStayDepartReviewReturn

By Don, DoneThat’s AI coach · updated

A draft only counts if it quotes the guest

The quality bar is a reply draft that repeats a sentence from the review, then answers that sentence. Empty stays empty when the guest never said the thing. A reputation manager still posts. Nothing auto-posts. Nothing invents a review score.

A template that opens with "We are delighted you enjoyed your stay" when the guest wrote about mildew is not a personalized draft. It is a form letter with a name merge. The cite is the proof that the model read the review. Without a cited span, you cannot tell whether the reply belongs to this guest or to last week's generic recovery script.

A Google listing reply is short and public. An OTA reply sits next to booking metadata the guest can see. Brand-voice guidelines usually constrain greeting, apology depth, and whether you name a department. The draft has to fit those constraints without padding topics the review never raised.

This sits next to a review alert monitor, which tells you a new review arrived, and a review sentiment and topic extractor, which labels tone and themes. Those tools classify. This one writes. Classification is not a substitute for a quoted sentence in the reply body.

Load the review from the channel you will answer on

Pull the live review text, the platform, the language, the stay dates, and the room or reservation identifier before you generate anything. Do not paste a paraphrase from Slack. Paraphrases drop the exact span you need to cite, and they often add a score someone typed from memory.

Reviews typically land in a reputation inbox or a property-management guest thread. Systems in this class include Revinate, TrustYou, Oracle Hospitality, and Mews. Treat them as the place the text already lives, not as interchangeable reply engines. Copy the guest's words out of the record you will post back into.

Capture three fields the model must not invent:

  • Platform habits: what a Google reply can say versus what an OTA reply can say.
  • The guest's language. Answer in that language unless brand rules require a bilingual close.
  • Stay facts you can verify in the PMS. If arrival dates, room type, or rate plan are not in the record, leave them out.

If the review is a star graphic with no prose, stop. There is no sentence to cite. Leave the draft empty and route the manager to a short, policy-safe acknowledgement already approved for score-only reviews. Do not have the model invent a numeric score, a "4 out of 5" gloss, or a reason the guest "must have meant."

When the same guest complained during the stay, pull that thread too. A mid-stay complaint predictor may already have flagged the corridor or the HVAC ticket. The drafter still quotes the public review, not the internal ticket, unless the guest repeated that wording in the review.

Cite a span, match tone, leave silence blank

Ask for a draft that does four things in order: quote or closely paraphrase one span from the guest; answer that span with a fact you can stand behind; match sentiment and brand voice for the platform; leave every other topic blank.

Here is the only example this page needs. A Booking.com review for a city property includes this sentence: "The corridor carpet outside 412 smelled of mildew after the rain, and nobody offered to move us." The guest does not mention breakfast, the gym, or the front-desk team by name. They do not give a prose score.

A usable draft cites that corridor sentence, apologizes for the smell and the missed move, and states what the house will do next: inspect 412 and the corridor, and offer a room change on a future stay only if that is actual policy. It does not thank the guest for a "relaxing stay" or praise the restaurant. If the PMS has no note that a move was offered, the draft must not claim one was. If mildew is unconfirmed, the draft says the team will inspect.

Tone matching is not cheerfulness. A frustrated review gets a calm, specific apology. A mixed review gets thanks only for the parts the guest actually praised, and a cite for those parts too. Follow the brand-voice sheet for names, private-email offers, and compensation. Do not invent a voucher amount.

Blanks are part of the artifact. If the guest was silent on breakfast, the breakfast paragraph is absent, not a hope they enjoyed the buffet. Silence in the review is not permission to upsell or to fill word count. A short draft that cites one problem beats a long draft that invents three compliments.

If the extractor tagged "housekeeping" and "noise" but the cited span is only the mildew sentence, the reply stays on mildew unless the manager adds a second verified span. Topic labels are hints for the complaint root-cause classifier and for ops. They are not extra paragraphs the guest asked you to write.

The manager posts; the draft is not live

Generate into a scratch field, a ticket note, or a local editor. Do not write straight into the live reply box with auto-send on. The quality outcome is a draft.

The manager checks four things before posting:

  1. The cited span appears in the review, word for word or as a tight paraphrase the guest would recognize.
  2. Every operational claim is true today: inspection, room move, contact path, compensation if any.
  3. The reply fits the platform and the brand-voice sheet, including language and length.
  4. Names, room numbers, and medical or legal details that should stay private are not in the public text.

Then the manager pastes, edits, and submits in Revinate, TrustYou, the Oracle Hospitality guest record, Mews, or the OTA console itself. Which screen they use does not change the rule: the model never clicks post.

Two failure modes hide in this step. First, a reply with no review cite. If the draft could be pasted onto any other review this week, reject it and regenerate against a span, or write the reply by hand. Second, treating the draft as posted. A saved suggestion in an inbox is not a public response. Clocks for "responded" start when the platform shows the reply, not when the model finished. If you mark the alert closed at draft time, the listing stays unanswered.

Do not use a model-invented review score as a close-the-loop metric. If the platform already shows a score, leave it alone. Outcome for this use case is the cited draft plus a human post, not a number the model guessed.

Keep detection, labeling, and the public reply on separate jobs

Keep the drafter downstream of detection and labeling. The alert still pages the on-call manager. The extractor can pre-fill tone and theme so the prompt starts in the right register. Neither tool should be allowed to skip the cite.

After the reply is posted, send the same review text into the classifier so housekeeping, engineering, or front office get a work item. The public reply is not the work order. Citing mildew in the guest-facing draft does not log a carpet replacement. Split those jobs on purpose.

If the review describes something that was already boiling during the stay, compare it with the mid-stay signal for the next occupancy. Do not stuff the public reply with internal jargon.

Prompt and checklist, in one pass: load the review from the system of record; require a cited span; forbid topics and scores the review did not state; leave blanks; require a named manager to post. If any of those steps is missing, you do not yet have a personalized response drafter. You have a faster form letter.

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