Digital Signage for Multi-Site Restaurant Chains: Rollout and Control
Forty restaurants is not forty times one restaurant. This guide covers the chain problem: who is allowed to publish what, how a price change reaches every site on the same morning, and how you audit that a screen is really playing what head office thinks it is.
On this page
A menu board in one restaurant is a design problem. The same board across forty restaurants is a control problem. Type size and viewing distance get answered once. What replaces them is harder: who is allowed to change what, how a price change lands at every site on the same morning, and how head office knows the screen three hundred miles away is showing what it published.
This guide covers that second set of problems. It assumes you already know what a good board looks like — the single-site planning guide covers layout, typography, dayparting and hardware, and the piece on what moves average order value covers content strategy. For the estate features themselves, see Qmanja Signage for restaurants.
What changes between one site and forty
Authority separates from proximity. At one restaurant the person deciding what the board says is standing in front of it. At forty, the decision is made by someone who will never see most of the screens, while the person who does see one has opinions and no way to act on them.
Verification stops being free. At one site, checking the board is walking past it — nobody designs that or budgets for it. At forty, nobody walks past thirty-nine of them, and your first real audit arrives as a customer complaint.
Blast radius grows. A wrong price at one site is a wrong price. The same edit published to a hundred and twenty screens is an incident with a legal edge, because until somebody notices, you are advertising what you are not selling.
The short version: decide who owns each zone of each board before you buy the second site's hardware, build the group structure before you pair the first screen, and put a way of checking what is actually on screen in place before the day you need it.
The control model: three tiers, decided first
Every estate has the same argument. Head office wants the boards identical; site managers want to change things, because they know the school across the road breaks up at half past three. Both are right, and the argument is unresolvable in the abstract but entirely resolvable in the layout.
Stop treating a board as one object with one owner and treat each zone as separately owned. A split-screen layout with a fixed menu column and a rotating promotional panel is the mechanism that lets head office lock one part and hand the other over.
| Tier | Typical content | Who publishes | Failure mode |
|---|---|---|---|
| Locked | Prices, allergen and nutrition text, brand template, national campaigns, legal notices | Central team only | A site edits a price; board and till disagree in front of a queue |
| Regional | Price band, regional range, second language, regional offers, market-specific compliance text | Area manager, scoped to their region | A regional offer runs nationally, or a site sits on the wrong price band for a month |
| Local | Opening-hour changes, recruitment, local events, "closed Tuesday for maintenance" | Site editor, own zone only | Nothing local ever changes and staff stop caring — or the board fills with unapproved clutter |
The failure modes in that last column pull in opposite directions, which is why estates oscillate between them. Lock everything and local content dies; open everything and within a month there is a phone photograph of a birthday cake on a menu board.
Designing the roles
- Estate administrator. Two or three central people, not one. A single administrator is a bottleneck and a point of failure the first time they are on holiday during a price change.
- Regional editor. Publishing rights over their region only. Without this role, head office fields forty requests for things that are genuinely regional.
- Site editor. Publishing rights over one site's local zone. This role decides whether the deployment is still alive in year two.
- Read-only observer. For franchise partners and area managers who need status without the ability to change anything.
[SCREENSHOT: role assignment showing an editor scoped to a single site's screen group]
Accounts belong to people, not sites. A shared login with the password on a card in the back office is the most common governance failure in hospitality signage. Management turns over; a shared credential does not leave when the person does, and an audit trail saying "the site" changed something is worth nothing when eleven people know it.
Franchise sites are a different animal
Company-owned sites are an internal control question. Franchised sites are a contractual one, and no software fixes a gap in the franchise agreement.
The awkward part is that the franchisee usually buys the hardware, pays for the network and often pays the subscription. Set the account up the obvious way and whoever pays the invoice owns it, leaving the brand a guest on a screen it is responsible for.
Two structures work. Head office holds one account for the estate and recharges franchisees, which keeps control clean and makes billing messy. Or each franchisee holds their own account and the agreement obliges them to accept a centrally managed template and locked zones, which keeps billing clean and makes control messy. Settle it before the first franchised site opens — talk it through with us if the estate is mixed, because the structure is easier to set up correctly than to migrate.
What signage contributes to the relationship is evidence: playback records turn "your site was running last quarter's pricing" from an argument into a record.
Screen groups: the structure everything depends on
Grouping decides what every subsequent day costs. Get it right and a national promotion is one publish; get it wrong and it is forty. The mistake almost everyone makes first is grouping by site and nothing else. You need three independent axes, with every screen belonging to several groups at once.
- Role groups describe what the screen does: menu board left, menu board centre, promotional panel, queue display, drive-through pre-sell. A campaign targets a role group and lands on the equivalent panel everywhere.
- Location groups describe where it is: site, region, country, and separately franchised or company-owned. Local content and trading-hour schedules target these.
- Attribute groups describe what the site can sell: licensed or not, drive-through or not, breakfast or not, price band A, B or C. This is the axis people leave out, and the one that stops per-site exceptions breeding.
A national breakfast promotion then publishes to the intersection of "promotional panel" and "sites serving breakfast" — one action that excludes the eleven sites where it would be wrong. Without the attribute axis, it becomes a hand-maintained spreadsheet of exceptions.
A naming convention readable at 200 screens
Screen names are the only map of the estate you will ever have. Use a fixed pattern with the most stable component first, so an alphabetical list sorts into something meaningful: region, site, role, position. "NW / Camden / Menu / Left" tells a support agent where to send an engineer; "Screen 12" does not. Put the same string on a physical label, as the Android TV setup guide recommends for a single site.
Rolling a price change to forty sites
This is the job the whole system exists for, and the difference between a good setup and a bad one is entirely visible here.
Step 1: know where the price actually lives
If you change one price, how many files change?
If your boards are exported images — a designer produces a JPEG per panel per site — a single price change is forty design edits, a review round and a bulk upload, and it takes two days. If the boards are layouts with text edited in place, it is one edit per menu variant. If the layout reads from a data source, it is one edit.
The target is one master layout per menu variant, never one per site. Sites differ by group membership and by which variant they are assigned, not by owning a private copy of the artwork. The moment a site has its own copy it has opted out of every future central change.
Step 2: schedule the moment, do not publish live
A price change takes effect at the start of trading on a given day, not whenever the artwork gets signed off. Build it as a scheduled change with a start time and let it fire, exactly as you would a daypart switch.
The rule that matters is not really about signage: the board must never lead the till. If the point-of-sale system takes new prices at midnight, the board changes at midnight or later. A board showing a price the till will not charge is a service problem; the reverse is worse.
Step 3: reconcile, because published is not played
Offline caching is a feature you want: a screen with no network keeps playing its last published schedule rather than going black. It also means a screen that is offline when you publish carries on showing last month's prices, looking perfectly healthy from the street.
So the procedure has a third step most people skip. After the change fires, check which screens have actually checked in and taken it, and chase the ones that have not. There will always be a few — a site closed that day, a player unplugged to charge a phone, a router rebooting since Sunday.
[SCREENSHOT: estate status list showing screens grouped by last check-in time]
Decide what undo looks like before you need it: the previous version of the layout should still exist and be republishable to the same group in minutes. And do not roll a significant price change on a Friday afternoon — everything that goes wrong stays wrong for three days.
Regional menus, local ranges and compliance
The instinct when a site is different is to give it its own board. Resist it — every per-site exception is a permanent maintenance cost. Almost all real variation can be modelled as groups instead.
- Price bands. Forty sites rarely have forty price lists. They usually have two or three — city centre, suburban, travel locations. That is two or three menu variants assigned by group, not forty copies.
- Range availability. Sites without a fryer, without an alcohol licence, without breakfast. These are attributes of the site, and boards should be assembled from them rather than hand-edited per location.
- Language. Bilingual markets need a permanent second-language zone or an alternating board. Alternating costs dwell time, so on a board read while queuing a dedicated zone is usually the better trade.
On compliance, be careful. Allergen, nutrition and calorie labelling requirements differ by country and, in several countries, by state or region, and they get revised. The rule that applies in your largest market may not apply in the next one, and may apply differently to a franchised site. Check each jurisdiction with someone qualified rather than assuming the strictest rule you know covers everything.
Mandated text also competes for board space with everything you want to show, and if you do not budget that space centrally, some sites will solve it by shrinking the type until nobody can read it. Fix the space allocation and minimum type size in the master template; the W3C accessibility guidelines are a reasonable source for the contrast ratios worth holding to.
Standardising hardware across franchise and company sites
One site can use whatever is in the cupboard. An estate cannot: every variation multiplies the number of things that behave differently and the number of instructions your support process carries.
The rule is one player model per role, two at most, with a documented specification floor and a named alternative — an actual model, not "an Android box". That belongs in the fit-out specification alongside panel size and socket position. Franchising makes it harder: the franchisee is spending their own money, so if the spec says "2 GB RAM", somebody will buy the box that claims 2 GB and has 1 GB.
- Buy for a mixed estate, because you will have one. Qmanja Signage runs today in any modern web browser and on Android TV, Amazon Fire TV and Windows, with macOS, Samsung Tizen and LG webOS players in development and iOS in review — check the players page for what is live before you specify anything.
- Hold spares regionally, not per site. A configured spare at forty sites is forty idle devices, most of which get borrowed for something else. A regional pool with next-day courier is better economics, because pooled spares stay configured.
- Budget a refresh cycle. Players are consumables and panels outlast the boxes driving them. Put replacement in the capital plan.
What breaks at scale that never breaks at one site
Silent dark screens. At one site somebody notices within an hour; at forty, a panel can be off for a fortnight. The substitute for walking past is an alert when a screen has not checked in for longer than a threshold you set, routed to someone whose job includes acting on it.
Time zones. Ask your vendor whether a schedule is evaluated in the screen's local time or the account's. In a single-country estate it makes no difference. The first time you open in another time zone, a breakfast board that switches at eleven starts switching at nine.
Media weight on your worst connection. A large video published to a hundred and twenty screens at nine in the morning is a bad morning for whichever sites are slowest. Publish heavy media overnight.
Fixed-pixel layouts. Site thirty-one has a portrait panel in the entrance, or a 32-inch screen where everywhere else has a 43. Stored in fixed pixels that is a rebuild; stored proportionally it is a group assignment — a question the buyer's guide covers in detail.
Captive portals. Forty restaurants means forty routers and at least one whose network puts a terms page in front of everything. An unattended player cannot accept a terms page, so that site never works and the symptom looks like a broken device.
The single content owner. One person producing everything is fine at three sites and a queue at forty. Once the queue is long enough, sites route round it — which is how unapproved content appears.
Auditing what is actually on screen
Head office believes the estate is showing the current menu, and that belief rests on the fact that somebody published it. The gap between published and playing is where multi-site signage quietly fails. Closing it takes three checks, because each catches what the others cannot.
- Device check-in. Tells you the player is alive and talking to the platform. It does not tell you the content is right, or that the panel is on.
- Proof-of-play records. Tell you what actually rendered, on which screen, at what time. This is the real audit and the only one that produces evidence you can put in front of a franchisee.
- A photograph. Software cannot see that the panel is on the wrong input, that a paper poster has been taped over the bottom third, or that the panel has failed.
[SCREENSHOT: playback record for one screen over a trading day]
The photograph need not be a feature. Ask each site to send one photo of each board on a fixed day of the month into a shared folder. It takes ninety seconds, and the sites that stop sending photos are usually the ones with something to hide.
What to report — and what to stop reporting
Resist the estate dashboard nobody opens. Report by exception: a weekly list of screens that failed one of the three checks. Four measures are worth tracking, and all four are things you can count rather than things a vendor can claim:
- Screens not checked in for more than twenty-four hours, as a count and as a share of the estate.
- Dark hours per site per month — time a screen should have been playing and was not.
- Time from publishing a central change to every screen confirming it. Always longer than the publish.
- Local edits that breached the template, caught in review. Zero is suspicious; it usually means nobody is checking.
Anyone quoting a percentage uplift for multi-site signage is guessing. Measure these four instead, and compare matched sites over matched trading periods for commercial effect, as the sales mechanics guide sets out.
A staged rollout that survives contact with operations
Installers will happily do the whole estate in three weeks, and that is almost always the wrong plan. The constraint is not hardware. It is that you learn things at site six that you want to apply at sites seven to forty, and once a site is live those lessons cost far more.
| Stage | Scope | What you are really testing | Gate before continuing |
|---|---|---|---|
| Pilot | One site — deliberately your worst network, not your flagship | The layout on a real panel, schedules firing, recovery after a power cut | Two weeks with no unexplained dark screen |
| Wave one | Three to five sites covering your format and region variety | Group structure, permissions, whether a site editor can do the job | A site manager completes a local publish unaided |
| Waves two on | Batches of about ten, a week apart | Install logistics, hardware consistency, the reconciliation step | Every screen from the previous wave checked in and audited |
| Steady state | The remainder, plus new openings | The instruction pack and the spares process | A new site live within a day of the panels going up |
Build on a bench, ship configured. Power up a wave's worth of players in one room, apply the settings, install the player app and pair each one before it leaves. The player displays a six-character code, you enter it in the dashboard, and the screen claims itself within seconds — so a device can be paired, named and grouped without being anywhere near a restaurant.
[SCREENSHOT: pairing screen showing the six-character code]
Assign groups at pairing time, never later. Retrofitting group membership across a live estate is the most tedious job in the project and the one most likely to introduce an error nobody spots for weeks.
Then ship each site a pack: labelled devices matching the dashboard names, a one-page sheet covering what the boards should look like and how to swap a failed player, and a named contact. Hospitality management turns over quickly, and that sheet has to live at the site rather than in an induction deck.
The commercials of an estate
Qmanja Signage lists at $6.99 per screen per month, or $4.99 per screen per month billed yearly, and above twenty screens it is quoted as a Business plan — which any multi-site restaurant group is, several times over. Use the published rate for early planning and get the quote before you commit a budget.
The lines larger than the licence, and the ones estate budgets routinely miss: network readiness per site; the content operation, because at estate scale scheduling content weekly is a defined role rather than a favour; reconciliation and audit time; spares and the player refresh cycle; and training at handover, then again for every new manager.
Decide who pays for what when you decide who controls what, and make them match where you can. Where head office locks the menu boards, head office paying for those screens removes the most common franchisee objection. The restaurant solutions page sets out what the estate features look like in practice.
Where to start
Do not start with hardware. Start with a one-page document naming, for each board in your standard layout, which tier each zone belongs to and who publishes it. That page settles the argument that otherwise runs for the life of the deployment, and it determines the group structure, the roles and the rollout order.
Then prove it on one site — your worst network, not your best restaurant. Get the board itself right first, which the planning guide covers, then prove that a central price change lands, that a site editor can publish their local zone without breaking anything, and that you can tell afterwards what actually played. If those work at one site, they will work at forty.
Test the control model, not just the screen. Qmanja Signage is free for your first screen — one screen, 200 MB of storage, free forever, no credit card — enough to build your real menu board and watch a scheduled change fire. For the estate questions, request a walkthrough and bring your actual site list.