Sorting guest complaints with AI: categories, urgency and who gets the case

AI complaint triage for hotels is a sorting step: the system reads each complaint and proposes three labels, a category, an urgency level and an owner, for a person to accept or change. It does not reply to the guest, close the case or decide compensation.

Three messages arrive in the same hour: a billing error, a broken balcony rail and a complaint about the lift being slow. They land in one inbox, and whoever is on duty reads them in the order they arrived. The order of arrival is not the order of importance. After reading this you will be able to design the sorting step yourself: the category list, the urgent list, the routing rules and the test you run before staff rely on any of it.

What does AI complaint triage actually do?#

It asks the same three questions of every complaint and writes down the answers as proposals: what kind of problem is this, how fast must a person look, and who owns it. It does not answer the guest.

Triage is borrowed from medicine: it decides how fast and who, never the treatment. In a hotel the treatment is a room move, a repair, an apology or a correction on the bill, and each of those stays with a person. Sorting and replying are separate jobs with separate risks: a wrong label costs a re-sort, a wrong reply commits the hotel.

The system reads free text, a guest message, a front-desk note or a review, and returns labels chosen from a list the hotel fixed in advance. It does not invent categories, and it does not add a category because one complaint did not fit. All three labels land in the complaint log next to the guest's own words, so a reader can check the label against the sentence that produced it.

The step sits before any reply is written. What it must never do alone: send a message to a guest, close a case, promise a refund, move money or reassign a room. Those are decisions with money and reputation attached. The gain is not the label itself but consistency: every complaint, including the ones that arrive at 02:00, gets the same three questions in the same order.

Why sort complaints at all?#

Because an unsorted log cannot be counted, and a complaint that cannot be counted cannot be fixed. Sorting turns a pile of messages into numbers a department head can act on.

Most hotel complaint logs are chronological: newest on top, oldest forgotten. The same failure returns for months because nobody can see that it is the same failure. Sorting produces counts by category, by room, by floor, by shift and by outlet. A count is the smallest unit of evidence a maintenance budget or a training session can be built on.

Without a sorting rule, urgency is decided by volume and tone: the loudest guest gets the fastest answer while a quietly worded safety problem waits behind three complaints about the lift. A fixed set of questions asked of every complaint is also a fairness mechanism between shifts and departments. The night team and the morning team see the same case described the same way.

Sorting is cheap to audit. You can read twenty sorted complaints in ten minutes and see whether the labels match the words; auditing twenty replies takes far longer and needs more judgment. The sorted log is also the input to a harder question later: finding the real cause in your hotel's complaint log, not just the latest symptom. Sorting does not replace the complaint record itself. The guest's words, the time, the room and the outcome stay in the log; the labels sit on top of them.

Which complaint categories should a hotel use?#

A short fixed list built around who can fix the problem, not around how the guest phrased it. If two trained people would sort the same complaint differently, the category is too fine.

Start from the departments that own a fix: housekeeping, technical maintenance, front desk, food and beverage, noise and neighbors, billing and payment, reservation and room allocation, staff conduct, and outdoor and facility areas such as pool, beach or spa. Separate symptom from cause. The guest writes a symptom, the room was cold, the bill was wrong; the log needs a cause, a failed boiler, a rate loaded incorrectly. The system can propose the symptom from the words; the cause is confirmed by a person after the fix.

Allow one primary and one secondary category. A single message often carries two problems, and forcing it into one category makes the second problem disappear from the counts. Keep categories stable across seasons: a list renamed every summer cannot be counted year on year, and a category that changes meaning quietly corrupts every comparison built on it.

Give every category a named owner. A category with no owner is a category that will be re-sorted by hand forever. Write one example sentence per category into the log's help text, in the words guests actually use, so the list survives staff turnover. The complaint form and the log must already capture the fields the sorting depends on; see the fields a guest complaint form should carry.

Which complaints are urgent, and who reads them first?#

Urgent means a person must look within minutes, not that the guest is angry. The urgent list is short, written down, and read by a named person at the start of every shift before the ordinary queue.

Defensible urgency criteria are concrete: risk to safety or health; a room that cannot be used as sold, such as no hot water, no heating or a lock that does not work; a legal or fiscal exposure such as a billing error or a missing identity notification; a guest leaving within the day; a vulnerable guest; something that will be public within hours.

