AI-drafted replies to hotel reviews: a workflow with a person in charge

An AI review response is a reply to a public guest review that a language model drafts from the review and the hotel's own notes, and a person checks for facts and privacy before posting. AI removes the blank page, not the judgment: the hotel still decides what is true, what is private and what goes offline.

The queue is full, so someone pastes a review into a chat tool, takes the paragraph it returns and posts it. It reads well. It also apologizes for a broken elevator the hotel does not have, and repeats the room number the guest mentioned. This article gives you the workflow that prevents both: what the model is given, what never goes public, how a draft is checked, which complaints move offline, and who owns the whole process day to day.

What does AI change in hotel review replies, and what goes wrong?#

It changes the drafting step, not the decision. A model produces a usable first draft in seconds from the review and the hotel's notes; reading, verifying and posting stay with people.

The blank page disappears, and so does the backlog. A team that previously answered only the angriest reviews can now answer all of them, which is a change in coverage before it is a change in quality. Coverage matters: a future guest reading the profile sees whether the hotel responds at all. But coverage alone does not earn trust, and the failures below are all failures of the workflow around the model, not of the model itself.

Failure one is repetition. The same opening and closing on every review means the guest, the next guest and anyone reading the profile see a template rather than an answer. Failure two is invented facts. A language model is built to produce fluent text, not to check records, so it fills gaps with plausible detail: a renovation that never happened, a facility that is closed in winter, a manager who does not exist. Failure three is privacy. A review is public, a reply is public and permanent, and a model will happily repeat a name, a room number or a health detail that the guest themselves mentioned. Failure four is misplaced apology. Apologizing for something the hotel did not do turns into a public admission and tells future guests the complaint was justified.

The useful mental model is this: the model is a writing aid with no access to the truth. The workflow you build around it supplies the truth.

What should the AI be given before it writes a draft?#

Three inputs: the review itself, the hotel's own record of that stay, and a short tone guide. Without the second, the model can only produce generic sympathy.

The review goes in whole, with its rating and its date. The date matters more than it looks: it tells you what was open, what was under renovation and which season the guest saw. A reply that promises the pool is wrong if the review is from January.

The hotel's notes on that stay come next: booking source, room type, arrival and departure, any complaint logged at the front desk, any recovery already offered. This is what turns a vague apology into a sentence about the noise reported on the second morning and the room change that followed. These notes come from the property management system's guest record, the front desk log and the guest relations inbox. If those notes do not exist, the draft will invent them.

Then the standing instructions. A one-page tone guide: whether the hotel writes as "we" or as a named person, how long a reply runs, whether thanks come first, and what the hotel never says in public, such as prices, blame on a supplier or an argument with the guest. Property facts that change over time: opening hours, renovation schedule, which facilities are seasonal. A model that does not know the pool closes in November will promise the pool.

Two more rules sharpen every draft. A banned-phrase list, because the interchangeable sentences are known in advance: "valuable feedback", "we strive", "rest assured", "we will look into it". And a shape rule: two to four sentences, one acknowledgement, one specific fact, one action or one invitation to a private channel. For more on building the prompt itself, see writing prompts for hotel work: a simple method with examples.

What must never appear in a public reply?#

Nothing that identifies the guest, nothing about health, money or identity documents, and nothing only the hotel could know. A public reply is read by future guests, by the guest's family and by anyone searching the hotel's name.

Start with names: not the guest's, not the companion's, not a staff member's full name. A first name plus a date plus a room type can already identify a person. Then the stay details that narrow identity: room number, exact dates, booking reference, group name, flight number. The guest knows these details; the point is not to confirm them publicly.

Health and personal circumstances stay out: illness, disability, pregnancy, a dietary need tied to a medical condition, anything the guest wrote in a private message rather than in the review. Money stays out too: the amount paid, a refund, compensation, a discount, whether a charge was waived. Billing belongs in a private channel, not under a public post.

Identity and compliance data are the hardest line. Nothing from the guest identity notification (KBS, misafir kimlik bildirimi) or from identity documents may appear in a reply, and staff should not paste such data into a drafting tool either. More generally, under Türkiye's personal data protection law (KVKK, kişisel verilerin korunması kanunu) personal data must be processed lawfully and limited to its purpose, and a public reply is a publication. Confirm your own case with a legal adviser; this article does not state penalties or deadlines.

