Kitchen time per dish: the number that defines the lunch menu and the dinner menu

A hotel restaurant seats two guests who have nothing in common. The lunch guest carries a laptop and a call in twenty minutes. The dinner guest just came from the pool, is in no hurry, and wants something different from what was on the plate yesterday. If your menu is the same at two in the afternoon and at nine at night, one of the two walks away unhappy.

Same dish, two very different guests

The business traveler staying midweek is not looking for a dining experience at lunch. They want to eat well, post it to the room and go back to their makeshift office. If their plate takes twenty five minutes, it is already too late for them: the call started without them, or they ate with one eye on the clock, and that discomfort is what ends up in the review, even if the food was fine.

The weekend guest eating dinner in the same restaurant carries a different rhythm. Dinner is part of the day, not an errand between meetings. That guest rewards a dish that took time, because a longer cook time also communicates care: a cut of meat that rested, a reduction built slowly. The common mistake is designing one menu that tries to serve both and ends up convincing neither.

What kitchen time per dish actually is

Kitchen time per dish is the number of minutes between the order hitting the kitchen and the dish being ready to serve. It is measured per dish, not per table or per shift, because a table that ordered four different dishes has four different clocks running at once, and what the guest feels is the slowest of the four.

You need to separate cook time, which is what the flame or the oven takes, from total kitchen time, which also adds plating and the wait when a station is backed up. The recipe card gives you the first. The real service floor gives you the second, and that is the one the guest sitting at the table actually feels.

Why the recipe card is not enough

The recipe card says the salmon takes eight minutes on the grill. That is true on a quiet Friday at three in the afternoon. On a Saturday at nine at night, with the grill station backed up and two servers waiting on a pickup, that same salmon can take eighteen. The recipe card describes the dish. Kitchen time describes your kitchen.

How to capture the data without a stopwatch

You do not need anyone carrying a stopwatch between stations. If your orders route through a kitchen display or a tablet at the point of sale, every dish already gets a timestamp when it comes in and can get another when it is marked ready. Subtracting the two gives you kitchen time, captured for free, without relying on someone writing it down on a slip that later disappears.

Measure for at least two full weeks before drawing conclusions, because one unusually busy day or one unusually slow day will hand you a misleading average. Split the data by station: cold, hot, grill and pastry do not share a rhythm, and lumping them into one average hides the exact bottleneck you are trying to find.

Lunch needs a maximum time filter

A guest eating between meetings has a fixed total time budget, from sitting down to walking out, and that budget rarely runs past thirty or forty minutes. Subtract ordering, waiting on the check or the room charge (Room charge) and getting up, and what is left for kitchen and service is usually fifteen minutes, maybe twenty on a generous day.

The practical consequence is simple: set a maximum kitchen time for the lunch menu, say twelve minutes, and only let a dish onto that menu once your own kitchen data confirms it consistently meets that cap, not just on a good day. A dish that sometimes comes out in ten minutes and sometimes in twenty does not belong on the executive menu, no matter how good it tastes.

Dinner has room for what takes time

The guest eating dinner, especially on a weekend or at a leisure destination, is not counting minutes. That is where slow-cooked dishes belong, reductions that need time, cuts cooked to order that cannot be rushed without losing quality. The dinner menu can and should be more ambitious than the lunch menu, precisely because the guest is running on a different clock.

That does not mean time stops mattering at night. It means the ceiling is different, and it still needs to be measured: if a dinner dish starts taking twice as long as it did a month ago, something changed in the kitchen, with a supplier or with the workload, and that number warns you before a review does.

An illustrative example

The numbers below are made up to show the calculation. They do not describe any real property; use them only to follow the reasoning.

With a twelve minute cap for lunch, three of the five dishes in the example clear the filter easily, one lands right at the edge, and two fall outside it. Those two do not disappear: they move to the dinner menu, where the guest actually has the time, and often the mood, to wait for them.

What this tells you about your whole menu

A dish that consistently fails its time filter, shift after shift, has three ways out: move it to a different shift, redesign it to lower kitchen time with more prep done ahead, or drop it from the menu it does not belong on. What does not work is leaving it where it is and hoping the kitchen rushes it out through sheer pressure: pressure does not cook, prep does.

• A dish that is slow to prep ahead of time can become fast at service, even if its components take a while to build.
• A dish that looks fast on the recipe card but is slow in real service almost always hides a bottleneck at a single station.
• Dishes that consistently work at lunch tend to share one trait: few components that need to cook at the same time.

How it connects to the kitchen and the point of sale

Time-per-dish data is only worth so much if it lives solely in the chef’s memory. When the order runs through the restaurant’s system, station time lands in the report (Reports) and can be reviewed by shift, by day of week and by season, without depending on anyone remembering it. And when the menu is managed from the same point of sale (Point of sale), turning off a dish for the lunch shift and turning it on at dinner is one action, not a reprint of physical menus.

The kitchen (Kitchen) knows its real times better than anyone, but the report is what makes them visible to the manager and the controller without needing a daily meeting just to ask how service is going.

What to do this week

1. Check whether your system already stores the time an order came in and the time it went out; if it does, you already have the data without lifting a finger.
2. Set a maximum time for the lunch menu with the chef, based on the real time your executive guest actually has at the table.
3. Split kitchen time by station for one week and mark which station backs up first during dinner service.
4. Identify the two dishes that miss their shift’s time limit most often and decide: move shifts, redesign, or drop from that menu.
5. Review the prep work for any dish you want to move from dinner to lunch before you move it.

Inn Restaurant logs the time of every order by station, from the kitchen through to the point of sale, with no stopwatches or side logbooks. If you want to see how this report comes together for your hotel’s restaurant, book a fifteen minute demo (contact).