Why your Foody rating dropped and what actually changes it

Foody looks like a local Cypriot platform to restaurant operators using it, and one part of its partner tooling is not local at all. Foody’s partner portal loads its reviews screen as a separately versioned module, and on the day we checked that module carried the same build identifier on Foody in Cyprus, on Talabat and on HungerStation. This is a statement about one shared component, not about the platforms: they are different marketplaces run by different businesses, and everything around this screen, including the data in it and the switches behind it, differs. What it does mean is that the reviews page, the review drawer and the reply control a Foody operator is looking at are the same piece of software.

The practical value of knowing this is that Foody publishes almost no rating documentation of its own, while the module itself is readable from outside. Where Foody is silent, what the shipped module exposes is the best available description of what a Cypriot partner can and cannot do about a bad review.

Where does a Foody partner see ratings and reviews?

In the partner portal served at partner-app.foody.com.cy, which is assembled from independently deployed and independently versioned modules. One of them is named reviews, and its published entry point exposes a page module, a reply button and a review drawer. In other words, a list of reviews, a detail panel and a way to answer.

Each host publishes a manifest naming the version of every module it is currently serving, and on the day we checked the reviews entry carried an identical build identifier on all three. The manifests as a whole are not identical, and the platforms are not one product. One module is shared. That is enough to make guidance about this particular screen transferable, and not enough to make anything else about the three platforms comparable.

Why can one Foody partner reply to reviews and another cannot?

Because the reviews module gates its capabilities behind feature flags, and flags are configured per tenant rather than per platform. The published module reads a set that includes ReviewReplyFlag, ViewOrderDetailsFlag, RatingThumbsFlag, DishLevelRatingsFlag, HasRatingHistory, HasPredefinedReply, ReviewReplySuggestionFlag and HasDisputeButton. Every one of them defaults to off in the shipped configuration.

So the answer to why a colleague has a dispute control and you do not is not that you are missing a setting in your account. It is that the switch is held above your account, at the level of the brand or the experiment group. Asking Foody support to enable a control is a reasonable request. Expecting the control to exist because a colleague on another marketplace has it is not a safe assumption, even when both screens are the same module.

What does Foody publish about how its rating is calculated?

Nothing an operator can plan against, and it is better to say so than to fill the gap. We found no published averaging window, no minimum number of rated orders before a score is displayed, no statement on whether cancelled orders can be rated, and no threshold at which Foody restricts a store or its promotions. Foody’s public presence is the consumer marketplace at foody.com.cy, which lists stores across Cyprus for delivery and takeaway.

We are not going to supply those numbers from a neighbouring platform. A shared front end module says what buttons exist. It says nothing about how a score is computed on the server, and that is where every marketplace running this screen is entitled to differ.

Which operational failures move a Foody rating?

The ordinary marketplace three, and one that is amplified in a small market. Missing or incorrect items, late handovers and rejected orders are what customers rate badly everywhere. In a market the size of Cyprus, the amplification comes from the review base being small, so a single bad week represents a larger share of a store’s total ratings than the same week would in a large city.

That is the arithmetic operators should worry about even without Foody publishing a formula. A store with a few hundred lifetime ratings moves fast in both directions. A run of five one star reviews is a visible drop on the storefront, and the same five reviews would be invisible on a store with thousands. It is also why Foody stores recover faster than their operators expect, provided they keep trading through the recovery rather than pausing.

Does Foody separate the food rating from the delivery rating?

Foody does not publish an answer, and the module does not settle it either, because the flag named RatingThumbsFlag suggests at least two different rating inputs can exist in the same screen depending on configuration. An operator should establish empirically what their own reviews contain before building an argument on the distinction.

This matters more than it sounds. On platforms that do separate the two, such as Wolt, a restaurant has a defence when a score is really about the ride. On platforms that do not, a courier’s bad day lands on the kitchen’s number. Reading twenty recent Foody reviews and counting how many are about delivery rather than about food is a half hour job that tells a manager which of those two worlds they are operating in, and it is worth doing once per market rather than assuming.

Can a Foody review be taken down?

Only if the dispute control is enabled for your account, and Foody publishes no policy describing it. The HasDisputeButton flag establishes that a dispute path exists in the code the portal serves. It does not establish that Foody accepts disputes, on what grounds, or within what time. We are not going to describe a process the platform has not documented.

What the module clearly invests in instead is replying, with a reply button, predefined replies and a reply suggestion experiment. That tells you where the platform expects the effort to go. The practical assumption on Foody should be that a customer’s score stands and the visible response is the lever available to the restaurant.

One more consequence of a shared module is worth planning for. Its version is published centrally and moved centrally, not released market by market, so the Foody reviews screen can change without any announcement in Cyprus, and a control that appeared last month can be gone next month if a flag is turned off again. Screenshots of the portal go stale quickly, and internal training material written around a specific button is worth writing around the task instead.

How should a Cypriot chain watch Foody ratings?

Per store and daily, because the portal shows reviews rather than changes. There is no movement alert in the reviews module, no published threshold to breach, and therefore nothing in the product that raises a hand when a store drifts down over three weeks. On a small review base, three weeks is enough to move a storefront number by a visible amount.

The second thing worth tracking is the review count, not just the score. A Foody store that stops accumulating reviews has stopped taking orders, and its frozen average will keep looking healthy in any report that reads the score alone. Because a Foody store rating and a stalled Foody listing look identical on the number, Kitchain (kitchain.co) records both the rating and the review count for each Foody store daily, so a chain can tell a quality problem from a listing problem before the month closes.

Our platform profile of Foody, its Cypriot market and the states a store can be in, is at kitchain.co/aggregators/foody/.