Échanger avec les clients depuis la réservation

Choisis la bonne réservation comme contexte de conversation

Ouvre Invités → Messages ou les messages détaillés des invités. Recherche par numéro de réservation, invité, dates ou chambre et vérifie le panneau contextuel avant d'écrire.

Seules les réservations liées à un client principal peuvent recevoir des messages. Corrige un lien manquant dans le dossier du client ou de la réservation plutôt que de créer une autre personne.

Démarre chaque conversation à partir de la réservation exacte. Recherche par numéro de réservation, client ou dates de séjour, ouvre le dossier et compare le destinataire, l'arrivée, le départ, la catégorie de chambre, l'état actuel et la source de réservation. Un même client peut avoir plusieurs séjours passés ou futurs, et un profil à lui seul ne permet pas d'identifier de quelle arrivée, annulation ou facture concerne le message. STRYK utilise donc invité et réservation ensemble. Si le contexte de réservation n'est pas clair, arrête-toi avant d'écrire et résous-le dans l'enregistrement source. Conserve les détails privés dans la conversation de réservation autorisée et utilise une référence de réservation ou de chambre dans les notes de transfert plutôt que de copier les données de contact ailleurs. La vérification du contexte est terminée lorsqu'un autre collègue peut identifier le destinataire prévu et rester sans deviner le corps du message.

Comprendre le canal à partir de la source de réservation

Les réservations manuelles, par téléphone, sans rendez-vous, par courrier électronique, sur le site Web et sur le moteur de réservation utilisent le courrier électronique, avec l'objet et les formats bruts ou HTML. Vérifie d'abord l'adresse enregistrée.

Les réservations OTA et de chaînes utilisent une conversation de chaîne en texte brut. Ne le contourne pas avec un e-mail séparé, sinon l'historique des réservations deviendra incomplet.

Lis le canal de communication de la source de réservation. Les réservations manuelles et directes utilisent le courrier électronique ; Les réservations OTA ou canal utilisent le canal de réservation comme conversation en texte brut. Le compositeur ne propose pas de choix libre du canal, car modifier l'itinéraire romprait la relation entre la source de réservation et l'historique des messages. Confirme le canal affiché et le destinataire disponible avant de sélectionner un modèle. Les e-mails peuvent utiliser du texte brut ou du HTML approuvé avec aperçu, tandis que les messages du canal restent en texte brut et ne doivent pas dépendre d'un formatage non pris en charge. Si un itinéraire de contact différent est nécessaire sur le plan opérationnel, traite-le comme un processus autorisé séparément et documente pourquoi ; ne cache pas le changement à l’intérieur du compositeur. Pour les réservations sur le portail, STRYK envoie le message en texte brut via l'itinéraire connecté Booking.com ou Airbnb et conserve chaque réponse dans la même conversation de réservation.

Choisis un modèle par objectif, canal et langue

La liste affiche les modèles actifs correspondant au canal dérivé. Choisis en fonction du but du voyage du voyageur et de la langue requise, et non en fonction d'un nom à consonance similaire.

STRYK applique le format, le sujet et le corps. Les corrections récurrentes appartiennent au modèle central ; les détails ponctuels restent dans le brouillon. Évite les copies privées obsolètes.

Choisis un modèle en fonction d'un objectif concret, du canal affiché et de la langue de l'invité. Les informations d'arrivée, le rappel de paiement, les données manquantes et les remerciements après le séjour sont des décisions différentes et ne doivent pas être combinés dans un vague message universel. Utilise uniquement un modèle actif proposé pour le canal dérivé. Lis-le avant de postuler : vérifie la formule de salutation, le ton, les horaires de l'hôtel, les liens, le libellé d'annulation ou de paiement et la signature par rapport aux pratiques hôtelières actuelles. Un modèle est un point de départ révisé, et non une autorisation d'envoi inchangé. Si la langue du client diffère de celle par défaut de l'hôtel, sélectionne ou rédige une version complète dans cette langue ; un sujet traduit avec un corps en plusieurs langues n'est pas prêt. Supprime les paragraphes qui ne s'appliquent pas à ce séjour et ajoute uniquement les faits déjà approuvés dans les paramètres de réservation, de politique ou de l'hôtel.

