Where service actually breaks
Every restaurant runs well at 4pm. The test is 8:40 on a Saturday.
When service falls apart, it very rarely falls apart everywhere at once. It fails at a handover — a moment where something has to pass from one person to another — and then everything downstream inherits the failure.
There are four of them.
| # | Handover | What failure looks like |
|---|---|---|
| 1 | Guest → order | A table sits ten minutes waiting to be noticed. Second rounds never get taken. |
| 2 | Order → kitchen | A ticket is lost, misread, or cooked out of sequence. |
| 3 | Kitchen → floor | Food sits under the pass going cold because nobody told the waiter. |
| 4 | Table → next guest | A cleared table sits unnoticed while a party waits at the door. |
Notice what these have in common. Each one depends on a person remembering something at the exact moment they have the least attention to spare. That is not a discipline problem. It is a design problem, and it is why "we just need to be more careful during the rush" never works twice.
The useful question for each handover is: what happens here if everyone is busy and nobody remembers? If the answer is "it fails", that handover needs a mechanism, not a reminder.
Handover 1 — guest to order
The wait to order is dead time for everyone. The guest is ready, the kitchen has capacity, and the only constraint is a captain being physically free.
On a full floor with two servers covering sixteen tables, five to ten minutes per table is normal, and it is worse than it looks. It delays the first order, which delays the kitchen, which delays the table turn — and it silently kills second rounds, because a second round only happens if someone comes back to ask.
Three things help:
- Section discipline. Every table has a named owner every shift. Shared responsibility means the table nobody owns waits.
- A rehearsed greeting window. Water and acknowledgement within ninety seconds, even when the order will take longer. Guests tolerate waiting far better once they have been seen.
- Removing the dependency entirely. Letting guests order from their own phone at the table takes this handover out of the critical path — the order does not wait for a person to be free. Whether that suits your room is a real question, and the honest version is here: it works well in cafés, family dining and bars, and works badly in rooms where the service is the product.
Handover 2 — order to kitchen
This is the loudest failure. A lost ticket becomes a table waiting twenty-five minutes for food nobody is making, and you find out when the guest complains.
Paper KOT systems fail in three specific ways, and it is worth naming them separately because they have different fixes:
- Loss. The ticket falls, gets splashed, or slides behind the counter.
- Sequence. Tickets get cooked in the order they were clipped in, not the order they arrived. An early table waits behind a late one for no reason anyone chose.
- Legibility. A scrawled modifier becomes a remake, or worse, an allergy incident.
Sequence is the one owners underestimate. It does not produce a complaint — it produces a slightly slower service where nobody can point at what went wrong.
The fixes, in order of cost: write tickets in a fixed format everyone uses; keep a single rail with a strict oldest-first rule that one named person owns; or move the queue to a screen, where oldest-first is automatic and there is no paper to lose. If you go the last route, what a kitchen display board actually changes is the sequencing and the notification, not the technology.
Handover 3 — kitchen to floor
Food that is ready and food that has been collected are different things, and the gap between them is where quality dies.
The traditional mechanism is shouting. It works in a quiet room with three staff and fails in a loud one with eight — which is to say it fails exactly when you need it.
What helps:
- Mark items ready individually, not orders. Starters leaving the pass before mains is normal; treating the whole order as one unit means either running food early or holding it late.
- A single expediter during peak. One named person owns the pass for the rush. Not "whoever is nearest".
- A signal that does not depend on being heard. A screen the floor can see, or a notification to the waiter who owns the table.
The measurable version of this handover is the time between an item being ready and reaching the table. If nobody has ever measured it in your restaurant, it is almost certainly longer than you think during peak.
Handover 4 — table to next guest
A cleared table nobody notices is a cover you did not serve. A party turned away while a table sits wiped and empty is the same loss with a worse feeling attached.
This handover fails because the floor plan lives in someone's head, and heads go out of date every few minutes during a rush. The host seats from memory; a captain covering another section does not know which of those tables just paid.
The fix is a shared view that updates itself rather than one person's mental model. Whether that is a physical board someone owns or a floor map that marks tables occupied and free as orders and payments happen, the requirement is the same: everyone on shift looking at the same picture at the same moment.
Table turnover: measure it before you improve it
Table turnover is the operational number that converts most directly into revenue. It is also the one most often "improved" in the way that costs you guests.
Measure it per table, not as an average. An average hides the problem. What you want to know is which specific tables sit longest and why — table 14 by the kitchen door that nobody wants, the six-top that gets seated by parties of two, the corner that captains forget.
Track, for a fortnight:
- Time seated → first order placed
- Time first order → food delivered
- Time last course → bill requested
- Time bill settled → table reseated
Almost all recoverable time is in the first and last of those. The middle is the meal, and compressing it is how you lose repeat guests.
A worked example. A 20-table restaurant doing two sittings a night, average order value ₹850. Recovering ten minutes per table across the evening:
- 20 tables × 2 sittings = 40 turns
- 10 minutes recovered × 40 = 400 minutes of table time
- At an average 70-minute occupancy, that is roughly 5.7 additional covers-worth of table time a night
- ≈ ₹4,800 a night, or roughly ₹1.4 lakh a month
That is more than most independent restaurants make from marketing, and it comes from time guests did not want to spend anyway.
Peak hours: capacity, not effort
When a restaurant "can't handle" its rush, the reflex is to add staff. Usually the constraint is sequencing, not headcount, and adding people to a badly sequenced service makes it slower.
Before you roster another server, check three things:
- Is the kitchen queue ordered? If tickets are being cooked out of arrival order, you have manufactured wait time that no amount of staffing removes.
- Is anyone doing two jobs during peak? A captain who is also running food is a captain not taking orders. Split the roles for the ninety minutes that matter, even if it means combining them either side.
- Do you know when your peak actually is? Most restaurants roster to a belief about their rush that is off by an hour or more. Pull orders by hour of day for a month before you build the roster — the method is in the twelve numbers worth checking every week.
Routines that hold it together
Operations is mostly the boring part: the same things done the same way, so that the interesting problems are the only ones you have to think about.
- Opening and closing checklists. Short, owned by a named role, and actually checked. The free templates and the reason most checklists get ignored by week three are worth ten minutes.
- A pre-shift briefing. Five minutes. What is 86'd, what is being pushed, who owns which section, anything unusual about the night.
- A weekly numbers review. Twenty minutes, fixed day, four numbers. Not a dashboard you look at twice.
- A monthly menu conversation. What sold, what did not, what the kitchen hates making. Backed by data, not by whose turn it is to have an opinion.
Common mistakes
Treating a design problem as a discipline problem. "Be more careful during the rush" has never worked. If a handover fails under load, it needs a mechanism.
Adding staff to fix sequencing. More people running a badly ordered queue is a more expensive badly ordered queue.
Improving turnover by rushing the meal. Clearing plates early and hovering with the bill works exactly once per guest.
Checklists nobody owns. A line assigned to "the team" is assigned to nobody.
Optimising the part you can see. Owners spend time on the dining room because that is where they stand. The pass and the reseat gap are usually where the money is.
What to do this week
- Pick the handover that fails most often in your restaurant. Just one.
- Ask what happens there when everyone is busy and nobody remembers. If the answer is "it fails", it needs a mechanism, not a reminder.
- Time four moments per table for a fortnight — seated to ordered, ordered to served, last course to bill, settled to reseated.
- Name an owner for each section, every shift, in writing.
- Pull orders by hour for last month and compare it to your roster. Fix the mismatch before adding anyone.
- Cut your opening checklist to ten lines and give each one a named role.
The short version
- Service breaks at four handovers, not at random. Find yours before you change anything.
- Any handover that depends on someone remembering will fail during a rush. Replace the memory with a mechanism.
- Measure table turnover per table, over a fortnight, in four segments. The recoverable time is at the start and the end, never the middle.
- Ten minutes per table across 40 turns is roughly ₹1.4 lakh a month for a mid-sized restaurant.
- Peak-hour collapse is usually a sequencing problem wearing a staffing costume.
- Short, owned, checked routines beat long aspirational ones every time.
