Pizza på 12 minutter og mezze på 4 minutter ved samme bord. Avfyres samtidig, står mezzen kald i åtte minutter. Svaret er algoritmisk forsinkelse av bonger.
Algoritmens logikk
Hvert produkt har feltet cook_time: pizza 12, mezze 4, hovedrett 8 minutter. Bestillingen tar lengste cook_time som mål og regner baklengs.
Pizza-bongen avfyres t=0, mezze t=8 (12 − 4). Begge ferdige t=12. Synkron servering i stedet for to ukoordinerte tallerkener.
Da Felice-case
Den romerske trattoriaen med 28 sitteplasser slo på fan-out høsten 2025. Snitt bong-til-bord falt fra 31 til 23 minutter — 26% reduksjon uten ekstra personell.
- Pizzaovn tomgang: -18%
- Klager på kald mat: -71%
- Bordrotasjon per time: 1,4 → 1,8
Implementeringsdetaljer
I thMenu er cook_time valgfritt. Utfylt: KDS sekvenserer automatisk. Tomt: bongen avfyres t=0 — full bakoverkompatibilitet.
Stasjonskapasitet teller med: fire pizzaer i ovnen, femte bestilling venter tre minutter. Planleggeren kjenner kødybden.
FAQ
Hvem fyller ut cook_time? Kjøkkensjefen måler hvert produkt under realistisk belastning og legger det inn i thMenu-admin.
Holder det under rush? Spesielt da — stasjonens kø går inn i sanntid.
Hvilken plan? Platinum, sammen med KDS og ordremodul.
Var dette nyttig? Del det.
Relaterte artikler
Hva er en QR-meny? Komplett guide for restauranter
En QR-meny gir gjestene øyeblikkelig tilgang til menyen din via smarttelefon — u…
Bytte fra papirmeny til digital QR-meny: steg for steg
Vil du innføre QR-menyer, men vet ikke hvor du skal begynne? Denne guiden dekker…
Geo-målrettede QR-menyer: ulike språk basert på besøkendes IP
Hvordan et 180-seters all-inclusive resort i Antalya ruter samme QR til tyrkiske…