Examiner les espaces réservés à partir du contexte de réservation réel

Le sélecteur expose les valeurs résolvables dans le contexte actuel du client et de la réservation. Lis l'aperçu résolu et compare les dates, les détails de la chambre et de la réservation avec le panneau contextuel.

Les espaces réservés non résolus sont affichés sous l’aperçu. Corrige les données sources manquantes, recharge et révise à nouveau ; s'il n'est pas disponible de par sa conception, supprime le jeton ou réécrive la phrase.

Résous chaque espace réservé en aperçu par rapport à la réservation en cours. Vérifie le message d'accueil et le nom du client, l'hôtel, l'arrivée et le départ, la catégorie ou la chambre attribuée, le numéro de réservation, le total, le montant impayé, la politique d'annulation et les coordonnées selon l'objectif du modèle. Un jeton non résolu, un tiret vide ou une valeur invraisemblable est un bloqueur et non un texte cosmétique. Corriger les données sources manquantes lorsqu'elles devraient exister ; sinon, réécrive la phrase sans faire de promesse. Si aucune chambre n'est attribuée, indique la catégorie réservée plutôt que de deviner un numéro de chambre. Si une valeur de paiement est contestée, ne la remplace pas manuellement dans le message ; résoudre d'abord les finances. Les espaces réservés d'alias peuvent s'afficher à des fins de compatibilité, mais le sélecteur doit utiliser les valeurs canoniques actuelles disponibles dans ce contexte de réservation. L'aperçu final doit contenir uniquement des données réelles et explicables.

Lire le contenu en tant qu'hôte et réviseur

Lis en tant que client : les deux premières phrases doivent expliquer pourquoi l'hôtel écrit et ce qui se passe ensuite. Utilise des horaires clairs et un langage de tous les jours, et non des codes internes.

Vérifie ensuite le destinataire, la formule de salutation, le numéro de réservation, les dates, les demandes de chambre, les références de prix, les liens, la signature et la langue. Le HTML nécessite une révision visuelle ; les messages du canal restent en texte brut et clair.

Lis le message final deux fois : d'abord en tant qu'hôte, puis en tant que critique. En tant qu'hôte, rends évidente la prochaine action du voyageur, utilise un langage respectueux et n'inclus que les informations qui facilitent le séjour. En tant qu'évaluateur, vérifie les faits de réservation, les dates, les montants, les déclarations de politique, les liens, le délai de réponse, la signature et la confidentialité. Un message doit avoir un objectif principal et une réponse claire à ce que le client doit savoir ou faire. Évite le jargon interne, les reproches, les promesses juridiques que l’hôtel ne peut pas tenir et les données sensibles non nécessaires à cette fin. En cas de changement urgent, indique ce qui a changé, quel séjour est concerné et où le client peut répondre. Pour les e-mails HTML, inspecte à la fois l’aperçu formaté et le texte lisible ; pour les messages de canal, assure-toi que la signification survit au texte brut. Un message spécifique concis est plus sûr qu’un long modèle rempli de clauses non pertinentes.

Envoie une fois et prouve le résultat dans le fil de discussion

Confirme la réservation, envoie une fois et attends. Si STRYK affiche une erreur, conserve le brouillon, corrige la cause et n'enregistre pas le succès prématurément.

Après succès, recherche le message dans le même fil de réservation et vérifie la direction, l'heure, le canal, le sujet le cas échéant et le numéro de réservation. S'il n'est pas visible, recharge avant de réessayer.

