Demande de réservation en attente : le protocole 2026

Pourquoi la demande de réservation en attente changetelle en 2026 ?

La demande de réservation en attente devient un véritable événement d’inventaire, et non plus une simple notification à traiter. L’évolution la plus concrète vient de Request to Book 2.0 (RtB 2.0) de Booking.com, annoncée dans le changelog Connectivity du 4 août 2026. Dans l’ancien flux INQUIRY, une demande ne bloquait l’inventaire côté fournisseur qu’une fois convertie en réservation. Dans le nouveau flux RTB, le partenaire de connectivité doit bloquer la disponibilité dès la création, puis la libérer si la demande est refusée, retirée, expirée ou impossible à traiter. Booking.com préautorise en outre le montant total ; l’acceptation du gestionnaire confirme directement la réservation. La documentation officielle de Request to Book 2.0 précise ces différences. Airbnb applique déjà une logique proche côté calendrier : les dates d’une demande sont bloquées pendant le délai de réponse de 24 heures et peuvent rester fermées après expiration jusqu’à une réouverture manuelle. Depuis l’été 2026, Airbnb déploie aussi des demandes audelà de la fenêtre de disponibilité pour les hôtes utilisant la réservation instantanée. Ces demandes doivent donc rejoindre le même circuit de contrôle que les demandes classiques. Cette actualité ne remet pas en cause le rôle du classement d’un meublé sur les OTA, sujet pilier expliqué dans ce guide sur le classement et la diffusion d’un meublé. Elle ajoute une couche opérationnelle : après avoir rendu un logement réservable, il faut savoir quand son stock doit être gelé.

Quelle différence entre demande, option et réservation confirmée ?

Une demande attend une décision, une option immobilise volontairement des dates et une réservation confirmée crée le séjour à exécuter. Ces trois objets ne doivent jamais partager un statut générique “réservé” dans le PMS. | État métier | Calendrier multicanal | Revenu prévisionnel | Automatisations à lancer | ||||| | Demande INQUIRY | Selon la règle du canal ; pas de blocage fournisseur en RtB 1.x | Aucun revenu ferme | Alerte et réponse seulement | | Demande RTB | Blocage immédiat jusqu’au dénouement | Revenu potentiel, séparé du confirmé | Alerte, minuterie, contrôle d’éligibilité | | Option manuelle | Blocage avec échéance décidée par le gestionnaire | Aucun revenu ferme | Relance interne et libération programmée | | Réservation confirmée | Blocage ferme sur tous les canaux | Revenu confirmé selon la politique comptable | Messages, ménage, accès, paiement et reporting | Cette distinction protège les indicateurs. Si une demande en attente est comptée dans le chiffre d’affaires, le forecast est gonflé. Si elle n’est pas bloquée dans l’inventaire alors que le canal l’exige, une vente concurrente peut provoquer un double engagement.

Comment paramétrer le PMS et le channel manager ?

Le PMS doit conserver le statut source, l’identifiant de demande, l’échéance et la raison de sortie ; le channel manager doit propager le blocage utile sans créer une fausse réservation. Avant d’activer Request to Book, demandez à votre éditeur s’il distingue explicitement INQUIRY et RTB. Utilisez cette checklist de recette sur un logement test : 1. Créer la demande. Vérifiez qu’elle apparaît en moins d’une minute dans la boîte d’actions avec le canal, les dates, le montant et l’heure limite. 2. Contrôler le blocage. Recherchez les mêmes dates sur les autres canaux et sur le moteur direct. Une demande RTB doit empêcher la vente du même inventaire. 3. Tester l’acceptation. Une seule réservation confirmée doit être créée, avec l’identifiant OTA conservé et sans second débit ni doublon de tâche. 4. Tester chaque sortie. Refus, expiration, retrait du voyageur et échec technique doivent libérer les dates conformément au statut reçu. 5. Vérifier les automatisations. Aucun code d’accès, ordre de ménage ou message d’arrivée ne doit partir avant la confirmation. 6. Conserver la trace. Journalisez l’heure de réception, la décision, l’utilisateur ou la règle ayant agi, puis l’heure de réouverture. Beds24 ou tout autre channel manager connecté par API doit être évalué sur ce cycle complet, pas seulement sur l’import de la demande. Un flux qui bloque correctement mais ne libère pas correctement crée des nuits orphelines invisibles. Pour approfondir la logique des statuts et des échanges, utilisez aussi le journal de synchronisation PMS, Airbnb, Booking.com et Beds24.

Quel workflow automatisé évite le surbooking ?

Le workflow le plus sûr sépare quatre événements : réception, blocage, décision et déblocage. Chaque événement doit produire une action vérifiable et une alerte seulement si l’étape suivante n’arrive pas dans le délai prévu. Exemple pour une conciergerie de 25 logements : La documentation Booking.com indique également qu’un voyageur peut retirer une demande avant la décision du partenaire. Le statut WITHDRAWNPENDINGAPPROVAL doit donc fermer la tâche humaine et libérer l’inventaire sans attendre une intervention. En parallèle, la messagerie de préréservation est disponible via l’API Messaging pour certains flux RtB ; elle permet de clarifier une demande sans lancer prématurément les messages de séjour. Un tel workflow complète le protocole de prévention du surbooking en location saisonnière : la synchronisation transporte l’état, tandis que le PMS décide quelles opérations cet état autorise.

