---
title: "Booking.com deelt geen telefoonnummers van gasten meer. En nu?"
description: "Sinds 28 september 2026 stuurt Booking.com geen telefoonnummers van gasten meer naar PMS'en en channel managers. Zo bouw je een pre-stay die ze niet nodig heeft."
url: "https://www.holidayhero.com/nl/blog/pre-stay-in-eigen-hand-booking-com-telefoonnummer-gast"
published: "2026-10-06T14:40:00+00:00"
updated: "2026-10-06T14:40:57+00:00"
author: "Hjalte Niehorster"
---

# De pre-stay in eigen hand: wat de telefoonnummerwijziging van Booking.com echt blootlegt

> Sinds 28 september 2026 geeft Booking.com telefoonnummers van gasten niet meer door aan PMS'en en channel managers. Het ontbrekende veld is niet het probleem. De afhankelijkheid wel.

Het is 1 uur 's nachts. Je gast staat met een koffer voor de deur. De deurcode zou per sms komen. Die kwam niet, want er was geen nummer om hem naartoe te sturen. De receptie sloot om elf uur. De review is al half geschreven voordat ze ergens anders een bed hebben gevonden.

Sinds 28 september 2026 is dat scenario niet meer hypothetisch voor accommodaties die via een PMS of channel manager op Booking.com verkopen. Toch is het ontbrekende telefoonnummer niet het eigenlijke verhaal. Het verhaal is hoeveel van de gastreis er stilletjes op leunde.

## Wat er veranderd is, en waarom

Booking.com stuurt telefoonnummers van gasten niet meer door naar connectivity-aanbieders: de channel managers en property management systemen waarmee de meeste hotels en verhuurders hun reserveringen ontvangen. Het nummer bestaat nog wel. Je ziet het in het Booking.com Extranet en in de Pulse-app. Het komt alleen niet meer in je andere systemen terecht.

In de praktijk zijn twee details belangrijk:

- Het geldt voor nieuwe reserveringen vanaf 28 september, maar ook voor oudere reserveringen die na die datum worden gewijzigd. De wijziging komt binnen zonder nummer.
- Berichten via Booking.com en het gemaskeerde e-mailadres van de gast blijven gewoon werken.

De opgegeven reden is fraude. Booking.com ziet steeds meer nep-WhatsApp- en sms-berichten aan reizigers, vaak uit naam van de accommodatie en met een verzoek om betaalgegevens. Hoe minder systemen het nummer hebben, hoe minder plekken waar het kan uitlekken. Nadat Booking.com eerder dit jaar klanten waarschuwde voor mogelijk ongeautoriseerde toegang tot reserveringsgegevens, valt moeilijk vol te houden dat het motief niet echt is.

Dit is dus geen stuk over OTA's die zich misdragen. Het gaat over wat de wijziging blootlegde.

## Waarom één veld zoveel kapotmaakte

