How to Route Service Requests Through Chat to the Right Team

Routing service requests through chat means a guest's message is typed, given a priority, and sent to the team that does the work, with the guest acknowledged immediately and the request tracked until done. The desk is informed, not interrupted. That is the entire model, and it fits in a table you can build in an afternoon. It also happens to be the operational core of our guide to the best hotel AI concierge platforms, because a concierge that cannot route a request is just a very polite voicemail.

I think about this every time I text a resort for more towels and then, 20 minutes later, text again to ask whether the first text arrived. Nobody ignored me. The message went to the desk, the desk radioed housekeeping, housekeeping was on another floor, and nobody owned the part where someone tells the guest what is happening. The request did not fail. The relay did.

Why does every request still land at the front desk?

Because for most properties the desk is both the only channel and the only owner. Guests call or message the desk, the desk relays to the team, and the desk is also expected to know whether it got done. That worked when the desk had three people on it. It does not work now.

In the American Hotel and Lodging Association's 2025 survey of 282 hoteliers, 65% reported staffing shortages, and the most critical openings were housekeeping at 38% of hotels, front desk at 26% and maintenance at 13% ^[1]. The relay model asks the two most short-staffed departments to run a hand-off between them, by radio, dozens of times a day.

The tools do not help. Access Hospitality's 2026 research found hotels use an average of five systems, with staff spending 78 minutes a day switching between platforms or combining data ^[2]. A towel request that lives in a chat window, gets copied into a radio call and lands on a housekeeping sheet has touched three of those systems and been recorded in none of them. The result shows up as slow response times that no single person caused.

How does a chat system decide which department gets a request?

Two steps: classification, then a routing table. Classification reads the message and assigns a type and a priority. The routing table says who owns that type at that hour, and who the backup is. The owner is a role, never a person, because people go on break and roles do not.

Types for most resorts: housekeeping, maintenance, food and beverage, front desk, concierge, and other. Priorities, three levels: safety (water leak, locked out, medical word), comfort (no AC, no hot water, missing cleaning), convenience (towels, extra pillows, a restaurant recommendation). The classification step is where AI for housekeeping requests earns its place, because a model trained on your examples can tell "the room was not cleaned" from "the safe will not open" in under a second, at 2am, without waking anyone.

Priority matters most for maintenance, where the same department handles a dripping faucet and a flooding bathroom. The classifier should read "leak" and "water on the floor" as safety, not comfort, and the routing table should send safety to a phone that rings, not a queue that waits. That is the difference between maintenance requests from chat working at 2am and working only during the day shift.

Illustrative routing rules for a mid-size resort, 2026. Targets are the property's own choices, not an industry standard.

Food and beverage deserves a note: an order is a request with a menu attached, and how room service orders move from chat to the kitchen follows the same model with a kitchen confirmation step added.

What happens to a request the system cannot classify?

It goes to a person. Not to a best guess, not to the department with the lightest load, to a person who decides. A misrouted request is worse than an unrouted one, because it looks handled on every screen while the guest sits in a hot room waiting for housekeeping to fix the air conditioning.

Set expectations honestly about how much the software will handle. Revinate's 2025 Hospitality Benchmark Report, drawn from its own platform data, found automation handled 31% of guest messages, with automated responses answering in 1.8 seconds against about three minutes for staff ^[3]. Read that as a floor for human involvement, not a ceiling for automation: most of what arrives still touches a person at some point, and the routing model's job is to make that touch a decision rather than a relay.

Three rules I would hard-code. Any message containing an allergy, a safety word or a medical word escalates, regardless of how confident the classifier is. Any message with negative tone escalates, because an upset guest asking for towels is not asking for towels. And the unclassified share gets measured monthly, with new examples added for whatever keeps falling through. ResortConcierge AI uses smart escalation to send anything it cannot classify, and any message with negative sentiment, to the escalation queue so a person decides instead of the request stalling. The mechanics of that queue, and why it needs an owner and a clock, are covered in what an escalation queue is.

