What Happens When a Guest Message Goes Unanswered

Most operational failures in short-term rentals are quiet. A thermostat left running, a slightly-too-tight turnover, a slow-draining sink nobody reported. They cost a little, they accumulate, and you find out about them eventually.

An unanswered guest message is not quiet. It's the failure that turns into a one-star review, a chargeback dispute, or a guest standing outside a locked door at 11 PM with a phone that's getting no reply. It's also the failure that's easiest to prevent, because the information you need already exists: this message has been waiting too long. The problem is almost never that nobody cared. The message scrolled out of view.

Why messages slip

Picture a manager with twelve properties. On a normal day, inbound guest messages arrive across three OTA inboxes, maybe a direct-booking channel, and the occasional text. Most are routine: a question about parking, a thanks-for-the-stay, a request for a late checkout. A few are urgent: a lockbox that won't open, a heating system that's down, a guest who can't find the unit.

The routine and the urgent arrive in the same stream, in the same visual weight, interleaved with each other. The urgent one came in at 4:47 PM. By 6 PM it's six messages down. By the time someone scrolls back to it, the guest has already messaged again, angrier this time, and left a note in their head about how this stay is going.

Nothing about that sequence requires negligence. It requires only a flat, undifferentiated inbox and a busy afternoon. Volume plus uniformity is enough.

Response time is the metric guests actually feel

Guests don't experience your occupancy rate or your RevPAR. They experience how long it took you to answer them when something was wrong. Response time is the operational metric that shows up most directly in reviews, and it's the one most OTA ranking algorithms weight heavily. Airbnb's response-rate and response-time signals feed your search position.

The uncomfortable part is that response time is bimodal. Reply to most messages within an hour and one within six hours, and your average looks fine. But that one slow reply was probably the urgent one, and it's the one the guest remembers. Averages hide exactly the failure that matters. What you want to minimize is not mean response time. It's the oldest unanswered message at any given moment.

What a triage layer does

"Answer faster" is an instruction, not a system. The real fix is to make the inbox sort itself by urgency so the important message can't hide behind the routine ones.

A triage view does a few specific things.

• Separates needs-a-reply from already-handled. A thread where the guest's last message is unanswered is a different animal from one where you replied and they said thanks. The first needs a human. The second is closed. Collapsing them into one list is what creates the scroll-back problem.
• Sorts by how long the guest has been waiting. Not by most-recent-activity, which surfaces the chatty threads, but by the age of the oldest unanswered message. The thread that's been waiting eight hours should be at the top, not buried under a thread that just got three back-and-forth messages about checkout time.
• Spans every property at once. A per-property inbox means a manager has to remember to check all twelve. A cross-property "needs attention" view surfaces the urgent message regardless of which unit it belongs to. For a team with a dedicated communications coordinator, that's the difference between triage and whack-a-mole.

That's how Pomello treats guest comms. Messages live in one source of truth, and a single "needs attention" surface spans the whole portfolio and ranks by who's been waiting longest, so the oldest unanswered message is always one glance away rather than buried in whichever property's inbox you happened not to open. The features page covers how this connects to a Hostfully-based setup.

Hand-offs: the part most inboxes ignore

There's a second failure mode that's subtler than the slow reply: the message that looks answered but isn't resolved. A guest reports the dishwasher is broken. Someone replies "so sorry, we'll get someone out there." The thread now looks handled, since the guest's last message has a response. But the actual work hasn't happened, and the person who needs to do it doesn't know it exists.

This is where the inbox needs more than read/unread. It needs a notion of ownership: this thread is now Mara's problem, and it stays flagged until Mara marks it done. A hand-off turns a conversation into a tracked task without leaving the inbox, so the maintenance issue doesn't evaporate the moment the reassuring reply goes out.

Teams that run hot inboxes well almost always have some version of this, even if it's a manual one (a shared spreadsheet, a group chat with "claimed" reactions). The trouble with the manual versions is that they live outside the inbox, so everyone has to remember to update two places. Ownership that lives on the thread itself is what survives a busy day.

A practical standard to hold yourself to

You don't need software to start improving this. You need a standard and a way to check it:

1. Set a maximum wait for an unanswered guest message. Many professional operators use one hour during waking hours, with a faster bar on check-in days. The number matters less than having one.
2. Check the oldest, not the average. Once a day, look at the single longest-waiting unanswered thread across all properties. If it's older than your standard, that's your signal the system isn't keeping up, not a quarterly average that looks fine.
3. Make resolution explicit. A reply is not a resolution. Decide what "done" means for a thread, and don't let "we'll look into it" count.
4. Give every urgent thread an owner. Especially on a team. The most common cause of a dropped issue is diffusion of responsibility: everyone assumed someone else had it.

This connects to something we've written about before, the operations layer that sits above your PMS. It exists because the PMS is built around booking events, not around the real-time, time-sensitive question of who's waiting and who owns it. Guest comms is the highest-frequency, highest-stakes version of that question. It deserves a view of its own.

A guest who gets a fast, complete answer when something goes wrong will often forgive the thing that went wrong. A guest who waits, and then has to ask twice, remembers the waiting more than the problem. So make sure the waiting never happens, and that starts with an inbox that refuses to let the urgent message hide.