AI replies to guest messages: when to hand over to staff

Hand over to staff, meaning pass the conversation to a person, whenever the answer is not already in the hotel's approved written facts: money, complaints, health and safety, exceptions, or any promise the hotel cannot keep. Automate only written answers, start with drafts a person sends, and review transcripts weekly.

A guest writes at 23:40 that the room above is being refurbished and asks to move. The reply goes out in four seconds, in faultless German, and promises a sea-view upgrade the hotel does not have. The language was never the problem. Nobody had written down what the hotel may promise. This article gives you the rules to write before any AI guest messaging for your hotel sends a single reply: what the software may answer alone, what goes to staff, how the guest is told, and what staff receive at handover.

What should an AI guest messaging system never answer alone?#

Anything the hotel has not written down in an approved fact sheet, plus four categories that always reach a person: money, complaints, health and safety, and exceptions.

Start with the written facts. One short document the hotel owns, one line per fact: breakfast times, pool and spa hours, parking, pet policy, distance to the airport, cancellation terms, extra-bed charge, check-in time. Number every line. This document is the boundary of what the software may say.

Apply one test to every incoming message: can the answer be traced to a numbered line in that document? If yes, the software may answer. If no, it hands over. Confidence is not a substitute for a written line, because a generated answer is fluent whether or not it is correct. Türkiye's Personal Data Protection Authority (KVKK) describes this in its generative AI guide, published 24 November 2025, as content that does not match reality but often looks plausible and convincing, and says accuracy has to be checked (KVKK, "Üretken Yapay Zekâ ve Kişisel Verilerin Korunması Rehberi (15 Soruda)", 24 November 2025 (opens in a new tab)).

Treat the four categories as structural, not as settings. Money is a commitment with a paper trail. Complaints carry legal and emotional weight. Health and safety can become a duty. An exception is by definition outside the written rule. Allow the software a narrow role even in those categories: acknowledge the message, ask for the room number, state when a person will reply, and stop. It never decides the outcome.

Weigh the two failure modes honestly. A slow human answer annoys one guest. A wrong promise forces the hotel either to honour a cost it never planned or to break its word in front of the guest. Write the never-answer list down and date it, so that a new employee, a new channel or a new tool cannot quietly widen what the software is allowed to say. For a wider view of where AI fits in hotel operations, see AI in hotels: a practical guide to uses, limits and safeguards.

How do you start safely: drafts a person sends first?#

Run the system in draft mode first: it writes, a person edits and sends, and every correction becomes a line in the fact sheet. Nothing reaches a guest automatically until its topic has a written answer and an owner.

Use three stages, not one switch. Stage one is draft-only. Stage two is automatic replies for a short list of fact-sheet topics. Stage three widens that list topic by topic. The temptation is to jump to stage three, and then nobody can explain afterwards what the software said.

Make the fact sheet the gate: a topic goes live only when it has a written answer, a named owner and a review date. A topic without those three stays in draft mode. Keep a parallel do-not-answer list for refunds, medical questions, safety incidents, legal correspondence and anything involving a third party's money.

In draft mode, record why each draft was edited: missing fact, wrong fact, wrong tone, wrong trigger. That log is the real output of the first weeks, more useful than any count of messages handled. Give the fact sheet one owner, usually the front office manager, with versioned and dated changes, so that two departments cannot hold two different truths about the same policy.

Test the handover route with a real message from a staff phone before go-live, including at night, because a handover that lands in an unwatched inbox is worse than no automation at all. Accept that stage one costs staff time; it is the only stage where you can see the software's judgement before a guest does.

Which guest messages must go to a person at once?#

Five groups: money, complaints, health and safety, exceptions and promises, and anything involving identity or the law. In all five the software may hold the conversation open, never close it.

Money covers refunds, invoice corrections, deposit disputes, rate differences and chargebacks. The software may read back what is already on the guest's bill; it may not change, waive or promise an amount. Complaints cover noise, cleanliness, a broken fixture, a bad meal, a missed pickup: acknowledge, apologise once, give a time, hand over. Recovery is a human sequence with its own routine, which we cover in Hotel guest complaints at the front desk: a recovery routine.

Health and safety covers illness, injury, allergy, fire, security, a missing child, water or electricity failure. Hand over immediately and never reassure on the software's own authority. Exceptions cover early check-in, late checkout, upgrades, extra beds, connecting rooms, pets and room moves: the answer depends on today's inventory and on a person's judgement about this guest.

Identity and law covers the guest identity notification (KBS), police requests, insurer or lawyer correspondence, and data requests made under KVKK. These leave the marketing channel and enter a formal process. Add two behavioural triggers: a guest who is still angry after two exchanges, and a guest who asks directly whether they are talking to a person. Both go to staff without further argument.

Before handing over, the software sends one short holding reply with a time, attaches the thread and makes no promise beyond when a person will answer.

How do you tell the guest it is software, and who answers next?#

Say it plainly in the first reply, in the guest's language, and name the person who takes over. This is good practice; confirm your own legal position with an adviser rather than treating any single rule as your duty.

