1. Testez une réservation qui a été modifiée, pas seulement une nouvelle réservation sans particularité.
2. Si des éléments facultatifs de la formule de salutation manquent, une formulation neutre peut convenir. En cas d’incertitude sur les montants, les adresses ou les consignes d’accès, bloquez l’envoi.
3. Validez ce que le destinataire reçoit réellement, y compris la destination de chaque bouton.
Un modèle est validé lorsque son message final correspond bien à la réservation au moment de l’envoi. Une orthographe correcte et un aperçu réussi ne suffisent pas. La messagerie client hôtel doit renseigner les données évolutives à partir du bon séjour, et sa règle d’envoi doit toujours être adaptée à ce séjour.
Utilisez les contrôles ci-dessous pour décider d’envoyer le message, de corriger puis de retester le modèle, ou de suspendre l’envoi pour vérification par le personnel. Ils vérifient le sens du message, au-delà du simple fait qu’un champ affiche du texte.
Rédigez le message attendu avant de vérifier l’aperçu
Une variable est un espace réservé remplacé par une information de réservation, comme un nom ou une date d’arrivée. Sélectionnez-la à l’aide du sélecteur de champs prévu par le logiciel. Des noms de champs copiés depuis un autre système peuvent sembler corrects sans fonctionner.
Prenons une réservation fictive de test gérée par le personnel : Maya arrive le 24 novembre, le séjour coûte 240 USD et un acompte de 60 USD a déjà été encaissé. Le solde de la chambre est de 180 USD, en l’absence d’autres frais. Aucune chambre précise n’a encore été attribuée.
Pour un rappel de solde, un résultat acceptable pourrait être : "Bonjour Maya. Votre arrivée est prévue le 24 novembre. Le solde à régler pour votre chambre est de 180 USD." Le message ne doit pas réclamer 240 USD ni communiquer un numéro de chambre non confirmé.
Consignez ces informations attendues séparément de l’aperçu. Comparez-les à la réservation et aux paiements enregistrés par l’hôtel, plutôt qu’au message de la veille. Sinon, le personnel risque de valider un résultat plausible simplement parce que tous les espaces réservés ont été remplacés.
Vérifiez également qui doit recevoir le message. Un assistant a peut-être réservé pour Maya. Même si le nom du voyageur est correct, un message envoyé à la mauvaise personne constitue un échec du contrôle.
Smart Order affiche le contexte de la réservation à côté des conversations avec les clients, ce qui permet à la réception de comparer la réponse prévue aux informations du séjour. Utilisez ce contexte pour vérifier une date ou une question de paiement ; le simple fait qu’un modèle soit disponible dans la liste ne prouve pas qu’il a été testé et validé.
Vérifiez l’information qui détermine la prochaine action du client
Consultez la réservation à côté de la conversation avant de demander au client de payer, de se présenter à l’établissement ou de suivre une consigne propre à celui-ci.
Testez les réservations les plus susceptibles de mettre le modèle en défaut
Continuez avec le séjour de test de Maya en modifiant une seule condition à la fois. Utilisez des dossiers de test approuvés et des destinataires contrôlés par le personnel, sans solliciter de vrais clients ni envoyer de demandes d’encaissement réelles. Il s’agit de cas de test, pas d’une séquence de clics imposée.
La date d’arrivée change après la préparation du message
Reportez l’arrivée du séjour de test du 24 au 26 novembre en suivant la procédure prévue. Vérifiez un nouvel aperçu ainsi que tout message déjà préparé ou en attente d’envoi. Le résultat acceptable est l’affichage de la nouvelle date, ou la suspension de l’envoi exigeant le remplacement de l’ancien message.
Si seuls les nouveaux aperçus se mettent à jour, le champ de date peut être correct alors que le message enregistré conserve une ancienne valeur. Supprimez ou remplacez ce message obsolète à l’aide des commandes prévues. Consignez cette limite dans la procédure d’envoi.
Un autre paiement est reçu avant l’envoi
Supposons qu’un paiement supplémentaire de 40 USD soit encaissé au moyen de la méthode de test de paiement approuvée. Le solde attendu pour la chambre passe à 140 USD, au lieu de 180 USD. Vérifiez si le rappel se met à jour et si l’ancienne demande de paiement reste valide.
Si le solde actuel ne peut pas être établi de manière fiable, n’indiquez aucun montant et exigez une demande vérifiée par le personnel. Ne le remplacez pas par le montant total de la réservation. Pour un séjour de test prépayé auprès d’une OTA, vérifiez que le message ne réclame pas un montant lié à la chambre que l’hôtel ne doit pas encaisser.
Des informations facultatives sont manquantes
Supprimez le prénom facultatif dans un dossier de test adapté. Un simple "Bonjour" peut convenir si l’éditeur permet cette solution de repli. En revanche, un libellé de champ affiché tel quel, une formule de salutation vide ou un nom déduit d’une adresse e-mail ne conviennent pas.
Les informations essentielles exigent une autre réponse. L’absence de devise, d’adresse de l’établissement ou d’informations indispensables à l’arrivée doit entraîner la suspension du message pour vérification. Une formulation chaleureuse ne peut pas rendre sûre une consigne qui ne l’est pas.
La personne qui réserve, l’établissement ou la chambre diffère
Testez une réservation effectuée par un assistant pour Maya et, si nécessaire, une réservation dans un autre établissement. Vérifiez séparément le destinataire, la formule de salutation, l’adresse, le moyen de contact et les consignes d’arrivée. Une valeur correcte ne valide pas les autres.
Pour les messages propres à une chambre, comparez l’attribution avec la vue des réservations de la réception. Les messages contenant des informations d’accès nécessitent leurs propres contrôles approuvés avant envoi. La seule confirmation d’une réservation ne doit pas déclencher la communication d’un numéro de chambre ou d’un code.
Le canal ou la langue change
Lorsque cela est possible, utilisez un circuit de test sécurisé sur le canal d’envoi prévu. Lisez le message reçu sur un téléphone en vérifiant les liens, les sauts de ligne et la traduction. Un aperçu d’e-mail ne prouve pas qu’une conversation sur une OTA affiche le même contenu.
La traduction doit préserver le bon fonctionnement des champs et ne doit pas transformer une demande de paiement en confirmation de paiement. Ouvrez les liens de test pour vérifier leur fonction. N’incluez pas de véritables identifiants d’accès ni de liens de paiement actifs dans les notes de contrôle qualité partagées.
Décidez : envoyer, corriger puis retester, ou suspendre
Ne validez que les cas essentiels à l’objectif de ce modèle. Un message de bienvenue peut ne nécessiter aucun test de solde ; un rappel de paiement en exige un. Choisissez les tests en fonction des conséquences d’un message erroné, plutôt qu’à partir d’une liste universelle de champs.
Choisissez de corriger puis retester lorsque la cause est identifiée : un champ non pris en charge, une solution de repli manquante pour une information facultative ou un texte fixe obsolète. Répétez le cas concerné et les autres cas qui dépendent de la modification. Le bon affichage d’une seule réservation standard ne suffit pas.
Choisissez de suspendre l’envoi pour vérification par le personnel lorsqu’une valeur actuelle fiable ou le bon destinataire ne peuvent pas être établis, ou qu’un message en attente d’envoi ne peut pas être actualisé de manière fiable. Saisir manuellement une réponse correcte aide le client concerné, mais ne corrige pas le modèle réutilisable.
Conservez une note de validation indiquant l’objectif et la version, les conditions testées, les résultats attendus et reçus, ainsi que la personne ayant donné son accord. Reprenez les tests pertinents après toute modification des règles de paiement, des informations de l’établissement, des langues ou du moment d’envoi. Ne retestez pas des champs sans rapport avec le modèle simplement pour remplir un formulaire.
Si des messages incorrects ont déjà été envoyés
Mettez en pause le modèle ou la file d’envoi concernés. Identifiez les destinataires selon la version et la période d’envoi, puis envoyez un seul rectificatif clair par un canal approuvé. Une erreur dans la formule de salutation appelle une réponse différente de la divulgation des informations de chambre d’un autre client ou d’une demande d’encaissement incorrecte.
En cas d’erreur de paiement ou d’accès, faites intervenir le responsable concerné et déterminez si l’ancienne demande ou l’identifiant d’accès doit être révoqué. Vérifiez tout encaissement avant de réclamer à nouveau de l’argent. Traitez la divulgation d’informations concernant une autre personne conformément à la procédure de confidentialité de l’hôtel.
Ne rétablissez l’envoi automatique qu’une fois le cas ayant échoué de nouveau testé et validé. La décision de remise en service dépend de ce que reçoit le destinataire, et pas seulement de la capacité de l’éditeur à enregistrer le modèle.
