Order Throttling : ralentir le flux de commandes quand la cuisine est saturée

Samedi 21h30, 18 tickets ouverts en cuisine, le chef crie "stop". Continuer à accepter des commandes QR allonge la cuisson des pâtes de 35 minutes — c'est un avis 1 étoile garanti. Solution : l'order throttling.

Seuil de profondeur de file

Chaque cuisine a un plafond de tickets concurrents qu'elle peut exécuter correctement. thMenu compte les commandes ouvertes ; au-delà de 15 tickets, le menu QR affiche "Nous sommes très sollicités, réessayez dans 5 minutes." Le panier reste sauvegardé.

Le seuil est dynamique : 12 au déjeuner, 18 au dîner. Si le poste pizza est le goulet, on peut activer un throttling par catégorie.

Exemple romain : fila virtuale

Da Enzo à Trastevere utilise une file virtuelle depuis 2023. Le client voit "attente actuelle 12 minutes, votre commande sera prise à 20h45" et accepte en conscience. Pas de frustration : l'attente était annoncée.

Aux États-Unis, DoorDash propose la même idée avec "pause new orders" : si le temps de préparation dépasse 35 minutes, le restaurant suspend les commandes 15 minutes.

Implémentation technique

Backend : le KDS maintient le compteur en D1. POST /api/orders vérifie ; si le seuil est dépassé, l'API renvoie 429 Too Many Requests avec Retry-After: 300. Le client affiche un compte à rebours de 5 minutes et retente automatiquement.

Règle d'or UX : ne cachez pas l'attente, valorisez-la. "Nous sommes occupés car tout est cuisiné minute" transforme la contrainte en argument qualité.

FAQ

On perd du chiffre ? Non — un avis 1 étoile coûte plus cher à long terme.

Quel seuil choisir ? 3-5 tickets actifs par poste, soit 18-25 pour 5 postes.

Si le client part ? Le panier reste 24 heures ; il reprend à son retour.

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