QR codes for multi-location and franchise businesses: one code design, per-location tracking, and a rollup report

QR codes for multi-location and franchise businesses: one code design, per-location tracking, and a rollup report

A single restaurant with one QR code on the counter is the easy case. A 40-unit franchise rolling out the same table tent to every location is a different problem entirely, and most of the advice written about QR codes assumes the first scenario. The moment a client has more than a handful of physical locations, an agency runs into questions the generic guides skip over: does every store get the same code or a different one, how do you generate dozens or hundreds of codes without doing it by hand, what happens to a code when a store closes, and how do you hand corporate one number while each location manager only wants to see their own. This is the setup that answers all four, using a real restaurant or retail rollout as the working example throughout.

The decision every rollout has to make first

Before anything else, decide whether the campaign uses one shared QR code with a redirect that varies by location, or a genuinely unique code per location. Both are real options and vendors sell both, so it is worth understanding what each one is actually capable of.

A shared code works by encoding one URL that points at a redirect service, which then looks at the scanning device's IP address and tries to send it to the nearest or most relevant destination. That IP lookup is doing more work than most campaign briefs assume. MaxMind, one of the primary commercial IP-geolocation databases, publishes its own accuracy figures: country-level identification is reliable, above 99 percent excluding VPN traffic, but state or provincial accuracy runs from roughly 55 to 80 percent depending on the country, and city-level accuracy falls to somewhere between 20 and 75 percent. Mobile connections make this worse, because a phone on a carrier network often resolves to a broad regional IP block rather than anything close to the handset's actual location. IPinfo, a competing geolocation provider, has published a direct rebuttal to the whole category of "99% accurate" marketing claims, pointing out that vendors rarely disclose the radius their accuracy figure was measured against: one company's "accurate" means correct country, another's means within 50 miles, and a headline percentage tells you nothing until you know which. The practical takeaway for a multi-location campaign is that IP-based routing is genuinely good for country or language-level decisions and not reliable enough to route a scan to one specific store out of twenty in the same metro area.

A unique code per location sidesteps the guesswork entirely: the code printed at store 14 encodes a link that only ever points at store 14's landing page, so there is no inference step to get wrong. The tradeoff is that it needs a system for generating, naming and distributing potentially hundreds of distinct codes, which is the part this piece spends most of its time on. As a rule, use a shared geotargeted code when the routing decision is coarse (which country's site, which language) and use a unique code per physical location whenever the client needs to know which specific store actually drove a scan. For the mechanics of how geotargeted redirects work under the hood, see geotargeted QR codes: how location-based redirects really work.

Why five locations is a different problem to five hundred

Scale changes which parts of this are hard. According to the International Franchise Association's 2025 economic outlook, US franchise establishments grew to roughly 851,000 units in 2025, up about 20,000 from the prior year, and franchise employment passed nine million jobs. FRANdata, the research firm behind those figures, tracks close to 9,000 distinct franchise brands operating across the country. Named brands sit at very different points on that scale: Subway operates something in the region of 20,000 US units and McDonald's around 13,500, but the vast majority of the roughly 9,000 tracked franchise systems are nowhere near that size. Most are regional operations with anywhere from a handful of units to a few hundred.

That range matters because the right tooling at five locations is manual and the right tooling at five hundred is not. An agency can create five codes by hand in an afternoon, name them sensibly, and keep the mapping in their head. At fifty locations, hand-creation starts producing errors. At five hundred, it is not optional to have a system: bulk generation, a consistent naming convention and a single source of truth for which code belongs to which store stop being nice-to-haves and become the only way the rollout ships without a store getting the wrong sign. The rest of this piece assumes you are somewhere past the "I can just remember it" threshold, because that is where multi-location campaigns actually go wrong.

Generating the codes without doing it by hand fifty times over

The mechanical part is straightforward once you have decided on unique codes per location: you need a way to create many codes in one pass, each pointing at its own destination, rather than clicking through a create-code form fifty or five hundred times. ScanKit's bulk CSV import (a Pro-plan feature) takes exactly this shape: one row per code, a name and a destination URL, imported in one batch rather than one at a time. For a franchise rollout, that means one spreadsheet with a row per store, the store's landing page URL in one column, and a sensible name in the other, imported once. See how to generate QR codes in bulk for the mechanics of that import.

Where this differs from the ordinary agency use case is the workspace structure sitting above it. A previous piece, one workspace per client: organising QR codes for an agency, covers how an agency separates codes between different clients. A franchise rollout is the same tool used one level down: one client (the franchise brand) with one workspace, and inside that workspace a group for every physical location. Groups in ScanKit are exclusive, so each code belongs to exactly one group, which maps cleanly onto "this code belongs to store 14 and nowhere else." Tags sit alongside groups and are not exclusive, which is the right place for anything that cuts across locations, such as a national spring promotion that fifty stores are all running simultaneously. A code can carry the "spring-promo" tag and still belong to its own store's group, which is what makes it possible to filter the dashboard either by location or by campaign later.