How should the guest be acknowledged, and how fast?

At once, with an expected time. The acknowledgment is the one step that can and should be automatic. The fix is human and takes as long as it takes. What guests cannot stand is the gap between sending a message and hearing anything at all, because silence reads as "nobody saw this," and the guest starts composing the second message in their head.

Guests are fine with the first reply being automated. In Oracle Hospitality and Skift's 2022 survey of 5,266 consumers, 77% were interested in automated messaging or chatbots for service requests, and 34% named staff shortages and slow service as their top reason not to rebook ^[4]. They want to know it landed and when to expect it. They do not need a human to type "got it."

Two messages, then, and both should be templated. First: "Got it, housekeeping has your towel request. Expect them within 20 minutes." Second, when the state changes to done: "Towels delivered. Anything else tonight?" ResortConcierge sends both through notifications on the channel the guest used, so a WhatsApp request gets a WhatsApp reply and nobody has to remember which guest texted and which one used the web chat. I am not going to give you a universal minute benchmark for acknowledgment, because there is no sound one; set your own, by type and priority, as the table above suggests.

How do you track a request from new to done?

Five states, each with an owner who moves it and a message the guest sees or does not. The point of states is not reporting. It is that at any moment, anyone can look at a request and know whose turn it is.

Request states and owners, common practice, 2026.

A visible queue per team is the other half. Housekeeping should see housekeeping's list, not the whole inbox, and a supervisor should see anything older than its target in a different color. ResortConcierge creates service requests with a type, owner and status from web chat, SMS, WhatsApp or email, and each team gets its own view.

The cost of losing one is not abstract. In J.D. Power's 2025 study of 39,219 guests, about 12% of stays involved a problem such as a housekeeping issue or noise, and when a problem occurred, satisfaction fell 217 points on a 1,000 point scale, from 677 to 460 ^[5]. A request that went into a radio and never came out is exactly that kind of problem. The shift change is where most of them disappear, and keeping requests from getting lost between shifts is its own discipline.

Does request routing need a PMS or task-management integration?

No, not to start, and I would push back on anyone who says otherwise. The routing model needs three pieces of data: what the guest wants, which room they are in, and when they sent it. A QR code in the room or a stay link in the pre-arrival message supplies the room. Failing that, the first automated reply can ask for it.

A property management system (PMS) connection adds things later: room status so housekeeping knows the room is occupied, folio posting for chargeable requests, and the guest's name without asking. Those are worth having at volume. They are not the price of entry. On ResortConcierge, PMS connectors are planned, not shipped, and there is no integration with third-party housekeeping or maintenance task systems today, so the queue described above is the system of record for requests. If a vendor implies otherwise, the questions in what to look for in a PMS integration will sort out what is live from what is on a roadmap.

How do you roll routing out at one property?

Two weeks, if the people are in the room. Here is the sequence I would run.

1. Day one and two: define the six request types and write 10 example messages for each, in the words guests actually use, including the misspellings.
2. Day three: build the routing table. One owning role and one backup per type, for day and for night. If you cannot name a night owner for a type, that type escalates to the night manager by default.
3. Day four: set acknowledge and resolve targets per type. Write them down. Put them on the wall in the housekeeping office.
4. Day five: write the two guest messages (received and done) per type. Short, plain, with a time.
5. Week two, days one to three: run it in parallel with the radio. Every request goes through the queue and also through the old relay, and you compare.
6. Week two, days four and five: train the escalation habit. Anyone who sees a request they are unsure about moves it to the queue and says so. No heroics, no guessing.
7. Days 15 to 45: review the queue daily, 10 minutes, anything older than its target. Measure the unclassified share and add examples.

If after 30 days the radio is still carrying requests, the table is wrong, not the staff. Fix the table.

Start with the examples. Ten real messages per type, written down tonight from what the desk heard today, is the whole foundation, and it costs nothing but an hour and a notepad. Everything else in this post is built on top of that list.