It is 23:47. The guest landed forty minutes ago and is standing outside a building they have never seen, in a street where the numbers skip. Their phone shows no data: the roaming did not activate, or they declined it because of what it cost them last time in Croatia.
The door code went out at 16:10 in a WhatsApp message, delivered while they still had airport WiFi. It also went out in the booking confirmation email, which they have not opened since the day they booked. Whether the next ten minutes involve a phone call to you depends entirely on which of those the guest can reach right now, standing on a pavement with one bar of GSM signal and no data.
That is the whole argument for thinking about channels separately. WhatsApp, SMS and email are not three ways of doing the same thing with different logos. They fail differently, they get read at different speeds, and they leave behind different amounts of evidence. Most hosts either pick one and use it for everything, or run all three badly.
This article compares them on the properties that actually differ, assigns each type of message to the channel that fits its job, and is honest about the fourth channel you do not get to opt out of.
What Actually Differs Between the Three
Forget "modern" and "personal". Seven properties decide which channel a message should go on.
Whether it arrives at all. WhatsApp needs data at both ends and an account on the guest's side. SMS needs only carrier signal, which exists in places and situations where data does not. Email arrives almost always, but into a mailbox with filters between it and the reader.
Whether it is read, and how fast. WhatsApp and SMS land on a lock screen and are typically read within minutes. Email is read in hours or days, and holiday email is read less than that.
What happens when the guest replies. A WhatsApp reply lands in a thread you can answer from. An SMS reply lands wherever your sending route sends it, which for many bulk-SMS setups is nowhere useful. An email reply often lands in a no-reply address by design.
Cost shape. Email is effectively free per message. SMS is priced per message and varies sharply by destination country. WhatsApp business messaging is priced on a different model again, built around message categories and reply windows, and both the categories and the pricing have changed more than once: treat any specific figure you read as out of date and check the current terms.
Whether it crosses a border cleanly. WhatsApp rides over data, so a message to a guest in another country costs you what any other message costs. SMS has per-country pricing, sender-ID registration rules that differ by market, and delivery behaviour that is genuinely inconsistent internationally. Verify for the countries your guests actually come from.
Whether it carries a photo or a document. WhatsApp handles photos, PDFs and voice notes, which matters when the answer is a picture of which switch on the fuse box. SMS is text in practice. Email carries anything, and nobody opens it standing in a hallway.
Whether you can find it later. Email is searchable by both sides years afterwards. A WhatsApp thread is searchable if you still have access to the account it lives in. SMS is the worst record of the three.
The Comparison, Side by Side
| Criterion | SMS | ||
|---|---|---|---|
| Needs to arrive | Data plus an account on both ends | Carrier signal only | Almost always arrives, into filters |
| Typically read within | Minutes | Minutes | Hours to days |
| Reply path | A real two-way thread | Only if the route is set up for it | Often a no-reply address |
| Cost shape | Per conversation or category; check current terms | Per message, varies by country | Effectively free per message |
| Across borders | Rides on data, no international surcharge | Per-country pricing and rules | Unaffected |
| Photos and documents | Yes, plus voice notes | Text in practice | Yes, but read late |
| Findable in three weeks | If you still have the account | Rarely | Yes, by both sides |
| The job it is best at | The live conversation | The message that must arrive | The document to retrieve |
The last row is the one to read twice. Each channel is genuinely good at something the others are bad at, which is why the sensible setup is not "pick the best one" but "give each one the job it is good at".
Match the Message to the Channel
Work down the list of things you actually send, and the assignment is mostly obvious once the criterion is stated.
The booking confirmation, the address, the invoice, the cancellation terms: email. These are documents, not notifications. The test is whether the guest will need to retrieve it in three weeks, possibly to forward it to whoever is paying or to find the street name at an airport taxi rank. Email is a filing cabinet with a search box, and nothing else here is.
The door code and access instructions: the channel the guest has open at 23:00, with a fallback. This is the message that must arrive, so it is the one to send redundantly on purpose: the full instructions with photos in the conversational channel, and the code plus the street number as plain text somewhere it survives no data. Do not let the code exist only inside a PDF attached to an email.
"Your taxi is outside", "the water is off until noon", "the cleaner needs ten more minutes": wherever it will be read in ninety seconds. These have a short shelf life; a notification read at 18:00 about a taxi that arrived at 09:40 is worse than nothing, because it teaches the guest your messages are not current.
A question the guest asked: the channel they asked it in. Answering an email with a WhatsApp message, or the reverse, splits a conversation across two systems and guarantees that one of you loses half of it.
An offer: the channel already open, and only at the right moment. Which moments those are is a discipline of its own, covered in offering in-stay upsells without turning the stay into a funnel. An offer sent to a channel the guest reads next Tuesday is not an offer.
Anything you might need in a dispute: a channel with a record. Photographs of a damaged sofa and the exchange around it belong somewhere retrievable months later, which usually means email, or a summary written into the booking platform's own thread.
SMS Is What Works When the Data Does Not
SMS gets written off as the old channel, and that judgement misses the single property that makes it valuable: it does not need data. Every scenario where your guest communication matters most is a scenario where data is least reliable.
The guest who has just landed and has not sorted roaming. The guest whose prepaid data ran out on day three. The rural property in a valley with one bar of GSM and no usable mobile data. The guest who does not have WhatsApp at all, which in some markets is a large share of arrivals and in others is almost nobody: this varies enormously by country and you should check your own guest list rather than assume.
For that reason SMS earns a narrow, permanent job: the access fallback. One message, under 160 characters, containing the street number, the door code and your phone number. Sent shortly before arrival, in addition to the real instructions rather than instead of them.
The honest costs of keeping SMS in the mix: you pay per message and international rates are not trivial; sender-ID and registration requirements vary by country and change, so what worked last year may not send this year; replies come back to a route you must actually monitor, or the guest is texting into a void; and you cannot send a photo, so a troubleshooting answer becomes a link. Those are all tolerable for one short message per arrival. They are not tolerable as the basis of a whole guest communication setup.
Email Is a Filing Cabinet, Not a Notification
The mistake in the other direction is sending time-sensitive information by email because it is free and you already have the address.
Email's strengths are real and specific: it holds long-form content, it carries attachments, it is forwardable to the person who is actually paying, and it is searchable by both sides long after the stay. For confirmations, invoices, pre-arrival packs and anything a guest may need to produce later, nothing else comes close.
Its weakness is equally specific: you do not control whether it is read, or when. It can land in a promotions tab or a spam folder, and a guest on holiday is not checking the address they gave you at booking. If the consequence of a message going unread for two days is a guest standing outside a locked door, email is the wrong channel regardless of how well written it is.
The Fourth Channel You Do Not Get to Opt Out Of
Any comparison of three channels is incomplete, because there is a fourth one you did not choose: the booking platform's own inbox.
Pre-booking enquiries generally have to stay there: platforms restrict moving a conversation off-platform before a booking is confirmed, and those rules are enforced with varying strictness and change over time. The platform's response metrics are calculated from that thread: Airbnb, for instance, measures how quickly and how consistently a host replies inside its own messaging, and the exact windows and thresholds are the platform's to change, so check its current documentation rather than a blog post. A host who has moved every real conversation to WhatsApp can still be scored on an inbox they have stopped reading.
The dispute process reads that thread too. If a claim is assessed, the platform reads what is in its own system, not your WhatsApp history.
The practical consequence is a rule rather than a choice: keep answering in the platform inbox, even when the substance of the conversation has moved elsewhere, and write a one-line summary back into it whenever something material was agreed off-platform. The case for still moving the live conversation to WhatsApp after booking is made in why WhatsApp works as the default guest channel, and the platform inbox is the reason that argument is "as well as", not "instead of".
Running More Than One Without Running Them Badly
Multi-channel is not free. Every channel you add is another place someone has to look, and the failure mode is a guest waiting four hours in the one inbox nobody opened.
A few rules keep it manageable:
- Write the assignment down once. One page: which message type goes on which channel, and what the access fallback is. Without it, each person answers wherever they personally prefer.
- Reply where the guest wrote. Never migrate a conversation mid-thread because another channel is more convenient for you.
- Deliberate redundancy only. Access details are the one thing worth sending twice. Everything else sent twice reads as noise and trains the guest to ignore both copies.
- One monitoring surface, or one person per channel. If nobody can say who is watching SMS replies this week, you are not running SMS, you are paying for it.
- If you can only do one properly, do the one your guests are on. A single channel answered in ten minutes beats three channels answered in four hours, and it is not close.
If you are moving between tools and deciding which channels come across, that decision deserves its own plan; switching guest communication tools mid-season covers the sequence that does not drop a guest in the process.
Where This Breaks
Multi-channel means multi-place-to-look, and most hosts underestimate that cost. Three channels run badly is a worse guest experience than one run well. If adding a channel does not come with a named person and a defined monitoring habit, adding it makes your operation worse, not more accessible.
"One channel" is already two. The platform inbox does not go away, so the realistic minimum is your chosen channel plus the platform's, and any advice that ignores this is describing an operation that does not exist.
Channel mix is a geography question, not a best-practice question. Which channel your guests actually use depends on where they come from, and the differences between markets are large. Check your own arrivals list for the last year before taking any recommendation, including the ones above, as applying to you.
Deliverability is not yours to control. A guest can have no data, a full mailbox, an aggressive spam filter, a number that rejects unknown senders, or simply no WhatsApp account. Design for the message failing rather than assuming it arrived, which is the entire reason the access fallback exists.
The mechanics underneath all three keep changing. Business messaging pricing and categories, template rules, per-country SMS registration, platform off-platform-contact policies: all of these have moved in recent years and will move again. Anything in this article that sounds like a current fact about a third party should be checked against that company's current documentation before you build a process on it.
And about Welco specifically. Welco is WhatsApp only. It is not an SMS gateway, it does not send your booking confirmations, and it does not read or reply inside your Airbnb or Booking.com inbox. It answers verified guests (a phone number matched to a reservation) in their own language, from what you have loaded, and escalates what needs you. If your guests are not on WhatsApp, it is the wrong tool, and no amount of feature list changes that. Choosing between categories of tool, rather than between channels, is the subject of how to choose a guest communication platform.
The Operational Picture
Three channels, three jobs: email for what must be retrievable, SMS for what must arrive, WhatsApp for the conversation that actually happens during the stay, with the platform inbox still answered because the platform is scoring it. Assign each message type once, write it down, and the daily decision disappears. For the wider case on running the live conversation over WhatsApp, the guide to WhatsApp for vacation rental guest communication is the full picture.
Welco is a WhatsApp AI assistant for vacation rental hosts: guests message from their own WhatsApp with nothing to install, reservations sync by iCal, and the questions it cannot answer are escalated to you rather than guessed at. Access is currently by demo request, and a demo is the right place to work out whether WhatsApp is genuinely where your guests are.