The inquiry came in at 11:14 on a Tuesday. A potential guest, a four-night stay, peak season pricing. By the time someone responded, it was 12:01. The lead had already booked elsewhere.

The operator's instinct was to blame the person who missed it. The real problem was that no one had defined who owned that inquiry in the first place. There was no routing logic — only hope that the right person would notice.

When response time is slow, the first diagnosis is usually a people problem. More staff, better coverage, a shared inbox, a rotation schedule. Operators spend real money and management energy on solutions that do not address the actual failure.

The actual failure is almost never that a person was unavailable. It is that the system had no opinion about who was supposed to respond, under what conditions, through which channel, and within what window. That is a routing problem. People cannot consistently do what the system has not defined.

Routing is the logic that answers four questions the moment an inquiry arrives: who owns this, through what channel do they receive it, what is the response deadline, and what happens if that deadline passes.

In most short-term rental operations, none of those four questions have a written answer. Inquiries from Airbnb go to one person by habit. Inquiries from the direct booking site go to a general inbox nobody monitors on weekends. Vrbo messages are seen when someone happens to check the app. Booking.com requests wait for a login.

This is not a staffing shortage. It is an unmapped handoff. The inquiry enters the system and then falls into a routing void.

Operators answering inquiries inside five minutes convert at roughly 21 percent. Past the 60-minute mark, that rate falls to approximately 4 percent. That is not a motivational statistic — it is a structural one. The conversion gap is not explained by the quality of the response. It is explained almost entirely by when the response arrives.

Picture a 20-unit operator running three channels: Airbnb, a direct booking site, and one OTA. The direct site generates roughly 30 percent of inquiry volume. Those inquiries arrive in a general email account that gets checked twice a day. Illustratively, that operator is converting direct inquiries at a fraction of what the channel could produce — not because the offer is wrong, not because the pricing is off, but because the routing logic for that channel was never built. The lead cooled before the machine noticed it existed.

An audit of a typical STR operator's inquiry stack tends to surface the same failure modes repeatedly.

First: channel-specific dead zones. One booking source has a configured integration. Another dumps into a generic inbox. A third exists only as a mobile app notification that routes to whoever's phone is logged in.

Second: no escalation logic. The routing assigns an owner but has no fallback. If that person is unavailable — at dinner, on a flight, at a cleaner walkthrough — the inquiry waits. There is no second owner, no timeout trigger, no alert.

Third: source attribution is absent. Even when someone does respond quickly, the system does not record which channel the inquiry came from. The operator cannot tell you whether their direct site or their OTA drives faster-closing leads. Without that data, they cannot route intelligently — they can only guess.

Fix the routing before hiring for coverage. The sequence matters because adding people to an undefined system creates the illusion of capacity while the structural leak continues.

Defined routing means: every inquiry source has a named owner, a documented response window, a fallback owner when the primary is unavailable, and a log entry the moment the inquiry arrives. That log is what makes the system auditable. Without it, the operator is not running a response process — they are running hope.

The channel that is currently routing to a general inbox needs its own workflow. The mobile-app notification that goes to one person's phone needs a web-hook to the shared system, not just a personal alert. The escalation logic needs to fire at 15 minutes, not when someone eventually notices.

None of this requires new staff. It requires that the system have opinions — and that those opinions be written down, automated, and inspectable.

Slow replies look like a people problem from the inside. From the outside, they read as a routing gap that was never closed. The inquiry volume is there. The team is there. What is missing is the logic that connects the two before the lead goes cold.

If you are not certain which of your inquiry channels has defined routing, a response-window owner, and an escalation fallback — you have at least one routing void. The free STR Leak Scorecard maps where the logic breaks down. Run it before the next peak-season inquiry window opens.