An error log for AI drafts: what to record when an assistant gets it wrong

An AI error log is a one-line record of each assistant draft that was wrong or nearly wrong: the exact question, the draft, what was wrong, who caught it and whether it reached a guest. Reviewed once a month, it turns scattered mistakes into changes to the tool, the written instruction or the approval step.

Someone mentions in the corridor that the assistant quoted the wrong rate yesterday. By the evening nobody can remember which booking it was, what exactly was asked, or who noticed. The mistake is gone; the fault behind it is still there. This article gives you the fields for an AI error log your hotel team can keep in a minute per case, the split of duties around it, and a ten-minute monthly review that turns entries into rules.

Why does a log beat memory when an AI assistant gets something wrong?#

Memory keeps the story and loses the detail you need to fix anything. A log keeps a few facts per case, and a few facts are enough to change a rule.

The corridor version drops the exact question. Without the question you cannot tell whether the tool lacked the rate, the written instruction was vague, or the person approving was rushed. Each of those faults has a different fix, and only one of them is fixed by writing a sterner instruction.

Memory also keeps the dramatic case and forgets the boring near miss, which is the cheap warning: the same fault, caught before it cost anything. A written entry makes the month countable. Ten scattered complaints feel like a bad week; ten entries in one column show which field is actually failing.

An entry protects the person who caught the mistake. It records a draft, not a person, so catching something early is visible rather than silent. And the log is a change list, not a complaint file: every entry should end in one of three places, no action, a change, or a closed case with a reason.

Start with the last mistake you can still remember. If you cannot reconstruct the question and the draft, that is the argument for the log.

What goes into a one-line AI error entry?#

One row per case, seven fields, written within the hour: date, where it happened, the exact question, the draft, what was wrong, who caught it, and whether it reached a guest.

Paste the draft rather than describing it. A summary loses the wording that caused the problem, and the wording is usually the evidence. Record the exact question too, because you will re-run it after every fix; it is the only test you already own.

Use a fixed short list for what was wrong: wrong fact, wrong policy, wrong tone, missing step, invented detail, wrong language. Free text cannot be counted. Record the stage where it was caught, draft, approval or after sending, and record the action taken in the same row, so a closed entry explains itself six months later without anyone's memory. Keep the row short enough to write in a minute. A form that takes ten minutes gets filled in for a week and then abandoned.

The seven fields#

What is the difference between a near miss and a mistake that reached a guest?#

A near miss was stopped before it left the hotel. A mistake that reached a guest was sent, charged, printed or said out loud, and it is handled as a guest problem first and a log entry second.

Classify by stage, not by how bad it felt. The stage is a fact; the severity is an opinion that changes with who is telling the story. A near miss is the useful signal: the same fault as a reached-guest mistake, found while the cost is still a correction rather than an apology.

A near miss becomes a real one the moment an approval step is removed or a busy shift skips it. The log shows how thin that step has become. For entries that reached a guest, record what the guest was told and what was corrected, so the next person does not reopen a settled case. Some corrections cannot be taken back: a message already sent to a guest stays sent, the same logic that applies to irreversible actions in hotel AI such as messages, refunds and invoices. Treat those entries as the ones that must never repeat.

If the hotel already keeps an incident record for guest complaints, do not duplicate it. Log the draft fault and point to the incident record for the guest side. And never delete an entry because it was resolved: close it with a line, and keep the count.

Who should add entries, and who should review them?#

Anyone who sees a draft may add an entry, on any shift, without asking. One named person owns the log and runs the review, and a department head decides which rule changes are made.

Adding is open, closing is controlled. If a person needs permission to write a line, the log will only contain the mistakes that were already visible to a manager. Name the owner as a role with a deputy, not as one enthusiastic person; the log dies the week that person is on leave.

Keep the reviewer separate from the person who approves drafts day to day, or the same blind spot reviews its own work. Say plainly, in writing, that entries are not disciplinary material. The first time an entry is used against someone, the log ends.

Put one line in the shift handover: drafts checked, entries added. That reaches people who will never open a spreadsheet on their own. Give the night shift a route in, since most quiet-hour drafts are answered by whoever is on duty, and those are the cases nobody hears about, especially around the question of when an AI reply to a guest should be handed to staff. The owner's job is not to judge entries but to keep them short, complete and closed.

How does the monthly ten-minute review work?#

Once a month, with the log open, the owner and one front-desk person read every open entry, group them, and leave with at most two changes and a date for each.

Ten minutes on the calendar, not an hour when someone remembers. A review that needs preparation stops happening by the third month. Read the entries aloud in order; reading forces the group past the two dramatic cases and onto the repeated one.

Count by the fixed terms from the log, not by department. The repeated field is the target; the loudest complaint usually is not. Compare this month with last month, never with a target. There is no benchmark to hit, and inventing one turns the log into a scoreboard. A quiet month is also a finding: either the drafts improved, or fewer drafts were checked. The second is more common and worth asking about.

Close or re-date every open entry before the meeting ends. An entry that stays open for two reviews is telling you nobody owns it. Write the two decisions in the same file, under the month, so next month's review can see what was tried.

The ten-minute checklist#

How do you turn a pattern into a rule?#

Every repeated entry points to one of three levers: the tool's data and limits, the written instruction the assistant works from, or the human approval step in front of it. Pick one lever per change.

A wrong rate, a wrong policy or a wrong date is almost never a wording problem. It is missing or stale data, or a task the tool should not be doing at all. Wrong tone, wrong length or wrong language belongs to the written instruction: the short text that tells the assistant how this hotel speaks and what it may say. A wrong action, or anything that cannot be taken back, belongs to the approval step; move that task up a tier rather than rewriting the instruction around it.

Change one lever at a time. Change two and the next month's review cannot tell you which one worked. Re-run the exact question from the log after the change. If the draft is now right, close the entry and note the date; if it is still wrong, the diagnosis was wrong too.

Some patterns cannot be fixed. If the same field fails after two attempts, the honest move is to take that task away from the assistant and give it back to a person. Record the change next to the entries that caused it, so the log becomes the history of the rules rather than a list of complaints. This discipline is the same one that should govern running an AI pilot in a hotel with a clear stop rule.

How do you keep personal data out of the error log?#

Log the question and the draft, never the guest. Replace names, room numbers, phone numbers, identity and payment details with a booking reference before the entry is saved.

The draft itself is the risk: assistants repeat what they were given, so a pasted draft can carry a guest name, an email address or a card fragment. Strip before pasting, not after. Once a row is saved in a shared file, the data has already been copied somewhere new.

Use a booking reference the hotel can resolve internally. It is enough to find the case and useless to anyone outside. Decide who can open the file: a log that lives in a group chat or an open shared drive is a guest data list with a different name. Give closed entries a review date and a deletion date; keeping every row forever is a habit, not a policy.

A guest request about their own data covers anything in the log that points to them, including the booking reference if it can be resolved. Check the assistant's own conversation history too, since how long a hotel keeps guest chats with an AI assistant is a retention question of its own, and the log is only one of the places a draft is stored.

What to do next#

Open a spreadsheet today with the seven fields as columns, add the one mistake you can still remember from last week, and put ten minutes in the calendar for the first review. The log is not a record of blame; it is the short list of questions you will re-run, the changes you will test, and the tasks you will take back from the assistant when a pattern will not move.