• À la réception, le PMS crée demandeenattente, horodate l’échéance et affecte le dossier au gestionnaire d’astreinte.
• Si le type est RTB, le stock est fermé sur Airbnb, la vente directe et les autres OTA ; si le type est INQUIRY, la règle de blocage documentée par le fournisseur s’applique.
• Une alerte part après 15 minutes sans prise en charge, puis une escalade intervient bien avant le délai du canal.
• L’acceptation transforme le même objet en réservation confirmée. Elle déclenche ensuite seulement la séquence voyageur, le ménage et l’accès.
• Le refus, le retrait ou l’expiration lance une réouverture idempotente : répéter l’ordre ne doit ni ajouter une unité ni dépasser la capacité initiale.

Comment répondre sans perdre une vente rentable ?

Une réponse rapide doit vérifier seulement les éléments qui changent réellement la décision : capacité, règles essentielles, faisabilité opérationnelle et conformité. N’utilisez pas la demande comme un questionnaire général, car chaque échange inutile consomme une partie du délai et augmente le risque d’expiration. Préparez trois réponses courtes : acceptation après contrôle, question bloquante, refus motivé avec éventuelles dates alternatives. Booking.com permet désormais aux partenaires équipés de l’API Messaging d’échanger avant la réservation dans le flux RtB, mais les pièces jointes et le partage de coordonnées y sont limités. Airbnb demande de répondre dans les 24 heures ; son aide officielle sur les demandes de réservation rappelle que les dates expirées peuvent rester bloquées jusqu’à leur réouverture manuelle. Pour décider, comparez le revenu net attendu, et non le prix facial : commission, ménage, durée, trou créé avant ou après le séjour et risque d’intervention. Une demande de trois nuits à 420 € peut être moins intéressante qu’une vente directe à 390 € si elle ferme une nuit forte invendable et déclenche une rotation coûteuse. Le calcul doit toutefois rester une aide : appliquez les règles de nondiscrimination de chaque plateforme et des critères identiques pour des situations comparables.

Quels contrôles intégrer à la routine quotidienne ?

Le contrôle quotidien doit repérer les demandes proches de l’échéance, les blocages sans demande active et les demandes acceptées sans réservation correspondante. Cinq minutes matin et soir suffisent si les exceptions remontent dans une file unique. À retenir Ajoutez enfin un contrôle hebdomadaire des blocages âgés de plus de 24 heures, puis rapprochez chaque anomalie du journal d’API. La gestion des alertes de réservation multicanal aide à régler les seuils sans transformer chaque demande normale en urgence.

• Un statut en attente n’est ni une réservation confirmée ni un simple message.
• Booking.com RtB 2.0 impose au partenaire de connectivité de bloquer l’inventaire dès la création d’une demande RTB.
• Un retrait, un refus, une expiration ou un échec doit déclencher une libération contrôlée des dates.
• Les messages, tâches de ménage et codes d’accès commencent uniquement après confirmation.
• Une alerte utile signale une anomalie ; elle ne remplace pas un état fiable dans le PMS.

FAQ sur les demandes de réservation en attente

Combien de temps une demande Airbnb restetelle en attente ? Airbnb accorde généralement 24 heures à l’hôte pour accepter ou refuser une demande. Si elle expire, les dates peuvent rester bloquées jusqu’à une réouverture manuelle ; le gestionnaire doit donc contrôler le calendrier après l’échéance. Une demande Booking.com bloquetelle toujours les autres canaux ? Non. Dans Booking.com Request to Book, une demande INQUIRY et une demande RTB n’ont pas la même règle. RtB 2.0 exige un blocage côté fournisseur dès la création d’une demande RTB, alors que l’ancien flux attend la confirmation. Fautil envoyer le message d’arrivée dès l’acceptation ? Le message d’arrivée doit partir uniquement après la création de la réservation confirmée dans le PMS. Une demande acceptée peut encore suivre des états techniques ; déclencher trop tôt expose des informations d’accès à une personne sans séjour confirmé. Comment traiter deux demandes simultanées sur les mêmes dates ? Le premier blocage valide doit rendre l’inventaire indisponible aux autres flux. Si deux demandes arrivent malgré tout, le PMS doit les placer en exception, empêcher toute acceptation automatique et demander une décision humaine avant engagement. Quel indicateur suivre pour améliorer le processus ? Suivez le délai médian entre réception et décision, le taux d’expiration, le nombre de blocages non libérés et les doubles engagements évités. Analysez ces indicateurs par canal et par équipe, sans mélanger demandes en attente et réservations confirmées. Une demande de réservation en attente bien modélisée protège à la fois le calendrier, le revenu et l’expérience voyageur. LEA, le PMS intelligent pour la location saisonnière, peut centraliser les statuts, les échéances et les exceptions afin que votre équipe intervienne au bon moment, sans automatiser aveuglément la décision.