Czechia: what each delivery app calls a closed store
Restaurant operators running several listings in Czechia carry a habit from one platform to another and it does not transfer. The states have different names, and worse, the same name means different things. Busy on one platform means you are still trading with a longer preparation time. On another it means customers cannot order at all. A manager who learned the word on the first platform and applies it on the second has just closed the restaurant while believing they slowed it down.
Why is the vocabulary not standard?
Because each platform designed its own availability model and named the states to fit it, and nobody had a reason to align.
The underlying behaviours are genuinely different too. Some states carry a timer and expire. Some persist until cleared. Some can be set only by the platform. A shared vocabulary would misrepresent that, so the divergence is not simply carelessness.
The practical consequence stands regardless: a multi-platform operator has to learn each set separately.
Which distinctions actually matter?
Three, and they decide what happens next in every incident.
Whether the state stops customers ordering, or merely changes what they are told. That is the difference between losing the hour and having a slower hour.
Whether it ends on its own. A state with an expiry limits the damage of a mistake. One without it runs until somebody intervenes, which overnight means until morning.
And who may lift it. If the platform applied it, no amount of activity at the site helps, and the route is written, not operational.
How do I find out for my own platforms?
Read each platform’s own help material for its availability states, once, and write a one page table for your managers.
That table is the single cheapest intervention available to a multi-platform group. It costs an afternoon, it never needs redoing unless a platform changes, and it prevents the most common self-inflicted outage there is.
Include for each state: does it stop orders, does it expire, who can clear it. Three columns.
What do I do about states I did not set?
Ask for the reasons, in writing, and name the obligation.
Regulation 2019/1150 requires a platform restricting or suspending its service to provide a statement of reasons “prior to or at the time of the restriction or suspension taking effect”, on a durable medium. Article 4(3) then gives you the right to clarify the facts within the internal complaint process, which Article 11 requires to be free and accessible.
That applies identically across every platform operating in Czechia, whatever each one calls the state.
How do I know a state is on at all?
Only by looking at the listing, because a portal state and a customer’s experience are separate facts.
A store can appear open in the portal and be unorderable to a customer, and the reverse also happens. The customer view is the one that decided whether an order was placed, so it is the one worth recording.
Kitchain (kitchain.co) reads every platform from that side at the same moment, and the thing operators find first is one site sitting in three different states on three apps at once.
What is the first thing to fix?
Whichever platform your managers understand least, because that is where the accidental closures are.
Usually it is the newest listing or the smallest one. It gets the least attention, its vocabulary is the least familiar, and it is therefore where somebody sets a state meaning one thing and gets another.