Votre métier · Votre OS

Hôtellerie : une demande qui suit les changements d’équipe

Gardez les demandes clients, transmissions entre services et mises à jour promises dans le contexte opérationnel de l’hôtel.

Exemple de parcours

Un parcours concret, du signal à la suite du travail

  1. Un client signale un problème pendant l’équipe de nuit.

  2. La demande est liée au bon service interne et à la réponse attendue.

  3. L’équipe du matin voit ce qui a été signalé et ce qui reste non résolu.

  4. Une réponse vérifiée prolonge la même relation client après la passation.

Illustration fictive. Les fonctions, sources et accès disponibles dépendent de votre environnement ; les conditions sont précisées ci-dessous.

Sur cette page
  1. Une demande, plusieurs services
  2. Quand le service change
  3. Incident et préparation d’arrivée
  4. Décisions et connaissances d’équipe
  5. Langues et opérations sur plusieurs établissements
  6. Périmètre métier et responsabilités
  7. Outils et prérequis

Une demande, plusieurs services

Réception, étages, maintenance et responsable peuvent participer à une même demande. Le contexte doit indiquer qui attend quoi et quelle information le client doit recevoir.

Quand le service change

L’équipe suivante retrouve ce qui a été promis, les actions encore ouvertes et les décisions enregistrées. Le client ne doit pas reprendre toute son histoire parce que son interlocuteur termine son service.

Incident et préparation d’arrivée

Une demande particulière avant l’arrivée peut nécessiter plusieurs préparations internes. Un incident peut garder son historique et les actions déjà tentées, sans produire automatiquement un diagnostic technique.

Décisions et connaissances d’équipe

Une décision du responsable et les réponses approuvées peuvent être conservées dans un groupe autorisé. L’expérience réutilisable ne doit pas exposer inutilement un dossier client ou des informations sensibles.

Langues et opérations sur plusieurs établissements

Une expérience compatible peut expliquer un message client dans une autre langue avant la préparation de la réponse. Les vues de responsable et de groupe hôtelier dépendent des périmètres autorisés ; elles ne constituent pas une surveillance universelle du personnel.

Périmètre métier et responsabilités

AlefOS ne remplace pas le PMS : réservations, chambres, tarifs, paiements, arrivée, départ et statut ménage restent dans les outils hôteliers. Il ne gère pas cartes d’accès, stocks, paie ou revenu. Ce parcours n’encourage pas à stocker passeports, numéros complets de cartes de paiement ou données sensibles inutiles.

Référence de fonctionnement

Modules, outils et conditions d’accès

Cette référence décrit les opérations MCP et leurs effets. La liste effectivement exposée à votre assistant dépend du serveur déployé, des modules et des autorisations. Une lecture, un brouillon et une exécution sont des opérations distinctes.

Connaissances et publications GroupOS

Recherche et digest sont des lectures. La publication suit son mode de confirmation. Modifier ou archiver une entrée et gérer les membres exigent les droits correspondants de l’auteur ou de l’administrateur.

OutilFonction et effet
groups.listLister les groupes privés accessibles et leur contexte partagé récent.
groups.getLire un groupe et le contexte d’appartenance visible par l’utilisateur courant.
groups.searchRechercher les entrées du groupe par texte, thème, type et période.
groups.digestLire un digest compact sans rien publier.
groups.messagesLire les entrées de travail récentes d’un groupe accessible.
groups.draft_sendPrévisualiser ou publier une entrée structurée selon confirmMode.
groups.message.updateModifier une entrée existante avec les droits requis d’auteur ou d’administrateur.
groups.message.archiveArchiver une entrée avec les droits requis d’auteur ou d’administrateur.
groups.members.addAjouter un membre autorisé de l’entreprise ou préparer une invitation de contact extérieur.
groups.members.removeRetirer un membre dans le périmètre du rôle ; le créateur du groupe ne peut pas être retiré.

Consulter la documentation du module →

Missions et responsabilités

Lire la source et l’état d’exécution avant d’agir. Confirmer exécute une mission en attente ; rejeter et archiver ont des effets distincts. L’affectation dépend des rôles de l’entreprise.

OutilFonction et effet
missions.listLister les missions de l’utilisateur courant, éventuellement regroupées par contact.
missions.getLire la source, les objets liés et l’état d’exécution d’une mission.
missions.confirmConfirmer et exécuter une mission en attente.
missions.rejectRejeter une mission en attente sans l’exécuter.
missions.archiveArchiver une mission sans exécuter ni supprimer son action.
missions.assignAffecter depuis la file d’entreprise ou réaffecter avec le rôle requis ; les changements sont tracés.

Consulter la documentation du module →

Messages IBOX

Message enregistré, notification externe et lecture sont des états distincts. Un lien temporaire /m/:token donne accès à son message ; ce lien doit rester confidentiel.

OutilFonction et effet
ibox.listLister les messages IBOX visibles par l’utilisateur courant.
ibox.getLire un message IBOX accessible.
ibox.mark_readMarquer un message comme lu. Cette opération n’envoie pas de réponse.
messages.draft_sendPréparer l’aperçu d’un message sortant avec un action_id pour confirmation.
actions.confirmExécuter après confirmation le travail préparé identifié par action_id.

Consulter la documentation du module →

Les scénarios de cette page illustrent des parcours, pas des données clients réelles ni une garantie de résultat. Les connexions et capacités doivent être activées et vérifiées pour votre environnement. Les outils métier officiels conservent leurs responsabilités.

Poursuivre la lecture

Ce parcours utilise les capacités de votre OS IA, configuré sous votre marque. Son périmètre suit votre équipe, les outils pris en charge et les règles d’accès. Comprendre votre OS IA ↗

Choisissez la prochaine étape.