Table turnover time: the restaurant number hiding inside your own POS
A restaurant sells time as much as food. The same room, the same kitchen and the same staff can serve forty covers in an evening or sixty, and the difference is minutes per table. Those minutes are already sitting in your restaurant system as timestamps nobody reads.
The number is simple to define and easy to get wrong. It is seated to reset, not ordered to paid.
On this page
Define it the way the room works
Table turnover time also has to account for the gap between parties. A table that sits empty for twelve minutes because nobody seated the waiting group is lost capacity, even though the cycle itself was fast. Where a waiting list exists, measure that gap too.
The clock starts when guests sit down and stops when the table is cleared and laid for the next party. A table that was paid ten minutes ago and still has plates on it is not available, and counting it as available flatters the number.
Measure it per table size as well as overall. A two-top and an eight-top behave nothing alike, and averaging them produces a figure that describes neither.
Then split by daypart. Lunch in a business area turns fast because guests have somewhere to be. Weekend dinner does not, and should not.
The table turnover time stamps you already have
Most restaurant systems record more than anyone looks at. Order creation, each kitchen ticket, item fire times, bill print and payment are usually all stamped.
Two stamps are usually missing: seating and reset. Both need a tap from the floor staff. That is the only new work in the whole exercise, and without it you are measuring the middle of the cycle and guessing the ends.
Where the minutes actually go
Split the cycle into stages and measure each one. The total is rarely the problem. One stage usually is, and it is often not the one people assume.
Eating time is mostly not yours to change, and trying to compress it is how restaurants earn a reputation for rushing people. The stages worth attacking sit either side of it.
| Stage | Usual cause when it is slow | Cheapest fix |
|---|---|---|
| Seated to order taken | Server covering too many tables | Re-section the floor at peak |
| Order to first dish | Kitchen sequencing, not speed | Fire starters immediately |
| Last plate to bill asked | Nobody prompting | Offer the bill, do not wait |
| Bill asked to paid | One card machine for the room | A second terminal, or pay at table |
| Paid to reset | Clearing staff pulled elsewhere | One person owns resets at peak |
The payment stage is usually the cheapest win
The gap between a guest asking for the bill and leaving is almost pure friction. Printing, walking, waiting for a terminal, walking back, waiting for a signature.
Paying at the table removes most of it. So does a second payment device at peak hours, and so does splitting a bill without rebuilding it from scratch.
Bill splitting deserves its own mention. Where a group of six has to be re-entered as six separate bills, that table loses ten minutes and the server loses their temper. The system should split by item or by share in a few taps.
Faster is not always better
There is also a floor below which service quality drops. Guests notice being moved along, and they notice it most at the end of a meal. A restaurant that cuts table turnover time by rushing dessert usually sees the average bill fall by more than the extra cover is worth.
Turnover is a means, not a goal. A table that turns in forty minutes with a low average bill may be worth less than one that takes ninety and orders dessert. The sales reports will show both if you ask them to.
The number to watch is revenue per seat per hour, which combines both. Turnover time is one input to it, and chasing turnover alone can quietly reduce the figure you actually care about.
- Measure turnover by table size and daypart, never as one average
- Track revenue per seat per hour alongside it
- Compare the same daypart week on week, not against the restaurant next door
- Look at the slowest stage, not the total
- Change one stage at a time, so you know what worked
Starting this week
- Add a seating tap and a reset tap to the floor routine
- Pull a week of stage timings from the system before changing anything
- Pick the single slowest stage at your busiest daypart
- Apply the cheapest fix from the table above
- Compare the same daypart next week, and only then move to the next stage
A week of baseline before changing anything is the step people skip. Without it, table turnover time improves and nobody can say which change did it, so the next decision is a guess again. The timings live in your back office reports once the two taps exist.
Frequently asked questions
How is table turnover time measured?
From guests being seated to the table being cleared and laid for the next party. Measuring from order to payment flatters the figure, because a paid table with plates still on it is not available to anyone. Track it per table size and per daypart rather than as a single average.
What data do I need that I probably do not have?
Two timestamps: seating and reset. Order creation, kitchen tickets, bill print and payment are usually already recorded. The two missing stamps each need a tap from floor staff, and that is the only new work the whole exercise requires.
Which stage is usually worth fixing first?
Normally the payment stage, because it is almost pure friction and the fixes are cheap. Paying at the table, a second device at peak and proper bill splitting remove most of it. The stage from last plate to the bill being asked for is usually second.
Is faster turnover always better?
No. A table that turns in forty minutes with a small bill can be worth less than one taking ninety minutes with dessert and drinks. Watch revenue per seat per hour, which combines both, and treat turnover time as one input to it rather than the goal.
How long should I measure before making changes?
A week of normal trading, with no changes at all. Without that baseline the next improvement cannot be attributed to anything, so the decision after it becomes guesswork again. Then change one stage at a time.
Sources, method and author
Built from timestamps a restaurant system already records, plus two that usually need adding. The stage breakdown reflects how a service cycle is normally decomposed in hospitality operations. No benchmark minute counts are given here. They vary enormously by format, city and daypart, and the only useful comparison is against the same restaurant’s own previous week.
- Investopedia on revenue per available seat hour — the measure turnover time feeds into
- National Restaurant Association of India — industry context for Indian restaurant operations
- NPCI — UPI, which removes most of the payment stage friction
Clotouch is a point of sale product built by Clonet Technologies Pvt Ltd. The method works in any restaurant system that timestamps orders and payments, including ours. The fixes suggested are operational, not product features.
Author. Aman Raj. Published 20 October 2026 for Clonet Technologies Pvt Ltd, Bengaluru.
