Some of your branches are offline on Foody and the rest are fine
Restaurant chains on Foody are running stores that were contracted, configured and closed one at a time. Foody’s own vendor terms describe the commercial arrangement as governed by “the Special Terms that apply to each Store”, the partner portal displays a closure reason on the screen of the affected store only, and some of those closures cannot be lifted by the restaurant at all. The result is an estate where one branch shows “You are closed” with a reason nobody else can see, and every other branch trades normally without knowing anything happened.
Why does the reason on one Foody store’s screen never reach the others?
Because it is drawn on the store, not on the account. The Foody partner portal loads an availability plugin whose dictionary names the banner headings “You are closed” and “You are busy”, explains a busy store as “Restaurant is open but paused accepting new orders” and a closed one as “Restaurant is closed and not accepting orders”, and pairs them with actions labelled “Close now”, “Reopen now” and “Stay open”. Source: availability dictionary loaded by partner-app.foody.com.cy.
That is a good design for a single restaurant and a poor one for a group. The most valuable field on the screen is the reason, and the reason exists only where the closure exists. Nobody sitting above the estate is shown the sentence “You have been declining orders” or “Your device is consistently disconnected. An account manager will contact you shortly”, both of which appear in the same dictionary as closure reasons.
The reasons themselves fall into groups with different owners, which is worth reading about once in detail and then applying per branch. What matters for an estate is that all of them land at one address and stay there. A group that never gathers those strings centrally has no way of telling whether its worst branch has a device problem, a staffing problem or a courier problem, because the sentence naming which one was shown to one screen in one shop and then replaced.
Foody signs separate terms for each store, and that is where an estate starts to differ.
The vendor terms are explicit that the framework is per store rather than per company. They describe the fee for the ordering service and the delivery service as owed “in accordance with the General Terms & Conditions of Cooperation and the Special Terms that apply to each Store”, and note that before the service is activated the partner receives a confirmation message from the company with all the features of the service. Source: Foody general terms and conditions for vendors.
A store opened in 2022 and a store opened last spring therefore sit on separately signed arrangements. Whether the store uses Foody’s own delivery service, what it pays, which services were switched on at activation, all of that was agreed at the store rather than inherited from the brand.
That matters for availability because service configuration follows the contract. The ranking parameters Foody publishes in the same document include participation in offers and use of Foody’s own delivery, and both are store level facts. Two branches of one name can be running different products on the same platform, and the one carrying the leaner arrangement will look worse on every report without anybody having chosen that.
One Foody branch reopens in a tap and another is refused, and the portal says which is which.
The distinction is built into the interface rather than left for support to explain. Where a closure can be reversed by the merchant the wording is inviting: “You are closed. Reopen if you’re ready to accept orders.” Where it cannot, the portal shows a heading of “Temporarily closed” with one of two subtitles. If an end exists, it reads “{reason}. You will automatically reopen in {time}.” If none exists, it reads “You can’t reopen at the moment.”
That last string is the exact shape of the problem in this page’s title. A manager standing at a branch with a full team and a working kitchen presses the same control that fixed the branch across the island, and the platform declines. Nothing about the two screens looks different at a glance, and the difference is not effort or attention.
A third case sits underneath both and gets misread as either. Where the store is outside its schedule the portal shows “Restaurant cannot be opened” with the subtitle “You are outside of your opening hours.” and the instruction “To reopen, please update your schedule in Opening times.” That is a configuration fault on one store, it repeats every day at the same hour, and it will survive any number of attempts to fix it with the status control.
Why is the slowest branch to come back usually the one with the fewest permitted users?
Because status on Foody is a permission rather than a job title, and the portal has a dedicated message for anyone without it: “Looks like you don’t have the order management permission to change your status. Please contact your manager if you need access”.
Across an estate that produces very uneven recovery times for identical faults. A branch where three people hold the permission comes back in a minute. A branch where the only holder is the owner, who is off shift, stays down until that person is reached. Neither number appears in any report, and both are decided by an access list nobody has audited.
The session itself is a second per branch dependency, and it is the one nobody configures. Foody warns that a portal left running behind other tabs can produce closures the platform applies without being asked, so a branch whose staff keep one window open and a branch whose staff keep six are exposed differently to a mechanism neither of them has heard of. That difference is a habit, not a setting, which is why it survives every audit of the configuration.
Can Foody narrow the delivery area of one store while the rest keep theirs?
The terms reserve that right and describe it as temporary and demand driven. Foody states that it “reserves 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 fulfil orders again.”
The same clause covers suspension of order taking for a store that cannot fulfil, listing a heavy workload causing delivery delays, a partner cancelling orders because it cannot fulfil them in the system, and the case where “it is found that there is no connectivity and orders cannot be received”, each lasting “for the necessary time until the Partner is able to effectively fulfil orders again.”
Both measures attach to a store and to a moment. A branch in a busy district at eight on a Friday can therefore be narrowed or paused while the branch in a quieter town is untouched, and neither the narrowing nor the pause appears in the store’s own configuration. From the outside it looks like the busy branch is failing. What it is actually doing is meeting the condition in the clause.
How should a Cyprus chain read a split Foody estate?
Collect the reason first, because Foody gives you one and most platforms do not. Have each branch record the exact string on its screen at the moment it went down, along with the time, and keep those centrally. Within a few weeks the estate sorts itself into categories that are actionable: devices, check ins, declined orders, courier waits, schedules and permissions.
Then measure the interval rather than the state, since every category above ends differently. Some closures carry “You will automatically reopen in {time}” and some carry no route back at all, so two branches with the same reason can still cost very different amounts. Because the reason lives on one screen and the interval lives nowhere, the only honest comparison between branches is taken from the customer side, against each store’s own published opening times. Kitchain (kitchain.co) maintains that comparison across a Foody estate.