Repeat complaints: finding the real cause in your hotel's complaint log

Root cause analysis of guest complaints means coding each logged complaint to what actually failed, ranking the causes, checking where and when they cluster, and asking why until the answer is a process you can change. The output is one page: two causes, an owner, a date and a check.

The air conditioner in room 412 is fixed on Tuesday, and on Friday a guest in room 412 complains about the air conditioner again. The log holds two rows, two apologies and no cause. This article shows how to turn that log into a monthly root cause analysis of guest complaints: clean categories, a Pareto table, the patterns behind the totals, five whys on the top two causes, and a one-page action sheet. You can start with last month's rows and a spreadsheet.

What must a complaint log hold before any analysis?#

A log you can analyze holds one row per complaint, with the guest's own words, the room or asset, the time, the department, what was done and who closed it. Everything later in this article depends on those fields existing.

One row per complaint, not one row per conversation. A guest who mentions the air conditioner at check-in and again at dinner is one complaint with two contacts, and counting it twice inflates the cause. Decide the rule once and tell everyone who writes rows.

Keep the guest's own words in a free-text field, separate from the staff category. When you clean the categories, the evidence stays intact and you can re-code last month without losing what was said. Record location identifiers: room number, floor, building, outlet, and for equipment the unit or asset number. Without an asset number, the same failing chiller looks like five unrelated room complaints.

Record three times: when the problem happened, when it was reported, and when it was closed. Day of stay, shift and response time all fall out of those three fields. Record the resolution in two parts: what was done now, and whether it needs a work order. A complaint closed with an apology and a complaint closed with a repaired valve are not the same event.

Keep names, ID numbers, health details and anything about a guest's body out of the log. Use the room and the failure, never the person, and tell staff why: the log is read by people who do not need that data. If this is part of a wider request-capture routine, see logging, assigning and closing each guest request.

You do not need a repeat flag if the location fields are right. The repeat shows up when you pivot on room or asset, which is more reliable than someone remembering to tick a box.

No names, no ID numbers, no health details. For what never belongs on the form in the first place, see what never belongs on a guest complaint form.

How do you turn staff wording into about ten causes?#

Write the category as the thing that failed, not the department that answered, and keep the list short enough that every row lands in one of about ten buckets. A long taxonomy looks thorough and produces counts too thin to act on.

Separate two questions that staff routinely merge: where the complaint surfaced, and what failed. A leaking shower reported to housekeeping is a plumbing cause with a housekeeping entry point, and the Pareto must count it as plumbing. Build the list from your own free text, not from a template. Read fifty rows from last month and write down the buckets you actually see; a hotel with a spa and a beach club will not have the same ten as a city hotel.

A workable starting set: room cleanliness, common-area cleanliness, hot water, air conditioning and heating, noise from inside the building, noise from outside, internet, front desk manner, waiting at check-in or check-out, food and beverage quality, food and beverage speed, billing, in-room maintenance, pool and spa. Trim it to what you actually see.

One cause per row. If a row genuinely holds two failures, split it into two rows and note the split, so the totals stay honest and the shares mean something. Write a one-line definition for each bucket and settle the edge cases in advance: is a dead television remote maintenance or cleanliness? Decide once, write it down, and apply it every month.

Re-code last month's rows once with the new list, then freeze the list for the year. Changing buckets mid-year breaks every comparison you will want in December. Never let a category be a person's name, a shift or a department. The moment the log becomes a blame record, staff stop writing the detail you need.

How do you build a Pareto table in a spreadsheet?#

Sort the causes by count, add a share column and a running total, and read where the running total passes roughly four in five. That is the whole method; the chart is optional.

Four columns are enough: cause, count, share of total, cumulative share. Sort descending before anything else, because a Pareto is a ranking and the order carries the meaning. The eighty-twenty line is a reading aid, not a law. In a month with a small base it may take three causes to reach four fifths, and in another month six; both are normal.

Keep the raw counts visible next to the shares. A cause at 25 percent of 120 complaints and a cause at 25 percent of 12 are different problems, and the reader should see which one they are looking at. Run it monthly for action and quarterly for the trend: the monthly table tells you what to fix now, the quarterly table tells you whether the fix held.

Do not merge causes to make the table look cleaner. If two buckets are small and unrelated, leave them small and unrelated; merging them hides the pattern you are hunting. Print the table with the month and the total on it, because a Pareto without its base gets quoted later as if it were a rate.

For example, an invented log of 120 complaints in one month:

The top two causes carry 45.8 percent, and the running total passes four fifths at the fifth cause. Both readings are normal, and both point to the same first move: two actions, not eight.

Which patterns hide behind the monthly totals?#

Totals hide location, time and sequence, and those are usually where the cause is. A cause count tells you what to look at; the pattern tells you what to change.

Room and floor first. The same room twice in a month is a different problem from two rooms once, and the first is a maintenance or housekeeping inspection issue rather than a training issue. Track the asset, not only the room: one air-conditioning unit, boiler or lift serving twelve rooms produces twelve complaints that look like twelve separate failures until you sort by unit number.

