1. Un Système de Gestion Hôtelière peut être installé et configuré sans être prêt à accepter des réservations réelles : tout dépend de la validation de la configuration dans les scénarios qui se présenteront réellement.
2. Les échecs de mise en service se concentrent dans cinq domaines : inventaire des chambres incorrect, tarifs non conformes aux attentes, restrictions inopérantes, paramètres de paiement non testés et comptes du personnel dotés d’autorisations inadaptées.
3. Cette checklist couvre ces cinq domaines au moyen de 30 points vérifiables, chacun correspondant à une défaillance précise susceptible d’affecter un client si elle n’est pas détectée avant l’ouverture du calendrier.
4. Parcourez la liste complète une fois avant la première réservation réelle, et non après.
Pourquoi des établissements sont-ils mis en service avec des erreurs ?
Les étapes de configuration d’un nouveau Système de Gestion Hôtelière sont claires : créer les catégories de chambres, saisir les tarifs, connecter les canaux et ajouter le personnel. La plupart des établissements les accomplissent toutes. Le problème est qu’accomplir une étape et la vérifier ne sont pas la même chose.
Un tarif mal saisi ne se remarque que lorsqu’un client réserve au mauvais prix. Une connexion à un canal qui semble active, mais ne synchronise pas les disponibilités, ne se révèle que lorsqu’une double réservation survient. Un compte employé doté d’autorisations trop étendues ne pose visiblement problème que lorsqu’une personne modifie un tarif auquel elle n’était pas autorisée à toucher.
La checklist ci-dessous constitue une étape de vérification, et non un guide de configuration. Chaque point suppose que la configuration est déjà terminée et vise à vérifier qu’elle produit le résultat attendu.
Catégories de chambres et inventaire (vérifications 1 à 6)
1. Chaque catégorie de chambres correspond aux chambres réelles. Les noms, les quantités et les descriptions figurant dans le Système de Gestion Hôtelière correspondent aux chambres réelles de l’établissement. Une catégorie appelée « Chambre double avec vue sur l’océan » doit inclure toutes les chambres doubles offrant une vue sur l’océan, ni plus ni moins.
2. Le nombre de chambres est exact et empêche toute surréservation. La capacité enregistrée dans le système pour chaque catégorie de chambres correspond au nombre réel d’unités disponibles. Effectuez une réservation test qui occupe toute la capacité d’une catégorie, puis vérifiez que le système bloque toute réservation supplémentaire de cette catégorie aux mêmes dates.
3. Les chambres hors service sont bloquées. Toute chambre en maintenance, en rénovation ou autrement indisponible est placée sous le statut « Maintenance » et retirée de l’inventaire commercialisable. Vérifiez que ce blocage apparaît sur tous les canaux connectés.
4. Les équipements des chambres sont correctement renseignés. Les caractéristiques utilisées par les clients comme filtres — accessibilité, rez-de-chaussée, lit king size, balcon — sont associées aux bonnes catégories de chambres. Un client appliquant le filtre « accessible » ne doit voir que les chambres qui répondent réellement à ce critère.
5. La capacité maximale est définie pour chaque catégorie de chambres. Le système impose un nombre maximal de clients pour chaque catégorie de chambres. Une chambre prévue pour deux personnes ne peut pas être réservée pour cinq.
6. Les photos attribuées à chaque catégorie de chambres sont à jour. Les images affichées sur le moteur de réservation directe et sur les annonces des OTA correspondent à l’état actuel de la chambre, et non à celui d’avant sa rénovation.
Tarifs et politique tarifaire (vérifications 7 à 12)
7. Un tarif de base couvre toute la période de 90 jours. Chaque catégorie de chambres dispose d’un tarif configuré pour chaque date des trois prochains mois. Les dates non couvertes provoquent des erreurs ou des réservations à tarif nul.
8. Le cas échéant, les tarifs du week-end sont définis séparément. Si l’établissement applique du vendredi au samedi une tarification différente de celle des jours de semaine, vérifiez que l’écart tarifaire s’applique aux bons jours sans déborder sur les dates adjacentes.
9. Les tarifs des périodes de pointe et des événements sont chargés. Les dates connues de forte demande — jours fériés, événements locaux et vacances scolaires — disposent de tarifs reflétant la demande réelle plutôt que du tarif de base par défaut.
10. Des seuils tarifaires minimaux sont en place. Aucune catégorie de chambres ne peut être réservée à un tarif inférieur au seuil de rentabilité de l’établissement. Vérifiez que ni les outils automatisés ni les ajustements manuels ne peuvent faire descendre les tarifs sous le minimum défini.
11. Les tarifs des canaux OTA sont corrects après prise en compte de la commission. Si l’établissement publie des tarifs nets, vérifiez que la majoration aboutit au prix client prévu après l’ajout de la commission par la plateforme. S’il publie des tarifs bruts, vérifiez que la commission de l’OTA n’est pas ajoutée en supplément.
12. Une réservation directe test affiche le bon total. Effectuez une réservation test depuis le lien ou le widget de réservation directe et vérifiez que le total affiché — tarif, taxes et éventuels frais compris — correspond au montant prévu avant de passer au paiement.
Vérifiez les tarifs, l’inventaire et la synchronisation des canaux avant votre première réservation réelle
La checklist de configuration de Smart Order accompagne les exploitants dans la configuration des tarifs, la connexion des canaux et la gestion des autorisations du personnel, afin que la mise en service soit un état vérifié et non une simple supposition.
Restrictions (vérifications 13 à 16)
13. Les restrictions de séjour minimum sont appliquées aux périodes de pointe. Un week-end férié soumis à un minimum de 3 nuits ne peut pas être réservé pour une seule nuit. Faites le test : tentez de réserver 1 nuit à une date soumise à cette restriction et vérifiez que le système bloque la réservation.
14. Les dates de fermeture à la vente sont bloquées sur tous les canaux. Les dates auxquelles l’établissement n’accepte pas de nouvelles réservations sont bloquées dans le Système de Gestion Hôtelière, et ce blocage est répercuté sur chaque canal OTA connecté, pas uniquement sur le calendrier de réservation directe.
15. Les restrictions relatives aux jours d’arrivée et de départ sont actives. Si l’établissement n’autorise pas, par exemple, les arrivées le vendredi pendant l’été, cette restriction est configurée dans le système et testée en tentant une réservation avec une arrivée un jour interdit.
16. La fenêtre de réservation de dernière minute est définie. Le système comporte une heure ou un délai limite déterminant jusqu’à quel moment avant l’arrivée il accepte de nouvelles réservations — le jour même, 24 heures ou 48 heures avant, par exemple — et ce paramètre est cohérent entre les réservations directes et celles provenant des canaux.
Politique de paiement et d’annulation (vérifications 17 à 21)
17. Le montant et le moment de prélèvement de l’acompte sont configurés pour les réservations directes. Le pourcentage ou le montant fixe de l’acompte, ainsi que le moment de son prélèvement — lors de la confirmation de la réservation ou 48 heures plus tard — sont définis et s’appliquent automatiquement à chaque nouvelle réservation directe.
18. Le délai d’annulation est défini et testé. Le nombre de jours avant l’arrivée à partir duquel une annulation entraîne la perte de l’acompte est configuré. Faites le test : annulez pendant ce délai et vérifiez que l’acompte est conservé ; annulez avant le début de ce délai et vérifiez qu’il est remboursable.
19. Les règles de facturation en cas de non-présentation sont en place. Les frais applicables lorsqu’un client ne se présente pas sans avoir annulé dans le délai prévu sont configurés et associés au moyen de paiement enregistré.
20. La connexion au prestataire de paiement est testée au moyen d’une transaction réelle. Un débit test a été traité par le prestataire de paiement connecté, puis annulé. Le bon fonctionnement d’une intégration de paiement n’ayant traité aucune transaction réelle ne peut pas être confirmé.
21. La politique d’annulation affichée lors de la réservation correspond à celle configurée. Le texte lu par le client lors de la réservation — sur la page de confirmation et dans l’e-mail de confirmation — correspond exactement aux règles effectivement appliquées par le système.
Rôles et autorisations du personnel (vérifications 22 à 25)
22. Chaque membre du personnel dispose d’un compte actif. Chaque personne appelée à utiliser le Système de Gestion Hôtelière avant ou pendant le jour de la mise en service s’est connectée et a confirmé le bon fonctionnement de ses identifiants.
23. Les autorisations de la réception sont correctement délimitées. Les comptes de la réception peuvent consulter les réservations, traiter les arrivées et les départs, et gérer les paiements, mais pas modifier les tarifs, accéder à l’ensemble des rapports ni changer les paramètres du système.
24. Les comptes des services d’étage sont limités au statut des chambres. Les utilisateurs des services d’étage peuvent uniquement mettre à jour le statut des chambres (Départ effectué → À nettoyer → À inspecter → Prête → Maintenance). Ils n’ont accès ni aux données de paiement des clients ni aux informations financières des réservations.
25. Les comptes de la direction et du propriétaire respectent la hiérarchie d’accès appropriée. Le compte du responsable permet d’accéder aux rapports et aux paramètres. Le compte du propriétaire dispose de toutes les autorisations. Aucun compte employé ne bénéficie d’un niveau d’accès supérieur à celui nécessaire à son rôle.
Connexions aux canaux et messagerie (vérifications 26 à 30)
26. Chaque connexion à un canal OTA est testée au moyen d’une réservation réelle. Effectuez une réservation test sur Booking.com ou Airbnb et vérifiez qu’elle apparaît dans le Système de Gestion Hôtelière en moins de deux minutes. Ne supposez pas que la connexion fonctionne simplement parce que l’écran de configuration indique « connecté ».
27. Les blocages de disponibilités sont synchronisés sur tous les canaux connectés. Bloquez une chambre dans le Système de Gestion Hôtelière à une date précise et vérifiez que le blocage apparaît sur chaque canal OTA connecté. Débloquez-la ensuite et vérifiez que la disponibilité est rétablie sur tous les canaux.
28. Le lien ou le widget de réservation directe affiche des disponibilités exactes. Ouvrez la page de réservation directe comme le ferait un client et vérifiez que les disponibilités affichées correspondent au calendrier du Système de Gestion Hôtelière, blocages et restrictions compris.
29. Le contenu du message de confirmation est exact. L’e-mail de confirmation de réservation contient l’adresse correcte de l’établissement, la plage horaire d’arrivée et un numéro de téléphone opérationnel. Envoyez une confirmation test à l’adresse d’un membre du personnel et vérifiez chaque champ.
30. La programmation des messages de pré-arrivée couvre tous les types de réservations. Le rappel envoyé 72 heures avant l’arrivée part automatiquement pour chaque source de réservation, y compris pour les réservations provenant des OTA et pas uniquement pour les réservations directes. Vérifiez-le en consultant la programmation des messages d’une réservation OTA test.
Ouvrez votre calendrier en toute confiance, sans vous fier à des suppositions
Smart Order réunit dans un même système l’inventaire des chambres, les canaux OTA, les paramètres de paiement et les messages automatisés destinés aux clients, de sorte que les 30 vérifications de cette liste portent sur une configuration unique plutôt que sur cinq outils distincts.
FAQ
Que dois-je vérifier avant la mise en service d’un nouveau logiciel de gestion hôtelière ??
Les cinq domaines les plus susceptibles de comporter des erreurs lors de la mise en production sont l’inventaire et le nombre de chambres, la configuration des tarifs, les restrictions de réservation, les paramètres relatifs aux paiements et aux conditions d’annulation, ainsi que les autorisations des comptes du personnel. Chaque catégorie comprend des éléments précis qui peuvent être testés avant la première réservation réelle : terminer la configuration ne signifie pas qu’elle a été correctement vérifiée.
Comment tester les connexions aux canaux OTA dans un système de gestion hôtelière ?
Effectuez une réservation test sur la plateforme OTA et vérifiez qu’elle apparaît dans le PMS dans un délai de deux minutes. Bloquez ensuite une chambre à une date donnée dans le PMS et vérifiez que ce blocage apparaît dans le calendrier de l’OTA. Ces deux tests sont indispensables : une connexion qui synchronise les réservations entrantes peut ne pas transmettre correctement les mises à jour de disponibilité, tandis qu’une connexion qui transmet les blocages peut ne pas recevoir correctement les réservations entrantes.
De quelles autorisations le personnel de la réception doit-il disposer dans un logiciel de gestion hôtelière ?
Les comptes de la réception doivent permettre de consulter et de modifier les réservations, de traiter les arrivées et les départs, de gérer les paiements des clients et d’ajouter des notes aux dossiers de réservation. Ils ne doivent pas donner accès à la configuration des tarifs, aux paramètres système, à l’ensemble des rapports financiers ni à la gestion des comptes des autres membres du personnel. Limiter les accès de la réception aux tâches opérationnelles permet d’éviter les modifications tarifaires accidentelles et de réduire l’ampleur de tout incident de sécurité lié aux identifiants de connexion.
Comment vérifier que les conditions d’annulation sont correctement configurées dans un PMS ?
Testez les deux cas : annulez une réservation en dehors de la période soumise aux conditions d’annulation afin de vérifier que l’acompte est remboursé ; annulez-la pendant cette période afin de vérifier qu’il est conservé. Comparez également le texte des conditions affiché au client lors de la réservation avec le comportement réel du système : les deux doivent présenter les mêmes modalités.
Quand un PMS hôtelier est-il prêt à être mis en production ?
Un PMS est prêt à être mis en production lorsque chaque point de la liste de contrôle préalable au lancement a été validé par des tests, et non simplement configuré par saisie. Cela comprend une vérification des tarifs sur l’intégralité de la période de 90 jours, une réservation test réelle effectuée sur chaque canal, une transaction de paiement confirmée, l’activation de tous les comptes du personnel avec des droits correctement définis, ainsi que la vérification de l’exactitude du contenu des messages automatisés. La configuration et la vérification sont deux étapes distinctes : la mise en production intervient après la vérification, et non après la simple configuration.
