Déployer SevenRooms sur plusieurs marchés : le cas Nammos

Déployer SevenRooms pour une marque présente dans plusieurs villes ne se résume pas à créer un compte de plus. Il faut décider ce qui est commun à toutes les adresses et ce qui reste propre à chacune. Ce cas client revient sur le déploiement SevenRooms réalisé par māhie pour Nammos, à Dubaï et à Londres, puis explique pédagogiquement ce que cela implique pour un groupe qui opère sur plusieurs marchés.

Ce que cet article couvre, et ne couvre pas. Il s'appuie uniquement sur ce qui est public : la présentation de Nammos et du projet sur mahie.io, et le site nammos.com. Nous ne détaillons ni la configuration réelle de Nammos, ni ses résultats, ni ses données. La partie pédagogique s'appuie sur la documentation officielle de SevenRooms et décrit ce qui existe en général, pas ce qui a été activé chez ce client.

Nammos à Dubaï et à Londres : le contexte et le déploiement

Né à Mykonos, Nammos a exporté son art de vivre méditerranéen sur les plages de Dubaï et dans une adresse de deux étages à Mayfair, au cœur de Londres. La marque combine l'univers du beach club et celui du restaurant, avec une dimension internationale.

Sur mahie.io, Nammos figure parmi les maisons chez lesquelles māhie a déployé SevenRooms, avec Manko, L'Arc et Rural by Marc Veyrat. C'est la seule information publique sur la nature de la mission : un déploiement SevenRooms pour une marque présente à Dubaï et à Londres. Le détail du besoin de départ n'est pas publié, nous ne l'inventons donc pas.

En revanche, la situation est classique pour un groupe international : plusieurs adresses, des clientèles différentes, des langues, des devises et des habitudes de réservation qui varient d'un marché à l'autre, mais une marque qui doit rester cohérente.

Que signifie déployer SevenRooms pour une marque multi-marchés ?

Déployer SevenRooms sur plusieurs marchés, c'est configurer chaque établissement pour son contexte local, tout en gardant une structure commune pour la marque. Concrètement, trois questions se posent.

• Qu'est-ce qui doit être identique partout ? Le ton, la manière de qualifier un client, les catégories d'étiquettes (tags), les indicateurs que la direction suit.
• Qu'est-ce qui doit être local ? Les plans de salle, les horaires de service, les conditions de réservation, les politiques de paiement, la langue des communications.
• Qui a accès à quoi ? Un directeur de groupe, un responsable régional et un hôte à l'accueil n'ont pas les mêmes besoins.

Une bonne mise en place répond à ces trois questions avant de configurer le moindre réglage. Sinon, chaque adresse finit par fonctionner à sa manière et il devient impossible de comparer ou de piloter à l'échelle de la marque.

Cette réflexion vaut pour une marque de deux adresses comme pour un groupe de vingt. Plus le nombre de marchés augmente, plus l'absence de socle commun coûte cher : chaque nouvelle ouverture repart de zéro au lieu de reprendre une base éprouvée. À l'inverse, un socle trop rigide empêche les équipes locales de s'adapter à leur clientèle. Le travail d'un déploiement consiste à trouver le bon équilibre, adresse par adresse.

Structurer le groupe : établissements, Pods et accès

SevenRooms propose pour les groupes un Group Portal, qui permet de gérer les réglages, les accès et la performance sur l'ensemble d'un groupe d'établissements. Il est disponible sur certains packages SevenRooms. Vérifiez donc ce que le vôtre inclut.

Trois notions sont utiles à connaître.

• Les Pods : des regroupements d'établissements selon une caractéristique commune. Les catégories de Pods les plus courantes sont la cuisine, le type de service, la marque, la région, le pays ou la propriété. Pour une marque présente à Dubaï et à Londres, on pourrait par exemple imaginer une catégorie « Pays ». Ce n'est qu'un exemple d'usage, pas la configuration de Nammos. La gestion des Pods est réservée aux clients du package Premium, d'après la documentation.
• Les Group Users et les Roles : un utilisateur peut avoir accès à tout le groupe, à certains établissements ou à certains Pods, avec des rôles différents selon l'adresse. Mettre à jour un rôle une fois suffit pour l'appliquer à tous ceux qui l'ont.
• Les Tags globaux ou limités à certains Pods : les étiquettes de clients et de réservations peuvent être standardisées pour tout le groupe, ou réservées aux établissements concernés.

L'intérêt est simple : les équipes voient uniquement ce qui les concerne, et la direction garde une vue d'ensemble.

Exemple fictif, pour illustrer : une marque ouvre une deuxième adresse dans un autre pays. Si chaque équipe invente ses propres étiquettes (« VIP », « Client important », « Gros client »), les rapports de groupe ne veulent plus rien dire. Si la marque définit trois catégories communes dès le départ et laisse deux étiquettes libres par adresse, les équipes gardent leur souplesse et la direction garde sa lecture. Ce choix de méthode coûte une demi-journée de cadrage et évite des mois de nettoyage.

