Workflow Order Bumped : le serveur confirme, la cuisine ferme le ticket

Un steakhouse de Tribeca a vécu le scénario : la cuisine marque une côte de bœuf "ready", le ticket KDS disparaît, mais le serveur met huit minutes à arriver au pass. L'assiette sèche sous la lampe chauffante, le client se plaint, la cuisine jure que tout était parfait. Le pattern POS classique n'enregistre rien de ce trou parce que le ticket est déjà fermé côté cuisine.

Faille du ticket classique

Dans un flux KDS standard, le ticket passe par trois états : fired, preparing, ready. Dès que la cuisine valide ready, le ticket disparaît et la responsabilité bascule silencieusement vers le serveur. Or ce transfert n'est jamais mesuré : trois edge cases reviennent — serveur en salle annexe, deux serveurs qui croient que l'autre s'en occupe, assiette posée du mauvais côté du pass.

Pattern de confirmation serveur

Solution : quand la cuisine appuie sur ready, le ticket ne disparaît pas. Il change de couleur (vert vers ambre clignotant) et envoie une notification à la tablette du serveur. Le ticket ne se ferme qu'au tap "Récupéré" du serveur, loggé avec ID appareil et timestamp. Tribeca a constaté 34% de plaintes en moins et un temps moyen sous lampe passé de 4,2 à 1,7 min.

Couche optionnelle : confirmation client via smartphone. Cela complète la chaîne de preuve, précieuse pour les litiges.

Mise en œuvre

Trois events suffisent : kitchen_ready, server_picked_up, customer_acknowledged. Escalade à 90 secondes, alarme critique à 180. Mesurer le temps sous lampe par serveur en KPI hebdomadaire crée une pression sociale qui déplace la médiane.

FAQ

Cela ralentit-il la cuisine ? Non, le flux cuisine reste identique.

Sans tablette ? Apple Watch ou cloche du pass avec bouton de confirmation.

La confirmation client est-elle obligatoire ? Non, mais très utile en cas de litige.

Cet article vous a été utile ? Partagez-le.