Qmanja Signage
Restaurants

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.

The three content tiers in a multi-site restaurant signage estate, with owners and failure modes
TierTypical contentWho publishesFailure mode
LockedPrices, allergen and nutrition text, brand template, national campaigns, legal noticesCentral team onlyA site edits a price; board and till disagree in front of a queue
RegionalPrice band, regional range, second language, regional offers, market-specific compliance textArea manager, scoped to their regionA regional offer runs nationally, or a site sits on the wrong price band for a month
LocalOpening-hour changes, recruitment, local events, "closed Tuesday for maintenance"Site editor, own zone onlyNothing 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.

  1. 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.
  2. 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.
  3. 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.

A staged rollout plan for a multi-site restaurant signage estate
StageScopeWhat you are really testingGate before continuing
PilotOne site — deliberately your worst network, not your flagshipThe layout on a real panel, schedules firing, recovery after a power cutTwo weeks with no unexplained dark screen
Wave oneThree to five sites covering your format and region varietyGroup structure, permissions, whether a site editor can do the jobA site manager completes a local publish unaided
Waves two onBatches of about ten, a week apartInstall logistics, hardware consistency, the reconciliation stepEvery screen from the previous wave checked in and audited
Steady stateThe remainder, plus new openingsThe instruction pack and the spares processA 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.

Frequently asked questions

How do you manage digital signage across multiple restaurant locations?
Through screen groups and scoped permissions rather than per-site editing. Group every screen on three axes: the role it plays (menu board left, promotional panel), where it is (site, region, franchised or company-owned), and what the site can sell (licensed, drive-through, breakfast). Central campaigns then publish to a group in one action, while site editors are restricted to their own local zone. Build that structure before you pair the first screen, because retrofitting it across a live estate is the most tedious job in the project.
How do you push a price change to every restaurant at once?
Edit the master layout for that menu variant and schedule the change to take effect at the start of trading, rather than publishing live whenever the artwork is approved. Never let the board lead the till: if the point-of-sale system takes new prices at midnight, the screens change at midnight or later. Then reconcile — check which screens have actually checked in and taken the change, and chase the handful that were offline when you published.
How much control should individual restaurants have over their screens?
Split the board by zone rather than arguing about the board as a whole. Prices, allergen and nutrition text, the brand template and national campaigns stay locked to the central team. Regional offers, price bands and second languages sit with area managers. Local zones — opening-hour changes, recruitment, community events — belong to the site. Locking everything kills local content and the screens become wallpaper; opening everything up produces off-brand clutter within a month.
How do you handle digital signage in a franchise restaurant estate?
Decide who owns the account before the first franchised site opens, because whoever pays the invoice tends to end up controlling it. Either head office holds one account for the whole estate and recharges franchisees, or each franchisee holds their own account and the franchise agreement obliges them to accept a centrally managed template with locked zones. The software gives you the mechanism and the playback evidence; the agreement gives you the authority.
How do you know a restaurant screen is actually showing the right content?
Use three independent checks, because each catches what the others miss. Device check-in tells you the player is alive, but not that the content is correct or that the panel is even on. Proof-of-play records tell you what actually rendered on each screen and when, which is the only evidence you can put in front of a franchisee. A monthly photograph from each site catches what software cannot see: the wrong input, a poster taped over the panel, or a dead display.
Should every restaurant in a chain use the same signage hardware?
As far as possible, yes — one player model per role, two at most, named by actual model in the fit-out specification with a stated fallback for when it goes out of stock. Estates still end up mixed as sites are acquired and devices replaced, so the requirement that really matters is that one dashboard manages all of them. Franchised sites need the model named explicitly, or somebody will buy the cheapest box that appears to match the description.
How do you handle regional menus and local price differences?
Model them as groups, not exceptions. Forty sites rarely have forty price lists — usually two or three bands such as city centre, suburban and travel locations, which means two or three menu variants assigned by group rather than forty copies of the artwork. Site differences such as no alcohol licence or no breakfast are attributes, and boards should be assembled from them. Every per-site exception you create is a permanent maintenance cost.
How long does a multi-site signage rollout take?
Longer than the installer will quote, deliberately. Run a pilot at one site — pick your worst network, not your flagship — for two weeks, then a wave of three to five sites covering your formats and regions, then batches of about ten a week apart with a gate between each. The constraint is not hardware; it is that lessons learned at site six become expensive to apply once sites seven to forty are already live.
What does digital signage cost for a restaurant chain?
Qmanja Signage lists at $6.99 per screen per month, or $4.99 per screen per month billed yearly, and anything above twenty screens is quoted as a Business plan — which every multi-site group is. The licence is usually the smallest line in the budget. Budget separately for a wired network drop behind each panel, spares and player replacement, training at every handover, and the person who schedules content each week.

Qmanja Signage Solutions Team

Customer Solutions

The team that plans and rolls out digital signage deployments with restaurants, retail groups, campuses and multi-site operators.

Keep reading

See all digital signage guides

Free for your first screen

Try it on one of your own screens

Pair your first display in minutes — free, no credit card required.