Tone is not urgency. An all-caps message about a slow lift and a calm message about a loose balcony rail are not the same case, and a text classifier reads tone more easily than it reads risk. The urgency label is a flag, not a filter: nothing is removed from the ordinary queue because the system marked it low; the low pile gets read too, later.

Over-escalation has a real cost. If a third of the log is urgent, the list stops being read within a month, and the one case that mattered is buried in it. Under-escalation is the failure that matters. Design the process so a missed urgent case is visible: a daily check of the low pile by the duty manager, looking for anything that should have been flagged. Record the read, not just the list: who opened the urgent queue, at what time, and what they did with each case. That record is what makes the process auditable after a bad night.

Who gets the case, and who decides?#

One named owner per case at any moment, and a person, not the system, decides what happens next. Routing rules are written by the hotel; the sorting step only proposes which rule applies.

The routing rule is a combination the hotel can state in one sentence: category, plus time of day, plus outlet decides the first owner. Night arrivals about noise go to the night manager, not to housekeeping. Ownership is a field with a person's name in it, not a department. A department cannot be asked why a case is still open on its third day.

Handover is where cases die. At shift change the open cases pass with the urgent ones read aloud, and the log carries the time of the handover. Write the escalation path in advance: who the owner calls when the fix needs money, a room move or a compensation decision, and what the owner may promise before that call.

The system can route, remind and summarize. It cannot approve compensation, move a guest to another room or close a case. Sorting ends where the reply begins. Once a case has an owner, whether the hotel answers, who answers and in what words is a separate decision with its own rules; the boundary is covered in when to hand a guest message over to staff.

How do you test the sorting before staff rely on it?#

Run it on complaints your team has already sorted by hand, then read the disagreements rather than only counting them. The test set, not a vendor's claim, is what tells you whether the labels are usable.

Build the test set from last season's log: thirty to fifty cases, deliberately including the hard ones, meaning messages with two problems, sarcasm, a complaint written in another language, and a complaint that names no problem at all. Have two people sort the same set by hand first. Where they disagree, the category list is the problem, not the system, and no amount of automation will fix an ambiguous list.

Compare the proposed labels with the agreed human labels, then read every disagreement. A pattern of disagreements is more useful than a single score. Score the three outputs separately: a wrong category costs a re-sort; a missed urgent case costs a guest. They must never be averaged into one number.

Run in shadow mode for a period: the system sorts, a person sorts, and nobody acts on the system's labels yet. Compare the two piles at the end of the week. Write down in advance what would make you stop: a missed urgent case in the test set, or a category the system cannot separate at all. Keep the test set and re-run it after every change to the category list, because the list is what the sorting is actually measured against. The same discipline applies more broadly in how to test a hotel AI assistant before staff use it.

What goes wrong, and what should you review each week?#

The common failures are mixed complaints, missing context and slow drift in the category list. The fix is a short weekly read of a sample by two people who compare notes.

Mixed complaints are the first failure: one message carries a billing error and a cleanliness problem. Without a primary and a secondary label, the second problem vanishes from the counts and from the queue. Missing context is the second: a guest writes that it is the same as last night. The system sees one message; a person sees the stay, the previous case and the room history.

Politeness and sarcasm mislead a text classifier. A calmly worded complaint about a safety issue reads as low urgency, which is exactly why a person checks the low pile. Language matters too: a complaint written in a language nobody on shift reads may be sorted correctly and still needs a reader who understands it before anyone replies. Drift is the slow failure: categories get used differently over months as staff change, and a monthly sample re-read by two people catches a category that has quietly changed meaning.

Every time a person changes a label, that change is the record you review when you revise the category list. Keep the corrections in one place, not in a chat thread. Never let the sorted log replace the original text: the guest's words stay next to the labels, because the words are the evidence and the labels are only a description of it.

What to do next#

Take last month's complaint log, pick thirty cases including the awkward ones, and have two people sort them by hand before you buy or build anything. Where they disagree is your category list's real problem, and it is the same problem any sorting system will inherit. Once the list is clear, the three labels, category, urgency and owner, become something a person can check in minutes rather than a decision anyone has to trust.