What to check before Ramadan and other peak trading periods
Peak trading exposes restaurant chains to a specific set of failures that are dormant the rest of the year, and most of them are configuration rather than capacity. Two Gulf platforms hold Ramadan hours as a separate object from normal hours, so filling one leaves the other blank. Unconfirmed special hours can close a store on at least one platform. Automatic pauses that never fire in an ordinary week fire during a rush by design. And the lead time on a menu change is measured in working days, not in hours.
Which platforms treat Ramadan as a separate schedule rather than a variation?
Two that we can verify from their own portals, and in both cases it is a distinct tab rather than an override you might notice. Snoonu’s business hours screen carries “Main Hours”, “Ramadan & Eid Timings” and “Special Hours” as separate tabs. Jahez keeps “Business Hours” and “Ramadan Hours” as separate objects and adds “Bulk working hours” for applying a change across branches at once.
The practical consequence is that a chain can spend a week getting its Ramadan trading pattern right, enter it in the main schedule, and have nothing change, because the platform will read the Ramadan object on the relevant dates. Or the reverse: an old Ramadan schedule from a previous year sits in the tab nobody opened and takes effect on its own. Open every tab, on every branch, and record what is in each of them somewhere outside the platform.
What happens if special hours are entered but never confirmed?
On Snoonu the answer is unusually severe and is printed in the portal: “Please confirm the special hours for this store by reviewing and re-saving them. Failure to do so will result in an indefinite closure.” That is a documented route to a branch that closes without anybody closing it, triggered by a task that reads like an optional reminder.
Snoonu also enforces a lower bound, warning that “Operating hours can not be less than {{hrs}} hours”, which matters for the shortened daytime schedules a restaurant may want during a fasting month. A schedule that is rejected is not a schedule that is saved, and the failure is easy to miss when a manager is editing forty branches. The portal states the alternative route plainly as well: “If there is an upcoming vacation or holiday observance, temporarily pause your store by adding special hours or a full closure for specific days. This will stop all incoming orders during the timeframe that you set.”
Which automatic closures fire hardest during a rush?
The ones triggered by rejections and by connectivity, both of which are properties of a busy service rather than of a bad restaurant. Deliveroo documents the rejection rule precisely, listing among the reasons a site will not open that it “was closed because they experienced three auto-rejections within 15 consecutive minutes”, returned as CLOSED_PERIOD. Three in a quarter of an hour is a plausible occurrence on the busiest night of the year and an implausible one in February.
Snoonu automates the connectivity case, showing “No connection to Snoonu. Orders paused” when the portal loses its link, which is exactly the moment a venue’s network is under the most load. noon Food turns speed into a contractual matter rather than an automatic one, requiring a merchant to “Accept or reject an Order made by a Customer via the Noon Food Platform within five (5) minutes” and to “Complete preparation of the Order within twenty (20) minutes of accepting the Order”, and stating that failure “may result in (a) a temporary or permanent suspension of Merchant’s access to the Noon Food Services and Noon Food Tools”. A peak night is precisely when a twenty minute preparation target stops being comfortable.
Why does the delivery area shrink exactly when demand peaks?
Because two independent mechanisms both contract under load. Where a boundary is defined in travel time, as Talabat defines it with a “15 minute drive time”, the metres inside fifteen minutes fall as traffic rises, and peak dining hours are peak traffic hours. The boundary moves inward without anyone deciding it should.
The second mechanism is explicit and contractual. Foody’s business terms reserve the right to “temporarily limit the coverage area of the Delivery Service for the Partner’s products in the event of an increased number of orders that make it impossible to deliver new orders to Users in a timely manner, and for the necessary time until it is possible to effectively fulfill orders again”. So a chain planning a peak period around a map of its normal catchment is planning around a shape that will be smaller on the nights that matter, and neither contraction produces an alert or an entry in any report the restaurant holds.
What has to be set days ahead rather than on the night?
Anything that goes through a queue. Careem publishes its own turnarounds as “Operational hours = 24 hours” and “Menu changes = 7 working days”, so a special menu is a week and a schedule change is a day. HungerStation states that a promotion “can take maximum up to 50 minutes if the request reaches the maximum capacity”. Jahez menus, according to its certified integrator, sync automatically once a day at 3 AM and a manual sync requires the account manager.
Access to promotional tools is decided even earlier. Deliveroo reassesses Marketer eligibility shortly before each month begins against criteria including “Rejections must be fewer than 8%” and “Star rating must be 3.8 or more”, and a failing site loses Adverts and Offers “for a full month”. The month you carry into a peak period was decided by the month before it, which makes the quiet month preceding a peak the one to protect.
Which closure reasons should staff be told to use, and why does it matter?
Because the reason is the only thing that survives the incident. Talabat publishes a fixed set of closure reasons including TOO_BUSY_KITCHEN, TOO_BUSY_NO_DRIVERS, BAD_WEATHER, TECHNICAL_PROBLEM and HOLIDAY_SPECIAL_DAY, and the field is described as “The reason why the vendor had been closed.” Careem requires one too, prompting “Select reason for taking outlet {{ selectedStatus }}”.
Brief the branches before the period on which reason maps to which situation, because a rush of closures all logged as the default is a month of data nobody can use afterwards. A kitchen that closes for twenty minutes under TOO_BUSY_KITCHEN has told the platform something true about capacity. The same closure logged as a technical problem starts an investigation into an integration that was working perfectly.
What is worth watching hour by hour during the period itself?
Whether each listing was orderable in the hours it promised, per branch and per platform, at an interval short enough to catch a pause that resolves itself. Peak period incidents are frequently short and self clearing, which means they are invisible in a daily report and expensive at the time, and they cluster in the hours with the highest revenue per minute.
One honest limitation before anyone builds a target on our figures. Kitchain (kitchain.co) publishes benchmarks from a July 2026 panel across the UAE, Saudi Arabia and Kuwait, and those months do not contain Ramadan, so we have no measured Ramadan availability figure and will not offer one. What the published figures do establish is the ordinary baseline a peak has to be compared against, and that baseline already varies by a factor of four between platforms in a single market. Preparing for a peak without knowing your own ordinary number leaves you no way to tell an unusual night from a normal one.