A guest sends you a message at 11 PM on their second night. Your bot answers. The answer is fine. The bot also routes that message into one of, say, fifteen categories you defined six months ago when you set up the routing logic.
We had fifteen categories. We'd been running the bot for three years. Last week we finally looked at three years of actual messages — 33,000 of them — and matched them against the categories the bot was using. The result was uncomfortable.
The second-most-common complaint had no category at all. One of the categories we did have was mislabeled and had been quietly answering the wrong type of question for months.
This is the analysis. The numbers below are from one operator — RENTUJEMY, the ~300-property short-term rental business that runs on Enhanced Rentals — over almost three years.
The setup
33,007 messages. Incoming guest messages where the guest was physically in the property at the time of sending (between arrival and departure dates). Across 4,909 distinct reservations. From August 2023 to June 2026.
That's most of an operator's lifetime of in-property messaging data. A surprisingly large dataset for an industry most people assume is small-batch and bespoke.
The question we wanted answered:
Sounds obvious. Wasn't obvious. The point of running a three-year analysis is exactly that the categories you thought were the top categories aren't.
How we filtered for complaints
First cut: 33,000 in-property messages. Second cut: complaint-language only. Multilingual ILIKEs against the message body (we're Polish + English heavy with German and occasional Russian).
Filter keywords, in three buckets:
- State-of-thing words: broken, not working, doesn't work, nie działa, zepsute, uszkodzone
- Absence-of-thing words: no hot water, missing, brak, nie ma, can't find, can't open
- Distress words: urgent, emergency, awaria, pilne, help
After filtering, 1,700 messages looked like real complaints. That's roughly 5% of all in-property guest messages.
Hold that number for a second. Most STR operators (and most SaaS founders building for them) frame guest comms as mostly complaint handling. The data says the opposite. 95% of in-property guest messages aren't complaints. They're information requests — codes, parking, WiFi password, "what time can I leave luggage on departure", "is there an iron in the apartment". The high-volume work is dispatch, not damage control.
The complaints are still the most painful 5%, though.
The top 5
From the 1,700 complaint messages, ranked by theme:
| # | Theme | Messages | % of complaints | Example signals |
|---|---|---|---|---|
| 1 | Access / lockout | 278 | 16.4% | code doesn't work, locked out, can't open door |
| 2 | Cleaning / dirty / mess | 255 | 15.0% | not clean, dirty, trash, brudne, śmieci |
| 3 | Water / plumbing | 229 | 13.5% | no hot water, leak, shower issues, brak ciepłej wody |
| 4 | Heating / cooling | 179 | 10.5% | too cold, AC broken, klimatyzacja, kaloryfer |
| 5 | Kitchen appliances | 148 | 8.7% | fridge, oven, microwave, dishwasher, coffee machine |
The next tier (bedding/linens 7%, WiFi 6%, electricity 5%, parking 3%, noise 1%) fades quickly. The top five carry the weight.
Notice the gap between #1 and the rest. Lockouts feel dramatic — they're what operators expect to be the dominant complaint. They are. But only by a fraction. Cleaning (#2), water (#3), and heating/cooling (#4) together are two-and-a-half times the volume of access issues.
What our bot already does
The on-stay routing bot for RENTUJEMY has fourteen action codes. Each code, when emitted, either fires a pre-written message template (in English and Polish) or hands off to an informational answerer bot. Here's the coverage map against the top five:
| Complaint theme | Bot action code | Coverage |
|---|---|---|
| #1 Access / lockout | TRIGGER_GUEST_ASSISTANT | ✓ Covered (via the catch-all informational bot) |
| #2 Cleaning | (none — escalates) | ✗ No action code. Every cleaning complaint = a human. |
| #3 Water / plumbing | WATER_PROBLEM | ✓ Covered (2 templates, EN + PL) |
| #4 Heating / cooling | HEATING_PROBLEM | ⚠ Code exists but is mislabeled. Cooling has no code. |
| #5 Kitchen appliances | COOKER_PROBLEM, WASHER_PROBLEM | ⚠ Partial. Fridge, oven, microwave, coffee uncovered. |
Where it doesn't
Cleaning has no action code at all. 255 complaint messages — 15% of all complaints, the second-largest theme — and the bot has nothing to say. Every cleaning complaint falls through to the "problem with the apartment" escalation rule, which is just a fast-track to a human coordinator. Three years of an unsexy, high-volume category being silently routed to manual work.
HEATING_PROBLEM is mislabeled. The action code is named after heating. The two templates it fires look like heating templates. But the "When" section in the bot's instructions — the part that tells the routing model when to emit this code — actually describes power outages. "Guest reports a complete power outage in the apartment." "Guest reports that multiple lights and electrical outlets across the apartment are not working." That's a separate code, ELECTRICITY_PROBLEM, which is correctly defined. So today, heating complaints either land on the right code by coincidence or get classified elsewhere. Either way the templates we've been sending are heating-flavoured and going to the wrong situation.
Cooling and AC have no code at all. Hot Dubai summers, Polish heatwaves — same situation: every AC complaint goes to a human.
Kitchen coverage is partial. We have COOKER_PROBLEM (stove) and WASHER_PROBLEM (dishwasher / washing machine). The remaining kitchen long tail — fridge, oven, microwave, coffee machine — is uncovered. That long tail is most of the kitchen complaint volume.
Bedding, linens, towels: no code. 123 complaint messages (7%) — escalates as "problem with the apartment."
Lessons
1. Coverage is taxonomy, not capability. The bot's fourteen action codes are technically capable. Adding a new code is half a day of work — write the classification rule, write two template variants, enable them. The actual scarce resource is the analysis that tells you which codes to add. Most operators ship with their best guesses and never look at the data again. We were one of those operators for three years.
2. A mislabeled action code is worse than a missing one. A missing code routes to escalation — a human sees the message, the guest gets a real answer eventually. A mislabeled code confidently emits the wrong template. The guest sees a heating response to an electricity complaint and concludes nobody is listening. Same as a confidently wrong human, except the confident-wrong-AI version is harder to spot because everything looks like it's "working" in the dashboard.
3. "Escalate to human" is hiding your biggest cost. Bot 2 escalates to a human for "problem with the apartment," "cleaning issue," "assistance with parking," and "asks about speaking with a manager." That's a deliberately broad safety net. It's also where 15%+ of complaints disappear into manual work. Building a new action code isn't "more automation" — it's simply measuring a cost that's already being paid by your team.
4. The unsexy categories beat the dramatic ones. Lockouts feel like the big problem. They're first, but only by a fraction. Cleaning, water, heating, and kitchen — the day-to-day, unglamorous, this-is-just-property-management categories — together outweigh access issues by 2.5×. Anyone building an operator-support AI should resist the gravitational pull of the dramatic categories and stare at the volume instead.
5. Most messages aren't complaints. 5% of in-property guest messages are real problems. The other 95% are dispatch — information, codes, instructions, FAQ. If you're building bot logic only for complaint handling, you optimised for the tip. The dispatch volume is where the day-to-day cost-of-service actually lives, and where AI quietly earns its keep before anyone notices.
What we're shipping next
The blog post wrote the kanban. Concrete next moves:
- Add CLEANING_PROBLEM action code + EN/PL templates. The single biggest gap. Likely sub-categorise into "state on arrival", "during stay", "trash / communal areas" so the right operational team picks it up.
- Fix HEATING_PROBLEM's "When". Rewrite the classification text to actually describe heating. Audit the action-code library for similar category errors while we're there.
- Add COOLING_PROBLEM as a peer action code. Same template structure as heating; different solution path (call the cooling technician, not the heating one).
- Add FRIDGE_PROBLEM, OVEN_PROBLEM, MICROWAVE_PROBLEM, COFFEE_MACHINE_PROBLEM. Or one consolidated KITCHEN_APPLIANCE_PROBLEM with sift-style conditions on the listing's amenity list.
- Add BEDDING_PROBLEM (pillows, sheets, towels). Includes a same-day delivery template plus a "next cleaning" one for non-urgent cases.
- Backfill the taxonomy review into a recurring job. Once a quarter, re-run the complaint-clustering query and compare against the current taxonomy. The cost of doing this quarterly is one afternoon; the cost of not doing it is roughly three years.
The point of running a 300-property operator on top of the platform you're building isn't that the platform handles 300 properties. It's that you find the gaps in the platform before any of your customers do.
We just found three years of them. Time to close.