How head office finds out what a franchisee changed on a delivery app
Restaurant chains that franchise usually assume there is a log somewhere, and there is not one they can read. No delivery platform in this category publishes a change history to a brand owner who does not hold the branch login, and the integration layer misses every change that never passes through it. What is left is detection by difference: two dated readings of the same public storefront, compared. That catches trading hours, orderability, prices, missing dishes and delivery area, and it never catches who made the change or why.
Do the platforms publish an audit trail a brand owner can read?
Not one we have been able to find in any public documentation across the platforms in this category. The portals record actions for their own purposes, and occasionally show that they do. Careem requires an explanation when a branch changes state, prompting “Select reason for taking outlet {{ selectedStatus }}”, which means the reason exists in Careem’s records and nowhere the brand can reach. Jahez displays an attribution banner, but for the other direction of access, reading “You are currently viewing restaurant ({{ restaurantId }}) as Jahez Employee” when platform staff work inside a restaurant’s account.
That second string is worth dwelling on for a franchise brand, because it establishes that a third party can also make changes. A brand investigating an unexplained schedule change is not choosing between head office and franchisee. Platform operations staff have account level access on at least one Gulf platform, by that platform’s own admission, and the account holder will not necessarily know which of the three acted.
What does the integration see, and what does it structurally miss?
It sees what flows through it, which is menus and orders, and it misses state changes made anywhere else. The clearest case is Jahez, where a certified integrator states the boundary outright: “Deliverect can no longer open or close your store on Jahez. Any request to open or close your store must be made directly with Jahez, not through Deliverect.” A branch pausing itself on Jahez performs an action the middleware cannot see, cannot record and could not have performed.
Hardware creates a second gap on almost every platform. Deliveroo confirms that “a store can still be manually opened or closed using the Deliveroo tablet” independently of the Hub, and its own web application acknowledges a reporting hole of its own: “POS errors don’t appear on the web app yet. If an order fails to transfer to the POS, it won’t show up in the Web app.” Anything done on a counter tablet is invisible to the middleware by design, and a middleware report that shows no change is therefore not evidence that nothing changed.
Which changes leave a mark that a second reading can catch?
Most of the ones that matter commercially, because they are the ones a customer has to be able to see. Five categories are readable from the public storefront without any credentials at all. Stated trading hours are printed on the card. Whether the listing can take an order right now is a binary anyone can observe. Prices are displayed. A dish that has been snoozed or marked out of stock is absent or greyed out. And whether a given address is offered the branch can be established by asking the app from that address.
Detection then becomes arithmetic rather than access. A reading taken on Monday and a reading taken on Friday differ in a specific field, and the difference is the change. This is the only method that works uniformly across platforms, because it depends on the customer facing surface rather than on each vendor’s back office, and the customer facing surface is the one thing every platform is obliged to keep accurate.
Which changes will no method detect?
Three kinds, and it is worth being blunt about them. First, anything with no customer facing expression: an auto accept threshold, a notification setting, a user added to the account. Jahez exposes “Auto Accept Orders” and “Number Of Auto-Accept / Hour” to the branch, and neither has any external symptom until an order goes wrong. Second, attribution. A schedule that changed on Tuesday is a fact, and the identity of the person who changed it is not recoverable from outside the account.
Third, and most awkward for a brand, intent. A branch that narrowed its declared hours may have done it to cut a loss making shift, to hide a staffing problem, or by accident while editing something else. All three produce the same observable change. The value of external detection is that it converts an argument about whether something changed into a conversation about why, which is a much shorter meeting.
Why do the changes that hide best also cost the most?
Because the ones that leave no operational trace are precisely the ones that suppress the alarms. A branch that pauses itself generates a visible outage. A branch that narrows its stated trading hours generates nothing at all, and every availability metric in the business, ours included, is calculated inside stated hours. Trimming the schedule improves the availability record while reducing the trading, and no report built on the platform’s own definitions can show that, because the definition moved.
The same logic applies to an indefinite item stockout, which removes a product line without removing a listing, and to a delivery area that has narrowed, which removes customers without removing anything the branch can see. Each of these is a commercial change dressed as an operational setting, and each is invisible to the systems that watch for outages.
What does a workable detection routine look like?
Read the whole estate on a fixed cadence and keep the readings dated. The unit has to be a listing, meaning one branch on one platform, because a franchisee operating on four apps has four independent sets of settings that routinely disagree with each other. Compare each reading with the last, and treat only the differences as events, otherwise the exercise produces a wall of unchanged data that nobody reads.
Kitchain (kitchain.co) does this from the customer side rather than from inside the accounts, checking each public storefront at roughly ten minute intervals and holding the result as a dated series, which is what makes a change comparable with the week before it. The definitions and the limits of that measurement, including what it cannot show, are at our methodology. The important limit for this question is that an external reading establishes what the storefront said and when, not who said it.
What should the franchise agreement carry, given that detection is external?
Three obligations that cost the franchisee nothing and close most of the gap. A duty to notify head office before changing declared trading hours, since that is the change that quietly rewrites every measurement. A duty to report any state a branch cannot lift itself, such as Careem’s “Outlet Closed” or a Jahez visibility change, because those require the brand to escalate and the franchisee usually cannot. And a right for the brand to hold read access, or failing that an acknowledgement that the brand will measure the storefront externally and will treat those readings as the record.
That third point is the one most worth writing down in advance. External readings are only useful in a dispute if both sides agreed beforehand that they count, and that agreement is far easier to obtain at signature than during the argument the readings caused.