How to get Pyszne.pl to put your restaurant back online
Restaurant chains on Pyszne.pl are running Just Eat Takeaway partner tooling under a Polish name, and the return procedure is the place where that matters most. The back office is Konto Partnerskie, the switch is a slider labelled “Przyjmowanie zamówień”, and going offline confirms with “Włączono tryb offline do jutra”. The Polish article documents that the state restores itself the next day and then stops. Coming back sooner, and extending a closure beyond tomorrow, are documented on the same product in another language and not in Polish.
The Pyszne.pl return happens by itself the next day
That is the one restoration Pyszne.pl publishes, and it publishes it as a bracketed note rather than as a procedure. The Polish opening hours article describes going offline under the heading “Jak tymczasowo przejść w tryb offline”, how to temporarily go into offline mode, and adds “(Uwaga: ta funkcja automatycznie przywraca status online następnego dnia.)”, a note that the feature automatically restores online status the next day. The step itself reads “Przełącz suwak ‘Przyjmowanie zamówień’, aby zmienić status”. Source: partnerinfo.pyszne.pl.
Automatic restoration is a genuine protection and it has a cost that is easy to miss. It also erases the event. A restaurant that went dark at 19:30 and came back at breakfast leaves nothing in Konto Partnerskie the following morning, so nobody investigates and the evening is written off as quiet.
The second control is a checkbox rather than a slider and behaves differently: “Zarządzając godzinami otwarcia i zamknięcia, masz również możliwość zamknięcia restauracji na dany dzień poprzez zaznaczenie odpowiedniego pola”, which describes closing the restaurant for a given day inside the hours editor. A change to hours confirms with “Zaktualizowano godziny otwarcia”. A slider will be undone by tomorrow. A ticked box for the wrong date will not.
Where the two Pyszne.pl offline switches are, and why either is enough
The Polish knowledge base answers the busy kitchen question by naming both, telling partners that to stop the inflow of new orders they switch to offline mode using the button in the top right corner of the Konto Partnerskie panel or on the order management device.
Two surfaces, one state, and only one person needs to touch either. In a branch with a rush and a shared device, offline is one tap away, and its confirmation appears only on the screen where the tap happened. Nothing is sent to head office, and the panel and the device do not announce to each other that a change was made.
For a return that means the person bringing the restaurant back should use whichever surface they can reach, and should then verify on the other one rather than assuming they agree. It also means an incident note that says only that the restaurant was switched offline is incomplete. Which surface it happened on is the difference between a device problem and a desk one.
How to come back sooner than tomorrow on Pyszne.pl
By reversing the same slider, which is documented on this product in English and not in Polish. The Just Eat version of the identical article carries two sections the Pyszne.pl version does not: how to go back online sooner than the automatic restoration, confirmed with a popup reading “You’re back online”, and how to extend a temporary offline period. Source: partnerinfo.just-eat.co.uk.
That the two are the same product is something we verified rather than inferred, and the evidence is set out on our page about why a Pyszne.pl restaurant goes offline. For the purpose of a return, what follows from it is a single practical permission: the reverse of a documented toggle is a reasonable thing for a Polish operator to look for on their own screen, because the toggle itself is documented in Polish and a slider that only travels one way would be a strange piece of software.
What that permission does not extend to is treating the English article as the rule book for Poland. Everything on it beyond the reverse toggle, including any automatic behaviour around unaccepted orders, is published for the United Kingdom and not for Poland, and a Polish manager who plans a recovery around an unpublished rule is planning around a guess. Look for the toggle. Do not assume the timings.
A longer Pyszne.pl closure is a request rather than a setting
On the English side of the same tooling, extending a temporary offline period is routed through support under a named topic, “Extend Temp Offline”. The Polish article documents no equivalent, which leaves a Polish operator with two published options: an offline that expires tomorrow, or a day closure entered in the hours editor for specific dates.
For a planned absence the hours editor is therefore the route to use in Poland, and it needs to be filled in for every date rather than opened as an indefinite state. A refit that runs eleven days is eleven ticked boxes, and each one is a separate opportunity to miss a day. That is worth doing deliberately in advance instead of relying on a support route that Pyszne.pl has not published.
A closure entered that way also has to be taken out again, which is the half of the procedure people forget. An offline slider is reversed by the platform whether or not anyone remembers it. A row of ticked dates is reversed by nobody, so a refit that finishes four days early finishes four days early only inside the building. Put the reopening date in the same calendar entry as the closing date, and give it to the person who will be on shift that morning rather than to the person who booked the work.
Check the device before you switch the restaurant back on
The order device guidance in the Polish knowledge base tells partners to leave the application open and visible on screen during trading hours and to disable battery optimisation for it. That is device hygiene advice with no stated consequence attached in Polish, and it exists for a reason, because an unanswered order is the input that produces an automatic rejection on this platform family.
So the sequence during a recovery is the same as on the other brands of the group. Confirm the device is powered, connected, unlocked and being watched by somebody named, then bring the restaurant back online. Reversing that order produces a restaurant that is technically online and functionally absent, which is worse than being offline because it accumulates rejections.
The most useful habit for a Polish operator is to require the confirmation message rather than the intention. A slider that was tapped and a slider that changed state look identical to somebody who walked away, and only the popup distinguishes them.
What should a multi country group write into one Pyszne.pl procedure?
One document per country, sharing a structure, differing in the parts that are actually documented. A procedure written from the English article will tell a Polish manager to use a support topic that Pyszne.pl has not published. A procedure written from the Polish article will omit the reverse toggle and the extension route entirely. Neither version is wrong about the product and both are incomplete about it, in different directions, which is the hardest kind of discrepancy to spot from head office.
The part no procedure can supply is the trigger, because a return procedure only ever starts when somebody knows there is something to return from. Pyszne.pl restores the restaurant on its own schedule rather than on the operator’s, so the whole value of a written recovery collapses into how quickly the recovery is begun, and in a Polish estate nobody is told to begin one. That is why the document is worth pairing with an outside check that says which restaurant is not orderable right now, which is what Kitchain (kitchain.co) reads on Pyszne.pl listings while the state is still open and a manager can still act on it.