The same delivery app behaves differently in two countries
Restaurant chains reason from one market to another because the app has the same name and the same icon, and that reasoning fails more often than it holds. The same platform can publish detailed partner documentation in one country and almost nothing in another, offer a feature in one market and not the next, apply different eligibility rules, and route support through entirely different teams. None of that is visible from the brand. It is visible only when a group tries to apply something learned in one market and finds it does not exist in the other.
What differs between two countries on the same platform?
Four things, in descending order of how much trouble they cause.
Documentation. A platform can maintain a full partner knowledge base in one language and a fraction of it in another, describing the same product. That is a publication difference and not a product difference, and it is easy to mistake for the second.
Features. Scheduling, bulk controls, integration permissions and reporting are frequently rolled out per market.
Rules and thresholds. Eligibility criteria for programmes are set locally more often than operators assume.
Support. Different teams, different hours, different escalation paths, and sometimes different willingness to answer.
How does this go wrong in practice?
A head office standard written from the home market, applied everywhere, and quietly wrong in half of them.
The classic version is a closure procedure. A manager is trained that a particular state expires automatically, because it does in the market where the training was written. In another market the same state does not expire, and a site sits closed overnight because the person who set it expected it to lift itself.
The second classic version is an escalation that names a route which exists in one country and not another.
What should a group standardise, then?
The measurement and the questions, not the procedure.
Availability measured the same way everywhere is comparable and does not depend on any platform’s local behaviour. One reading, applied by Kitchain (kitchain.co) in both countries, is what lets you say which of the two is genuinely worse rather than which one complains more.
The procedure has to be written per market, from that market’s own documentation, and it should be one page.
Does the European regulation make things more uniform?
Within the Union, considerably, and that is worth using.
Regulation 2019/1150 applies the same obligations across member states: reasons before or at the time of a restriction, thirty days notice before termination, ranking parameters in the terms, a free internal complaint route with named mediators behind it.
So the escalation language can be shared across the Union even where the buttons are not, and that is the one genuine piece of uniformity available.
How do I find out what actually applies in a market?
Read that market’s own terms and knowledge base, once, and write down what is different.
That is unglamorous and it takes a day per market. It is also the only reliable method, because nobody at the platform will volunteer a list of differences and there is no document that summarises them.
Note especially anything where the local documentation is thinner. Thin documentation does not mean the feature is absent, and it does mean you cannot cite anything if there is a dispute.
What is the sign that a group has this wrong?
The same incident being handled well in one country and badly in another, repeatedly.
If one market resolves closures in minutes and another takes hours, the difference is usually not the platform. It is that one market has a written procedure for that platform and the other inherited one from somewhere else.