Keeping one design while every location gets a different code

The phrase "one QR code design" for a multi-location rollout is easy to misread as "one literal image reused at every store," and that reading breaks the entire premise. A QR code's scannable data is its destination URL; if the printed graphic is byte-for-byte identical at every location, every scan resolves to the same place; and there is no way to tell store 14's scans from store 31's afterwards. Reusing the exact image chainwide only works alongside the shared, geotargeted approach discussed above, with the accuracy limits that come with it.

What "one design" should mean in a franchise rollout is a consistent visual template, not a single graphic: the same colours, the same border treatment, the same placement on the table tent or yard sign or window cling, produced from the same design file, but with a different underlying code swapped in for each location before it goes to print. This is exactly the kind of variable-data step print shops already do for personalised direct mail, just applied to franchise signage instead of letters. Practically, that means exporting each location's code as its own file from the bulk-generated batch, then merging those files into the shared template at prepress, one output per store. It is more setup than printing one PDF, but it is the only way "identical branding, per-store attribution" is actually possible, and it is worth explaining to a client who assumes those two things come for free together.

Because the codes are dynamic, this setup does not lock a store into its landing page forever. A destination can be updated at any point without touching the printed sign, which matters more at franchise scale than anywhere else, for reasons the next section gets into. See change a QR code's destination without reprinting for how that update works.

Naming and organising so nobody ships the wrong file to the wrong store

A print run across dozens of locations has one failure mode above all others: the wrong file goes to the wrong store, and nobody notices until the campaign is already live on a sign. The fix is unglamorous and entirely about discipline rather than tooling. Give every code a name that is unambiguous out of context, not just meaningful inside a spreadsheet you happen to have open. A convention such as brand-storenumber-city-campaign (for example, brand-014-denver-spring25) reads correctly whether you are looking at the group list, the exported file name, or the analytics dashboard six months later, which a name like "Denver location" or "Store 3" does not once there are three Denver stores or the store numbering has changed since the code was made.

Treat the store-to-code mapping as a single source of truth, not something held in an email thread or a print vendor's job ticket. One spreadsheet, one column per store number, code name and physical address, checked before every print run rather than reconstructed from memory. This is the same naming discipline covered in more depth in QR code UTM parameters: a naming convention that scales across every client, extended down to the code and group names themselves rather than just the campaign parameters on the destination URL. Before a print run of any size ships, scan every code against its intended destination and confirm the two match; the QR code testing checklist before print covers what else to check in that same pass.

What happens when a location closes, moves, or changes hands

Franchise systems are not static, and a code strategy that assumes every store stays open at the same address forever will eventually break in public. Under the FTC's Franchise Rule, every franchisor in the United States is legally required to disclose, in Item 20 of its Franchise Disclosure Document, the number of outlets opened, closed, transferred and non-renewed in each state for the previous three fiscal years. That is not an estimate or an industry rumour; it is a mandated annual filing, and it exists precisely because opening, closing and transferring units is routine, ongoing activity in any franchise system, not an edge case an agency can plan around ignoring.

This is where dynamic codes earn their keep in a way static, unique codes never could. A code with a fixed, physically encoded URL becomes a dead link the moment its store closes, and there is no way to fix a sign that is already screwed to a wall three states away. A dynamic code's destination can be repointed the same day, to a "this location has moved" page, to the nearest open store, or to a corporate landing page while a replacement tenant is sorted out, without anyone visiting the physical sign at all. For a franchise system where outlet turnover is a documented, annual, disclosed fact rather than a hypothetical, that difference is the entire argument for not using static codes at this scale in the first place.

Building the rollup report corporate actually wants

Two different people look at this data and want two different things from it. A location manager wants their own store's numbers: scans this week, trend against last month, nothing else cluttering the view. Corporate marketing wants the opposite: one number for the whole network, with the ability to drill into any single store when something looks off. Franchise-operations software outside the QR space already treats this as a named, standard pattern; FieldPulse, a field-service platform used by franchise systems, documents a feature it calls Roll-Up Reporting specifically for consolidating data across every franchisee location into one corporate view with drill-down, alongside a separate royalty-reporting feature that rolls location revenue up into the numbers corporate uses to calculate franchise fees. It is a useful model because it names the exact split a QR rollout needs: one aggregate view, one per-location view, built from the same underlying data.

