Pizza på 12 minuter och mezze på 4 minuter vid samma bord. Avfyras de samtidigt står mezzen kall i åtta minuter. Svaret är algoritmisk fördröjning av biljetter.
Algoritmens logik
Varje produkt har fältet cook_time: pizza 12, mezze 4, varmrätt 8 minuter. Beställningen tar längsta cook_time som mål och räknar baklänges.
Pizza-biljett avfyras t=0, mezze t=8 (12 − 4). Båda klara t=12. Synkron servering i stället för två ojämna tallrikar.
Da Felice-fallet
Romersk trattoria med 28 sittplatser startade fan-out hösten 2025. Genomsnittlig biljett-till-bord-tid sjönk från 31 till 23 minuter — minus 26% utan extra personal.
- Pizzaugn tomgång: -18%
- Klagomål kall mat: -71%
- Bordrotation per timme: 1,4 → 1,8
Implementation
I thMenu är cook_time ett valfritt fält. Ifyllt: KDS sekvenserar automatiskt. Tomt: biljetten avfyras t=0 — full bakåtkompatibilitet.
Stationskapacitet räknas med: fyra pizzor i ugnen, femte ordern väntar tre minuter. Schemaläggaren känner ködjupet.
FAQ
Vem fyller i cook_time? Köksmästaren mäter varje produkt under realistisk belastning och anger det i thMenu-admin.
Fungerar det under rush? Särskilt då — stationsködjup ingår i realtid.
Vilken plan? Platinum, tillsammans med KDS och ordermodul.
Var detta hjälpsamt? Dela det.
Relaterade artiklar
Vad är en QR-meny? Komplett guide för restauranger
En QR-meny ger gästerna omedelbar tillgång till din meny via smarttelefon — utan…
Byta från pappersmeny till digital QR-meny: steg för steg
Vill du införa QR-menyer men vet inte var du ska börja? Den här guiden täcker fo…
Geo-riktade QR-menyer: olika språk efter besökarens IP
Hur ett 180-sitsigt all-inclusive-resort i Antalya dirigerar samma QR till turki…