When the AI gets it wrong with a guest: an incident routine for hotels

An AI incident routine is a short written procedure a hotel follows when an assistant gives a guest a wrong answer: stop the answer spreading, decide whether to honor what was promised, correct it with the guest through one named person, fix the fact or rule behind it, and record the case.

A guest messages at 23:40 to ask whether the airport transfer is included. The assistant answers yes. The transfer is a paid extra, the guest has already told the front desk at arrival, and the person on shift has to decide in thirty seconds whether the hotel just gave away a car ride or a reputation. This guide gives you the routine to write before that night happens: who decides, who calls, what gets paused, what gets fixed and what gets written down. AI incident response for hotels is mostly preparation, not technology.

Why does a hotel need an AI incident routine before the first incident?#

Because the costly part of a wrong answer is not the sentence, it is the promise a guest has already acted on. A written routine decides in advance who may honor that promise, who speaks to the guest, and what gets written down.

An assistant answers from two things only: the facts it can read about the property and the rules it was given. A stale fact or a missing rule produces a fluent, confident, wrong answer that reads exactly like a correct one. There is no tone of doubt to alert anyone.

Guests act on answers. They book a transfer, plan a late checkout, invite someone to breakfast. By the time staff hear about it, the cost has moved from words to a plan, and the hotel is no longer correcting a sentence but unwinding an expectation.

Without a routine, the decision belongs to whoever is on shift at that hour, and the same situation gets three different answers in one week. The routine is one page: who decides, who calls, what is paused, what is written down. It sits beside the complaint and data procedures the hotel already runs.

One asymmetry shapes everything else: a message already sent to a guest cannot be recalled. Every other step in the routine can be corrected later, which is why the decision always comes before the next contact. This is the same asymmetry that governs irreversible actions in hotel AI: messages, refunds, invoices.

Naming the routine also protects staff. A receptionist who improvises a free upgrade to end an awkward conversation is not being generous, they are setting a precedent nobody approved. If you are setting up an assistant in the first place, pair this routine with guardrails for a guest-facing AI assistant.

What should happen in the first hour?#

Preserve the exact message, pause the topic, and put one person in charge of the decision. The first hour is for stopping the spread and gathering facts, not for apologizing.

Capture the exchange as it happened: the guest's question, the assistant's answer, the channel, the timestamp, the guest name and reservation. A screenshot is enough; a paraphrase is not. The exact wording matters later, because the difference between "the transfer is included" and "you can add a transfer" is the difference between a promise and a suggestion.

Establish what the guest has already done with the answer: booked something, paid, told other guests, or nothing yet. This sets the urgency of everything that follows. A guest who has not yet acted can be corrected cheaply, often before arrival.

Pause the topic, not the assistant. If the wrong answer was about the airport transfer, transfer answers come down and the rest keeps working. Switching the whole assistant off removes a working channel and hides the pattern your monthly review needs.

Name one owner for the case. The general manager owns money and policy exceptions; the front office manager owns recovery inside existing policy. Classify the case roughly at this stage: wrong fact, missing rule, unclear handover, or a correct answer the guest misread. The class decides who fixes it later.

Brief the people who will meet the guest: front desk, reservations, the restaurant if the promise touched it. A guest corrected twice, by two people, with two versions, is a worse case than the original error.

Should the hotel honor what the AI promised?#

Decide it as a commercial question with three tests, not as a question about who is at fault. Fault matters in the review; the guest needs a decision today.

Test one, cost: can the hotel deliver what was promised at a cost it would accept for a good customer? A breakfast for two is a different decision from a week at the wrong rate. Test two, repeatability: would honoring this create an expectation the hotel can keep for the next guest who asks the same question? If not, say so now rather than after the third case. Test three, reliance: did the guest reasonably rely on the answer, and is there a record of it? A written answer in the hotel's own channel is different from a half-remembered phone call.

There are three outcomes, not two: honor in full, honor in part with a clear alternative, or decline with an alternative and an explanation. A plain no without an alternative turns an error into a complaint.