The groups structure set up earlier is what makes this possible without a second tool. ScanKit's workspace-level analytics dashboard aggregates every code by default, which is the corporate rollup: total scans, network-wide trend, top-performing locations, all in one place. Filtering that same dashboard to a single group narrows it to one store's numbers only, which is what a location manager actually needs to see. QR code analytics: which scan metrics matter covers which numbers are worth reporting in either view, so the rollup does not just repeat raw scan counts without the context that makes them meaningful.

One limit is worth stating plainly rather than glossing over. ScanKit workspace access today is all-or-nothing: any member added to a workspace can see every code, group and analytics view inside it, because there is no franchisee-restricted, single-location role. If a franchisor needs to hand an individual franchisee a dashboard that shows only their own store and nothing else, the two working options today are exporting or sharing a group-filtered view for that one location, or giving that franchisee their own separate workspace and accepting that corporate then combines the numbers across workspaces manually rather than in one built-in rollup. Neither is as clean as a dedicated franchisee role would be, and it is better to plan around that honestly than to promise a restricted view the account structure cannot yet enforce on its own.

Frequently asked questions

Can I use the same QR code image for every location?

Only if you are using the shared, geotargeted approach and accepting its city-level accuracy limits (roughly 20 to 75 percent depending on country, per MaxMind's own published figures). If you need to know which specific store drove which scan, every location needs its own unique code with its own destination; the visual template can stay identical, but the underlying data cannot.

How many QR codes do I need for a 50-location franchise?

One per location if you want per-store attribution, plus however many campaign-level codes you use for anything that is not location-specific (a national landing page in an ad, for instance). Fifty locations means fifty codes at minimum, generated in one batch rather than created individually.

What's the real difference between a shared geotargeted code and a unique code per location?

A shared code encodes one URL and relies on IP-based inference to route the scan, which is reliable for country or region-level decisions but not for picking one specific store among several nearby. A unique code per location encodes a different, fixed destination for each store, so there is no inference step and no accuracy ceiling.

Can corporate see every location's data while each store only sees its own?

The underlying data supports it: a workspace-wide dashboard gives corporate the network rollup, and filtering to one group gives a single-location view. Whether an individual franchisee can log in and see only that filtered view depends on whether the account has a restricted role for that, which is worth confirming with whatever platform you use rather than assuming.

How do I organise QR codes across dozens of locations without mixing them up?

Use one workspace for the brand, one group per physical location, and a naming convention that is unambiguous out of context, such as brand-storenumber-city-campaign. Keep a single spreadsheet mapping store number to code name to address, and check every code against that mapping before a print run ships.

How do I generate QR codes in bulk for multiple stores?

Build a spreadsheet with one row per location, a destination URL column and a name column, then import it in one batch rather than creating codes individually. See the bulk-generation guide linked above for the exact steps.

What happens to a location's QR code when that store closes or moves?

A dynamic code's destination can be repointed the moment the closure happens, to a relocation notice, the nearest open store, or a corporate holding page, without touching the physical sign. A static code with a fixed, printed destination cannot be updated at all once it is on the wall.

What metrics should a multi-location QR campaign actually track?

Total scans and trend at the network level, then the same two numbers broken down per location so under- and over-performing stores are visible at a glance. Avoid comparing raw scan counts alone across stores of very different footfall; a rate relative to visible signage or footfall is more useful than a bare total.

Should a real estate brokerage with many branches use one code per branch or per agent?

Per agent, generally, since the person is usually the point of contact a lead needs to reach, not the branch office. A brokerage running signage across a whole regional office network faces the same bulk-generation and naming questions as a restaurant chain; see QR codes on real estate signs for the signage-specific detail.

Do franchisees need their own login, or does one shared dashboard work for everyone?

That depends on whether the platform offers a restricted, single-location role. Where it does not, the practical middle ground is sharing a group-filtered analytics view or export with each franchisee rather than full account access, so a manager sees their own numbers without seeing every other store's.

The short version

Decide first whether the campaign needs a shared, geotargeted code or a unique code per location, and be honest that IP-based routing is only reliable at the country or region level, not store to store. Past a handful of locations, generate codes in bulk from a spreadsheet rather than by hand, organise them with one group per physical location inside a single workspace, and settle on a naming convention that still makes sense out of context a year from now. Keep the visual design consistent across every location while letting the underlying code differ per store, because that is the only way branding and per-location attribution coexist. Because closures, moves and ownership changes are a routine, disclosed part of any franchise system, use dynamic codes so a sign never has to be reprinted just because the destination behind it changed. Build the rollup so corporate gets one network number with drill-down, and each location manager gets a view scoped to just their own store, and if your platform cannot yet restrict that view by role, plan around it with a filtered export rather than promising something the account structure cannot enforce. Start by mapping out how many physical locations the next campaign actually covers, then build the code list from that map instead of the other way round.