Scaling AI across fifteen branches is not the pilot repeated fifteen times. Branch four has a manager who rebuilt the intake process by hand and will not give it up. Branch nine runs a satellite link that drops at midday. Branch eleven has different opening hours, different staffing depth, and a local regulator the head office rarely thinks about. The strategies that work in 2026 are built around that variance: a readiness score per site, deployment in waves, and a written exceptions register that says which sites diverge and why. Teams that produce those three artifacts finish. Teams that produce a deployment plan stall somewhere around site five.
The Five Things That Decide a Multi-Site Rollout
- Site variance is the project, not a complication. Peak hours, staffing depth, connectivity and local practice differ per location and every one of them breaks a uniform plan.
- A readiness score decides the wave order. Score each site on connectivity, process conformity, staffing, and local champion, then sequence by the result rather than by revenue.
- The exceptions register is the real deliverable. Undocumented local divergence is what turns support into archaeology eighteen months later.
- Rollback has to work per site, not estate-wide. One bad branch should not cost the other fourteen their capability.
- The connectivity floor is a hard gate. A site below it does not get a cloud-dependent workflow, whatever the enthusiasm at head office.
Written for IT directors and operations leaders at 50 to 500 employee firms running between five and fifty locations.
Why the Pilot Site Told You Less Than You Think
The pilot site told you less than you think because pilots run where conditions are best: head office, good connectivity, the staff most interested in trying it, and the process closest to how the company believes it works. Every one of those is a selection effect. We now ask a specific question before reading any pilot result: would this site have been chosen if it were not convenient. If the answer is no, the pilot measured the ceiling rather than the average.
Run the Second Pilot Somewhere Awkward
Before committing to a wide rollout, run a second pilot at a site you would not have chosen: weaker connectivity, a manager who is sceptical, a process that drifted years ago. This costs a few weeks and reliably changes the plan. What surfaces there is what will surface at scale, usually in the form of a workflow assumption that was true only at head office. Teams that skip this discover the same issues at site six with twelve more already scheduled, which is the expensive version of the same lesson.
Score Sites Before Sequencing Them
Build a simple readiness score per location across four factors: connectivity headroom, how closely local process matches the documented one, staffing depth during the rollout window, and whether a credible local champion exists. Four columns and a number. Sequence waves so that early waves are high scorers, which builds evidence and internal advocacy, and the difficult sites arrive once the playbook has absorbed real lessons. Sequencing by revenue or by regional politics is the common alternative and it front-loads your hardest problems into the window where you have the least experience.
The Connectivity Floor Is Not Negotiable
Set a minimum connectivity standard below which a site does not receive a cloud-dependent workflow, and hold it. Sites under the floor get either a network remediation first or a workflow variant that tolerates interruption. This is the one criterion we refuse to bend, because a branch that experiences the tool as unreliable in its first month will not re-adopt it later, and recovering that goodwill costs more than the network upgrade. Distributed connectivity design is its own discipline, covered in SD-WAN for distributed enterprises.
Standardise Hard, Vary Deliberately
The working balance is a narrow standard core with explicitly approved local variation, because pure standardisation fails at the first genuine local difference and pure autonomy produces fifteen unsupportable deployments.
What Must Be Identical Everywhere
Identity and access, logging and retention, the escalation path, the model and version in use, and the data boundaries. These are the things that make support possible and audit answerable, and there is no legitimate local reason to vary them. Enforce them through templates and policy rather than documentation, because a setting that can drift locally will, usually during a busy week when somebody needed a workaround. The permission and exposure model underneath this is in are AI agents safe for enterprise use.
What Legitimately Varies
Prompt content referencing local services, business hours and escalation timing, language, the local knowledge base, and which workflows are enabled at all. A branch that does not offer a service should not have the workflow for it. Treating these as variation rather than deviation is what keeps the exceptions register short and meaningful, because a register that records everything records nothing.
The Exceptions Register Nobody Wants to Own
Every approved divergence gets a row: the site, what differs, who approved it, why, and when it is reviewed. This is dull and it is the artifact that determines whether year two is manageable. Without it, local divergence becomes invisible, support starts guessing, and the first estate-wide change breaks three sites nobody knew were different. Assign the register to one named owner, review it quarterly, and retire rows whose reason has expired. Coordination patterns across many deployments are the subject of multi-agent systems and coordinating AI agents, and the department-level analogue is in scaling Claude API integrations across multi-department operations.
The Knowledge Base Problem Multiplied by Fifteen
Retrieval-backed workflows inherit whatever the local knowledge base contains, and in a multi-site firm that is fifteen collections of documents at fifteen different levels of upkeep. Head office maintains its material because head office wrote the policy that requires it. Branch nine has a folder last tidied when its previous manager left. Point a retrieval system at both and the quality difference is invisible to the user, who sees a confident answer either way, while the underlying documents are accurate at one site and eighteen months out of date at another. The practical approach is to identify which content must be central and authoritative, typically policy, pricing, and anything regulated, and serve that from one source to every location regardless of local folders. What stays local is genuinely local: site procedures, floor plans, local supplier contacts. Auditing the local collections before enabling retrieval is tedious and it is the step that decides whether the tool is trusted at site nine, because the first confidently wrong local answer is the one staff remember.
Running the Waves
Waves of three to five sites work for most firms this size, spaced far enough apart that lessons from one wave can actually change the next.
Spacing the Waves So Learning Lands
Two to three weeks between waves is usually right. Shorter and the lessons arrive after the next wave is already committed, which produces the appearance of a phased rollout with none of the benefit. Longer and momentum dissipates, the playbook goes stale, and staff trained in wave one have forgotten it by the time their neighbours start. Write down what changed between waves, because a rollout that reaches site forty with an unchanged playbook either had a very uniform estate or stopped listening around site eight.
The Local Champion Problem
Every playbook says identify a local champion and almost none say what to do when a site has none. The honest answer is that such a site needs more central support rather than being pushed forward on schedule, and pretending otherwise produces a location where nobody owns the tool and usage decays quietly after the launch week. We either find a champion at a neighbouring site willing to cover two locations, or we move that site to a later wave and invest in training depth instead. Training design matters here more than tooling, which is the argument in training your team for effective adoption.
Per-Site Rollback and the Blast Radius Question
Build the ability to disable a workflow at one location without touching the others, and test it before wave one. The default in many deployments is a global switch, which means a problem at one branch forces a choice between leaving it broken there and removing capability everywhere. Per-site control turns that into a local decision taken in minutes. This is a configuration question rather than an engineering one in most platforms, and it is worth confirming during selection rather than discovering during an incident.
Measuring a Rollout by Spread, Not Average
Estate-wide averages conceal exactly the problem a multi-site rollout has. A usage figure of seventy percent can mean every branch at seventy or nine branches at ninety and six at twenty, and those two situations need opposite responses. Report the distribution per site and watch the bottom quartile, since the sites at the bottom are where the rollout is actually failing and where the next wave’s lessons come from. Two further per-site numbers earn their place: time from launch day to the first unprompted use by someone who was not in the training session, which measures whether the capability escaped the launch, and the ratio of local override to standard use, which measures whether the workflow fits how the branch really operates. A site with high usage and high override is telling you the design is wrong for it rather than that adoption succeeded. We review these at each wave boundary and let them drive the playbook change, which is the mechanism that keeps a fifteen-site rollout from arriving at site fifteen with the wave-one plan intact and a trail of quietly unused deployments behind it.
Frequently Asked Questions
How many sites should be in the first wave?
Three to five for most firms running between five and fifty locations, all high scorers on readiness. Small enough that problems are manageable and large enough that the result is not a second pilot. The purpose of wave one is to harden the playbook, not to cover ground.
Should we roll out to the biggest locations first?
Usually not. Sequence by readiness score rather than size, because a struggling rollout at a flagship site is visible and damages internal support for the whole program. Large sites often carry the most process divergence, which is exactly what you want to meet after the playbook has been tested elsewhere.
What if a site’s connectivity cannot be fixed?
Give that site a workflow variant that tolerates interruption, or leave it out until the network is remediated. Deploying a cloud-dependent workflow to a site below the connectivity floor produces a location that experiences the tool as unreliable, and re-adoption after a bad first month is considerably harder than a delayed start.
How do we stop local teams building their own variations?
Make the approved variation path faster than the unofficial one. Teams improvise when the official route is slow, so a request that gets a decision in days keeps divergence inside the register. Combine that with policy-enforced settings for the things that must never vary, since documentation alone does not hold.
Who owns the rollout across locations?
One named person with authority to sequence waves and approve exceptions, supported by local champions rather than replaced by them. Committee ownership produces a rollout that pauses between meetings, and that pattern is visible in every stalled multi-site program we are called into.
Who Is Behind This Guidance
Our team supports multi-location firms across managed IT and security, which means we spend time at the branches rather than only at head office, and that is where this article comes from. The recurring finding is that head office holds a model of how the business operates and the branches hold the reality, and an AI rollout is often the first project to discover the gap in detail. We plan for variance from the start because we have watched uniform plans collapse at site five often enough to stop expecting otherwise. Matt Rosenthal, Mindcore’s CEO, keeps the practice focused on making technology decisions hold up operationally rather than only on paper, which for a multi-site rollout means a plan that survives contact with branch four. That is the standard this is written to.
Score the Sites Before You Schedule Them
Build the readiness score across connectivity, process conformity, staffing depth and local champion, then sequence waves from it. Run a second pilot somewhere genuinely awkward before committing. Fix the standard core at identity, logging, escalation, model version and data boundaries, enforce it with policy rather than documentation, and put every approved divergence in a register with an owner and a review date. Space waves two to three weeks apart and write down what changed between them. Confirm per-site rollback works before wave one. Most multi-location firms we work with have the technology question settled and the variance question untouched, which is why the rollout that looked like a six-week plan is now in month five. If the underlying network is the constraint, our IT support services and cloud security practices cover that ground first. Bring your site list to a free strategy call and we will score the first wave with you.
