Riders queueing out the door
It is the first warm Saturday of the year and every order arrives at once. The kitchen has fifteen open tickets. The apps still think each order takes fifteen minutes, so riders are arriving for food that has not been started. They lean on the counter, check their phones and complain. Some leave and the app sends another. The customer watches the tracker stall.
Someone on the counter remembers that each app has a busy setting, and tries to find it. On one tablet it is a slider. On another it is buried in settings. On the third it is a pause button that stops orders completely, which is not what you wanted. By the time they have found them all, the rush is easing.
Why timings never match the kitchen
Prep time on the apps is usually set once, when the account is created, and left alone. It reflects a normal Tuesday, not a Saturday peak. Adjusting it during service needs someone to notice the kitchen is behind, remember where the setting is on each device and change them all. Those are three separate acts of attention at the worst possible time.
Nobody has a clear signal either. The chef knows the kitchen is struggling, but the counter decides the app settings. The number of open tickets is the most honest measure of how busy you are, and it is not connected to anything.
What mismatched timings lead to
| Symptom | Consequence |
|---|---|
| Riders arrive before food is ready | Crowded counter, frustrated riders, reassignments |
| Food ready with no rider | Orders go cold waiting for collection |
| Orders marked late | Weaker standing on the app |
| Pausing a whole channel | Lost orders when you only needed more time |
| Direct customers given wrong times | Complaints on your own channel |
The apps generally reward accuracy. A realistic longer time that you meet tends to go down better than a short one you miss, but only if you can change it quickly.
One busy control for every channel
- The tool counts open tickets from the combined order feed, weighted if you like by how heavy each order is, so it has a live measure of kitchen load.
- You set simple levels, such as normal, busy and very busy, each with a prep time for each channel.
- The level can change automatically when the ticket count passes a threshold, or the chef can set it from a kitchen screen with one tap.
- The new prep times are sent to each delivery app through its partner interface or aggregation service, and to your own site's quoted times.
- If you choose, a very busy level can pause lower-priority channels, for example a virtual brand or a distant delivery zone, while keeping your main listings open.
- Every change is logged with the ticket count at the time, so you can see how often you hit each level and whether your normal prep times need resetting.
Which settings each app lets a partner change varies. We confirm this for your accounts first and tell you plainly if any channel still needs a manual change.
The next warm Saturday
As tickets climb past your threshold, the kitchen screen turns amber and prep times on every app lengthen together. Riders arrive closer to when food is ready. When the rush eases, times drop back. Nobody on the counter had to find a setting on a tablet.
- Prep times that follow what the kitchen is actually doing
- Fewer riders waiting at the counter
- Channels paused selectively instead of all at once
- A history showing when you are really busy
Check your peak nights against this
- Riders regularly queue for orders that have not been started.
- Your app prep times have not changed since you signed up.
- Staff do not know where the busy setting is on each tablet.
- You pause whole apps at peak because it is the only quick option.
- Direct customers are told times the kitchen cannot meet.