Marking an item unavailable

This page walks through that task in both directions: taking something off, and bringing it back once it's in stock again. It applies to any restaurant that's set up shared ingredients or components — a cheese used across several sandwiches, a dough underneath every pizza on the menu, a sauce base that shows up in more places than its name suggests. If nothing on a menu is actually shared this way, marking a single stand-alone item unavailable is even simpler: it only ever affects itself, and the same screen and the same steps below still apply, just with a shorter list to review before confirming.

01Marking something unavailable

The task starts on the availability board, the screen built specifically for this moment rather than buried inside general menu editing. Search or browse to the item or component that's actually run out — a component if it's a shared ingredient used across several items, an item directly if it's just the one thing.

1. Find the item or component on the availability board and select it.
2. Mark it unavailable. Nothing publishes yet at this point — this step stages the change rather than committing it.
3. Before confirming, review the full list the screen shows of everything that change actually touches — every item, and every group, that depends on what's being marked, not a guess or a partial list.
4. Confirm. The change goes live for the very next call, not at the start of the next shift or after some delay.

That third step is the one worth slowing down for, even when the change feels obvious. A shared ingredient can sit underneath more of the menu than it looks like from its name alone — the same cheese in three different sandwiches, the same dough under every pizza and the calzone, the same sauce base across a whole section of the menu. Seeing the real, complete list before confirming means the decision is made with the actual scope in front of you, not discovered afterward when a caller asks about something that quietly stopped being offered without anyone meaning to touch it.

Once confirmed, the effect is immediate and it's exactly what the review screen showed — nothing broader, nothing narrower. An item marked unavailable directly simply stops being offered. A shared component marked unavailable applies whatever behavior was configured for each item that depends on it: some items go dark entirely, some drop just the one component with the caller told about it, some offer a preconfigured substitute instead. Which of those applies to which item was decided when the menu was set up, not chosen fresh in this moment — this screen is where the decision to mark something unavailable gets made, not where those behaviors themselves get configured.

02One ingredient, mid-shift

It's easier to see why the review step matters with an actual case than with the idea alone. Partway through a dinner rush, the mozzarella runs out. Whoever's handling it opens the availability board, finds mozzarella in the component list, and marks it unavailable. Before confirming, the screen shows the real, complete list of what that touches — not just the calzone, which is the obvious one, but every pizza that includes cheese by default and any other item that quietly depends on the same shared component. Nothing on that list is a surprise if the menu's dependencies were set up accurately, but seeing it laid out before confirming is what turns “I think this only affects one thing” into an actual, checked fact.

Confirming the change publishes it immediately. A caller who dials in a few minutes later asking about a calzone hears the truth plainly, in the restaurant's own configured terms — mozzarella is out, and wherever a substitute was set up in advance, it's offered instead, still subject to that caller's own confirmation before it's accepted. A different caller ordering something that never actually depended on mozzarella hears nothing about any of this at all, because that item was never on the list the review screen showed in the first place.

Later that same night, a fresh delivery arrives and mozzarella is back in stock. The same person, or whoever's on shift by then, goes back to the availability board, marks it available again, and confirms. The next call that reaches for a calzone gets the real thing again, not the substitute — and the running history now shows the full shape of the evening: marked unavailable partway through the rush, restored once the delivery landed, both changes attributed to whoever actually made them.

03Why the cascade itself isn't repeated here

The mechanism behind why marking one shared component can affect several items at once — and exactly which of the different behaviors applies to which item — is a real, deliberately built system covered in full on Menu, including the actual diagram of how one component's unavailability reaches every item that depends on it. This page doesn't rebuild that explanation. What matters here is narrower and more practical: doing the marking itself, correctly, with the real scope of the change actually in view before it's confirmed.

04Bringing it back

Restoring something works the same way, in reverse, and it's just as immediate.

1. Go back to the availability board and find the item or component currently marked unavailable.
2. Mark it available again.
3. Confirm. It's back on the very next call — nothing about restoring something waits for a batch update or a scheduled sync.

Every marking and restoring action is kept in a running history — what was marked unavailable, when, by whom, and when it was restored. That record is worth checking whenever the current state of something is unclear, rather than relying on memory of who changed what during a busy shift. It's also the fastest way to confirm a restore actually went through, if there's ever a moment of doubt about it.

05When something goes sideways

1. The wrong thing got marked unavailable. There's no separate undo step — restoring it is the fix, using the same steps above. Because the change only takes effect going forward, any call that happened while it was mistakenly marked unavailable is the only real consequence to check for; nothing about orders already placed before the mistake gets rewritten by fixing it afterward.
2. A caller asks about an item mid-call, right around the same time it's being marked unavailable elsewhere. What the caller actually hears when they ask about something's availability — and what happens if the answer changes between when they ask and when the order is actually confirmed — is covered in full on Allergy and ingredient questions. The short version: availability is always treated as current-but-provisional until an order is actually accepted, so a change made moments before or after a caller asks doesn't create a conflict.
3. The review screen shows more items than expected, and it's not obvious why one of them is on the list. That's worth treating as useful information rather than an error to dismiss — it usually means that item genuinely depends on the component in a way that wasn't top of mind. If the dependency itself looks wrong, that's a configuration question for menu components in onboarding, not something to work around by marking the change anyway and hoping it's fine.

None of this needs to happen in any particular order relative to anything else going on during a shift, and it doesn't need a manager specifically — whoever's actually working the floor or the kitchen and notices the shortage is usually the fastest person to make the change, since the delay between running out and marking it unavailable is exactly the window where a caller could still order something that can't actually be made. The review step is what keeps that speed from turning into a mistake: a quick change is fine, a quick change made without reading what it actually touches is how a caller ends up hearing about an unrelated item going dark for no visible reason.