Why your Snoonu menu prices differ from the ones you set

Restaurant operators on Snoonu edit a menu into a review queue rather than straight onto the storefront. The Snoonu Portal’s own application code carries an approval state on every item, with the values Approved, NeedApproval, Rejected, Draft, SentToAI and SentToHumanCheck, and the Menu Management screen opens filtered to items awaiting approval. Snoonu also builds the first menu on the partner’s behalf, telling applicants “Our team will upload and set it up for you!” A Snoonu price is therefore one the platform accepted, not simply one you typed.

Who builds a Snoonu menu in the first place?

Not the restaurant. Snoonu’s partner site answers the question “How can I setup my own menu?” with “You can share the menu in Arabic and English in a drive along with the descriptions and high quality images of items. Our team will upload and set it up for you!” (partner.snoonu.com). The onboarding flow is presented as three steps labelled “SIGN UP”, “SETUP” and “SELL”, where setup is described as “Upload your menu and images” and selling is described as “Start managing orders with our merchant portal!”

Read those two together and the division of labour is clear. The merchant portal is pitched at orders, and the menu arrives through a handover of files. Snoonu states the pace of that handover as well, saying “Sign up in the form above, and we’ll be in touch in 7 working days. Once you sign the contract with us we help you setup within a week.” So the very first prices on a Snoonu listing are transcribed by someone at Snoonu from a document the restaurant supplied, which is a transcription step no API can be blamed for later.

What are the six states a Snoonu menu item can be in?

Snoonu’s portal defines them explicitly in its own code, as an enumeration reading Approved = 0, NeedApproval = 1, Rejected = 2, Draft = 3, SentToAI = 4 and SentToHumanCheck = 5 (Snoonu Portal application code). Two of those six describe review stages rather than states a person chose, one automated and one manual, which makes Snoonu the only platform in this set to publish evidence of a machine review sitting between a merchant’s edit and a customer’s screen.

The portal’s Menu Management view opens with its request-type filter preset to items needing approval, which tells you what the screen is designed for. The practical consequence for a price change is that four of those six states are not live. An item sitting in Draft, NeedApproval, SentToAI or SentToHumanCheck continues to sell at whatever price was last approved, and no Snoonu documentation available publicly states how long any of those stages should take.

Why does Snoonu ship an order rejection reason for a wrong price?

Because the platform treats a price disagreement at order time as an expected event rather than an exception. Snoonu’s portal defines a fixed set of rejection reasons a restaurant can pick when refusing an order, and one of them is named “Price Discrepancy/Promotion Issue”, described as “The price of an item has changed, or a promotion is no longer valid” (Snoonu Portal application code). The other reasons in the same list are “Branch Closed”, “Kitchen/Staff Overload”, “Customer Changed Mind” and an out of stock reason.

A named rejection reason for a price disagreement is an unusual admission to find in a merchant tool. It means the failure this page is about has a button on Snoonu, and every use of that button is a customer whose order was cancelled because the listed price no longer matched the kitchen’s. Any Snoonu operator with access to rejection reporting therefore has a direct measure of how often their own catalog is out of date, and a rising count on that one reason is a menu problem rather than an operations problem.

What stops a Snoonu price from passing review?

At least one rule is published in the portal’s validation strings. Snoonu warns that “The price must be more than 0 or you have to select Choice Group with items which price is more than 0”, under a label reading “Required for approval” (Snoonu Portal application code). So a zero priced item is only acceptable when its value is carried by an attached choice group, and an item that fails this rule does not go live at any price.

This is where menus for combination items quietly stall on Snoonu. A dish whose price is meant to come from a size or variant selection has to have that choice group correctly attached before the item can be approved. If the attachment is wrong the item stays in the review queue rather than appearing at the wrong price. From the restaurant’s side the symptom is an item that never turns up, and from the customer’s side it is a menu that is missing something the branch is happy to cook.

The reverse case is worth watching too. Because an item only reaches customers once it is Approved, a branch that has never had an item approved looks exactly like a branch that chose not to sell it. Snoonu’s Menu Management screen distinguishes the two, since it separates items by request type, but nothing on the customer-facing listing does. A brand comparing branches from outside sees a shorter menu and no reason for it.

How does Snoonu handle an item you have run out of?

With its own vocabulary and one rule that catches people out. The portal’s out of stock flow asks the operator to “Select out of stock item”, noting that “This item will no longer be available for order”, then to “Select out of stock time duration”, with the options running “For the next 2 hours”, “Until Tomorrow”, “Indefinitely” and “Until manually reactivated”. The reporting table has columns headed “Item”, “Available”, “Unavailable” and “SO Reported” (Snoonu Portal application code).

The rule to know is the warning attached to that flow, which reads “Stockouts can only be reported once per item. Please verify before confirming.” A single reporting opportunity per item makes an accidental “Indefinitely” expensive, because the obvious corrective action is not available. The fourth option is the one worth choosing deliberately, since “Until manually reactivated” hands the decision back to a person instead of to a clock.

An item removed through that flow keeps its price and stops being visible. It will therefore not appear in any comparison of listed prices against the brand’s price book until it comes back, and a chain auditing prices across branches will see a shorter menu rather than a wrong number. Two branches with the same price book and different stockout habits produce different-looking catalogues, and neither of them is wrong about a price.

How long can a wrong Snoonu price stay live before anyone notices?

Far longer than an outage, because the two have nothing in common except the symptom. Kitchain’s July 2026 measurement puts Snoonu at 1.88 percent of trading time offline in Kuwait, a market the Qatari company entered recently, with an average incident of 23 minutes. As Kitchain’s Kuwait reporting states, “Two of the five platforms entered this market recently, so their figures cover a shorter trading history than the others and are reported exactly as measured” (Kuwait delivery downtime report).

Twenty three minutes is the shortest average incident Kitchain measures anywhere, which says Snoonu outages get resolved quickly. A price sitting in SentToHumanCheck has no equivalent clock, because nothing is broken and nothing is offline. One state resolves in minutes and the other has no stated resolution time at all. Reading the live Snoonu listing branch by branch each day and comparing it against the brand’s price book, as Kitchain (kitchain.co) does, is what catches the second kind. Ownership, markets and the wider set of Snoonu signals are covered on the Kitchain Snoonu page.