How to get Snoonu to put your restaurant back online
Restaurant operators on Snoonu are in the rare position of having the return decided at the moment of the pause rather than afterwards. When a branch is paused the portal asks a question rather than presenting a switch: “How long until you can start accepting orders again?” The answer becomes a countdown, the branch shows “Orders Paused” with the time remaining, and when the countdown reaches “Time is up” the portal restores the branch without anybody acting. The exception is a closure Snoonu applies for unconfirmed special hours, and that one is described as indefinite.
Snoonu asks for the duration at the moment you pause
That question is the whole design. The control is labelled “Pause Orders”, the subtitle reads “How long until you can start accepting orders again?”, and the branch card afterwards shows “Orders Paused” alongside a countdown whose labels are “left” and, at the end, “Time is up”. Behind it the branch carries a busyUntil timestamp next to its current status, and when the countdown completes the portal refetches the branch state. Source: the portal’s own localisation dictionary at snoonu-portal.snoonu.com.
That makes Snoonu one of the few platforms where an operator cannot create an open ended pause by accident, because the duration is a required part of the action rather than an optional field. It also means the useful discipline is choosing the duration honestly. A kitchen that asks for ninety minutes because it feels safe has bought ninety minutes of silence it did not need.
The vocabulary is worth pinning down, because Snoonu uses two words for one state. The button says “Mark branches busy” and the resulting status says “Orders Paused”, and the branch status list runs “Accepting Orders”, “Orders Paused” and “Closed”. Busy and paused are the same thing here, which is not true on Deliveroo and not true on Talabat.
How to resume a Snoonu branch before its countdown finishes
By resuming it directly, since the countdown is a ceiling rather than a lock. The portal confirms the action with a message reading “Branch {{branchName}} successfully resumed”, which is the string to look for as proof that the change landed rather than assuming it did.
Two things follow for a chain. First, teach staff that resuming early is available, because the default assumption everywhere is that a timed state has to run out. Second, treat the confirmation message as the definition of done in the shift log, since a pause and a resume look identical to somebody who walked away from the screen mid action.
There is a second route to the same state from a phone. Snoonu’s owner application, published as Snoonu for Business and calling itself Snoonu Business Manager inside the interface, describes its own controls as letting a partner “Adjust opening hours, set special closures, pause your store, or change availability instantly”. Source: Google Play. Whichever surface performs the resume, verify on the other, because neither announces itself to the other.
One Snoonu closure has no countdown, and re-saving your hours is the fix
Snoonu publishes exactly one rule under which it closes a store itself, and it names both the cause and the remedy in the same sentence: “Please confirm the special hours for this store by reviewing and re-saving them. Failure to do so will result in an indefinite closure.”
Read the word indefinite against everything above. Every branch initiated pause on this platform ends on a timer. This one does not, and it is not lifted by a resume action, because the thing Snoonu is waiting for is a confirmation of the hours rather than a change of status. An operator pressing resume on a branch in this condition is answering a question nobody asked.
The place to do it is the hours screen, which carries tabs named “Main Hours”, “Ramadan & Eid Timings” and “Special Hours”, plus a state for “Main Hours Unavailable”. Snoonu describes special hours as temporarily replacing the main hours, and it warns partners repeatedly in the portal with lines such as “Keep your branches running—update their hours to avoid closures.” and “Make sure your branch stays open—update your hours today.” Those are not decorative. They are the platform naming the failure it is about to apply.
One validation to be aware of while editing, because it blocks the save that would end the closure: “Operating hours can not be less than {{hrs}} hours”. A branch whose corrected hours fall under the minimum will be refused, and the refusal will look like a broken form.
Resuming many Snoonu branches at once uses a different screen
Snoonu builds bulk handling into the same feature rather than leaving it as repeated single actions. The bulk mode is entered through “Mark branches busy” and carries checkboxes, a “Select All” control and a counter rendered as “({{count}} Selected)”, with confirmations written in the plural, such as “Branches {{branchNames}} successfully paused”.
For a group recovering from something that hit a whole city, that is the screen to use, because pausing or resuming twenty branches individually is how three of them get missed. It is also the screen where a mistake is largest, since one action can move an entire estate.
A second control sits alongside and is easy to forget during a recovery. Snoonu handles pre orders separately and per branch, with a section described as “Control Scheduled Orders by Branch”, an instruction to “Quickly see which branches aren’t accepting scheduled orders.” and states rendered as “Scheduled Orders Feature Enabled” and “Scheduled Orders Feature Disabled” against a counter of enabled branches. A branch resumed for live orders can still be refusing scheduled ones.
What to do when a Snoonu branch resumes and pauses again immediately
Look at the connection rather than at the branch, because Snoonu pauses orders automatically when the portal loses contact. The strings are explicit: “No connection to Snoonu. Orders paused”, shown next to “Reconnecting services”.
That is a pause nobody chose, and it will repeat for as long as the underlying link is unstable. Resuming the branch while the connection is dropping produces a loop in which the branch is nominally restored several times an hour and effectively absent throughout, and the branch status history will show a pattern that looks like indecisive management rather than a network fault.
The order of work is therefore connection first, resume second, and the diagnosis is easier than it sounds because the portal says which one it is. A branch showing the connection message is a network case. A branch showing “Orders Paused” with a countdown is somebody’s decision. A branch closed without a countdown is the special hours case above.
Who do you contact at Snoonu, and what will the portal never tell head office?
Snoonu names an account manager and a WhatsApp route for enabling at least one feature, saying that “In order to activate DBS, reach out to your Snoonu account manager or WhatsApp us on” for its own delivery service. Outside that, Snoonu publishes no support channel dedicated to availability, no ticket type and no response time, and there is no API documentation or developer portal to fall back on. The account manager is the documented human, and a request should carry the branch name, the status shown, the countdown value if any, and the hours saved for that day.
What the portal will not do is tell anyone outside the branch that a pause happened. In Kuwait, where we measure it, Snoonu carries a mean incident of 23 minutes, the shortest of any platform in our panel, against a downtime share of 1.88 percent. That combination is the signature of a platform whose pauses expire correctly and happen often, which means the cost sits in frequency rather than in length and is invisible in any view that reports the current status. Counting those short absences against each branch’s published hours is what Kitchain (kitchain.co) does on Snoonu listings.