Tester davantage qu'un bouton de changement
Une démonstration PMS doit montrer plus que des dates modifiables. Vérifiez disponibilité de la nuit supplémentaire, nombre actualisé, traitement du prix et moment de confirmation. Demandez indisponibilité et attente d'accord en plus du succès. Utilisez des dossiers fictifs dans un environnement isolé des canaux actifs et messages clients. Ce sont des questions d'évaluation, pas des fonctions attribuées à un produit. Le guide public OPERA Cloud 26.2 décrit un écran de confirmation de disponibilité lors d'un changement de dates. Airbnb indique qu'une demande standard de l'hôte laisse la réservation inchangée si le client refuse ou ne répond pas, avec certaines exceptions selon le type. Ce sont des processus distincts. Une modification PMS ne prouve ni mise à jour automatique de tous les canaux ni parcours universel d'approbation.
Un dossier de démonstration complet
Commencez par une arrivée fictive le 16 octobre et un départ le 18 : deux nuits. Prolongez d'abord jusqu'au 19 : trois nuits. Supposez ensuite aucune chambre adaptée pour la nuit supplémentaire. Enfin, supposez disponibilité mais acceptation externe encore en attente. Ces dates ne correspondent à aucune réservation réelle. Précisez catégorie, nombre de personnes et hypothèse de prix pour relier résultat et entrée. Le vendeur confirme qu'aucune réservation, action de canal ou communication réelle n'est déclenchée. Les notifications restent des aperçus sans destinataire réel. Comparez dates, chambre et total avant et après. Un scénario n'est complet que si le résultat est vérifiable. S'il nécessite une connexion active absente, notez le manque de preuve et la vérification séparée proposée. Une fonction non montrée n'est pas démontrée.
Disponibilité, prix et confirmation
Sélectionner une date ne prouve pas la disponibilité. Où la nuit est-elle vérifiée, que se passe-t-il sans chambre disponible, la réservation actuelle est-elle préservée ? Examinez total initial et nouveau, explication par nuit, conditions conservées ou réexaminées. Les produits n'ont pas forcément la même méthode de recalcul. Un nombre inexpliqué ne doit pas être accepté seulement parce qu'il apparaît. Demandez une explication du comportement visible sans inventer un deuxième calcul. Distinguez demande, changement accepté et opération échouée. Ne généralisez pas le processus standard Airbnb à tous les canaux ; exceptions et types de réservation ont leurs règles. Quand l'opération est-elle terminée, quelles dates valent en attente, que voit l'utilisateur après refus externe ? Lorsque l'environnement sûr le permet, demandez un résultat visible de refus, pas seulement un récit.
Décider selon les preuves
Notez montré, partiellement montré ou non montré pour chaque cas. Une prolongation réussie affiche dates, trois nuits et total explicable. L'indisponibilité indique un conflit sans paraître confirmée. L'attente distingue état valide et demande inachevée. Ce sont des questions d'acceptation proposées, pas des écrans ou méthodes techniques imposés. Séparez comportement du produit et couverture des canaux. Une démonstration locale ne prouve pas un résultat identique en production. Comparez périmètre documenté, cas montrés et questions ouvertes. N'introduisez ni accès client ni réservation réelle dans ce travail éditorial. Si les preuves manquent, gardez l'incertitude dans la décision d'achat. Une bonne démonstration explique clairement changements réussis et échoués.