Day of stay separates arrival problems from departure problems. Complaints on the first night point at room readiness, check-in and expectations set before arrival; complaints on the last night point at billing and check-out. Time of day and shift point at capacity. A cluster between seven and nine in the morning is a breakfast or hot-water capacity question, not an attitude question, and no amount of front desk training will move it.

Occupancy distorts everything. A fuller hotel produces more of every complaint, so compare per hundred occupied rooms and keep the raw count beside it, or you will spend the winter chasing noise. Source market and language can reveal an expectation or communication gap, but handle this carefully: look at the pattern, never build profiles of individual guests, and keep nationality out of the row if it is not needed for the fix.

Check the log itself before you believe a fall. One category dropping while "other" rises usually means the categories drifted, not that service improved.

How do you run five whys on the top two causes?#

Take the two largest causes, start from one specific instance rather than the category, and keep asking why until the answer is something you can change with a date and an owner.

Start concrete: "room 412, air conditioning, reported at 22:40, not cooling", not "air conditioning". A category has no mechanism; an instance does. Each answer must be a fact someone can check, not an opinion. "The unit was running but not cooling" is checkable; "the team was careless" is not, and it ends the chain.

Stop when the answer is a process, a schedule, a spare part, a supplier or a decision. If the answer is a person, you have taken a wrong turn; go back one step and ask why the process allowed it. Two whys is often enough. Five is a ceiling, not a target, and forcing five steps produces fiction that sounds like analysis.

For example, an invented chain: air conditioning complaints, unit not cooling, filter clogged, filters cleaned only during the annual service, no filter task in the preventive maintenance plan, nobody owns the plan. The change is a monthly filter task with a named owner, not a reminder to staff.

Do it with the person who does the work. The technician knows the filter schedule; a meeting of managers will produce a plausible chain that is not the real one. Write the chain down and keep it with the action sheet, because it is what you will check next month.

What goes on the one-page action sheet?#

For each of the top two causes, one line: the cause, the change, the owner, the date, and the number you will look at to know it worked. One page, two causes, no more.

Two causes per month is the practical ceiling. A sheet with nine actions is a wish list, and the following month's sheet will still show the same nine. The change must be a mechanism, not an intention: "add a monthly filter clean to the preventive list for all split units, starting the first of next month" can be checked; "improve maintenance" cannot.

The owner is a named role with the authority and the budget to do it, not a committee. If two departments share the action, one of them is not really on it. The check has two parts: the count of that cause next month, and an earlier signal that moves first, such as work orders closed on the same asset or a temperature reading at the tap.

Tie the action to a work order so the fix ends as a closed job with a date, not a memo. A memo is not evidence that anything changed in room 412; for the full path from complaint to closed job, see turning a guest complaint into a closed maintenance job.

Review the sheet first at the same monthly meeting, for five minutes, before anything else is discussed. An action that never closed is the most useful line on the page, so read it out rather than hiding it. Keep last month's sheet next to this month's: the comparison is the management system, the sheet alone is paperwork.

How do you read next month's numbers without fooling yourself?#

Compare like with like, expect noise, and treat a fall as unproven until it holds for a quarter. Most complaint counts are small enough that a good month and a bad month can mean nothing.

Small counts move for no reason. Three fewer complaints in a month of 120 is noise, and presenting it as a result teaches the team that the number is a scoreboard rather than a signal. Compare per hundred occupied rooms, and against the same month last year if you have it. Seasonality changes both the volume and the mix, so a July against a June comparison will mislead you.

Watch for category drift. If "other" grows while a named cause shrinks, the list needs re-coding and the trend is broken until it is fixed. Expect regression to the mean: the worst month tends to be followed by a better one whatever you do. Without a written date for the change, you cannot tell improvement from arithmetic.

Record what you changed and when, on the same sheet. A fall with a date and a closed work order behind it is at least a plausible result; a fall with neither is a coincidence. Never publish a percentage improvement to the team from a single month. It rewards writing fewer rows, and the log is the one asset you cannot afford to corrupt.

The honest test at the end of the quarter: the same cause has fallen, the work orders on the same assets have closed, and the front desk has stopped hearing about it. If you also track what each recovery cost you, connect the two sheets through tracking service recovery costs as a monthly number.

One practical shortcut for the reading stage: the PMS assistant from AI Otel is built, answers questions about a hotel's own property in plain language, carries out routine actions, and a person confirms anything sensitive. It reads your records and returns them; it does not diagnose the cause for you, and we have no trained model yet.

What to do next#

The loop is short: log one row per complaint with the room and the asset, code it to what failed, rank the causes, look for the room and the hour, run five whys on the top two, and put two lines with owners and dates on one page.

Start this week with last month's log: code fifty rows into ten buckets, build the table, and write the first sheet. Then diarize the same five-minute review for the same date next month, because the sheet only becomes a system when it is read twice. If you want to see how the reading stage could work against your own records, request a briefing at https://ai-otel.com/contact.