In-room service request router

A usable classification quotes a span from the guest message and names a suggested department. Type and urgency attach to that same cite. None of that sends work. Guest services still dispatches.

If the model names a department without quoting the guest, the output is unfit. A route with no message cite is a guess with a department label. Do not turn it into a ticket.

If the guest message is silent, empty, or only a room number with no ask, leave type, urgency, and department blank. Empty stays empty. Do not fill housekeeping just because that desk is the usual destination. Do not invent an SLA so the row looks finished.

The working order is load the request, classify only what a cite supports, leave blanks when the text does not, then dispatch yourself.

Open the in-room message the way you already work the inbox. Confirm you have the guest text, the room or reservation handle your property uses, and the channel: app chat, SMS, in-room tablet, or a phone note an operator typed. Classification starts after that payload is in front of you. It does not start from a department dropdown.

Read the message for the ask, not for the brand of system it arrived in. Oracle Hospitality, Mews, Ivy / Go Moment, and Canary sit in the same class here: they are where requests and guest threads commonly live. This page does not map buttons, workflows, or clocks inside any of them. If your PMS or messaging tool already stores the thread, load from there. If a night auditor typed the request into a note, load that note. The classifier sees text. It does not see a live ticket.

When one message contains two asks, load the whole message. Do not split it in the tool before you have cites. Splitting is a dispatch decision you make after the cites exist.

Guest text from room 412: "Extra towels please, and the AC is blowing hot air." You load that string, the room, and the timestamp your system already shows. You do not load a pre-chosen department. You do not start a timer.

Classification is a span plus labels. For each suggested department, the output must include the exact words in the guest message that support it.

For the 412 text, a fit output can look like this:

• Cite: "Extra towels please." Suggested department: housekeeping. Type: amenity or linens. Urgency: routine, unless your property already treats missing towels as same-stay recovery.
• Cite: "the AC is blowing hot air." Suggested department: engineering. Type: in-room climate. Urgency: comfort, same stay.

Those are suggestions. They are not two closed work orders.

Reject a route that says engineering with no quoted span. The model may have inferred HVAC from a room type, a prior ticket, or a habit. Without the guest's words, you cannot tell. Send it back, re-run, or classify it yourself. Do not fix a missing cite by typing the department you expected.

Urgency is also cite-bound. "Blowing hot air" supports a comfort issue. It does not support emergency unless the guest said words that mean danger, medical need, or an immediate safety problem. Do not upgrade urgency to make a later SLA look tighter.

If the model returns one department for the whole message, check whether both spans were used. A single housekeeping label on a message that also cites climate is incomplete, not efficient. You may still send two tasks, or one lead department with a note. That choice is dispatch, not classification.

When the guest is asking for information rather than a task, use ai concierge rag powered. A dining-hours question is not an in-room service request. Do not force it through this classifier.

Silent means there is no ask you can quote. That includes an empty body, a sticker with no caption, "412" and nothing else, a duplicated thread with no new sentence, or a thanks with no new request.

In those cases the quality output is blank fields. Do not invent type. Do not invent urgency. Do not suggest a department so the screen is not empty. Do not invent an SLA.

A common bad pattern is filling housekeeping plus the property default housekeeping SLA because that is what the desk usually sends. Defaults belong in your dispatch playbook, not in the model's blanks. If you apply a default, you are the one applying it, after you decide the message actually contains an ask.

If the message is ambiguous ("it's not working") without naming the thing, you may still get no reliable department. Blank is correct. You can reply to the guest for a noun. The classifier should not guess TV or safe to complete the row.

When a complaint is forming across the stay rather than a single in-room ask, do not stretch this router to predict a problem. That is a different job: mid-stay complaint predictor.

Treat classify as unread until you send work. The suggested department is a hint for your queue, not a page to engineering.

The failure mode to watch is treating classify as dispatched. A department name appears and the coordinator moves to the next message. Neither housekeeping nor engineering got a task. The guest's AC is still hot. Classification can be complete and the stay still fails because nobody was assigned.

Your dispatch step is the same as today: pick the department, or split the two cites into two tasks, write the instruction in the language that team uses, attach room and guest identifiers, and start whatever SLA your property already defined for that task type. The model does not start that clock. If the classifier prints an SLA duration, discard it. You do not have a source for that number in the guest message, and this use case does not authorize inventing one.

Do not auto-route. Auto-route means the suggested department becomes the assignee without a human send. Skip that. Coordinators catch the cases the cite cannot: VIP handling, connecting rooms, a maintenance outage you already know about, a guest who asked for towels but the real issue is a wet floor. The classifier cannot see the radio channel.

When the work truly crosses departments after you have cites, handoff design lives in cross-department task orchestrator. Use that when you are sequencing tasks, not when you are still reading the first message.

Charges and this-should-not-be-on-my-bill language are not in-room service routing. Park those for folio dispute classifier.

An SLA timer is a property rule attached to dispatched work: housekeeping linen, engineering HVAC, in-room dining, and so on. It is not a field the classifier is allowed to mint from tone.

If your PMS or messaging stack shows timers, those timers belong to tickets you created. Oracle Hospitality, Mews, Ivy / Go Moment, and Canary may each surface aging work in their own way. Do not read a model-generated duration as if it came from those systems. Do not copy a number from the classification pane into the ticket so the row looks complete.

Working order:

1. Load the guest message and identifiers.
2. Accept a classification only when each suggested department has a cited span.
3. Leave type, urgency, and department empty when you cannot quote an ask.
4. Dispatch yourself. Set the SLA your hotel already uses for that task. If you have no SLA for that task type, leave the timer unset. Do not invent one to match the model's confidence.

A cited classification or an empty one, then you dispatch. That is the quality bar.