Open one of your longer guest threads and scroll to the top. There is a phone number in it. A name, a set of dates, a property. And somewhere in the middle, if the stay ran more than two or three nights, there is a line like "my daughter is allergic to nuts, is there anything in the kitchen cupboards" or "we'll be late, my father's discharge from hospital moved to Thursday."
You did not ask for either of those. A guest volunteered them because they were relevant at the time. They are still in the thread, and they will be in the thread in four years unless you decide otherwise. One of them is health information about a child.
This is not legal advice, and it is not a substitute for it. It is an operator's read of what the General Data Protection Regulation asks of someone whose main data-processing activity is answering guest messages. Specifics vary by member state, the rules interact with national tourism and tax law, and if you run at any scale you should be paying someone qualified rather than reading a blog post.
This article covers what is actually in a guest thread, how to say your lawful basis out loud, where stay logistics end and marketing begins, how long a conversation should live, who else holds your guest data, what a deletion request does to a thread, and what changes when an AI is answering.
What Is Actually in a Guest Thread
Start with an inventory, because most hosts have never made one. A typical WhatsApp conversation around one reservation holds the guest's mobile number, their name as they gave it, the property and the dates, arrival and departure times, occasionally a flight number, the access method, and a free-text record of everything that went wrong and how you handled it.
That last part is where it gets awkward. Free text is where guests tell you that one of them uses a wheelchair and needs the ground-floor bedroom, that they are coming for a funeral, that the baby will not sleep through the neighbour's music. None of that was requested on a booking form. All of it is now a record you control.
The regulation treats health, religion, ethnicity and a few other categories with more caution than ordinary contact data, and it does not care that the detail arrived unprompted. You cannot stop guests telling you things. You can control how long you keep the telling, who can read it, and whether it ends up somewhere you never think about: an export, a spreadsheet, a cleaner's group chat.
Lawful Basis, Said Out Loud
The first question a supervisory authority asks is not "did the guest agree." It is "why are you allowed to do this at all." The regulation gives a short list of answers, and for guest messaging three of them cover almost everything.
Contract performance. Sending check-in instructions, the door code, the WiFi password, parking directions and the answer to "is there a hairdryer" is necessary to deliver the stay the guest booked. You do not need consent for it, and asking for it is worse: consent can be withdrawn, and you would still have to send the door code.
Legal obligation. Several member states require hosts to report guest identity details to the police or a tourism registry, and tax law requires you to keep invoices for a set number of years. Where that applies, the basis is legal obligation, the guest cannot opt out, and the retention period is written for you. What you may not do is let data collected for that purpose quietly become your mailing list.
Legitimate interests. Keeping a record of a damage dispute, preventing fraud, protecting the property. This basis is available but it is not a shrug: it asks you to weigh your interest against the guest's and to have written down that you did.
Consent is the fourth, and it belongs to marketing, not to stay logistics. It has to be freely given, specific, informed and as easy to withdraw as it was to give. A pre-ticked box is not consent. "By booking you agree to receive our newsletter" is not consent either, because it was not freely given: the guest wanted the apartment.
Where Stay Logistics End and Marketing Begins
This is the line most hosts cross without noticing. "Your code is 4471, the bins go out Tuesday" is contract performance. "Book direct with us next summer and save ten percent" is marketing, and the fact that you have the number because the guest needed a door code does not entitle you to use it for the second message.
The distinction matters operationally as well as legally. Messaging platforms draw a similar line for their own reasons: WhatsApp separates ongoing service conversations from business-initiated outreach through a time-limited window, and the mechanics are covered in how the 24-hour customer service window works. Those thresholds change, so check current documentation before you build on them.
If you want to market to past guests, collect the permission at a moment when the answer is genuinely free (a checkbox at booking, a line in the guidebook, a question in the post-stay message) and record what they were shown, what they ticked and when. Some member states allow a narrower route for marketing your own similar services to existing customers, drawn differently in different countries. That is exactly the kind of detail you should not take from a blog post.
Retention: Forever Is a Decision You Made by Not Making One
Ask a host how long they keep guest conversations and the honest answer is usually "they're just in WhatsApp." That is a retention policy. It says forever, on a phone, with no review, including the thread where someone described their medication.
The principle is storage limitation: keep personal data in identifiable form no longer than the purpose needs. Only you can set that period, because only you know your purposes. What helps is splitting the record into parts with different clocks.
| What you hold | Why you hold it | Roughly how long |
|---|---|---|
| Invoice and booking record | Tax and accounting law | Set by national law, years |
| Guest registration data | Legal obligation where it applies | Set by that obligation |
| Message thread, ordinary stay | Delivering the stay, answering follow-ups | Months, not years |
| Message thread, active dispute | Evidence for the dispute | Until it is resolved, then deleted |
| Marketing list entry | Consent | Until withdrawn, reviewed periodically |
Those durations are deliberately vague; the real ones come from your accountant and your national law. The structure is the point. A stay record and a conversation are different objects with different justifications, and lumping them together means keeping the most sensitive part longest for no reason.
The dispute row is the one hosts get wrong in both directions. Deleting a thread the week after checkout and then discovering a damage claim leaves you with nothing to show: see how to handle damage claims without torching the review for why the evidence trail matters. Keeping every thread forever because one in two hundred becomes a dispute is the opposite error.
Your Processor Chain Is Longer Than You Think
You are the controller for the guest data you hold: you decided to collect it and what to do with it. Most of the tools you use are processors acting on your instructions, and the regulation expects a written arrangement with each of them covering what they may do, who they pass it to, where it sits and what happens when you leave.
Write the chain down once. For a typical operation: the booking platform, your channel manager or PMS, whatever handles messaging, the AI assistant if you use one, the cleaning tool, the smart lock provider, your accountant, your phone's cloud backup, and the group chat where you forward a guest's number to a cleaner.
Two of those deserve attention. The booking platform is generally not your processor: Airbnb or Booking.com decide their own purposes and share a limited slice of data with you, which makes them a separate controller and makes the handover point interesting rather than covered. WhatsApp is in your chain whichever way you use it: messages pass through Meta's infrastructure, the terms are Meta's to change, and the arrangement differs depending on whether you run the consumer app, the Business app or the Platform API through a provider, as the setup guide for WhatsApp Business sets out. Read the current terms rather than a summary of them, including this one.
The group chat is the uncomfortable one. Forwarding "guest arriving 23:00, +34 6xx xxx xxx, wants late checkout" into a group with four cleaners and a handyman is a disclosure to people you have no written arrangement with, on a channel you do not control, that nobody will ever clean up. It is also completely normal practice. The fix is not to stop coordinating; it is to pass the operational fact without the identifiers where the identifiers are not needed.
What a Deletion Request Actually Means for a Thread
A guest emails three weeks after checkout: "please delete all my data." Here is the honest version of what happens next.
First, satisfy yourself it is them, without demanding a passport scan you would then have to store. Second, find every place their data lives: the chain you wrote down above, which is why writing it down was worth doing. Third, separate what must stay from what can go: an invoice you are legally required to retain stays, a registration filing stays, an unresolved dispute record stays, the rest goes. Fourth, reply within the regulation's default window of one month, and say plainly what you deleted, what you kept and why.
Erasure is a right with exceptions, not a switch. "I have deleted your conversation and your contact details; your invoice is retained for X years because tax law requires it" is a complete and correct answer. Saying nothing is not.
The mechanical part is messier than the legal part. A WhatsApp thread is a two-sided object: you can delete your copy, you cannot delete theirs, and a deleted thread may still exist in a phone backup, in a CSV you exported last quarter, in a screenshot you sent your co-host. Honouring the request means knowing about all of those, which is the second reason the chain list exists.
Access requests work in reverse: a guest can ask for a copy of what you hold, and a thread export plus their booking record is usually the whole answer. Neither is common for a small operation, and both are far less painful when you have not kept everything forever.
What Changes When an AI Is in the Loop
An assistant in front of your guest messages does not change your lawful basis: answering a WiFi question is contract performance whether a person or a model does it. What changes is the surface area. Four questions are worth asking any vendor before you connect one.
Where does the text go, and who processes it. The assistant vendor is a processor; the model provider behind it is usually a sub-processor. You are entitled to the list, and to be told when it changes.
Is your guest conversation used to train anything. Business tiers of the major model providers have generally committed not to train on customer content, but that is a terms question, it has moved before, and it is yours to verify rather than assume.
What is retained, and for how long. An assistant that stores every message so it can answer "what did the guest say about the heating" is doing something useful and is also lengthening the life of the most sensitive text you hold. Your retention decision now governs a larger pile.
What is it allowed to decide. Automatically approving a late checkout, declining an extension or triggering a fee is a decision with a real effect on the guest, and the regulation is more interested in decisions made solely by a machine than in a machine handing you a draft. Keep a person on anything that costs the guest money or access.
There is also a transparency point: tell guests they are talking to an assistant and how to reach a human. EU rules on AI disclosure are arriving on their own timetable and you should check where they stand when you read this, but the operational reason is that guests dislike discovering it later, and the thread where they discover it is the thread that ends up in the review.
Honest Limits
A compliant messaging setup is mostly paperwork and one retention decision. It is a privacy notice a guest can actually find, a written list of who processes what, a lawful basis you can say out loud for each thing you send, a retention period you chose on purpose, and a process for the day someone asks you to delete them. None of that is software, and no tool can make you compliant on its own: a vendor telling you they are GDPR compliant is describing their own house, not yours.
That includes Welco. Where an assistant handles your guest messages it acts as a processor, and the useful questions are the four in the section above. The record of processing, the privacy notice, the retention policy, the lawful basis and the answer you send to an erasure request remain yours. Any vendor who implies otherwise is selling something that does not exist.
Two more limits. First, the framework applies across the EEA, but the parts you will actually trip over (marketing rules, registration obligations, tax retention) are national, and a host operating in three countries has three sets of details. Second, doing all of this correctly protects you from a data problem. It does not protect you from an angry guest, a platform dispute or a bad review.
If you are running more than a handful of properties, employ staff, operate across borders, or handle anything about guests beyond ordinary contact detail, get advice from someone who will put their name on it.
Where Welco Sits
Welco is a WhatsApp AI assistant for vacation rental hosts: guests message from their own WhatsApp, it replies only to verified guests whose number matches a reservation, and escalations reach you with an urgency level. It is one processor in the chain above, not a compliance product, and the retention and lawful-basis decisions stay on your side of the line. For the surrounding context, see running guest communication on WhatsApp and how guest experience automation fits together. If you want to know exactly what it holds and what it sends, request a demo and ask the processor questions directly.