Dans un restaurant, les outils de réservation, plan de salle, caisse et commandes doivent rester compréhensibles pendant le service. Une réservation de quatre personnes n’est pas seulement une table occupée : elle mobilise un créneau, une capacité et parfois une préparation particulière. La salle et la cuisine doivent partager les changements utiles. Le choix des outils part donc du service réel, avec arrivées tardives, groupes et modification d’une commande.
Point de départ
Le résultat à obtenir avant de choisir les outils
Priorité : Faire fonctionner réservation, commande et paiement pendant le service.
Socle utile : Un plan de salle à jour, des réservations visibles par l’équipe, une caisse fiable, une gestion des absences et des commandes sans double saisie.
Données de référence : Service, capacité par créneau, table, statut de présence, commande, addition et préférence consentie du client.
Ordre de mise en place
Quatre étapes pour construire sans disperser l’équipe
Dessiner le parcours d’un service chargé : réservations, arrivées tardives, sans réservation et groupes.
Fixer une capacité par créneau et les règles de confirmation, d’absence et de modification.
Relier plan de salle, commande et addition avec des rôles clairs entre accueil, salle et cuisine.
Tester une commande externe et un incident de paiement au même moment que le pic de service.
Coopération
Deux passages de relais à sécuriser
Réservation → salle
L’équipe doit connaître nombre de convives, horaire, besoins déclarés et statut de confirmation sans consulter plusieurs écrans.
Salle → caisse
Les ajouts et séparations d’addition doivent rester traçables sans créer d’écart entre commande servie et montant encaissé.
Essai opérationnel
Une démonstration à mener sur un dossier complet
Tester une réservation de groupe modifiée, une arrivée tardive, une commande sur place et une commande externe au moment du pic de service.
Signal d’alerte : Une solution qui ajoute des écrans en cuisine et en salle peut ralentir le service malgré une belle interface côté client.
Épreuve de terrain
Tester la stack lorsqu’un dossier change
Une démonstration standard renseigne peu sur la continuité du service. Ce scénario met les données, les responsabilités et la reprise au même endroit.
Situation à rejouer
Une réservation de groupe modifie son effectif quelques heures avant le service pendant qu’une autre arrive par un canal différent. Vérifiez la capacité réelle des tables, les consignes alimentaires et l’information donnée à l’équipe de salle. Pendant l’essai, faites expliquer au responsable de salle ce qui est confirmé, déplacé ou encore en attente. Une note libre non lue par la cuisine ne démontre pas la prise en compte du changement. Le plan de salle et la commande doivent conserver les références utiles sans exposer à chaque intervenant des données client dont il n’a pas besoin.
Condition avant d’étendre
Ne retenez pas un logiciel sur le seul nombre de couverts réservés. Observez la charge de saisie en service, les absences, les paiements et la possibilité de corriger une table sans perdre l’historique client. Validez la reprise d’un service par une autre équipe : réservations attendues, groupes, paiements éventuels et consignes doivent rester retrouvables. Comparez le temps passé à corriger les écarts et le nombre de doubles saisies ; la vitesse d’ouverture de l’écran ne mesure pas à elle seule l’efficacité pendant le service.
Arbitrage
Ce qu’il faut comparer avant d’étendre la stack
Une interface riche peut ralentir le service si chaque modification impose plusieurs manipulations. Évaluez les outils pendant un scénario dense, avec des collaborateurs de rôles différents.
Les conventions de mesure ci-dessous sont proposées pour le pilote. Les chiffres illustrent les calculs ; ils ne constituent pas des objectifs de performance. Conservez période, population, source et responsable de chaque mesure.
Trois mesures, leurs calculs et leurs limites pour Stack d’un restaurant
Mesure
Périmètre et calcul
Exemple fictif
Point de vigilance
Temps entre arrivée et prise en charge
Mesurer de l’arrivée constatée à la première prise en charge définie par l’établissement, avec même définition sur tous les services.
Pour cinq groupes, attentes de 2, 3, 4, 5 et 16 minutes : médiane quatre minutes et moyenne six minutes.
Le dernier groupe reste visible. Distinguer premier accueil, prise de commande et service du premier plat ; ce sont des étapes différentes.
Réservations non honorées et capacité réellement utilisée
Séparer réservations, couverts réservés, personnes présentes, annulations reçues et clients sans réservation sur le même service.
Quarante places, 32 couverts réservés, quatre absents sans autre changement : 28 présents réservés. Les 12,5 % d’absents portent sur 32, les 70 % de places occupées sur 40.
Une rotation peut faire servir plus de personnes que de places. Ces ratios ne décrivent ni le nombre de tables ni toutes les personnes servies pendant la soirée.
Corrections de commande et d’addition en service
Compter les commandes et additions distinctes corrigées, puis préciser le type d’écart et son effet en salle, cuisine ou paiement.
Sur 100 additions, huit sont corrigées au moins une fois ; ces huit corrections de dossier correspondent à onze actions enregistrées.
Huit dossiers affectés ne signifient pas onze clients mécontents. Garder le motif et vérifier si le résultat a été répercuté sur tous les systèmes concernés.
Utilisez les mêmes cas avec chaque fournisseur, puis comparez prix, support, reprise des données et traitement des exceptions. Filtrer le répertoire pour ce profil.
Décider par étapes
Trois passages avant d’étendre le dispositif
La caisse ou référentiel choisi porte produits, variantes, suppléments et taxes. Les canaux envoient une commande identifiée et son état ; cuisine, salle et paiement utilisent la même décision d’acceptation ou de refus.
Exercice fictif : un menu, une rupture et une réservation de groupe sont modifiés pendant le service ; la salle et la cuisine doivent retrouver le même état.
Preuves et décisions pour Stack d’un restaurant
Passage
Preuve attendue
Quand limiter ou arrêter
Avant diffusion du menu
Le menu présente le prix et les suppléments de la variante vendue ; une information alimentaire confirmée reste rattachée au bon plat.
Retirer le plat ou la variante dont l’information nécessaire reste inconnue ; ne pas recopier celle d’un produit au nom proche.
Avant service réel
Une rupture empêche une nouvelle commande du produit et un refus est retrouvé côté canal, salle et cuisine, avec prochaine action client.
Réduire les canaux ouverts si une commande reste présentée comme acceptée après refus ou si personne ne reprend le client.
Avant nouveau site
Deux établissements conservent horaires, menu et capacité propres ; une correction du site A laisse le site B inchangé.
Reporter le nouveau site si la correction d’un menu, d’une table ou d’un paiement écrase les références d’un autre établissement.
Rejouez achat, livraison, réservation et présentation en salle. Contrôlez inclusions, différence éventuelle à payer et statut après consommation. Testez une seconde présentation du même bon et une annulation avant le service. Le personnel doit pouvoir répondre sans accéder à toutes les données du payeur.
Décision avant d’étendre
Promouvoir les bons lorsque salle, réservation et encaissement partagent un statut cohérent. Corriger les consommations sans trace avant d’ouvrir de nouveaux canaux.
Le service qui garde capacité, commande et addition cohérentes
Organisez le service autour de capacités réellement utilisables, puis reliez réservation, présence, table et commande. Le nombre de sièges théorique ne décrit pas toutes les combinaisons de groupes ou les contraintes de circulation. L’équipe doit pouvoir accepter un changement sans créer une promesse que le plan de salle ne permet pas de tenir.
Pendant la démonstration, ajoutez un groupe, une arrivée tardive et une correction de commande pendant un service chargé. Vérifiez le passage de relais entre accueil, salle, cuisine et caisse. Conservez le résultat des actions, pas seulement la rapidité apparente de l’interface : une modification doit être lisible au poste qui doit l’exécuter.
Informations à transmettre et responsabilité à désigner
Objet
Contenu utile
Responsable à identifier
Service
Créneau, capacité et groupes attendus
Responsable de salle
Réservation
Effectif, présence et demande utile
Accueil
Commande
Lignes, modifications et état de préparation
Salle et cuisine
Addition
Montant, partage, paiement et correction
Caisse
Grille éditoriale à adapter à votre organisation ; les rôles indiquent une responsabilité à attribuer.
Distinguer établissement, service de salle et réservation
Un restaurant peut appartenir à un hôtel ou partager une adresse avec un autre service. Son identité, ses horaires et ses réservations doivent rester explicites. Les exercices portent sur les informations qui permettent au client de trouver la bonne salle et à l’équipe de comprendre le dossier reçu.
Cas pédagogiques à adapter au périmètre de votre organisation.
La fiche du restaurant reprend les horaires de l’hôtel
Le bâtiment est ouvert, mais le service de restauration fonctionne sur ses propres périodes. Une identité commune d’adresse ne démontre pas que la salle accueille des clients à toute heure.
Décision à préparer : Garder l’objet restaurant et ses services séparés, vérifier les horaires à la source appropriée et corriger les liens qui reprennent le bâtiment. Faire distinguer ouverture générale et créneau réservable.
Preuve à transmettre : Objet décrit, période de service, source et surfaces corrigées.
Le lien de groupe revient à une table de deux
Le partenaire ne conserve pas le nombre de couverts ou ouvre un circuit qui ne prend pas les groupes. La page peut rester accessible sans satisfaire la demande initiale.
Décision à préparer : Tester le périmètre autorisé et les paramètres de couverts. Orienter vers le circuit confirmé pour les groupes et préciser l’action attendue. Ne présenter aucun clic comme une table acquise.
Preuve à transmettre : Couverts demandés, parcours ouvert et état de confirmation réellement disponible.
Une importation multilingue altère le nom de salle
Le texte source permet d’identifier un espace particulier, mais son nom est tronqué ou normalisé dans le dossier. La salle peut alors être confondue avec une autre au même établissement.
Décision à préparer : Comparer libellé source, enregistrement et document remis. Corriger la transformation, conserver la référence d’espace et vérifier l’affichage dans les langues utilisées. Une clé de recherche normalisée reste distincte du libellé client.
Preuve à transmettre : Référence de salle, texte préservé et résultat relisible pour l’équipe.
Relire les usages avant de clôturer
La revue finale vérifie que le client atteint le bon établissement et que la réservation désigne le service exploitable. Le même nom sur une carte, une facture et un bâtiment ne suffit pas pour rapprocher tous les objets. Gardez adresse, entrée, espace et créneau selon le cas, avec leurs responsables. Les descriptions d’équipements ou de services communs ne doivent pas devenir des inclusions de la table réservée.
Quel dénominateur utiliser pour les absences au restaurant ?
Nommez l’unité choisie. Quatre couverts absents sur 32 réservés donnent 12,5 %, tandis que 28 présents sur 40 places donnent 70 % avant rotation et arrivées sans réservation. Les annulations annoncées doivent aussi être distinguées des absences. Un taux par réservation serait encore une autre mesure.
Pourquoi compter les additions corrigées plutôt que les seules actions ?
Une même addition peut être corrigée plusieurs fois. Huit additions affectées sur cent donnent 8 %, même si onze actions de correction ont été enregistrées. Gardez aussi les motifs et la charge ; le volume d’actions seul ne dit pas combien de dossiers ou de clients ont été touchés.
Que transmettre lors d’un changement de groupe ?
Le nouvel effectif, le créneau, la capacité disponible et les consignes réellement utiles au service. Désignez qui confirme le changement et qui ajuste le plan de salle. Évitez de laisser l’accueil et la cuisine travailler sur des versions différentes.
Peut-on utiliser l’identité de l’hôtel pour toutes les réservations du restaurant ?
L’adresse peut être partagée, mais le restaurant, la salle et le service ont leur périmètre. Conservez les références utiles à la réservation et les informations de leur propre source.
Documentation et application
Des références pour préparer le travail
Stripe : distinguer les règles d’idempotence v1 et v2
La documentation distingue les générations d’API. La même expression « requête idempotente » ne suffit pas à décrire les conditions d’une reprise.
API v1 : Une fois l’exécution commencée, le premier statut et le corps sont conservés pour la clé, y compris une réponse 500. Relire l’objet et l’état de l’opération avant de changer de clé après une erreur.
Durée de conservation v1 : Une clé peut être supprimée après au moins 24 heures ; sa réutilisation après suppression peut démarrer une nouvelle requête. Conserver aussi un identifiant métier durable ; la clé HTTP n’est pas une protection permanente.
Ces règles concernent Stripe ; elles ne confirment ni la prestation touristique ni le traitement idempotent d’un second système.
Stripe — Idempotent requests · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Réservation de restaurant : taille du groupe, espace et créneau
Le modèle Dining de Google décrit la disponibilité avec le nombre de convives et le créneau du service, plutôt qu’avec la seule capacité générale du restaurant.
Convives : resources.party_size doit être défini pour chaque créneau de réservation Dining. Ne pas remplacer la taille du groupe par le nombre de tables ou de créneaux ouverts.
Espace : room_id et room_name sont des précisions optionnelles des ressources Dining. Conserver l’identité de l’espace lorsqu’un choix de salle ou de terrasse est effectivement proposé.
Modèle Google Actions Center, à distinguer des contrats d’autres logiciels de restaurant. La présence d’un champ optionnel ne confirme pas une salle ou une terrasse pour chaque offre.
Restaurant : une demande reçue peut encore attendre le commerçant
Dans le parcours asynchrone documenté, le commerçant confirme ou refuse après l’envoi de la demande. Cet état doit rester visible pour le client.
Mode par créneau : confirmation_mode est défini au niveau de la disponibilité ; un même établissement peut proposer des créneaux synchrones et asynchrones. Ne pas attribuer un seul mode de confirmation à tout le restaurant.
En attente : PENDING_MERCHANT_CONFIRMATION précède une éventuelle confirmation. Ne pas envoyer une consigne affirmant que la table est confirmée à partir de cet état.
Fonction à activer dans le programme concerné, notamment Dining sans paiement. Ne pas généraliser ce comportement à tous les moteurs de réservation ou aux activités OCTO.
Deliverect : lire un statut avec son domaine et son origine
Le même nombre peut décrire deux étapes différentes selon qu’il vient de la caisse ou du suivi de livraison. Le registre doit garder cette distinction avant de produire un message destiné au client.
Préparation en caisse : Les statuts POS séparent Accepted 20, Preparing 50 et Pickup Ready 70. N’affichez pas « prêt à retirer » sur la seule acceptation de la commande.
Code 90 selon le domaine : POS Finalized 90 ne prouve pas la livraison ; côté livreur, 90 désigne Delivered. Conservez domaine, libellé et origine ; ne traduisez pas tout entier 90 par « livré ».
Nomenclature Deliverect publiée le 7 avril 2026 et consultée le 22 octobre 2026. Ces codes appartiennent aux domaines documentés par ce fournisseur ; les données ci-dessous sont des observations fictives simplifiées, pas des messages prêts à envoyer à son API.
Deliverect Channel : accusé de réception, identifiant et publication du menu
La réussite d’un appel HTTP, la création d’une commande et la mise en ligne d’un menu doivent être suivies comme des résultats distincts.
Retour HTTP 201 : Deliverect traite les commandes de façon asynchrone : un 201 confirme la réception de la requête, pas la création de la commande. Attendez les observations métier avant de clôturer la transmission comme réussie.
Identifiant de commande : La FAQ demande un channelOrderId unique, non réutilisable durant les 48 heures suivant le retrait, tous comptes confondus ; un doublon peut être écarté après le 201. Choisissez un identifiant globalement unique ; ne recréez pas une commande pour contourner un statut encore inconnu.
FAQ de l’intégration Channel Deliverect consultée le 22 octobre 2026. La présence d’une fonction dans cette documentation ne prouve pas sa configuration pour un compte. Aucun appel fournisseur, envoi de commande ou publication de menu n’est effectué par cette page.
Restaurant : identité de zone et descriptions cohérentes
Dans Actions Center, une zone fait partie de la définition du créneau. Son identité et sa description doivent suivre les échanges, pas seulement l’écran initial.
Identité stable : room_id identifie la zone et doit rester stable pour permettre le rapprochement avec les anciennes réservations. Gardez une identité durable même lorsqu’un libellé est corrigé.
Nom de zone : room_name doit désigner une zone de placement ou une expérience prépayée ; le guide déconseille d’associer une room à l’espace général par défaut. Distinguez terrasse, bar et expérience réservée sans transformer chaque note de préférence en zone.
Intégration Reservations End-to-End Actions Center, vérifiée le 23 octobre 2026. L’identité d’une zone ne prouve pas l’affectation physique d’une table.
Wix Restaurants : fréquence des créneaux, durée à table et pause des réservations
Un créneau affiché toutes les quinze minutes ne signifie pas qu’une table se libère toutes les quinze minutes. Les paramètres de Wix Restaurants répondent à des questions différentes : quand réserver, quand arriver et combien de temps occuper une table.
Délai de réservation : Le préavis minimal ferme la réservation avant son début ; le préavis maximal fixe l’horizon de réservation. Distinguez ces délais de l’heure du service et de la durée du repas.
Fréquence des départs : Time slots règle l’intervalle entre les heures proposées au client. Un intervalle court ne démontre pas qu’une même table peut être attribuée de nouveau à cet intervalle.
Disponibilité en ligne de Wix Restaurants Table Reservations, documentation consultée le 23 octobre 2026. Les règles dépendent du paramétrage du restaurant et de son établissement. Les horaires et durées des exemples sont fictifs, sans réservation ni disponibilité réelle.
Wix Restaurants : distinguer réservation, attribution et combinaison de tables
Recevoir une réservation ne prouve pas qu’une table précise a été attribuée. Le mode de gestion des tables, les combinaisons et les expériences doivent être relus séparément avant de promettre une place au client.
Attribution automatique ou manuelle : En mode automatique, Wix attribue les tables disponibles. En mode manuel, une réservation en ligne reste possible même si aucune table n’est disponible. Testez le mode réellement activé ; retrouvez l’attribution dans le dossier au lieu de la déduire de la seule réservation.
Combinaison de tables : Une combinaison possède ses propres nombres minimum et maximum de places. Son réglage de disponibilité en ligne s’ajuste en mode automatique. Relisez la capacité configurée de la combinaison : additionner les places de chaque table ne démontre pas la capacité commercialisée.
Périmètre : application Wix Table Reservations et réglages décrits dans l’aide consultée le 23 octobre 2026. Ce complément ne décrit pas les règles des autres logiciels ni tous les cas de demandes de grands groupes. Les exemples n’établissent aucune disponibilité réelle.
ResDiary : une demande en liste d’attente reste distincte d’une nouvelle réservation
Le parcours restaurant ResDiary fournit un exemple concret pour tester une liste d’attente : inscription, notification et réservation sont trois étapes distinctes. Cette distinction aide aussi à rédiger un scénario d’essai pour une activité, sans attribuer les réglages ResDiary aux autres produits.
Notification et nouvelle réservation : L’équipe peut notifier manuellement les clients lorsqu’une table se libère. Le message leur indique de faire une nouvelle réservation. Conservez l’état « notifié » jusqu’au résultat du nouveau parcours ; ne transformez pas l’envoi du message en réservation confirmée.
Unité de capacité : L’aide prévoit 50 % du maximum de couverts par intervalle pour la liste d’attente : dix couverts donnent cinq couverts proposés. Comptez des convives, pas cinq groupes de taille quelconque. Rejouez l’essai avec des tailles de groupes différentes.
Règles du parcours ResDiary consultées le 23 octobre 2026. La demande en attente ne garantit ni table, ni priorité exclusive après notification. Pour une activité ou un autre logiciel de restaurant, les règles de capacité et de conversion doivent être vérifiées dans sa propre documentation.
Le compte rendu de pilote et le relais de service complètent les documents des guides de ce parcours. Consultez les informations à rapprocher et les contrôles proposés.
Le premier budget doit réduire les ruptures pendant le service. Une réservation correcte peut encore poser problème si le nombre de convives change sans modifier le plan de salle. Une commande envoyée peut encore nécessiter une correction que la cuisine n’a pas reçue. Décrivez ces tâches avant de choisir de nouveaux canaux.
Distinguez activité sur place, commandes à emporter et livraison. Les capacités, horaires, documents et responsabilités peuvent différer. Le suivi doit conserver les modifications et annulations sur chaque circuit ; un total commercial unique peut masquer un service déjà effectué ou un paiement encore incertain.
Testez une addition partagée avec une ligne corrigée puis un remboursement. Le personnel doit retrouver les opérations sans reconstituer l’histoire oralement. Le bilan du premier lot porte sur les ressaisies, erreurs de transmission et écarts de clôture ; le nombre de fonctionnalités achetées n’est pas une mesure d’amélioration du service.
Priorités, périmètre et preuve attendue
Étape
Périmètre utile
Preuve à obtenir
Premier lot
Créneaux, tables et transmission salle-cuisine.
Retrouver les changements dans le poste qui doit agir.
Lot suivant
Caisse, paiement et clôture.
Expliquer une correction ou un remboursement ligne par ligne.
À différer
Nouveau canal sans capacité d’exécution identifiée.
Vérifier la charge simultanée et la gestion des exceptions.
Service fictif sans rotation ni arrivée sans réservation dans ce calcul : 40 places, 32 couverts réservés et quatre absents, sans annulation préalable ni autre changement. La réservation couvre 80 % des places ; les 28 présents réservés en occupent 70 %. Le taux d’absence par couvert réservé est de 12,5 %.
Avant d’investir : Le nombre de places est une capacité instantanée ; la rotation et les clients sans réservation modifient les personnes servies. Séparez couverts, tables, réservations et encaissements, puis vérifiez le changement de taille d’un groupe dans salle, cuisine et acompte éventuel.
