Guest message triage: turn an inbox into a work queue

Guest message triage turns incoming conversations into requests that someone can act on. For a vacation-rental team, the useful output is a matched booking, the work needed, a responsible person and the next action. A label such as "maintenance" is only the beginning.

AI can propose classifications and extract details from a message. Your operating rules still have to determine who responds, what happens when nobody accepts the request and which cases need immediate staff attention. This article covers that queue. The broader choices about automatic replies are in AI guest communication.

Build the queue around requests

An inbox groups messages into conversations. An operating queue groups work into requests. Keep a connection between them, but don't assume they are interchangeable.

Consider this illustrative guest message: "We found the parking space, thanks. The bedroom lamp isn't working, and could we get another blanket?"

The parking conversation is complete. The lamp needs one owner; the blanket may need another. If the whole message is classified as a thank-you, both requests disappear. If it becomes one vague maintenance ticket, the blanket may wait unnecessarily.

Create separate request records when the actions or owners differ. Keep them attached to the same guest conversation so staff can send a coherent update. Avoid forcing the guest to learn how your departments divide the work.

Each record should contain only what the next person needs. A useful minimum is:

Request reference
Reservation and property reference
Source message and received time
Requested outcome
Relevant details already supplied
Priority with reason
Assigned owner
Next action and due time
Guest update already promised
Status and completion evidence

The source message matters. A concise extraction can leave out a condition that changes the work, such as "please don't enter until we return."

Use a small set of routing categories

Start with categories that correspond to real owners. More labels won't help if staff still have to reread everything before deciding where it belongs.

Here is an illustrative queue for a small hospitality operation:

Some tools can create this routing directly. HelloShift documents department task creation from guest requests. Whether you use that feature or a manual queue, someone still needs to accept the task and confirm the outcome.

Keep an "unclear" category with an explicit review owner. That is more useful than pushing every uncertain message into a guessed department. Review the unclear queue regularly to discover missing categories or weak property information.

Separate urgency from tone

A polite message can describe an urgent problem. An angry message can concern a routine request. Sentiment can help an agent choose wording, but it shouldn't decide service priority by itself.

Use the reported situation, its effect on the current stay and the property's response procedure. Any message suggesting immediate danger should reach an appropriate person promptly under your emergency process. Do not hold it for an AI model to achieve a reassuring confidence score.

For other cases, write the priority reason in ordinary language. "Guest cannot access the property and is waiting outside" tells the next person more than a red badge. "Extra linen requested for tomorrow" supports a different response window even if the message is emphatic.

Be careful with keyword-only rules. "The door code worked yesterday but not now" contains positive words, yet reports a current failure. Include negation, changed conditions and multiple requests in the examples used to review the classifier.

Detailed repair intake belongs in maintenance request triage. The guest-services queue should retain responsibility for communicating while the physical work proceeds.

Make assignment visible and require acceptance

A request needs an accountable owner, even when several people can help. Assigning it to an entire department without a coverage rule leaves room for everybody to assume somebody else has picked it up.

Guesty's conversation assignment feature can notify the selected user. Treat that notification as the start of the handoff. It doesn't prove the person is available or has begun the work.

Use separate states such as new, accepted, waiting on another party and completed. "Waiting" should name the dependency and the next review time. A vendor who hasn't responded and a guest who hasn't confirmed a delivery slot are different reasons to wait.

Choose a fallback for an unaccepted request. During staffed hours, that may be the shift lead. Outside staffed hours, it should follow the after-hours coverage plan. Set response windows according to the operation's real commitments; don't copy an arbitrary service target from a software demo.

Merge duplicates without losing new information

Guests may send the same issue through a booking channel, a text and a phone call. Connect those reports to one request when they refer to the same event. Preserve where each report came from and whether the situation changed.

A second message saying "the lamp is still broken" is a follow-up. A second message saying "now there is a burning smell" changes the situation and needs fresh review. Duplicate detection must not suppress a meaningful escalation.

Match using the booking, property, issue and time context. Don't merge solely because two messages share a surname or mention the same appliance. When the match is uncertain, show the possible duplicate to staff rather than silently deleting it.

Airbnb's messaging documentation describes shared reservation threads and message attachments. Preserve those references when your queue is in another tool, so the person acting can inspect what the guest actually supplied.

Review a mixed message from start to finish

Return to the lamp-and-blanket example. A useful result creates two linked requests, assigns appropriate owners and prepares one reply acknowledging both items. It doesn't announce a delivery time or repair visit until those are confirmed.

Suppose the blanket is delivered while the lamp replacement is still pending. The guest conversation can show partial progress, while the lamp request remains open. Marking the whole conversation complete at that point would hide unfinished work.

If the shift changes, the incoming person should see the pending lamp request, the last update given and any access restriction. The handover guide provides a record for carrying those promises forward.

This example also gives you a practical test case. Check whether your proposed system identifies both requests, uses the correct property, retains the access condition and keeps the unfinished item open after the other one closes.

Measure the work that triage leaves behind

Review a sample of incoming messages against the resulting queue. Count requests missed, unnecessary duplicates, incorrect assignments and cases reopened after being marked complete. Also measure how long the next owner spends reconstructing context.

A fast classifier that generates frequent reassignment is adding work elsewhere. A slightly slower review that gives a service team a complete task may be the better operational choice.

Keep failed examples and use them when changing rules. If a message contains two requests and only one is captured, add that pattern to the review set. If a request reaches an off-duty person, fix the coverage mapping. Those changes improve the actual queue rather than its appearance.

The operations guide library connects this intake process with the delivery, maintenance and reporting work that follows it.