Un ticket ici n'est pas un bout de papier qu'un commerce imprime puis perd de vue — c'est une ligne que les deux parties voient en même temps. Un scan délivre un ticket, rattaché à un groupe de file et à une taille de groupe. Le personnel appelle le prochain ticket depuis le comptoir libre, et chaque changement de statut passe par la même base de données, pas par un tableau blanc qu'un seul employé garde en tête.
Obtenir un ticket — en libre-service ou délivré par le personnel
Un commerce peut gérer plusieurs groupes de file en même temps (retrait de commande, retours, un comptoir précis) et choisir, groupe par groupe, si le client scanne le QR code lui-même ou si le personnel délivre le ticket à sa place. Un ticket peut porter un nom, un numéro de contact et une taille de groupe. Chaque ticket appartient à la journée propre du commerce, pas à l'horloge de l'appareil qui scanne — un commerce ouvert après minuit se retrouverait avec deux tableaux mélangés si le jour était deviné d'après l'heure du téléphone. Si le serveur ne peut pas dire quel jour c'est pour ce commerce, l'écran annonce un échec de chargement, plutôt que de deviner et d'afficher un tableau vide alors que des gens attendent vraiment.
Suivre sa propre position
Une fois le ticket obtenu, le client voit son numéro, son groupe et son statut actuel. La position se rafraîchit toutes les 10 secondes tant que l'écran reste ouvert — ce n'est pas un compteur live à la seconde. Quand c'est réellement son tour, une notification push arrive immédiatement avec le comptoir où se rendre, donc pas besoin de garder l'écran ouvert pendant toute l'attente.
Le côté commerce — appeler, faire avancer le statut, limiter les absences
Le personnel appelle le prochain ticket de son propre comptoir, peut rappeler le même ticket si le client ne l'a pas entendu, et peut annuler un appel instantanément en cas d'erreur. Chaque groupe de file fixe le nombre de fois qu'un ticket peut être appelé et manqué avant d'être considéré comme absent, pour que toute la file ne reste pas bloquée derrière quelqu'un qui ne se présente jamais. Chaque écriture — délivrer, appeler, changer de statut, clôturer — passe par des fonctions serveur qui vérifient elles-mêmes le droit ; la table des tickets elle-même n'a aucun droit d'écriture directe, donc aucun ticket ne peut exister sans que le système le sache.
Où la file s'insère dans le reste
Un établissement qui sert au comptoir plutôt qu'à table remplace le QR de table du module restauration par un numéro d'attente, et un salon qui préfère des créneaux fixes utilise plutôt les rendez-vous.
Du côté du personnel, groupes de file et comptoirs se créent dans la console professionnelle, sur le même tableau de bord que les commandes et les congés. Un parc de voitures délivre lui aussi des tickets par QR, mais tarifés à la sortie plutôt qu'appelés à un guichet : voir stationnement.
Et une billetterie d'événement scanne ses QR codes par le même mécanisme, avec une réponse différente selon que le billet vient d'être admis ou l'avait déjà été.
Une capture d'écran d'un QR code de file ne fonctionne pas — il faut scanner le panneau physique présent sur place. Le jeton est lié au cycle d'émission actuel de ce groupe, pas à un code fixe réutilisable indéfiniment.
L'écran du ticket s'ouvre aussi depuis le lien imprimé sur le reçu (koratland.com/queue?...) — pas besoin de l'app pour vérifier sa propre position depuis un navigateur.