Count the tickets hanging on your expo rail at 7:15 on a Friday. If a third of them are phone and pickup orders sitting in the same queue as table tickets, sorted by the order they arrived, your expo is doing arithmetic in their head that nobody asked them to do and nobody trained them for.
Table tickets are sequenced by course and by when the table was seated. Phone tickets are sequenced by when the food has to be in a bag. Those are two different clocks, and running them on one rail means someone is constantly translating between them under pressure.
The ticket that tells expo nothing
A typical phone order lands at the pass looking almost exactly like a dine-in ticket. Items, modifiers, a ticket number, a time stamp of when it was fired. What it usually does not carry is the piece of information that determines when the food should be picked up off the line: the time the customer was told to arrive.
Without that, expo has one sane default, which is to work tickets in the order they came in. That default is wrong for phone orders more often than it is right. An order placed at 6:40 for a 7:30 pickup should not be built ahead of an order placed at 6:50 for a 7:00 pickup, but on a rail sorted by arrival time, it will be, and the 7:30 order sits under a heat lamp for half an hour.
Fixing this does not require new equipment in most rooms. It requires the promised time to be printed on the ticket, large enough to read from three feet away, and the rail to be sorted by that time rather than by fire time.
Sort by promise, not by arrival
The rule to give expo is short: build to the promise time, not to the print time.
That works only if the promise time is real. A quote generated by a fixed rule that says every order is ready in twenty minutes will be wrong all evening, and once expo learns the times on the tickets are fiction, they will go back to sorting by arrival and you have lost the whole benefit. The quoting logic has to reflect actual kitchen load, which is a separate piece of work covered in quoting accurate pickup times.
The same applies to volume. A promise time cannot absorb twelve orders arriving in one minute if the kitchen can only produce six. That is a throttling problem rather than an expo problem, and the mechanics of holding intake to capacity are in order throttling and kitchen capacity.
What a phone ticket needs on it
Four things, and most POS ticket layouts can be configured to include all of them without custom work.
- The promised pickup time, at the top, in the largest type on the ticket. This is the sort key and it should look like one.
- The customer name, because the handoff at the counter goes through a name and the person bagging should not have to look it up on a screen.
- The handoff type, meaning counter pickup, curbside, or third-party driver. These have different timing and different failure modes, and expo needs to know which one is coming.
- Anything that changes hold behavior, such as an order that includes something that will not survive ten minutes in a bag.
Everything else can stay in its usual place. The point is not to redesign the ticket. It is to put the sorting information where a person moving quickly can act on it.
The shelf is where orders actually die
Most kitchens are better at cooking phone orders than at what happens after. Food comes up, gets bagged, goes on a shelf, and then belongs to nobody.
The failure is not dramatic. It is a bag sitting eight minutes because the person who bagged it moved to the next ticket and the counter staff did not know it was ready. The customer arrives at their quoted time, the bag has been there since three minutes after it was promised, and the fries are done. Nothing broke. The food was made correctly and on time and it still went out badly.
Two things fix most of this. Put the promised time on the outside of the bag, written or printed, so anyone walking past can read it. And make one person per shift responsible for scanning the shelf on a loop, checking the oldest bag first. This costs nothing and it is the highest-return change on this list.
If your handoff is mostly curbside, the shelf problem gets worse, because a car in the lot is invisible from the kitchen. Text-based arrival notification is the standard answer there, and it works only if somebody is watching the messages, which is the same ownership problem wearing a different hat. Order status text updates goes into how that loop is supposed to close.
Separating the rails without separating the kitchen
You do not need a second kitchen or a second expo for this at moderate volume. You need the phone rail visually separated from the dine-in rail and sorted by its own rule.
In practice that means a physically distinct rail or a distinct screen region, positioned so expo can see both at once without turning. If your tickets are on paper, that is a second rail six inches from the first. If you are on a kitchen display, it is a filtered view, and whether a printer or a screen serves you better here has real trade-offs on both sides, laid out in printer versus KDS for phone orders.
The threshold for adding a dedicated person is lower than most operators expect. Once phone and pickup orders are running past roughly a fifth of your peak-hour tickets, one expo covering both rails will start dropping things, and the drops will be on the phone side because that is the rail with no guest sitting in the room to notice.
Run this test on your next Friday. Stand at the pass for fifteen minutes and write down, for each bagged order, the promised time and the time it actually left the shelf. If the gap is under three minutes on most of them, your flow is fine and the work is elsewhere, probably in accuracy rather than timing, which improving phone order accuracy addresses. If the gap is running eight or ten minutes, no amount of faster cooking will fix it, because the food was already done. Somebody just needs to own the shelf.