You answered something like three hundred guest messages last month. Broken hob at 22:00, a lost passport, four separate conversations about parking. Your response rate says 78%, and you cannot work out how.
Then you remember the Tuesday you spent driving. Three enquiries arrived between 14:00 and 14:40, you saw them at 21:00, and you replied to two. The third had expired.
Those three messages, not the three hundred, are what the metric was watching. Understanding why is most of the work, and it is the single most common misunderstanding hosts have about their own dashboard.
One caution before any of the detail: Airbnb changes these rules, their windows and their thresholds, and has done repeatedly. What follows describes the shape of the mechanism and the behaviour it rewards, not the current terms. Before you act on any specific number (a percentage, a deadline, a Superhost criterion) check Airbnb's current published documentation for your account and region, because the number in your help centre today beats the number in any article, including this one.
What the Two Metrics Count, and What They Ignore
The two figures are related but separate.
Response rate has generally been the share of new enquiries and booking requests you replied to within a set window, measured over a trailing period of recent activity. The window has generally been about a day; the trailing period has generally been measured in weeks or months. Both have moved over the years.
Response time has generally been the typical speed of that first reply, displayed to guests as a band (within an hour, within a few hours, within a day) rather than as a precise figure.
The critical word in both definitions is first. These metrics are computed from the opening move in a new conversation: an enquiry from someone who has not booked, or a booking request awaiting your decision. What they generally ignore is everything after that. Your reply to a guest's third message about towels, your 23:00 answer about the boiler, your careful handling of a complaint on day four: none of it is what the percentage is made of.
That design makes sense from Airbnb's side. The metric exists to tell a prospective guest whether a host will answer a stranger, because that is the risk the guest is taking at the moment they see it. It is a pre-booking trust signal, not a service score.
Why Attentive Hosts Still See a Mediocre Number
Once you see the mechanism, the paradox resolves.
In-stay messages are high in volume and low in weight. Enquiries are low in volume and high in weight. A host with ten properties might receive three hundred in-stay messages and fifteen enquiries in a month. Miss two of the fifteen and the metric records a substantial miss, no matter how good the other three hundred replies were.
The distribution is what catches people. Enquiries do not spread themselves evenly; they cluster around evenings, weekends and the exact hours you are driving, cleaning a property, or on a flight. And the cost of each miss is high precisely because the denominator is small. One ignored enquiry out of fifteen is worth roughly seven percentage points; one ignored message out of three hundred is worth nothing at all.
This is also why the metric feels unfair to hosts who genuinely care. Attentiveness during a stay (the thing guests write reviews about) is invisible to it. If you want to know whether your guest communication is actually working, you need a different set of numbers, and the four worth tracking are in the guest communication metrics that matter.
What Counts as a Response
Broader than most hosts assume. A response has generally meant any of these, and the list is worth knowing because two of them take a single tap:
- A written reply, of any length.
- Pre-approving the guest, for an enquiry.
- Declining the booking request.
- Sending a special offer.
Declining counts. That is the detail that changes behaviour: a host who leaves a request untouched because they do not want it is being penalised for politeness they were not obliged to show. Declining is an answer. Silence is not.
Two clarifications on the edges. Booking requests expire if you do not act within the response window, and an expired request has generally been treated as a non-response: the guest's plans move on and your metric absorbs the miss. And declining affects a different figure, your acceptance rate, which is tracked separately and has its own consequences. The two are easy to confuse and they are not the same number.
Check the current definitions before you build a workflow on any of this. The list above is stable in shape and has varied in detail.
Why an Unanswered Enquiry Is Worse Than a Declined One
Put the two outcomes side by side and the asymmetry is stark.
Decline a request and you have: a guest who knows where they stand and can book elsewhere within the hour, a response recorded, a dent in your acceptance rate, and a conversation that ended cleanly. Ignore it and you have: a guest left waiting for a day before the system releases them, a non-response recorded, a hit to your response rate, an unanswered message sitting visibly in the thread, and the same empty date you would have had anyway.
The decline costs you one metric. The silence costs you two (the response rate and the goodwill) and produces exactly the same booking outcome.
This is why the most useful single change most hosts make is not getting faster. It is deciding that every enquiry gets some answer, including the ones that are obviously not going to work out. A four-word decline is an answer.
The Knock-On Effects: Ranking and Superhost
Two consequences sit downstream, and they are worth treating with different levels of confidence.
Search ranking. Airbnb has generally been open about responsiveness being one of many factors in how listings are ordered, while keeping the weighting private. That is roughly all anyone outside Airbnb can honestly say. Nobody publishing a blog post knows how much your response rate moves your position, and you should be suspicious of anyone who tells you they do, including tools sold on that promise. Treat responsiveness as one input among dozens (price, reviews, acceptance, cancellation history, conversion, location, recency) rather than a lever with a known effect.
Superhost. Here the mechanism is more concrete, because the criteria are published and checked at fixed assessment points. A response rate threshold has generally been part of the qualifying set, sitting high: the sort of level where a small number of missed enquiries in an assessment period is enough to cost the badge. What that threshold is right now, and how the assessment window is defined, is exactly the kind of detail Airbnb revises, so read the current criteria rather than trusting a figure quoted in an article.
The practical consequence of a high threshold is the one worth absorbing: on a small denominator, the badge can turn on two or three messages you did not see. That is a notification problem masquerading as a performance problem.
What to Automate, and What a Holding Reply Does Not Achieve
Automation helps here, in a narrow and specific way.
Worth automating. A scheduled first reply to new enquiries (Airbnb's own quick replies and scheduled messages have generally supported this) that does more than acknowledge. The best version answers the two or three questions that almost every enquiry contains anyway: yes the dates are free, here is what the total would be with the cleaning fee, here is the check-in time, here is what to do next. That reply stops the clock and moves the booking forward.
Also worth automating. Rules that remove whole categories of message from the queue. Instant Book, where it suits your operation, eliminates the booking-request class entirely, because there is no request to answer. Pre-set rules for requests that conflict with your minimum stay or your calendar do the same thing at the other end.
What a holding reply does not achieve. "Thanks for your message, I will get back to you shortly" satisfies the metric and nothing else. The guest enquiring about your flat is typically enquiring about four others in the same twenty minutes, and the host who answers the actual question first is the one who gets the booking. A holding reply protects your percentage while losing the reservation: a clean example of a metric being improved without anything improving. The same trap shows up across guest communication generally, which is why speed and usefulness need separating, as in the real cost of slow responses.
What not to automate. Anything that commits you. Auto-accepting requests you have not read, or auto-quoting a discount, converts a metric problem into a revenue problem.
Usually a Notification Problem, Not an Availability Problem
When a host's response rate drops, the instinct is to promise to be more available. That is almost never the fix, because the missed messages were rarely missed during sleep: they were missed during the two hours the phone was in a bag.
Work through the plumbing first, in this order:
- Check push notifications are actually enabled for the Airbnb app, on the device you carry, with permissions granted at the operating-system level and not silenced by a focus mode. Notification permission quietly resets after some OS updates and app reinstalls. This one cause accounts for a surprising share of sudden drops.
- Add a second channel for the same alert. Email notifications as a backup to push, so a failure in one path is caught by the other.
- Give the account a second pair of eyes. A co-host with their own login and their own notifications covers your driving hours and your flights. This is a permissions change, not a hiring decision.
- Set up the enquiry auto-reply described above so the window is never the binding constraint even when nobody is looking.
- Look at when your misses actually happened. Pull the last three months of enquiries and note the hour of each one you missed. Most operations find a single recurring window (a commute, a school run, a Saturday morning) and a rule that covers that window fixes most of the problem.
Notice that four of those five are configuration, not effort. A response rate is mostly a plumbing metric, and plumbing is fixable in an afternoon.
Honest Limits
The most important limit is the one built into the metric's design: it rewards speed over usefulness. A host who replies to every enquiry in four minutes with a template that answers nothing will show a better figure than a host who takes two hours to write something genuinely helpful. Optimising hard for the number can make you a worse host, and the guest-facing consequences of that show up in reviews rather than in the dashboard: a connection worth reading sceptically in how guest messaging affects review scores.
It is also one input into a ranking system nobody outside Airbnb can see. Any claim about how many positions a percentage point is worth is guesswork, including guesses that sound confident and arrive with a chart.
The thresholds, the windows and the definitions above are described as a shape, not as current terms. I have deliberately not quoted a percentage or a deadline as fact, because they change and a stale number stated confidently is worse than no number. Read Airbnb's current documentation before you act.
And the largest limit for anyone reading this on a Welco page: Welco does not improve your Airbnb response rate. It cannot. It replies only to verified guests whose phone number matches a reservation, and an enquiry is by definition a person who has not booked, has no reservation, and reaches you inside Airbnb's own inbox. That message is yours to answer, with Airbnb's tools or your own attention. Any vendor implying otherwise is either describing a different product or overselling.
What a messaging layer changes is the volume and quality of everything after the booking: the part the response-rate metric was never measuring, and the part guests actually write about.
Where Welco Fits
Welco is a WhatsApp AI assistant for the post-booking conversation: it syncs reservations by iCal from Airbnb, Booking.com, VRBO and Hostaway, answers verified guests in their own language from the house rules, check-in steps and recommendations you load, and escalates the things that need you with an urgency level attached. The pre-booking enquiry stays in Airbnb's inbox, where it belongs, and the wider case for moving the rest of the conversation to a channel guests already use is in the WhatsApp guest communication pillar. Access is by demo request if you want to see how the post-booking half behaves before you change anything.