How to Tell Restaurant Staff an Item Is Sold Out
Update the POS or 86 list first, then send one short staff Ping and an explicit back-on-menu correction.
Update the restaurant's source of truth first. Then send one short staff alert: Sold out: salmon. Check the POS/86 list. When the item returns, correct the source first and send Back on menu: salmon. Source updated.
That order matters. The point-of-sale system, menu system, or written 86 list should say what can be sold. A private PingRoom Room can give the team an attention cue; it should not become a second inventory record.
Use the system that already owns availability
Some restaurant systems already handle this job. Square can mark an item sold out or available across supported ordering channels. NCR Aloha Cloud can surface item availability through its POS and kitchen-display workflow. If your current system already reaches the staff who need the change, use it.
The restaurant term 86 is common shorthand for an unavailable item, but its meaning can vary by context. A complete phrase is safer than a lone number on a lock screen.
| Your situation | Better starting point |
|---|---|
| The POS or menu system already updates staff as well as ordering channels | Its built-in availability workflow |
| Everyone is in one room and the written 86 board is visible | The board and the team's normal verbal call |
| A small floor team may miss the verbal call, but needs only a sparse cue | One private PingRoom Room |
| The team needs continuous conversation during service | A headset, radio, or normal voice procedure |
| The issue concerns an allergen, contamination, injury, fire, or another emergency | The venue's food-safety or emergency procedure |
PingRoom fits the third row. It does not track stock, change a menu, update a customer, or prove that a person saw an alert.
Use one message shape in both directions
Create a private Room for the people who need availability changes during a shift. Decide who is allowed to send—perhaps the manager on duty or the person responsible for the 86 list—before service starts.
Then use two fixed Custom Ping shapes:
| State | First action | Custom Ping | What the recipient does |
|---|---|---|---|
| Item becomes unavailable | Mark it sold out in the POS, menu system, or written 86 list | Sold out: <item>. Check the POS/86 list. | Stop offering it and verify details in the source of truth |
| Item returns | Mark it available in that same source | Back on menu: <item>. Source updated. | Verify the source before offering it again |
Use Custom Ping on iPhone because the item name changes each time. Do not save a separate Quick Ping for every dish. If a system update fails, say so in the restaurant's normal operational channel instead of sending Source updated when it is not true.
The correction deserves its own message. Sold out can linger in memory long after the item returns. Back on menu closes that state explicitly.
Rehearse the handoff in five minutes
Run this before a low-risk shift with a harmless example item.
- The designated sender marks the example item unavailable in the real source.
- They send
Sold out: example item. Check the POS/86 list. - One floor teammate opens the source and describes what changed.
- The sender marks the item available again in that same source.
- They send
Back on menu: example item. Source updated. - Repeat once with the recipient's phone muted, offline, or out of reach, then use the venue's normal voice, radio, or in-person fallback.
The failed round is useful. A sent Ping is not proof that someone saw it or acted. Connectivity, notification permission, Focus, Room settings, battery state, and operating-system behavior can all affect what appears on a phone.
Pingo the Pigeon, PingRoom's official mascot and fictional Chief Marketing Officer, watches the two blank tiles in our rehearsal illustration. He does not work the pass, inspect stock, enter private Rooms, or send Pings for the team. The people running the shift remain responsible for the source update and the alert.
These AI-generated editorial illustrations feature approved PingRoom avatars and Pingo. They are not restaurant or PingRoom screenshots and do not depict customers.
Keep the Ping out of the order record
The alert needs only the item and the state. Keep guest names, table numbers, order details, payment information, staff notes, and customer contact details out of it. Do not use a Ping to carry allergen, contamination, medical, or safety instructions.
When a guest has already ordered the item, handle that order through the restaurant's actual ticket and service process. The availability Ping tells staff to look at the authoritative system; it does not resolve an affected order.
This is also a different handoff from food waiting at the pass. Use the separate food-ready alert setup when the plate exists and the floor needs to collect it.
Try it for one shift
Start with one menu category, one designated sender, and one service period. Afterwards, ask:
- Was the source always updated before the Ping?
- Did the unavailable and available messages use the same shape?
- Did staff check the source instead of treating the lock-screen wording as inventory truth?
- Did the fallback work when a phone did not show the alert?
- Would the POS, menu system, headset, or 86 board do the whole job better?
If the last answer is yes, use that tool. If the sparse cue is still useful, keep the Room narrow and the wording fixed. The private group setup covers invitations, sender permissions, sounds, and a first test.
Create the private Room, agree on the two message shapes, and rehearse both the correction and the missed-notification fallback before service.
PingRoom
Short-form communication.