Whether a promise is legally binding is a legal question. The routine settles the commercial answer; counsel settles the legal one. The front desk settles neither. Write the decision and the reason in the record before the guest is called: a decision made on the phone, under pressure, with no note, cannot be reviewed or repeated.

How do you correct it with the guest?#

One named person contacts the guest, states what was said and what is true, gives the decision, and puts the outcome in writing. Speed and a single voice matter more than the wording.

Choose the channel by urgency: a phone call for anything that affects today's arrival or an in-house guest, a written reply for something already settled. Never correct a wrong promise with a second automated message, for the same reason you never send an automated apology for an automated error. On when an assistant should hand a conversation to a person in the first place, see AI replies to guest messages: when to hand over to staff.

Structure the conversation in four lines: what we told you, what is actually true, what we will do, and by when. Anything longer invites negotiation of details the hotel has not decided.

Do not blame the tool as the whole explanation. Saying the system told you so tells the guest the hotel does not know its own product. Own the answer as the hotel's answer, because it was. Do not offer compensation before the decision is made, either: an apology with a clear remedy is stronger than a discount offered to end the call.

Confirm the outcome in writing, in the channel the guest used or by email, so both sides hold the same version. If the guest is in-house, the front office manager says it face to face first. Record the guest's response, including a refusal: a guest who declines the remedy has still been handled correctly, and the record should show it.

How do you stop the same wrong answer reaching other guests?#

Pause the topic, decide whether the fault is a wrong fact or a missing rule, fix that, then ask the same question again before switching the topic back on.

Wrong fact, missing rule, unclear handover#

Wrong fact: the hotel's own data was stale or incomplete. The spa hours changed in spring and the assistant still reads the winter schedule. The fix belongs in the data, not in the assistant. Missing rule: nothing told the assistant it could not answer. It quoted a price for a service that has no rate in the system, because no rule said prices come only from the rate table. Unclear handover: the question was one a person should have answered, and the assistant answered instead. The fix is a handover trigger, not a new fact.

A fourth case is worth separating: the answer was correct and the guest misread it. That needs clearer wording, and it belongs to whoever writes the guest-facing text.

Pause, fix, retest#

Retest with the exact question and three or four variants, including one a guest would phrase differently. Re-enable the topic only after the retest. Then check the other places that carry the same fact: the hotel website, the booking site content, the guest app. A fact fixed in one place and left stale in another produces the same incident next month.

What goes into the incident record, and what does the monthly review look at?#

One page per incident, written so it can be appended but not quietly rewritten, and one monthly read across all of them for the pattern.

The record holds fixed fields: date and time, channel, guest and reservation reference, the exact question and answer, what the guest did next, the decision and who made it, any cost, the cause class, the fix, who verified the fix, and the closing date. Keep it append-only in practice: corrections are added as a new dated line, not by editing the old one. If the record can be rewritten without a trace, it is not a record. For what a good record should show more broadly, see AI audit trails in hotels.

The monthly review reads four things: incidents by cause class, topics that repeat, time from incident to decision, and whether each fix was verified by a retest. The review is where scope decisions are made. A topic that keeps producing wrong answers may need to move from answering directly to handing over to a person.

The record is also the document a hotel shows an insurer, a lawyer or an auditor. A calm one-page account written the same week is worth more than a reconstruction six months later. Retention: keep records at least until the guest dispute or the review cycle is closed, and align the period with the hotel's own data practice and the retention periods set for guest data. Ask counsel.

On tooling: some of this can be carried by software. Our decision record at AI Otel is built and runs in a public demo environment: small changes apply automatically and are logged, larger ones wait for a person, and every change can be undone, except a message already sent to a guest.

What to do next#

Write the one-page routine this week: name the decision owner, the person who calls the guest, the topics that get paused, and the record fields. Then run one tabletop case with the front office, so the first real incident is not the first rehearsal. The pieces fit together in one order: stop the spread, decide the promise, correct it with one voice, fix the fact or the rule, and record what happened so the monthly review can see the pattern. If you want to see how a built, demo-stage decision record handles this, request a briefing.