The pre-arrival email goes out three days before the stay. It has the address, the door code, the WiFi password, and a line at the top: download our guest app for everything you need. At 23:10, in a taxi from the airport with one bar of roaming data, the guest opens that email, sees the app link, decides they will do it later, scrolls for the door code, cannot find it under the app pitch, and messages you instead.
That scene is the whole argument against guest apps, and on its own it is unfair. A well-built guest app does several things a chat thread cannot do at all, and hosts who dismiss the category because of one bad arrival are throwing away capability they may actually need.
The honest version of this decision is not app versus messaging. It is a set of five jobs (pre-arrival information, in-stay questions, upsells, local recommendations, post-stay) where the two channels have genuinely different strengths, and where one of them wins outright.
What a Dedicated Guest App Genuinely Does Better
Start with the case for the app, because it is stronger than the messaging vendors admit.
Structure. A chat thread is linear and disposable. A guidebook in an app has sections, photos, a map, a search box, and a stable place where the bin collection day lives forever. A guest looking for the induction hob instructions can find them without scrolling past four days of conversation about towels.
Payment. If you sell early check-in, a mid-stay clean, an airport transfer or a parking space, an app can hold the whole transaction: see the option, see the price, pay, get the confirmation. A message thread can start that conversation and agree it, but it usually hands off to a payment link somewhere else, and every hand-off loses people.
Analytics. This is the real one. An app can tell you what share of arrivals opened the parking page, how many guests looked at the late-checkout upsell and how many bought it, and that nobody at all opened the section on the boiler. A chat thread tells you what people asked, which is a narrower and different signal: useful, but not behavioural. If you want the messaging equivalent, it exists and it is worth tracking, but it is a smaller set of numbers than an app's dashboard: the four that actually mean something are in the guest communication metrics worth measuring.
Offline access and consistency. Content downloaded before arrival survives a basement flat with no signal. And for a manager running thirty units, an app gives one surface with versioned content rather than thirty slightly different message templates that drifted apart over two seasons.
None of that is marketing. Those are real capabilities, and if they map onto a real problem in your operation, the app case is serious.
Adoption Is the Number App Vendors Are Quietest About
Now the counterweight. Every one of those capabilities is conditional on the guest installing the thing.
Count the steps between your email and a guest reading your guidebook in an app. See the prompt. Decide it is worth the effort. Open the store. Download over roaming data or airport WiFi. Create an account, or find and type a booking reference. Land somewhere that is not the page they wanted. Six steps, each of which a tired traveller can decline, and declining costs them nothing because they already have your phone number.
Ask any app vendor for their adoption rate and watch what happens. You will get a feature list quickly and a number slowly, if at all. When you do get one, ask how it is defined: a tap on the link, an account created, or a guest who opened the app at least once during the stay are three very different numbers, and the first one is not adoption in any sense that matters.
I am not going to give you an industry figure, because I do not have one I can defend and nor, usually, does the deck you are being shown. What you can do is measure your own: of your last fifty reservations, how many guests opened the app at all? Your vendor can answer that. If they cannot, that is itself the answer.
There is also a selection effect nobody mentions. The guests who install are the organised ones who read the email, plan ahead and ask fewer questions anyway. The ones who do not install are the ones who arrive at 23:10 and message you. Your app serves the guests who were never going to be the problem.
Pre-Arrival Information: The App's Best Case
Pre-arrival is where an app's structure is most useful and its install step is most expensive, because the same window contains both the richest content and the least patient guest.
Split the job in two. There are perhaps five facts that must arrive no matter what: the address, how to get in, when, where to park, and how to reach a human. Those belong in the channel the guest is already reading, as text, with no link to open and nothing to install. Everything else (the neighbourhood notes, the appliance photos, the bin day, the thirty-page depth) belongs behind a link, and the app can hold it beautifully.
The failure mode is putting the critical five behind the install. A guest who cannot find the door code without downloading something does not download something; they message you, or they call, or they stand outside and their review starts writing itself.
Verdict: the thread wins the five critical facts. The app wins the depth, provided it was installed days earlier in a calm moment rather than in the taxi.
In-Stay Questions: The Thread Wins, and It Is Not Close
A guest is standing in front of a dishwasher with an unfamiliar symbol flashing. In an app, they need to know what to search for: is this under Appliances, Kitchen, or Troubleshooting? In a thread, they photograph it and send it.
That asymmetry runs through the whole in-stay period. Questions arrive as questions, not as browsing intent. They arrive at inconvenient hours, in the guest's own language, sometimes as a voice note from someone who did not want to type. The channel that answers them best requires no navigation and no memory of where the information was filed.
This is where the sharp version of the argument lives: a guidebook nobody opens is worth less than a mediocre answer that arrives in the thread the guest is already reading. A perfect page on the water pressure quirk, structured and photographed and never opened, resolves nothing. A slightly clumsy answer delivered in ninety seconds resolves the stay.
Verdict: the thread wins, and the gap is large.
Upsells: Where the App Wins Outright
Here the concession is unambiguous. If your upsell revenue is real (early check-in, late checkout, mid-stay cleans, transfers, a stocked fridge, a cot), an app holds a transaction end to end in a way a chat thread does not.
The mechanics matter. In an app, the guest sees the option at the moment they are thinking about it, sees the price without asking, and pays in the same surface. In a thread, the ask is easy and the agreement is easy, but the payment is a hand-off: a link, a different site, a card entry on a phone in a foreign country. Each hand-off loses a share of people who had already said yes.
An app also lets you merchandise without asking. A late-checkout tile that sits there quietly is not a message; it does not interrupt, and it does not read as pushy on the third day of a stay. Doing the same thing in a thread requires sending something, and sending something has a cost.
If you run a portfolio of serviced apartments where paid extras are a meaningful line rather than a rounding error, this single job can justify an app on its own. Be honest about the arithmetic, though: the app's cost is paid on every property whether or not guests install it, so the question is revenue per install, not the install count.
Welco does not close this gap. It stops at the conversation: it does not take payments, and it will not process a card for a late checkout.
Local Recommendations: A Split Decision
Recommendations split by mode. Browsing and asking are different activities, and each channel owns one.
A guest on the sofa at 21:00 planning tomorrow is browsing. They want a map, photos, categories, and the ability to scroll. That is an app or a web guidebook, and a thread is a poor substitute: nobody wants twelve restaurants pasted into a chat.
A guest asking "where do we eat tonight, it is raining and we have a toddler" is not browsing. That is a question with three constraints, and it wants an answer, not a list. The thread wins that outright, and it wins it at the moment when a recommendation is most likely to convert into a booking you might earn something from.
Tracking is where it gets interesting for anyone monetising this. An app measures taps, which feels like measurement. What it does not measure is whether the guest walked in, and the only party who knows that is the partner. If you are building referral income on top of recommendations, the app's analytics are a proxy and the restaurant's count is the fact: a distinction worth reading properly in the guidebook as an untapped revenue stream.
Verdict: the app wins browsing, the thread wins asking, and most operations need both.
Post-Stay: Neither Channel Is Good
Post-stay is where both channels are weak and the app is weaker.
Guests delete apps within days of a trip ending, sometimes on the flight home. A push notification after checkout is an interruption from software they no longer have a reason to keep. Whatever you planned to do after the stay (a review nudge, a direct-booking offer, a feedback question), the app is usually gone before you send it.
The thread survives by default; a phone number does not get uninstalled. But this is where you should be most careful. Messaging someone after their stay about future offers is marketing, not service, and the rules depend on where the guest lives, what consent you captured, and the policies of the platform you used. Check your obligations before building a post-stay campaign on a service channel.
Verdict: the thread wins by default, weakly, and with the most caveats of any job here.
The Scorecard, and the Middle Path
Pulling the five jobs together:
| Job | Guest app | Messaging thread | Which wins |
|---|---|---|---|
| Pre-arrival: the critical five facts | Strong content, gated by install | Arrives without any action | Thread |
| Pre-arrival: depth and structure | Sections, photos, offline | Linear and easily lost | App |
| In-stay questions | Requires the guest to navigate | Photo, voice note, answer | Thread, clearly |
| Upsells with payment | End-to-end transaction | Agreement, then a hand-off | App, outright |
| Recommendations: browsing | Map, categories, photos | Poor fit | App |
| Recommendations: asking in the moment | Wrong shape for a question | Answers a constrained question | Thread |
| Post-stay | Usually deleted | Survives, with consent limits | Thread, weakly |
Read down that table and the middle path suggests itself. Most of the app's content advantages (structure, photos, a map, categories, translation) do not require an install. A web guidebook link delivers them, opens in a browser in one tap, and can carry a payment link.
What the link gives up is genuine: push notifications, offline access, and the per-guest behavioural analytics that an installed app collects as a matter of course. If those three are not load-bearing in your operation, the link version wins on cost and on the fact that everyone opens it. If they are, you are back to a real app decision, and that decision deserves the same scrutiny as any other tool purchase: the criteria are in how to choose a guest communication platform.
Honest Limits
This is a trade, not a verdict, and several things could move it for you.
A portfolio of serviced apartments with genuine upsell revenue may well justify an app, and the argument above says so. If paid extras are a real line in your P&L, the payment and merchandising advantages are not marginal, and the install friction is a cost you can afford to pay.
The install objection also weakens when guests repeat. A corporate-stay operator whose guests return eight times a year pays the install cost once and amortises it across every stay after that. The tired-traveller scenario is a first-stay problem.
Messaging has its own version of the adoption problem, and it is the one to be sceptical about here: Welco's answer is only better if the guest actually messages. A guest who never opens the thread gets exactly as much from an assistant as they get from a guidebook they never opened, which is nothing. Neither channel reaches a guest who does not engage with either.
"Meet them where they are" is also a principle rather than a specific app. WhatsApp dominates in much of Europe, Latin America and South Asia, and does not dominate everywhere. If your guests are mostly domestic North American travellers, the channel they are already in may be SMS or iMessage, and the same reasoning applies to a different pipe.
I have deliberately given you no adoption percentage, conversion lift or message-volume reduction. I have no measured numbers for any of them, and an invented one is worth less than the argument it props up. Anything a vendor shows you on either side should arrive with its definition and its sample size.
Finally, the category boundaries matter. Welco is not a property management system: no channel manager, no pricing, no smart locks, no payments. If your upsell needs a card taken, something else in your stack has to take it.
Where Welco Fits
Welco is a WhatsApp AI assistant for vacation rental hosts and property managers, which is a deliberate position on exactly this trade: guests message from their own WhatsApp, and there is nothing to install. It syncs reservations by iCal from Airbnb, Booking.com, VRBO or Hostaway, answers only verified guests in 30-plus languages from the house rules, check-in steps and recommendations you load, generates a guidebook as a web link and a PDF for the depth that does not belong in a thread, and escalates to you rather than guessing when it cannot help. Access is by demo request, and the fair test is how much of your guest volume in your markets is reachable by message at all: that wider picture sits in guest experience automation.