Guest Contact Data You Collect Yourself: Consent and Fallback

When a channel stops passing a phone number, the answer is not a workaround. It is a consent step at booking and a fallback chain that keeps the arrival call possible.

Last updated: November 2, 2026

The phone number used to arrive on its own. You opened a booking, saw a mobile, and saved it under the guest's first name. Then a channel changed that, and a workflow built on it quietly broke. The workaround most people reach for, asking the guest to message a number off-platform, is the one that causes trouble. The durable answer is duller: ask at booking, record the answer, and build a chain that works when nobody answers.

Key Takeaways

• The number isn't the requirement. The arrival call is. A phone number is one route to it, and there are others.
• Consent is a record, not a tick. What you asked, when, on which channel, and what the guest said.
• Four links, in order. Thread, then the number the guest gave, then a landmark, then the building.
• One purpose per permission. Contact for arrival isn't contact for next year's newsletter.
• Delete on a schedule, not on a feeling. The record should shrink without anyone remembering to shrink it.

Why platforms stop passing numbers

Booking.com stopped passing guest phone numbers to accommodation providers from 28 September 2026, as reported by eHotelier. The direction of that change isn't new; it's the same move platforms have been making for years, and the reasoning is consistent. A booking platform sits between a guest and a host, and every detail it passes across that gap is a detail it no longer controls.

Two forces push the same way. Guests expect their details to travel no further than the booking requires. Platforms would rather the conversation stayed where they can see it, because a conversation is a reason to book again. Neither force is about you, and both land on your arrival plan.

What changes is narrower than it sounds. You still get a name, the dates, the party size and usually the language. What you lose is the thing you used at eleven at night when the gate code didn't work. A host who built three years of arrivals on a phone number now has a workflow with a hole in it, and the hole shows up on the night a guest can't find the entrance.

The tempting fix is to ask the guest, in the thread, to message you somewhere else. Read the platform's terms before you do that, because several restrict exactly this, and a restriction enforced against a listing costs more than the call you were trying to make. The rest of this article is about the version that doesn't depend on moving the conversation.

What consent looks like in practice

Consent here is a small piece of paperwork that takes fifteen seconds and answers four questions: what you asked, when, where the guest answered, and what they said.

The asking is one message, at booking, in plain words. "I'd like a mobile number so I can reach you if anything goes wrong on arrival. I'll delete it after you check out. Is that all right?" That sentence does four things at once. It names the purpose, which is arrival. It names the retention period, which is the stay. It makes the answer easy to give or refuse. And it doesn't hide inside a booking confirmation that the guest will scroll past.

Then write the answer down where the reservation lives. Four fields: asked on, asked in, answer, and what the number is for. If the guest says yes in the thread, the thread is the record, and a line in the reservation notes pointing at it is enough. If the guest says no, that's also a record, and it's the more important one, because it's the one you'll be tempted to forget.

Keep purposes apart. Permission to call about a door code isn't permission to send a newsletter, and a guest who agreed to the first will be surprised by the second. If you want both, ask twice and record two answers.

One more thing belongs in the record, and it's the field everybody skips: where the number came from. A number the guest typed into a thread, a number on a booking confirmation and a number you found elsewhere are three different things, and only the first two are yours to use.

A fallback chain that stays inside the rules

The point of a fallback chain is that the arrival works without any single link. Four links, in this order, each one written into the arrival message so the guest knows what to expect.

Link one: the platform thread. It's the only channel both of you are certainly on, and the one the platform wants you to use. Everything that can be said there should be: the address, the entrance, the floor, the code, the name on the bell. A guest with all of that in one message doesn't need to call anybody.

Link two: the number the guest gave you. Used for the specific purpose it was given for, by the person it was given to. That last part matters more than hosts expect, because a number passed to a cleaner who wasn't part of the conversation is a different use of it.

Link three: a landmark. This is the link that saves the evening, and it costs nothing. Not the street address, which the taxi already has, but the thing a person can see: the blue door beside the pharmacy, the entrance behind the bus shelter, the third gate past the corner shop. A landmark works in any language and survives a dead battery.

Link four: the building itself. A concierge, a neighbour with a key, a lockbox whose code was already sent in the thread. This is the link that works when the guest's phone is off, and it's the reason a smart lock with a backup code beats a phone call every time.

Two details make the chain hold. The arrival message goes out in the guest's language where you can manage it, and that's a real constraint rather than a nice-to-have. In LOCALSBNB the language follows the store across six languages, English, simplified and traditional Chinese, Japanese, Thai and Malay, with Korean not yet available and English as the fallback. A Korean guest therefore gets the English message, which is fine if the message is short and the landmark is concrete, and it's the reason link three carries more weight than it looks like it should.

The second detail is that the chain is written down before the first arrival, not assembled during one. localsbnb.com keeps the four channels on one calendar and its inbox covers Airbnb conversations only, so a guest who booked elsewhere is answered in that platform's thread. Knowing which thread you're in, on the night, is half of the chain working.

Storing less than you collect

The cheapest way to protect a piece of data is not to have it. The second cheapest is to have it for a defined period and then lose it on purpose.

Start with a retention rule you can state in a sentence: the number is deleted when the stay closes and the record of the stay closes with it. For most hosts that means shortly after checkout, plus whatever window you genuinely need for a payment question. Write that window down beside the consent record, and put the sweep in the calendar rather than in your memory.

Then reduce what's held. A first name and a mobile, in one place, is enough for an arrival call. A copy of a passport, a photo of an ID, a screenshot of a booking page with the guest's card details visible: those get collected far more often than they're needed. Each one is a thing you'll have to delete later.

Where the detail sits matters too. Guest names, phone numbers and ID numbers are masked in LOCALSBNB, and the credentials that reach your store data are held locally rather than in a shared pool. That's the shape worth aiming for: the sensitive field masked by default, and the person who can unmask it named.

Two habits finish the job. Keep the number out of group chats, because a message forwarded to five people can't be recalled from any of them. And when a stay ends, delete the number before the review request goes out, not after.

FAQ

Can I ask a guest for a phone number at booking?

You can ask. Whether it's allowed depends on the platform's terms and the rules where you operate, which differ by place. Ask for one purpose, say how long you'll keep it, record the answer, and check the terms before the request becomes part of your standard message.

How long should I keep a guest's number?

As long as the reason you collected it lasts, and no longer. For an arrival call that means the stay, plus a short window if you need it for a payment question. Decide the window in advance, write it beside the consent record, and delete on a date rather than on a memory.

What if the guest won't give a number?

Then the chain carries the arrival, which is why it has four links. The thread holds the address, the code and the landmark; the building holds the last resort. A guest who declines a number would rather keep the conversation on the platform, and that's worth respecting.

Ask once, write it down, and let the chain do the work. localsbnb.com is where the four channels write to one calendar, and where the guest details you do hold are masked by default rather than sitting in plain view.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. Rules on collecting and keeping guest contact details differ by place, and platform terms on messaging change. Confirm the current requirements with the competent authority and the current terms of each platform you use before you act.