Toen de branche hierover discussieerde op LinkedIn ([de samenvatting van Danica Smith](https://www.linkedin.com/feed/update/urn:li:activity:7511485989618479105/) is het lezen waard), viel niet op hoeveel mensen zich ergerden. Wat opviel, was hoeveel verschillende dingen afhankelijk bleken van één enkel veld:

- WhatsApp- en sms-berichten vóór aankomst
- Deurcodes en digitale sleutels per sms
- Upsell-reeksen die vóór aankomst worden verstuurd
- Een terugkerende gast herkennen en aan zijn profiel koppelen

Niets hiervan was ontworpen rond "de data van de OTA". Het was ontworpen rond "het telefoonnummer van de gast", en niemand merkte dat dat hetzelfde was, tot een van de twee verdween.

Dat is het echte risico. Als een partner één veld kan uitzetten en je aankomstproces stopt met werken, dan was dat proces niet van jou. Je huurde het.

## De deurcodetest van 1 uur 's nachts

Een simpele maatstaf. Neem een gast die vandaag via Booking.com boekt, zonder telefoonnummer in je systemen. Kan die gast, zonder dat iemand iets moet opzoeken in het Extranet:

1. zijn aankomstinformatie ontvangen,
2. vóór aankomst inchecken, en
3. om 1 uur 's nachts het gebouw in?

Is het eerlijke antwoord op een van deze vragen "dan moet iemand ingrijpen", dan is je pre-stay niet robuust. En als het misgaat, komt de slechte review bij jouw accommodatie terecht, niet bij het platform dat de regels veranderde.

## Hoe een robuuste pre-stay eruitziet

De oplossing is geen slimmere manier om het telefoonnummer terug te halen. Het is een gastreis die het nummer nooit nodig had.

**Begin met een kanaal dat altijd werkt.** Bij elke Booking.com-reservering hoort een manier om de gast te bereiken: berichten via Booking.com en het gemaskeerde e-mailadres. Maak dat het eerste contactmoment voor elke boeking, met een link naar online inchecken. WhatsApp kan later komen. Het hoort niet het fundament te zijn.

**Maak van inchecken het moment waarop je je eigen gegevens verzamelt.** Bij online inchecken geeft de gast zijn gegevens rechtstreeks aan jou: telefoonnummer, e-mail, aankomsttijd en toestemming om benaderd te worden via het kanaal dat hij zelf kiest. Die gegevens zijn van jou, verzameld op een rechtmatige grondslag, in je eigen systeem. Ze hangen niet af van wat een OTA wel of niet doorgeeft, en het is dezelfde flow voor directe boekingen, Airbnb en Booking.com.

**Lever sleutels binnen de gastreis, niet per sms.** Deurcodes en mobiele sleutels horen pas vrij te komen als het inchecken is afgerond, in de bevestiging of het gastportaal, en niet per sms naar het nummer dat toevallig met de reservering meekwam. Het is ook veiliger: de sleutel gaat naar een gast die daadwerkelijk heeft ingecheckt.

**Behandel WhatsApp als opt-in, niet als vanzelfsprekendheid.** Veel gasten hebben nog altijd de voorkeur voor WhatsApp. Het verschil is dat de gast je zelf het nummer geeft en toestemming geeft, op je eigen zakelijke nummer, in plaats van dat jij een nummer appt dat een OTA toevallig doorgaf.

**Herken gasten aan meer dan een telefoonnummer.** E-mail, naam plus verblijfshistorie en de gegevens die bij het inchecken zijn verzameld, zijn betrouwbaardere kenmerken dan een veld dat je niet meer ontvangt.

**Zet aankomstinformatie waar gasten haar kunnen vinden.** Veel berichten vóór aankomst beantwoorden vragen over parkeren, laat aankomen of hoe de deur werkt, die eigenlijk op je website of in een gastgids thuishoren. Hoe minder er afhangt van een bericht dat de gast moet bereiken, hoe minder er mis kan gaan.

### Zo werkt het in HolidayHero

Dit is de flow waar HolidayHero omheen gebouwd is. Elke reservering, uit elk kanaal, krijgt een uitnodiging voor online inchecken via een kanaal dat de gast gegarandeerd bereikt; bij Booking.com is dat het berichtensysteem van het platform zelf. De gast checkt online in en laat zijn eigen contactgegevens en voorkeuren achter. Zodra het inchecken is afgerond, staat alles wat hij nodig heeft om aan te komen in het gastportaal, inclusief toegang tot het gebouw of de kamer waar een smart lock is gekoppeld. Vanaf dat moment loopt het gesprek via de eigen kanalen van de accommodatie, in één inbox.

Voor onze klanten veranderde 28 september één ding: een veld dat altijd gevuld was, is nu leeg. De aankomst merkte er niets van.

![image](https://www-api.holidayhero.com/storage/74/conversions/01M48T62PN6NW4J0CAREE0MV9Q-display.webp)

## Check je pre-stay deze week

- Welke van je automatiseringen gaan nog af op een telefoonnummer? Denk aan berichten vóór aankomst, upsells en het versturen van sleutels.
- Gaan deurcodes per sms de deur uit? Wat gebeurt er als er geen nummer is?
- Is Booking.com-berichtenverkeer gekoppeld aan de tool waarmee je met gasten communiceert, of kijkt iemand handmatig in het Extranet?
- Vraagt je online check-in om een telefoonnummer en toestemming voor contact?
- Staat je aankomstinformatie op je eigen website, in je eigen woorden?
- Wat gebeurt er met een bestaande boeking die na 28 september wordt gewijzigd? Test er één.

## Het volgende veld

Booking.com zal niet het laatste platform zijn dat verandert wat het deelt, en het telefoonnummer niet het laatste veld dat verdwijnt. Privacyregels worden strenger, fraude ontwikkelt zich, partners passen hun API's aan. Accommodaties die de pre-stay in eigen hand hebben, van het eerste contact via het inchecken en de sleutel tot het gesprek, merken daar nauwelijks iets van. De rest komt er telkens om 1 uur 's nachts achter.

Het verblijf runnen begint vóór de gast aankomt.

*Bron voor de wijziging bij Booking.com: [de samenvatting van Smoobu](https://www.smoobu.com/en/?p=82327) (Engelstalig).*