Use a short, unembarrassed line at the start of the conversation and again at the handover, not in every message, which reads as a disclaimer rather than a courtesy. Avoid invented personas that hide the software behind a human name; if a staff member's name appears, that person must actually be reachable in the stated time.

For reference, Article 50 of the EU AI Act requires providers to ensure people are informed they are interacting with an AI system, clearly and at the latest when the interaction begins, unless this is obvious to a reasonably well-informed person (European Commission, AI Act Service Desk, "Article 50: Transparency obligations", 27 July 2026 (opens in a new tab)). It is an EU rule and a useful model for wording, not a statement about hotels in Türkiye.

Remember that the channel is also a data collection point. Under Article 10 of Law No. 6698, the guest must be informed of the controller's identity, the purpose of processing, to whom data may be transferred, the method and legal basis of collection, and their rights (Mevzuat Bilgi Sistemi, Law No. 6698, Article 10, 1 November 2026 (opens in a new tab)). A messaging channel that quietly collects names and room numbers needs the same notice as a booking form. Keep the notice short in the chat and complete in a linked privacy notice; a guest will not read five paragraphs inside a chat window, and a one-line notice will not satisfy the information duty. Write the disclosure in every language the channel serves and have a speaker check it, because a translated disclosure that sounds like a legal warning defeats its purpose.

What should staff receive at handover, and how fast?#

A complete packet in one place, and a first human reply inside a time the hotel can actually keep. A handover without an owner and a clock is just a forwarded message.

The packet carries the guest's name and room, the language and channel, the full thread, a quote of what the software already said, the reason for handover, the fact that was missing, and a suggested next step. Quote the software's own words rather than summarising them, so the person does not contradict a promise the guest has already read.

Assign one owner at a time. A shared inbox with no owner is where handovers go to die, and the guest experiences it as being ignored twice. Set a response target per channel and per hour band, publish it internally, and keep it. For example, ten minutes during the day and thirty minutes overnight, with an honest "a person will reply by 08:00" outside those hours. That is an illustrative target, not a benchmark. Never let the software imply that a person is reading right now when nobody is on duty; a truthful time is better than a false presence.

Apply a contradiction rule: if the software said something wrong, the person corrects it in the first line and offers a fix, rather than letting the guest discover the error later. Log the handover, with the time it opened, the time it was answered and the reason, because that log is what the weekly review reads and what proves the process works. For how these tasks reshape front desk roles, see AI at the front desk: which tasks change and which stay human.

How do you answer in the guest's language without inventing policy?#

The software may translate the hotel's written facts into any language; it may not write new facts in any language. A missing fact is a handover, not a translation problem.

Keep a reviewed translation of the fact sheet for each language the channel serves, so the software is never the only translator of a policy that carries money or safety consequences. Check units and formats per language: 24-hour against 12-hour clocks, decimal commas, distances in kilometres, and floor naming, where a Turkish ground floor is not always a guest's first floor.

Keep Turkish names for room types, spa treatments and local places, with a short gloss the first time, rather than inventing an English or German equivalent that staff will not recognise. Write tone rules per language instead of letting the software guess: formality, how apologising is phrased, whether first names are used, how much small talk belongs in a hotel reply.

Watch for the quiet failure mode where a fact exists in Turkish but not in German, and the software fills the gap fluently. If the line is missing, the answer is missing. Re-read translated fact sheets after every policy change, because a price or a time updated in one language and not the others is a promise the hotel never agreed to.

What does KVKK ask of a guest message thread?#

Treat the thread as personal data: collect it for a stated purpose, keep it accurate, secure it, and delete it when the purpose ends. Confirm your own case with a legal adviser before you change any process.

List what the thread actually holds: name, contact details, room, stay dates, payment references, and often health details or complaint narratives. Health and complaint content needs more care than a breakfast question. Article 4 of Law No. 6698 requires processing that is lawful and fair, data kept accurate and where necessary up to date, specified and legitimate purposes, proportionality, and retention only as long as the law or the purpose needs (Mevzuat Bilgi Sistemi, Law No. 6698, consolidated text, 1 November 2026 (opens in a new tab)).

Article 12 requires technical and administrative measures for an appropriate level of security, and makes the controller jointly responsible with anyone processing data on its behalf, which includes an AI vendor reading your guest messages. Article 7 says that once the reasons for processing no longer exist, the controller deletes, destroys or anonymizes the data on its own initiative or at the person's request. A chat archive nobody owns is a retention problem waiting to be found.

Ask the vendor four questions in writing: where the text is processed, how long it is kept, whether it is used to train models, and who inside the vendor can read it. Use the authority's own framing in internal training: KVKK's generative AI guide, published 24 November 2025, says outputs can look convincing and still be wrong, and calls for regular monitoring of outputs supported by human oversight where needed.

A weekly transcript review that keeps the written facts accurate#

What to do next#

Write two documents this week: the fact sheet with one owner and the never-answer list. Run the system in draft mode for two weeks, read every draft, and let the corrections, not the vendor's demo, decide which topics earn automatic replies. The rest follows from that order: written facts first, then a narrow automatic list, then a handover with an owner and a clock, then a weekly review that keeps the facts true.