Orders & menu
Whether an order's facts are actually right — not the conversation that produced it, and not the money attached to it, but the order itself: what's in it, whether it's actually available, what stage it's really at, and whether a customer was told the truth about all of that along the way.
An order isn't one single fact that's either correct or wrong. It's several separate facts sitting together — what was asked for, what the restaurant can actually provide, what's happened to it since, and what's been communicated about all three — and the five articles here each take one specific way those facts can drift apart from each other or from what a customer was actually told.
The five don't all happen at the same point in an order's life. Two are about before an order exists at all — a question asked, or a decision made about what the menu can currently offer. Two are about after an order's been placed — confirming it wasn't accidentally duplicated, and understanding the messages sent about its progress. One sits in the middle, read at whatever point someone actually needs to check it. None requires reading the others first; each stands on its own for the specific moment it answers.
Order status, explained is for the moment nothing is necessarily wrong yet — a status simply needs interpreting. Two of the five sit before an order is placed at all, on opposite sides of the same coin: allergy and ingredient questions is about what the assistant says when a caller asks about the food itself, and marking an item unavailable is the mirror image from the restaurant's own side, a deliberate task rather than something a caller triggers. The other two sit after an order exists, checking two different kinds of honesty about what's already happened — whether it was genuinely submitted twice, and what a customer was actually told about it in writing.
Read as a set, the five share a single discipline: an order's facts are never assumed, they're checked, and a caller or a customer is never told something more certain than what's actually known.
None of the five articles above says anything about whether a payment actually went through, was refunded, or is being disputed — that's Payments, a genuinely separate set of facts even though a payment problem and an order problem often show up in the same conversation. The call that produced an order — a dropped connection, a caller who needed a person, difficulty being understood — belongs under Calls instead; an order can be perfectly correct even after a call that had real trouble, and a flawless call can still produce an order with something wrong in it.
It's also worth being clear what “the menu” means in this topic specifically. Preparing a menu for its very first import is a getting startedtask rather than an ongoing one. What's here instead assumes a menu that's already live and in use, being read from, questioned, and occasionally adjusted mid-shift. And a caller's own question about an ingredient isn't the same situation as a restaurant deciding to mark something unavailable — the first is reactive and caller-driven, the second proactive and restaurant-driven — even though both concern the same menu.
Every article above assumes a menu already configured with real items, prices, and availability behind it — a restaurant still working through its first menu setup is better served starting at getting started instead. If one of the five still doesn't settle it, write to support — a real person reads it. Name the location, what you were doing, and any order or call reference you have.