Finally, internal matters and legal admissions: an ongoing investigation, a disciplinary case, a named employee's shift, or a sentence such as "our food caused your illness". Say what was done, not what caused it, until the facts are established. For the broader question of what staff may paste into AI tools at all, see hotel AI policy: what staff may share with AI chat tools.

How do you check a draft before it is posted?#

Three passes, in this order: facts, privacy, specificity. Facts first, because a false statement cannot be repaired by tone.

The facts pass asks whether every claim in the draft matches the hotel's record: dates, room type, facility hours, and whether the promised action actually happened. The privacy pass runs the banned list against the draft, looking for names, numbers, money, health and documents. The specificity pass asks the only question that matters for quality: could this reply be posted under a different review without anyone noticing? If yes, it is not a reply yet. Then voice: does it sound like the person signing it, and is it free of the stock phrases?

Who checks matters as much as what is checked. The person who will sign the reply checks it, not the person who wrote the prompt, and anything above a mild complaint gets a second reader. The check costs a minute or two per reply; that is the price of the workflow, and it is smaller than the price of one leaked detail. Keep the posted reply next to a note of what was changed, so a pattern of model errors becomes visible within a month.

Which complaints should move offline, and who owns them?#

Complaints about safety, health, money, discrimination or staff conduct get a short public acknowledgement and a private conversation, and each type has one named owner.

The public part is two sentences: we are sorry this happened, we have contacted you directly, here is how to reach us. No detail, no defence, no summary of an investigation. The private part has a named person, a channel and a time limit the hotel sets for itself. The reply promises a conversation, never an outcome.

Owners by type, for example: safety and injury to the general manager; illness and food to the food and beverage manager with the GM informed; billing and refunds to the front office manager with accounting; staff conduct to the GM or human resources; discrimination to the GM. Injury, theft, allergic reaction and any suspected data incident go to the hotel's legal adviser before a word is written, public or private.

What not to do is as important as what to do: do not argue the facts in public, do not ask the guest to delete the review, do not offer money in a public reply, and do not let the model draft the private message from the same prompt that produced the public one. Close the loop by putting the offline outcome back into the guest record, so any later reply starts from what actually happened. And if the same complaint appears three times in a month, the reply is not the problem; the operation is, and it belongs in the weekly operations meeting rather than in the review queue. For the front desk side of the same problem, see hotel guest complaints at the front desk: a recovery routine.

How do you keep replies from sounding identical?#

Force one specific detail from the review into every draft, and ban the phrases that make replies interchangeable.

The one-detail rule is the core: every reply names something only this guest mentioned, in the guest's own words where possible. Ban the openers, "thank you for your valuable feedback", "we are delighted", "we strive to", and replace them with a plain sentence about the stay. Vary the shape as well: sometimes start with the action, sometimes with the acknowledgement, sometimes with the fact. A model repeats structure when the prompt repeats structure.

Rotation helps too. Replies signed by guest relations, the front office manager and the GM read differently, and the model can be told who is signing. Keep a sample file of ten replies the hotel is proud of and give it to the model as the voice reference; update it every quarter. Audit monthly by reading twenty consecutive replies: if five of them could be swapped without anyone noticing, the inputs or the prompt are too thin.

Accept some sameness. Greetings and closings will repeat, and that is fine. What must not repeat is the middle, where the answer lives. If you want ready-made wording to start from, see example replies by complaint type.

Who is in charge, and how does the workflow run day to day?#

One named person owns review replies end to end: the model drafts, a checker verifies, and the owner signs anything sensitive.

The roles are three: a drafter, which is the model plus whoever runs the queue; a checker, who is the person who signs; and an escalation owner for each complaint type. The daily rhythm is short: pull new reviews, match each to a stay record, draft, check, post, log. On a normal day this is a short block of work, not a project. Weekly, read the posted replies together, note repeated model errors, and adjust the tone guide and the prompt. Monthly, run the complaint pattern review with department heads, which is where replies turn into operational change.

When volume spikes, draft in batches but never check in batches; the check is per review. Write the rules down on one page: who may post without a second check, who may not, and what always escalates. A one-page rule is followed; a long policy is not. And if the hotel has no AI policy yet, start there, because staff are already pasting reviews into whatever tool is open on their phone.

What to do next#

Write the tone guide and the banned-phrase list this week. Name one owner for replies and one escalation owner per complaint type. Then run ten past reviews through the whole workflow, from record to draft to check to signature, before touching the live queue. The pieces fit in one order: inputs from the hotel's own records, a draft, a facts and privacy check, a person's signature, and an offline path for the complaints a public reply cannot resolve.