Pizza 12 minut i mezze 4 minuty przy tym samym stoliku. Odpalenie obu jednocześnie sprawia, że mezze stoi zimne przez osiem minut. Odpowiedź: algorytmiczne opóźnienie ticketów.
Logika algorytmu
Każdy produkt ma pole cook_time: pizza 12, mezze 4, danie główne 8 minut. Zamówienie bierze najdłuższy cook_time jako cel i liczy wstecz.
Ticket pizzy startuje w t=0, mezze w t=8 (12 − 4). Oba gotowe w t=12. Synchroniczna podaż zamiast dwóch rozjechanych talerzy.
Przypadek Da Felice
Rzymska trattoria z 28 miejscami uruchomiła fan-out jesienią 2025. Średni czas ticket-stolik spadł z 31 do 23 minut, czyli -26%, bez dodatkowego personelu.
- Bezczynność pieca: -18%
- Reklamacje zimnego dania: -71%
- Rotacja stolików/godzinę: 1,4 → 1,8
Szczegóły implementacji
W thMenu cook_time jest polem opcjonalnym. Wypełnione — KDS sam sekwencjonuje; puste — ticket leci w t=0, pełna kompatybilność wsteczna.
Pojemność stacji też liczy: cztery pizze w piecu, piąte zamówienie czeka trzy minuty. Scheduler zna głębokość kolejki.
FAQ
Kto uzupełnia cook_time? Szef kuchni mierzy każdy produkt w realnych warunkach i wprowadza w panelu thMenu.
Działa w godzinach szczytu? Szczególnie wtedy — kolejka stacji w czasie rzeczywistym.
W jakim planie? Platinum, razem z KDS i modułem zamówień.
Czy to było pomocne? Udostępnij.
Powiązane artykuły
Czym jest menu QR? Kompletny przewodnik dla restauracji
Menu QR umożliwia klientom natychmiastowy dostęp do karty dań przez smartfon — b…
Przejście z papierowego na cyfrowe menu QR: przewodnik krok po kroku
Chcesz wdrożyć menu QR, ale nie wiesz od czego zacząć? Ten przewodnik obejmuje f…
Geo-targetowane menu QR: różne języki w zależności od IP gościa
Jak resort all-inclusive na 180 miejsc w Antalyi kieruje ten sam kod QR do menu …