To keep servers from taking orders for dishes that have run out, agree on a short routine for the current shift: the kitchen confirms the dish is out, the person in charge updates one working record, and the front-of-house staff say they got the change. Put the dish back on offer to guests the same way, after the kitchen confirms again.
To start, a sheet at the server station or a shared note that everyone can open during work is enough. Below we'll go through a manual routine for one restaurant. Try it on your next shift and adjust it to how your team works.
A stop list is a list of dishes and drinks from the menu that you can't serve guests for now. For example, the kitchen said the prep has run out and the dish isn't being made for now. The dining room needs to know which exact item to stop offering and who confirmed it's out.
Write the name the way the server sees it in the menu. "No fish" leaves too many questions: are all fish dishes unavailable or only one? Ask the kitchen for the exact items. If one ingredient goes into several dishes, don't ask the server to decide on their own which of them can be made.
Agree separately on how to report a dish that is running low but is still available. The phrase "almost out" doesn't say if you can take the next order. Agree on this: before offering such a dish to a guest, the server checks with the person in charge, and that person checks with the kitchen. Don't mark it as fully out until the kitchen confirms it.
Before work starts, choose a kitchen staff member who confirms which dishes are available, and a person in charge of the stop list on the dining room side. This can be the chef running the shift and a manager or head server. Name a backup for breaks: colleagues should know who to go to if the person in charge has stepped away.
Split the tasks:
In a small cafe, one person can do all these roles. Make sure the kitchen's message has reached every staff member who offers the menu to guests.
Illustration of the manual process: kitchen → current record → dining room. Staff confirm they got the change themselves; this is not an automatic notification.
Choose a place that is easy to check during the shift. If it's a paper sheet, put it in a place everyone knows. If it's a shared note, make sure staff have access to it. Don't keep several separate lists at once: if they don't match, you'll have to figure out which one is right.
Here is a sample record. The dish name and the time in it are just examples.
| What to write | Sample |
|---|---|
| Date and shift | Today's date, evening shift |
| Menu item | Mushroom pasta |
| Current status | Stop: no new orders |
| When it changed | 19:10 |
| Who confirmed | The chef running the shift |
| Who updated the record | Shift manager |
| Received by the dining room | Check marks from the servers who are taking orders now |
Use your own staff names or their work titles. You don't need guest data here.
You can use a chat to draw attention to a change, but it's better to keep the current status itself in the place you chose. A "pasta is on stop" message among other messages is hard to use as a working record, especially if "it's back" appears later in the thread. If you chose a note in the chat, agree on which exact record you update and how to find it quickly.
When you open the shift, check the list with the kitchen. During the day, update it after every confirmed change, without waiting for the next team meeting. If a staff member joins later, show them the current record before they start taking orders.
After you make the record, go to the servers on shift and say the full dish name. Ask for a short, clear answer: "We're not offering the mushroom pasta for now, I saw it in the list." This way you check that your colleague understood which item you mean, and didn't just hear you talking.
Choose a handy way to confirm in advance: a check mark next to the record, a reply in the work chat, or a direct reply to the manager. If a staff member is at a table at that moment, the person in charge comes back to them when they're free. A sent message alone doesn't prove that the whole dining room got the change.
When you put a dish on stop, also ask the kitchen what happens to the orders already taken. Don't assume the new status explains on its own which of them the kitchen can make. Pass the answer to the servers whose orders are affected.
If you're not sure a dish is available, check before you take the order. A simple line works for the server:
"Let me check with the kitchen if this dish is available right now, and I'll come back to you."
When you come back with a confirmed answer, tell the guest. If the dish isn't available, you can offer another option, after checking that it's available. Don't promise the item will be ready "in a few minutes" when the kitchen hasn't confirmed it yet.
If the paper list and a spoken message don't match, go to the person in charge. They check the status with the kitchen and update the shared record to match the answer. Don't leave the server to choose between two versions on their own.
Don't lift the stop just because the food delivery arrived or someone said, "I think we have it now." Wait for the kitchen to confirm that this exact dish can be made again for new orders.
After the kitchen confirms, the person in charge changes the current status, writes down the time and the staff member who confirmed it, and then tells the dining room the item is back. Ask the servers to confirm this change too. Otherwise, one part of the dining room will start offering the dish while another still thinks it's not available.
On paper, you can cross out the old status and write the new one next to it with the time. In a note, update the line so the current state is clear right away. Keep the previous mark for the shift review, but don't leave two equal entries, "stop" and "available".
Illustration of the return rule: a food delivery alone doesn't lift the stop. First get the kitchen's confirmation, then update the record and tell the dining room.
Before service starts, walk through one sample case with your colleagues, without changing which dishes are really available. Let the kitchen report that a chosen item is out, the person in charge show how they'll make the record, and a server find it and explain what they'll tell the guest. Then go the other way: the kitchen confirms the dish is back, the record changes, and the dining room gets the update.
See at which step a question came up. Couldn't find the list - choose an easier place to reach. Mixed up the dish - make the name clearer. Nobody knew who should tell the dining room - give this task to a specific staff member and their backup. This way you check that everyone understands the routine before you serve guests.
After the shift, save notes about unclear statuses and about orders that were taken after the kitchen's message. If you want to look at these cases together with other operating metrics, the article about CRM analytics in a restaurant will help. You can come back to this review later, once messages between the kitchen and the dining room run smoothly.
If a guest has already shared feedback about a bad order, the next steps are covered in the article "Review after a visit: from issue to solution".
Start with an agreement for one shift: who confirms the status in the kitchen, where the current record is, and who checks that the dining room got the change. Then see in practice whether this routine is easy for your colleagues to follow.
How to check the outcomes of past bookings: choose the visit dates and the base for the calculation, count reschedules, separate no-shows from unknown outcomes and compare periods.
How to ask a guest for a review after a visit in a neutral way, respond to an issue and check that the service got better. Sample messages and how the restaurant team works.
You can collect guest reviews with Loona.ai