Envoie une fois et attends le résultat réel. Un bouton désactivé, un compteur ou un réseau lent n'autorise pas à cliquer à plusieurs reprises. En cas de succès, rouvre la même conversation de réservation et vérifie exactement une entrée sortante avec l'horodatage, le canal, le sujet le cas échéant et le contenu visible corrects. Pour le courrier électronique, un résultat de candidature réussi et une entrée dans le fil de discussion prouvent que STRYK a accepté l'envoi ; les échecs de livraison doivent rester visibles via le statut ou le suivi approprié. Pour une conversation de canal, confirme que le message en texte brut se trouve dans le bon fil de réservation. Si l'envoi échoue, conserve le brouillon, lis l'erreur et corrige le destinataire, le canal, le contenu ou la connexion à sa source. Ne crée jamais une entrée de réussite locale et ne copie jamais le message dans une autre réservation simplement pour que l'historique paraisse complet.

Vérifie deux erreurs courantes avec un test séparé. Premier cas : le client ne dispose pas d'adresse e-mail utilisable dans une réservation directe. Le résultat correct ne consiste pas à deviner le destinataire ou à utiliser l'adresse d'un autre client, mais à bloquer et à clarifier les informations de contact dans le profil du client ou dans la réservation. Deuxième cas : ils choisiraient un modèle d’e-mail pour la réservation OTA. Le canal et le formulaire de texte brut dérivé par le système doivent rester visibles ; ne copie pas manuellement le message dans un e-mail séparé en perdant la connexion de la conversation. Pour les deux répétitions, note le numéro de réservation, la chaîne attendue, les commentaires réels et le prochain responsable. De cette façon, l’équipe peut non seulement gérer un envoi réussi, mais également un arrêt en toute sécurité lorsque les données sources ou le canal ne conviennent pas.

Maintenir une norme de messagerie d’équipe

Définis un modèle responsable par situation récurrente, canal et langue, avec appropriation et révision régulière. Préfère un petit ensemble clair à de nombreux noms similaires.

L'hôtel Nordlicht teste le courrier électronique direct, l'aperçu HTML direct, le canal OTA simple, un espace réservé manquant et un client avec deux réservations. Les problèmes sont résolus au niveau de la source, du modèle ou de la réservation.

Maintiens une petite équipe standard pour les messages récurrents. Chaque modèle approuvé doit avoir un objectif, un canal, une langue, un propriétaire, une date de dernière révision et un déclencheur de prochaine révision. Examine les modifications apportées aux heures d'enregistrement, au processus de paiement, aux conditions d'annulation, aux contacts de l'hôtel, aux liens ou au parcours des clients. Conserve le contenu du modèle dans le catalogue back-end central et les espaces réservés dans le système de modèles central plutôt que dans les extraits personnels ou les fichiers locaux. Échantillonne une vraie conversation après activation dans la démo isolée de l'Hôtel Nordlicht, en vérifiant le contexte de réservation, les valeurs résolues, la qualité éditoriale et l'envoi unique ; n’utilise jamais un compte client existant comme preuve de documentation. Retire les modèles obsolètes au lieu de laisser les quasi-doublons actifs. Le processus est fiable lorsqu'un collègue peut comprendre ultérieurement l'objectif, le destinataire, le séjour, le canal, le contenu exact et le résultat uniquement à partir de la conversation de réservation.

Échantillonne au moins trois conversations par mois ou après chaque changement opérationnel important : un e-mail direct, un message en texte brut sur un canal et un cas où l'envoi a dû être bloqué. Vérifie le bon contact de réservation, la langue du client, l'espace réservé déverrouillé, l'objectif clair, la ligne sortante unique et la fermeture responsable de l'erreur. Ne copie pas de contenu personnel dans un document pédagogique ; le contrôle qualité doit enregistrer uniquement la référence de réservation et le résultat requis. En cas d'erreur récurrente, ne corrige pas chaque message un à un : identifie s'il est provoqué par un modèle, des données centrales de l'hôtel, une source de réservation ou un processus d'équipe, commande une correction et un nouveau test.

Enregistre la date et la personne responsable de la révision à côté du modèle afin que la raison et la date d'échéance de la prochaine révision soient claires pour tous les collègues.