Un mardi à 19 h 30 en février, vous avez des tables libres. Un samedi à 20 h 30, vous refusez du monde. Pourtant, la plupart des restaurants appliquent la même politique de paiement aux deux : une empreinte bancaire partout, ou rien nulle part. Dans le premier cas, vous freinez les réservations quand vous en manquez. Dans le second, vous supportez les no-shows quand chaque table compte.
La Smart Payment Policy SevenRooms (nommée Smart Payment & Policy dans le centre d'aide) répond à ce problème : le système applique automatiquement une politique de paiement différente selon l'affluence prévue de chaque créneau. Souple quand c'est calme, stricte quand c'est plein.
Cette fonction est en bêta limitée. Dans ce guide, nous vous disons précisément ce qu'elle fait, comment la configurer pas à pas, comment la combiner avec vos Access Rules et vos Shifts, et comment mesurer son effet.
Attention, fonction en bêta limitée. SevenRooms la décrit comme une limited beta, ouverte pendant la période de test aux venues Growth et Premium éligibles, avec un processeur de paiement compatible. Si elle n'apparaît pas dans votre compte, demandez l'accès à votre représentant SevenRooms.
Smart Payment Policy SevenRooms : le principe
Au lieu d'une seule règle, vous définissez trois politiques, une par état de demande :
- Cold (demande faible) : votre politique la plus souple. Exemple : aucune garantie. Elle réduit la friction à la réservation quand vous avez de la place.
- Neutral (demande moyenne) : votre politique standard. Exemple : une empreinte bancaire.
- Hot (forte demande) : votre politique la plus stricte. Exemple : empreinte bancaire avec frais d'annulation, ou acompte.
Le système classe chaque créneau de 15 minutes dans l'un de ces états, jusqu'à 30 jours à l'avance, puis applique la politique correspondante. Vous configurez une fois ; SevenRooms ajuste au fil de la demande.
Les règles de classement sont fixées par SevenRooms : les 20 % de créneaux les plus chargés sont Hot, les 20 % les moins chargés sont Cold, le reste est Neutral. Retenez bien ce point : vous ne réglez pas de seuils. Vous choisissez ce qui se passe dans chaque état, pas à partir de quel taux de remplissage on y entre.
Comment SevenRooms prévoit l'affluence
La prévision repose sur un modèle de machine learning qui analyse plus de 30 signaux : rythme des réservations en temps réel, saisonnalité, historique propre à votre établissement. Il ne se contente pas de supposer que « ce mardi ressemblera au mardi dernier ». SevenRooms indique que le modèle est testé chaque semaine et s'améliore avec les performances réelles de réservation.
Deux conséquences pratiques :
- Un nouvel établissement a peu d'historique. Le modèle s'appuie sur celui de votre venue : surveillez les premières semaines de près.
- Vous ne pouvez pas forcer un créneau. Le statut Hot, Neutral ou Cold est entièrement piloté par le modèle. Impossible de déclarer Hot votre soirée de la Saint-Valentin à la main. Pour une soirée spéciale, passez plutôt par une Access Rule dédiée (voir plus bas).
Étape 1 : partir du mode « Dynamic by Demand »
Vous n'avez rien à construire de zéro. SevenRooms crée automatiquement un Smart Mode nommé Dynamic by Demand. Dans le portail web :
- Ouvrez Settings > Availability Settings > Modes > Payment & Policy.
- Repérez le mode Dynamic by Demand.
- Cliquez sur les trois points pour le modifier.
Étape 2 : définir la politique de chaque état
Dans le Smart Mode, choisissez le Payment & Policy de chaque état. Pour chacun, deux possibilités : sélectionner un Payment & Policy Mode existant dans la liste, ou choisir + Custom Settings pour construire la politique directement dans le Smart Mode. Les Custom Settings couvrent l'exigence de paiement, les règles d'annulation et de remboursement, les droits du client de modifier ou d'annuler, et la Booking Policy. Cliquez sur Apply Settings quand vous avez terminé.
Voici trois profils réalistes pour un restaurant français. Les montants sont des exemples à adapter à votre ticket moyen, en € TTC.
Bistrot de quartier, 40 couverts, ticket moyen 35 €
- Cold : aucune garantie.
- Neutral : empreinte bancaire, sans débit.
- Hot : empreinte bancaire avec frais d'annulation de 20 € par personne en cas d'annulation moins de 24 h avant ou de no-show.
Table gastronomique, ticket moyen 120 €
- Cold : empreinte bancaire sans débit.
- Neutral : empreinte bancaire, avec débit de 40 € par personne en cas de no-show.
- Hot : acompte ou prépaiement partiel de 50 € par personne, remboursable jusqu'à 72 h avant.
Brasserie à forte fréquentation, ticket moyen 45 €
- Cold : aucune garantie, annulation libre.
- Neutral : empreinte bancaire sans débit.
- Hot : empreinte bancaire avec frais de 25 € par personne, annulation gratuite jusqu'à 24 h avant.
Ces exemples s'appuient sur les options proposées par les Custom Settings : exigence de paiement, règles d'annulation et de remboursement, droits de modification. Les montants et délais sont des exemples de māhie, pas des valeurs de SevenRooms. Un principe pour les fixer : le frais Hot doit couvrir une partie réaliste du coût d'une table vide, sans paraître punitif.
Pour choisir entre acompte, empreinte et prépaiement, lisez notre guide sur la politique de paiement adaptée à votre restaurant.
Étape 3 : appliquer le Smart Mode à vos Shifts
Un Smart Mode n'agit que lorsqu'il est assigné à un Shift. Deux méthodes.
Modes Matrix (recommandée), pour plusieurs Shifts à la fois :
- Allez dans Settings > Payment & Policy > Modes.
- Cliquez sur l'icône crayon à droite de la section Shifts.
- Glissez-déposez chaque Shift depuis la colonne de droite vers la colonne du mode voulu.
- Enregistrez. Le mode s'applique immédiatement à ces Shifts.
Depuis un Shift, un par un :
- Allez dans Availability Settings > Shifts.
- Ouvrez le Shift, puis Edit All Days.
- Dans le panneau (Shift Slideout), créez, modifiez ou sélectionnez le mode Payment & Policy.
SevenRooms recommande d'activer la fonction sur tous vos Shifts. Le système s'appuie sur l'historique et le rythme de réservation pour s'adapter : plus il couvre de services, plus il est cohérent. Déjeuner et dîner : appliquez un Smart Mode à chacun, avec des montants différents si les enjeux diffèrent.
Combiner avec les Access Rules
Par défaut, une Access Rule suit les réglages Payment & Policy de son Shift. C'est la configuration recommandée : vous mettez un Smart Mode sur vos Shifts, et les Access Rules suivent.
Vous ne changez ce comportement que pour une expérience particulière : menu dégustation du chef, soirée événementielle, réveillon. Pour cela :
- Settings > Availability > Access Rules, puis ouvrez l'Access Rule et cliquez sur Edit.
- Dépliez Payment and Policy, puis Edit.
- Décochez Follow Shift Settings for Payment & Policy.
- Sélectionnez Smart Mode: Demand-based payment requirement.
- Choisissez le mode dans la liste Smart Mode : un aperçu affiche les réglages Cold, Neutral et Hot.
- Cliquez sur Done, puis Review Changes.
Pour un événement où vous voulez le même prépaiement quelle que soit la demande, ne mettez pas de Smart Mode : gardez une politique fixe sur l'Access Rule, comme pour un réveillon prépayé.
Ce qui se passe quand un client modifie sa réservation
Selon les sources, une nouvelle exigence de paiement ne s'applique que si la modification change la disponibilité : date, heure ou nombre de couverts. Le système regarde alors l'état de demande du nouveau créneau et applique sa politique. Un client qui décale son dîner de 19 h à 20 h 30 un samedi peut donc basculer de Neutral à Hot et se voir demander une garantie. Une modification qui n'affecte pas la disponibilité ne déclenche rien.
Côté équipe, si votre compte a les droits nécessaires, vous pouvez ne pas appliquer le paiement exigé lors d'une réservation interne, en cochant « Override: do not enforce required payment » dans le flux d'ajout de réservation. Utile pour un habitué ou un VIP, à réserver à ceux qui connaissent la règle.
Risques et précautions
Faire varier la politique selon l'heure peut créer de l'incompréhension si vous ne l'encadrez pas.
- Clients frustrés. Deux amis réservent, l'un à 19 h sans garantie, l'autre à 20 h 30 avec empreinte. Ils s'en étonneront. Écrivez-le simplement : « Selon l'affluence, une garantie bancaire peut être demandée à la réservation. »
- Politique affichée incomplète. Le client doit voir, au moment de réserver, ce qui peut être débité et à quelle condition. Un débit mal expliqué est la première cause de contestation bancaire. Rédigez vos textes dans Settings > Guest-Facing Language > Policies et vérifiez qu'ils couvrent les trois états.
- Incohérence avec les autres canaux. Si vous êtes aussi sur des plateformes tierces, vérifiez ce que le client y voit réellement avant de lancer.
- Équipe non briefée. L'accueil et le téléphone doivent savoir expliquer pourquoi une garantie est demandée un soir et pas un autre.
- Bêta. Testez avant de généraliser, et gardez une politique fixe de repli.
Un bon réflexe : faites une réservation test sur un créneau que vous savez chargé, puis sur un créneau creux, et comparez ce que voit le client dans chaque cas.
Mesurer l'effet sur les no-shows et le remplissage
Les sources ne décrivent pas de rapport dédié à cette fonction. Mesurez donc vous-même, avec une méthode simple :
- Relevez l'état de départ : taux de no-shows, taux d'annulation tardive et couverts par service sur les 6 à 8 semaines précédentes, par jour et par Shift.
- Activez le Smart Mode sur tous les Shifts (c'est la recommandation de SevenRooms) et notez la date.
- Comparez à périodes équivalentes : mêmes jours de semaine, hors vacances et événements exceptionnels.
- Suivez trois indicateurs : le taux de no-shows aux heures de pointe, le taux de remplissage aux heures creuses, et le nombre de clients qui abandonnent au moment de la garantie, si votre suivi web le permet.
- Ajustez les montants et les textes, pas les seuils, que vous ne contrôlez pas.
Exemple de calcul, pas un résultat promis : un restaurant de 60 couverts qui passe de 8 % à 4 % de no-shows sur ses soirs Hot récupère environ 2 à 3 couverts par service. À 45 € de ticket moyen TTC, cela représente 90 à 135 € par soir.
Pour les créneaux Cold, la bonne question est de savoir si l'absence de garantie fait réellement gagner des réservations. Si vos creux restent vides malgré une politique souple, le problème est ailleurs : visibilité, prix ou offre. Voyez à ce sujet comment remplir vos services creux.
Questions fréquentes sur la Smart Payment Policy SevenRooms
Peut-on choisir soi-même les seuils d'affluence ?
Non. SevenRooms classe chaque créneau de 15 minutes comme Hot, Neutral ou Cold grâce à un modèle de prévision, et vous ne pouvez pas modifier ce statut à la main. Vous choisissez uniquement la politique de paiement appliquée à chacun des trois états.
Quelles formules SevenRooms donnent accès à cette fonction ?
Pendant la bêta limitée, elle est proposée aux venues Growth et Premium éligibles qui utilisent un processeur de paiement compatible. Contactez votre représentant SevenRooms pour savoir si votre compte peut y accéder.
Un client qui modifie sa réservation voit-il la politique changer ?
Oui, si la modification change la date, l'heure ou le nombre de couverts. Le système applique alors la politique du nouvel état de demande du créneau choisi. Une modification sans effet sur la disponibilité ne change rien.
La Smart Payment Policy remplace-t-elle les Access Rules ?
Non, elles se complètent. Les Access Rules suivent par défaut le Smart Mode de leur Shift, et vous ne leur en attribuez un autre que pour une expérience particulière, comme un menu dégustation.
Besoin d'aide pour configurer la Smart Payment Policy sur SevenRooms ?
Bien réglée, une politique de paiement selon l'affluence protège vos soirs chargés sans pénaliser vos services calmes. Mal réglée, elle déroute vos clients et complique le travail de l'accueil. Entre Smart Mode, Shifts, Access Rules et textes de politique, les réglages se croisent vite.
māhie est une agence spécialisée dans la restauration et l'hôtellerie, experte de SevenRooms. Pour ce sujet, nous pouvons :
- configurer votre Smart Mode : politiques Cold, Neutral et Hot, montants adaptés à votre ticket moyen, application aux Shifts ;
- auditer l'existant : Access Rules, Shifts, textes de politique et cohérence entre canaux ;
- rédiger vos politiques d'annulation pour qu'elles soient claires et acceptées au moment de la réservation ;
- mettre en place le suivi : no-shows, remplissage et conversions du module, avant et après activation ;
- former vos équipes à expliquer la règle aux clients et à gérer les exceptions.
Vous voulez savoir si votre compte est éligible et comment démarrer ? Découvrez notre expertise SevenRooms ou contactez māhie.

