Central menu and pricing across all outlets.

Honestly, and this matters, so here is the plain version rather than the marketing one. When you publish a menu or pricing change centrally, it propagates outward to the stores and to the connected devices and apps at those stores. How fast any given location actually sees it is not a single number, because it depends on that store's own connectivity and on the state of its devices at that moment. A site with a healthy connection and its tills powered on and online will pick a change up quickly. A site whose network is down, or whose terminal is off overnight, or which is mid-service on a patchy link, does not receive it until it is next able to — a store that is offline updates when it reconnects. That is the truthful shape of it, and it is worth saying because a command-center screen can make rollout look like flipping one switch and having the whole estate change in the same instant. It is not that. There is no honest promise of a change landing simultaneously across every store, and certainly none of it landing instantly across thousands of them; anyone who tells you otherwise is describing an ideal network, not a real chain with a store on a rural line and another behind a failing router. So plan changes the way experienced operators do: publish ahead of when you need them live rather than at the moment of a price change, give slower or intermittently connected sites time to catch up, and — for anything time-sensitive like a promotion start — have a way to confirm which stores have actually received it before you rely on it being everywhere. If you need guarantees about propagation timing, offline behaviour, or how a change is confirmed as applied, put those questions to our sales and implementation team in writing, because those are commitments for a contract, not claims for a page.

Yes. The page describes exactly this, and it is one of the more straightforward capabilities here, so plainly: you are not forced into one price list or one menu for the whole group. There are regional pricing rules, so a set of stores — a city, a territory, a franchise cluster, however you group them — can carry a price band that differs from the rest, without you editing each site individually. There are scheduled menu shifts, so a menu can change on a timetable rather than by someone remembering to switch it: a breakfast menu that gives way to lunch, a seasonal range that comes and goes on set dates, a weekend layout that differs from a weekday one. And there are per-store overrides for the cases that do not fit a region or a schedule — the single location with a local specialty, the flagship that carries items nowhere else does, the site that has to price differently because of its rent or its market. The way to think about it is layers: a shared baseline for the group, regional rules layered over that for clusters, schedules layered over that for time, and per-store overrides for the genuine one-offs — with each layer only overriding where you have said it may. That keeps the common parts consistent and edited once, while letting the places that genuinely need to differ actually differ. What the page does not specify is the exact mechanics — how rules resolve when two of them could apply to the same store, how far in advance a scheduled shift can be set, how overrides interact with a central change published later. Those are sensible questions to confirm with sales against your own group's structure before you design your price and menu hierarchy around them.

The page separates what a store manager can do from what a corporate admin can do, and that separation is the point of the feature. Permissions control the reach of each account: a store-level user can be given the ability to act on their own site — see and run their own store, work within the menu and pricing they have been handed, manage their own people — while being kept out of the group-wide levers, so they cannot change another location's setup or alter the central definitions that flow down to everyone. Corporate admins hold the broader controls: the central menus and pricing, the regional rules, the promotions, and the ability to grant and shape everyone else's access. Configured well, this is what lets you push consistency outward while still letting each site run itself within the boundaries you set. Here is the important caveat, and it is a caveat about what this feature is rather than a doubt about whether it works. Role-based access is access control — it governs who can edit what inside the software. It is not, and cannot be, a substitute for your own franchise agreements, operating standards, and governance. The software can stop a franchisee from changing a price they are not permitted to change; it cannot define what they are permitted to change in the first place, resolve a dispute about it, or carry the commercial and legal relationship between you and your franchisees. Those live in your contracts and your operating manual, and the permission model should be configured to reflect them, not to replace them. Set the roles to match the governance you have already agreed, review them as your agreements change, and treat the access model as the enforcement of your rules rather than the source of them. If you need specifics — how granular permissions get, whether roles can be scoped to a region rather than a single store, how access is audited — confirm those with sales against how your group is actually structured.

The honest answer is that this page does not put a hard number on it, and we are not going to invent one for it. What it says, and what is fair to repeat, is that the product is built for multi-location groups — chains and franchises running many outlets from one place rather than a single restaurant. That is the shape of the thing. What it deliberately does not claim, and what you should be wary of seeing claimed anywhere, is a specific ceiling like thousands of stores with zero degradation. That kind of line is easy to print on a slide and hard to stand behind, because real-world capacity depends on how your estate is actually put together: how many stores, how many devices per store, how often changes are published, how much history you keep, how heavy your reporting is, and where your sites sit on the network. A number that is comfortable for one group's usage pattern is not automatically comfortable for another's. So rather than quote a figure that would be marketing rather than fact, the right move is to take your real numbers to our sales and implementation team — your store count, your growth plans, your device footprint, your reporting needs — and get capacity, scaling behaviour, and any service-level commitments answered against those specifics, in writing. Service levels in particular, uptime, support response, what happens under load, belong in a contract with your name on it, not in an FAQ. If you are evaluating this for a large or fast-growing group, that scoping conversation is the one worth having early, because it turns a vague reassurance into an actual commitment you can hold someone to.

You get reporting aggregated across your locations, with the ability to drill from the group-level view down into an individual outlet — the pattern the command-center dashboard on this page is illustrating. So you can look at the whole estate together and then open up a single store to see where a group-level figure is coming from, which is the genuinely useful part: it is how you spot that one region is dragging a number, or that a promotion landed in some sites and not others. Two honest qualifications, though, and both matter for how much weight you put on what you are looking at. First, and again, every figure on the dashboard as drawn here is sample data — the 42 outlets, the $1.2M, the 98.4%, the 12.4% are illustrative and were not measured anywhere; treat the screen as showing the layout of the reporting, not results you should expect. Second, and this is the one to internalize for daily use: aggregated reporting depends on each store syncing its data up, so the figures you see reflect each location's last sync, not a guaranteed live feed. A store on a healthy connection reports recent data; a store that has been offline, or whose devices have been off, contributes numbers only as current as its last successful sync, and until it catches up the group total is quietly incomplete. That does not make the reporting less valuable, but it does change how you should read it — a group figure is only as fresh as the least-recently-synced store inside it, so a dashboard that looks live may be waiting on a site that dropped off this afternoon. For anything where timing is critical — reconciling a day's takings, judging a promotion in its first hours — check the freshness of the underlying stores rather than assuming the top-line number is current to the minute. If you need specifics on how often stores sync, whether any of the reporting is closer to live, or how sync gaps are surfaced, confirm those with sales.