A guest messages at 19:05: the oven will not turn on. You reply at 19:06: "let me check on that for you." You find the manual, work out that the hob has a child lock, and send the actual fix at 22:40.
Your dashboard records a one-minute response. The guest waited three and a half hours in a kitchen with a cold dinner on the counter. Both of those are true, and only one of them is on the badge you are being measured against.
That gap is the whole problem with response time as the headline number. It is the metric the platform shows you, so it is the metric hosts optimise, and it is the easiest of the four worth tracking to make look good without improving anything for the person in the property.
The Metric You Are Shown, and Why It Is the Weakest
Response time survives as the default for a reasonable reason: it is trivially computable. Two timestamps, a subtraction, done. Nobody has to read anything.
The problem is what it counts. It measures the arrival of a message, not the arrival of an answer. Any reply stops the clock: an acknowledgement, a holding line, an emoji. That makes it the only one of these four metrics you can improve to near-perfection in an afternoon by setting an auto-reply that says "thanks, looking into this now", while every guest waits exactly as long as before.
It is also computed differently depending on who is doing the computing. Airbnb's version counts a specific and narrow set of messages rather than everything a guest sends you, which is why hosts who answer guests constantly still see a mediocre figure: the mechanics are worth understanding on their own terms in what Airbnb's response rate and response time actually measure.
Response time is not useless. It is a floor. Below a certain speed everything else degrades, and the cost of being slow is real and well documented in the real cost of slow responses. But a floor is not a target, and treating it as the goal produces the 19:06 reply above.
Metric One: Time to First Useful Answer
The fix is one word. Stop the clock when the guest receives something they can act on.
The oven message is answered at 22:40, not 19:06. A question about parking is answered when the guest has the street name and the permit rule, not when you say "good question". A stay-extension request is answered when the guest has a yes, a no, or a price, not when you promise to check the calendar.
What improving it moves. Fewer follow-up messages chasing the first one, which is a compounding effect: each unanswered thread generates two or three more messages, and those messages land on whoever is on duty. Fewer conversations that migrate from text to a phone call because the guest gave up waiting. And fewer arrivals where the guest's first experience of you is a delay.
How it gets gamed. Generously. A sentence that technically contains information ("the parking is nearby") can be counted as useful when it is not. The only defence is to define usefulness as whether the guest's next message is a thank-you or a repeat of the question, and to check by reading. If the guest asks again, the first answer was not an answer.
How to measure it without a project. Take thirty conversations. For each, find the guest's first question and the first reply that resolved it. Median, not mean: one three-day thread about a broken boiler will drag an average anywhere it wants. Thirty read by hand beats three hundred counted by a script you do not trust.
Metric Two: Resolution Without Escalation
The second metric is the share of guest conversations that end without a human having to step in. Not "without a human involved at all," most hosts are in the thread somewhere, but without the question having to leave the channel it arrived in and land on someone's personal phone.
This is the number that maps most directly onto your workload. A hundred guest conversations a week where eighty resolve in the thread is a different job from one where forty do. It is also the number that determines whether your evenings belong to you, which is the honest reason most people start measuring any of this.
What improving it moves. Your own time, and your team's. Every escalation is a context switch for a person who was doing something else, and context switches cost more than the two minutes the reply takes.
How it gets gamed. Two ways, both easy. Define escalation narrowly enough and nothing qualifies. Or answer questions badly enough that guests stop asking: a conversation where the guest gave up looks identical, in the data, to a conversation that was resolved. This is why this metric is worthless on its own and useful alongside the fourth one below. A resolution rate that rises while repeat questions also rise is not resolution; it is attrition.
Metric Three: Escalation Rate, and What It Is Made Of
The escalation rate is the mirror of the previous metric, and on its own it tells you almost nothing. Twelve per cent is neither good nor bad. What matters is what the twelve per cent is made of.
Sort your escalations into four buckets and the number starts speaking:
- Decisions only you can make. Stay extensions, discounts, an early check-in that depends on the cleaner, a refund. These are not failures. They are the job, and driving them to zero would mean an assistant approving discounts on your behalf, which you do not want.
- Knowledge gaps. The question had an answer, but the answer was not written down anywhere. Every one of these is a task, not a mystery: write it down once.
- Emergencies and safety. A gas smell, a flood, a lockout at midnight. These should escalate immediately and always, and a system that resolves them without you is a system with a bug.
- The guest simply wanted a person. Some do, particularly after something has already gone wrong. This bucket should stay small but it will never be empty.
A portfolio whose escalations are ninety per cent bucket one is running well and does not need a project. A portfolio whose escalations are ninety per cent bucket two has a documentation problem wearing an escalation costume, and one afternoon with a text file fixes most of it.
How it gets gamed. By reclassification. Anything can be relabelled a decision-only escalation if nobody audits the labels, and the people doing the labelling are usually the people the number reflects on.
Metric Four: Repeat-Question Rate
This is the one that earns its place. Repeat-question rate is how often the same question arrives from different guests at the same property.
Three separate guests at the same flat asking how the washing machine starts is not three guest questions. It is one missing paragraph in your house manual, asked three times. Four guests asking whether the street parking needs a permit on Sundays is a sign on a wall that you have not printed yet.
What improving it moves. Volume, at the source. Every other metric here improves when a repeated question stops being asked, because the fastest answer is the one nobody needed. This is also the only metric of the four that is genuinely difficult to game, which is exactly why it is worth keeping: there is no clever reply that makes a question stop recurring except actually documenting the answer.
How it gets diluted. By counting strings rather than meanings. "How do I start the washer?", "the washing machine won't go" and "which button for laundry" are the same question, and a tally that treats them as three different ones will report a healthy-looking spread of unique queries. Group by what the guest wanted, by hand, at least the first time.
There is a sharp version of this signal for anyone who has invested in a guidebook or an app: if a question keeps arriving despite being answered on page four, the page is not the problem: the fact that nobody opens page four is. That is the argument running through guest app or WhatsApp, job by job.
A Worked Month, With Illustrative Numbers
Every number in the table below is invented to show the shape of the calculation. None of it is measured, from Welco or anyone else. Treat it as arithmetic, not evidence.
| Metric | Month one | Month two | What the change suggests |
|---|---|---|---|
| Guest conversations | 180 | 190 | Volume roughly flat |
| Median response time | 4 min | 3 min | Barely moved, and barely matters |
| Median time to first useful answer | 46 min | 19 min | The change that guests actually felt |
| Resolved without escalation | 58% | 74% | Fewer interruptions for the on-duty person |
| Escalations: knowledge gaps | 31 | 9 | Documentation caught up |
| Escalations: decisions only the host can make | 14 | 15 | Unchanged, correctly |
| Repeat questions (same property) | 22 | 8 | The knowledge base had a hole; it is smaller |
Read it as a pattern rather than a result. Response time moved by a minute and tells you nothing. Time to first useful answer halved. Knowledge-gap escalations collapsed while host-decision escalations stayed flat, which is the shape you want: the system absorbed the documentable questions and left you the ones that need a human with authority.
The Baseline Problem: No Record, No Measurement
Here is the part most articles on this subject skip. You cannot calculate a single number above without a record of the conversations, and most hosts do not have one.
The typical setup is three channels at once. Some guests message the platform inbox. Some get your mobile number from the booking confirmation and text you directly. Some end up on WhatsApp on your personal phone, where the thread sits between your sister and a plumber. A co-host answers a few from their own phone, in their own account, and those conversations do not exist anywhere you can see.
That arrangement is not slightly harder to measure. It is unmeasurable. There is no export, no consistent timestamp, no way to tell whether a question was answered at all, and no way to know that three guests asked about the washing machine because the three threads live on three devices. This, not laziness, is the real reason so few operations have any idea how their guest communication is performing.
So the first month of work is not a dashboard. It is consolidation: decide on one channel of record, move guest conversation onto it, and accept that this is a habit change for you and your co-hosts before it is a data project. Be honest about the cost. Telling a co-host to stop replying from their own phone is a management conversation, not a settings change.
What to Track in the First Month
A deliberately small starting point, in order:
- Pick the channel of record. One place where guest conversation lives. Anything answered elsewhere gets pasted back in or it did not happen.
- Read thirty conversations by hand. Not a sample of three hundred through a script. Thirty, read properly, with the two timestamps written down: first question, first useful answer.
- Tag every escalation with its cause using the four buckets above. Do this weekly while the memory is fresh; retrospective tagging is fiction.
- Keep a tally of repeated questions per property. A text file per property is enough. When a question hits three, write the answer into your house manual that day.
- Re-read the same thirty-conversation sample a month later. Compare medians, not averages, and expect the numbers to be noisy.
Five steps, no software purchase, and enough signal to tell you whether the problem is speed, documentation or staffing.
Honest Limits
These are operational metrics, not business ones, and the distinction matters more than it sounds.
None of the four proves a revenue effect. A faster useful answer is plausibly connected to better reviews, and better reviews are plausibly connected to ranking and bookings, but "plausibly" is doing real work in that sentence, and you will not be able to demonstrate the chain from your own data at ten properties. Your sample is too small, your seasons are not comparable, and one broken boiler in February moves your review average more than a quarter of careful messaging. The reasoning behind that connection is worth reading with the same scepticism in how guest messaging affects review scores.
Every one of these metrics also becomes worse the moment it becomes a target for someone whose performance is judged on it. That is Goodhart's law, and guest communication is an unusually easy place for it to bite, because the person generating the number is often the person reporting it.
Be sceptical of tooling that scores itself, and include Welco in that. An assistant's own dashboard reporting its own resolution rate is self-assessment: it counts a conversation as resolved because no escalation was raised, which is exactly the failure mode described earlier. The check is to read a sample of the transcripts yourself, monthly, and see whether you agree with the machine.
Finally, the four metrics say nothing about tone, warmth or whether guests actually liked talking to you. A property can score well on all four and still feel like an automated kiosk. The numbers catch the operational half; the rest is judgement, and the only instrument for it is reading what your guests were actually sent.
Where Welco Fits
Welco is a WhatsApp AI assistant for hosts and property managers, and its relevance here is upstream of any metric: it puts guest conversation for every property in one place, from a channel guests already use, with nothing for them to install. Questions it cannot answer are escalated to you with an urgency level, and a question you answer once is saved and reused for every future guest, which is the repeat-question loop closing by construction rather than by discipline. It is not an analytics product, and the sceptical read of its dashboard above applies to it as much as to anything else. If the wider picture of automating guest experience is what you are working on, start with the guest experience automation pillar, and request a demo if you want to see how the conversation layer behaves before you measure it.