Langue, paiements et règles de réservation : ce qui varie selon le marché

Chaque marché a ses propres usages. Voici ce que SevenRooms permet d'adapter, selon la documentation.

La langue des clients. Le réglage Guest-Facing Language permet de personnaliser les textes affichés au client (widgets de réservation, pages de confirmation, e-mails, SMS, politiques) et d'activer plusieurs langues. SevenRooms indique que toute personnalisation doit être traduite manuellement dans chaque langue activée. Si vous changez un terme, par exemple, vous devez mettre à jour la traduction dans toutes les langues. Cette fonction dépend aussi du package.

Les règles de réservation et de paiement. Chaque établissement a ses propres réglages de disponibilité et de paiement. Pour une adresse saisonnière ou une adresse très demandée, les règles ne seront pas les mêmes. Sur le sujet des acomptes, voyez notre article sur l'acompte, l'empreinte bancaire et le prépaiement.

La circulation des clients entre adresses. Avec la fonction de promotion croisée (Cross-Promotion), un client qui ne trouve pas de table dans un établissement peut se voir proposer les autres établissements du groupe. Selon la documentation, les widgets Cross-Promotion et Group sont réservés aux clients des packages Growth ou Premium.

Les données personnelles. Les règles de protection des données varient selon les pays. Avant de configurer le consentement, les e-mails et le marketing, faites valider votre approche par votre conseil juridique pour chaque marché. Pour le cadre européen, notre article sur l'emailing et le RGPD avec SevenRooms donne les bases.

Suivre la performance et unifier la connaissance client

Un déploiement multi-marchés n'a de valeur que si la direction peut comparer. Le Group Portal propose des rapports consolidés (Group Reporting). Selon la documentation, ils permettent notamment de :

• consulter les réservations passées et futures, et suivre les couverts ;
• comparer les établissements et repérer les plus performants ;
• analyser annulations et no-shows ;
• suivre les clients qui reviennent ;
• examiner les paiements et les remboursements, avec des montants en devise locale.

Les Pods servent de filtres dans ces rapports : on peut par exemple comparer les établissements d'une même région.

Côté connaissance client, l'enjeu est la cohérence. Des Auto-tags et des Reservation Tags définis de la même manière dans toutes les adresses permettent de segmenter la clientèle de façon comparable. Notre article sur les Auto-tags explique comment les construire.

À noter. Les fonctions, les packages et les libellés SevenRooms évoluent. Avant de bâtir un plan de déploiement, confirmez avec SevenRooms ce que votre formule inclut aujourd'hui, notamment le Group Portal, la gestion des Pods, Guest-Facing Language et Cross-Promotion. Un plan fondé sur une fonction que votre package n'inclut pas coûte du temps à chaque étape suivante.

Comment aborder un déploiement SevenRooms multi-établissements

Voici la méthode que nous recommandons à un groupe qui s'étend sur plusieurs marchés.

1. Cartographier les adresses : types de service, langues, devises, équipes, outils déjà utilisés (caisse, site, newsletter).
2. Définir le socle commun : catégories de tags, rôles utilisateurs, indicateurs de suivi, ton des communications.
3. Définir les variations locales : horaires, politiques de paiement, langues activées, règles d'accès à la réservation.
4. Configurer un établissement pilote, le tester avec de vraies réservations, puis dupliquer la logique aux autres adresses.
5. Relier SevenRooms au reste de l'écosystème : site, CRM, newsletter, formulaires. Notre service SevenRooms inclut ces connexions jusqu'à l'API.
6. Former chaque équipe locale, en tenant compte des différences de langue et de rôle.
7. Suivre après le lancement : vérifier les rapports de groupe, corriger les écarts, ajuster les règles.

Quelques erreurs fréquentes à éviter :

• configurer chaque établissement séparément, sans socle commun ;
• multiplier les tags sans définition partagée ;
• oublier de traduire chaque personnalisation dans toutes les langues activées ;
• donner à tout le monde un accès complet « pour aller plus vite » ;
• reporter la formation des équipes locales après l'ouverture.

Questions fréquentes sur le déploiement SevenRooms multi-marchés

Besoin d'aide pour déployer SevenRooms sur plusieurs établissements ?

Un groupe qui grandit a besoin d'une structure claire dès le départ. māhie a déployé SevenRooms plus de 60 fois pour des restaurants, des hôtels et des groupes, et accompagne plus de 90 maisons.

• Mise en place et migration depuis votre ancien outil, sans perdre vos clients.
• Audit sur-mesure de votre configuration actuelle.
• Segmentation des clients : VIP, habitués, entreprises, première visite.
• Connexions API avec votre site, votre CRM, votre newsletter et vos outils internes.
• Formation des équipes : salle, réservation et direction.

Découvrez notre offre SevenRooms et nos projets, puis Contactez māhie.