Some of your branches are offline on Pyszne.pl and the rest are fine
Restaurant chains on Pyszne.pl hold no estate wide switch, because every setting the platform recognises belongs to one restaurant. Ten locations are ten configurations that share a logo. Nothing about the arrangement is inherited, nothing is compared for you, and an offline restaurant is put back by the platform the following morning, so the branch that lost a Friday evening and the branch that traded it look the same to anyone opening Konto Partnerskie on Saturday. Divergence here is the normal state rather than the exception.
Which Pyszne.pl settings are held by the restaurant and which by the group account?
Both layers exist and they live on different hosts, which is the first thing to establish before comparing two branches. The Polish partner articles link users into a host carrying the group name for account settings, at partner-hub.takeaway.com, and into the Polish one for the menu, at partner-hub.pyszne.pl.
The live availability control belongs to the restaurant, and it is a slider labelled “Przyjmowanie zamówień”, taking orders. The Polish article documents it under a heading about going temporarily into offline mode. Source: partnerinfo.pyszne.pl.
Shutting a whole day is a third control again, and it lives in the hours editor rather than on the home screen, as a tick box inside the opening and closing hours screen. Saving it returns a confirmation reading “Zaktualizowano godziny otwarcia”, the opening hours have been updated.
Three controls, spread over two hosts, and each of them addressed to one restaurant. Nothing in this arrangement is inherited, so a group of ten locations is ten separate configurations that happen to share a name.
Why do branches of one group follow different published rules across Pyszne.pl and its sister brands?
Because the product is shared across the group’s national brands and the instructions are written separately for each one. Pyszne.pl sits in that family beside Lieferando in Germany, Thuisbezorgd in the Netherlands, Bistro in Slovakia and SkipTheDishes in Canada, and what those sites publish about the same controls is not equivalent in length or in coverage. The evidence for the shared tooling, and what the Polish pages leave out, are set out on our page about why a Pyszne.pl restaurant goes offline.
For an estate the consequence is a training problem rather than a reading problem. A Polish area manager who has worked in the group elsewhere arrives with habits formed on a fuller set of instructions and applies them to branches where those steps are undocumented. A manager who has only ever worked in Poland arrives with a shorter method and applies it correctly. Both then report that their branches are being handled to the standard, and the two standards are different.
That is worth catching before it turns into an argument about competence. When one region of an estate loses more evenings than another, the first thing to compare is not the staff but the instruction each region was given, because on this platform the instruction genuinely differs by country and nobody in either country was told that it does.
Where can a Pyszne.pl branch be switched offline from?
From inside that branch, which is the whole reason an estate goes uneven rather than dark all at once. The controls Pyszne.pl documents are reachable by the people working the shift, and they act on that restaurant alone, so the blast radius of any single mistake is exactly one location. The surfaces themselves, and which one a returning manager should check first, are covered on our page about getting a Pyszne.pl restaurant back online.
What matters at estate level is who those people are. The branches most likely to lose evenings are not the busiest ones, they are the ones with the most hands on the same screen: high turnover, agency cover, a device shared between the pass and the counter. Those attributes are known to head office already and are never joined up with availability, because availability is not measured per branch anywhere in the account.
Joining them up is a cheap piece of analysis with an unusually clear output. Rank the estate by evenings lost, put the staffing pattern of each branch next to it, and the ranking usually explains itself in one reading. Without the first column the exercise cannot start, and Pyszne.pl does not supply the first column.
Why does an overnight return leave a Polish estate looking healthy?
Because the restoration is written into the feature. The Polish article carries it in brackets, “(Uwaga: ta funkcja automatycznie przywraca status online następnego dnia.)”, noting that the feature automatically restores online status the next day, with the confirmation popup reading “Włączono tryb offline do jutra”.
Automatic restoration is genuinely useful and it is also an evidence problem. By morning every restaurant in the group is online. There is no closed period to inspect, no reason code to read and nothing in the account that distinguishes the branch that lost four hours of dinner service from the branch that traded all evening. The lost revenue is explained away as weather or a slow week, and the same branch does it again the following Friday.
That is why the useful unit of comparison on Pyszne.pl is the interval rather than the state. A short offline that ended before the automatic restoration was probably noticed by somebody. One that ran to the next morning was not. Across an estate the second pattern clusters, and where it clusters it names a shift or a device rather than a run of accidents.
What does the split between collection and delivery hours do across a Polish estate?
It produces branches that are half present, which is a symptom nobody reports accurately. Collection hours and delivery hours are independent on this tooling, and updating one does not update the other.
A brand rolling out a change therefore has two edits per restaurant, and any restaurant where only one was completed is orderable through one channel and absent from the other at the same moment. Customers describe that as the restaurant being closed. Staff, who can see orders arriving, describe it as the restaurant being open. Both are right, and the disagreement will survive several phone calls unless somebody thinks to ask which fulfilment type the customer was using.
Because this is a configuration state rather than an event, it does not end overnight the way an offline state does. It repeats every day at the same hours until the second set is edited, which makes it the most durable of the differences on this platform and the easiest to fix once identified.
How should a Polish chain compare its Pyszne.pl restaurants?
By recording, per restaurant, whether the listing could actually be ordered from, separately for delivery and for collection, against the hours that restaurant published for that day. Nothing inside Konto Partnerskie will reconstruct that after the fact, for the reason set out above.
Two shapes are worth naming in advance so that the record is read correctly. A branch that goes dark in the evening and is back by morning was switched off, by a person or by a rule, and the cost is concentrated in the hours that followed. A branch that is missing at the same hour every day, or missing on one channel only, is a settings fault and costs the same amount every single day until it is corrected.
A partner account showing the present state cannot distinguish the two shapes, because both restaurants are online by the time it is opened and one of them has been quietly wrong for a month. Recording each restaurant separately, on both fulfilment types, is what makes the difference legible, and that per restaurant record is what Kitchain (kitchain.co) builds across a Pyszne.pl estate.