Multi-site rollouts fail in the gap between a head office standard and what a branch actually does on a Saturday. The differences that stop the programme at the fourth location are invisible from a central report.
This guide covers what a visit to the least typical site reveals, what each location has to get back for the data it supplies, and why the pilot belongs at a difficult branch rather than a willing one.
Key takeaways
- Pilot at a difficult site: A rollout proven at the easiest location tells you little, and the problems arrive everywhere at once later.
- Give each site something back: A system that only sends information upwards is treated as reporting overhead and complied with minimally.
- Measure by location: One strong site can carry an average while four others never start, and the total hides that.
- Visit the least typical branch: The differences that will stop the rollout at site four are invisible from a central report.
Define the decision before comparing options
Name the actual selection before scoring options, an approach, a product, a partner, or a combination of them. Then state the outcome, protected constraints, unresolved assumptions, and evidence required before the next commitment. Without that frame, proposals can appear comparable while solving different problems.
For multi-location business digitization, the aim is to balance shared workflows, local permissions, master data, reporting, and phased rollout. Ask every option to address the same representative journey, operating workflow, integration boundaries, quality expectations, and ownership after launch.
Trace one valuable process across customer contact, employee action, systems, decisions, and management review. Mark recurring delays, duplicate records, policy choices, and exception routes before deciding which layer should change.
Compare the same four capabilities
1. Shared Standard
Write down the part of the process that must be the same at every site, and the reason a branch manager would accept it. Shared standards survive when the reason is visible and quietly stop being followed when it is not.
2. Local Workflow
Record what each location does differently that genuinely works, and what would break if you removed it. The least typical site is usually the one holding the requirement nobody at head office has heard of.
3. Central Data
Decide which figures head office needs, at what frequency, and what each site gets back for supplying them. A system that only sends information upwards is treated as reporting overhead and filled in to the minimum.
4. Rollout
Plan the order of sites, who trains whom, and what happens when the fourth location reports a problem the first three did not have. The rollout sequence is where multi-site projects usually fail, not the software.
Normalize proposals before comparing price
| Area | What to compare | Warning sign |
|---|---|---|
| Outcome | The user and business result the work is meant to improve | Success is described only as shipping features |
| Scope | Complete journeys, roles, operations, and failure paths | A screen count hides backend or staff work |
| Evidence | Prototypes, working slices, tests, and readiness reviews | Progress is reported only through hours or tickets |
| Commercials | Assumptions, exclusions, change model, and payment points | A low total depends on unstated happy-path assumptions |
| Ownership | Access, documentation, data, deployment, and support | Handover is deferred until the end |
Ask for evidence of the delivery approach
Past work helps establish credibility, but delivery practice and decision quality require their own evidence. Ask to see anonymized examples of a journey map, scope boundary, architecture decision, risk log, quality plan, or release-readiness review. The goal is not to collect documents; it is to understand whether decisions become visible and testable.
For a connected-product example, review How to Build a Digital Operating Model for Your Business and use the same customer-plus-operations lens when testing proposals.
Make commercial and governance responsibilities explicit
Make live-operation ownership explicit while the approach and commercials are still being agreed. Store accounts, cloud environments, analytics, support access, incident response, dependency updates, and roadmap review all need a named home. A partner may operate some of them, but the business should retain appropriate visibility and exit options.
Review risks before commitment
| Decision area | Risk to expose | Evidence to request |
|---|---|---|
| Shared Standard | Unclear priorities | Request the assumption, an early validation step, and the decision that follows. |
| Local Workflow | Process drift | Confirm inclusions, dependencies, exclusions, and the commercial change rule. |
| Central Data | Adoption gap | Review a failure scenario, quality evidence, owner, and proposed response. |
| Rollout | Weak evidence | Verify access, documentation, handover, support, and a workable exit path. |
A trustworthy proposal shows how open questions will be answered over time. It shows how uncertainty will be reduced and how the roadmap can change without losing control of the outcome.
Run one reference scenario before the final choice
Give every shortlisted option the same realistic scenario involving shared standard, a failure or exception around local workflow, and a business decision tied to rollout. Ask each team to talk through the user experience, staff response, data movement, evidence, and tradeoffs. The exercise does not need speculative design work. Its purpose is to reveal how the team structures ambiguity, notices operating consequences, and communicates a decision.
Test ownership with a future handover exercise
Imagine that the team responsible for multi-location business digitization changes one year after launch. Ask each option to explain how a new team would understand shared standard, operate local workflow, diagnose problems around central data, and take responsibility for rollout.
Review the expected source access, environment ownership, data export, deployment process, monitoring, documentation, decision history, dependency list, and support procedures. Do not require paperwork for its own sake; require the information and access a competent team would need to protect continuity.
Then test a change request. Ask how a newly discovered rule or integration constraint would move from business decision to estimate, design, implementation, verification, release, and documentation. The answer exposes the real change model behind the proposal.
This future-handover view helps the business balance shared workflows, local permissions, master data, reporting, and phased rollout without creating avoidable supplier dependency. It also distinguishes a partner willing to build durable ownership from one whose process remains understandable only while the original individuals are present.
A 30-day validation plan: Multi location business digitization
Days 1 to 5: visit the least typical site. Spend two days at the location head office finds most difficult and watch the process run. The differences you find there are the ones that will stop the rollout at site four, and they are invisible from a central system report. Go on a day the site is busy, because the workarounds that matter only appear when there is no time to follow the official route.
Days 6 to 15: agree what each site gets back. Decide what a branch receives in exchange for the data it has to supply: a figure it can act on, a decision made faster, a task removed. A rollout that only sends information upwards is experienced as reporting overhead and is complied with to the minimum. Make that exchange explicit in the rollout material, since a site that cannot see the return will treat the new system as somebody else's project.
Days 16 to 30: pilot at a difficult location. Run the change at the hardest site rather than at the willing one, and record every exception. Proving a rollout at the easiest location tells you very little, and the problems you avoid finding there arrive at every remaining site at the same time. Count how many of the exceptions were local and how many would occur anywhere, as only the second group should delay the next site.
A practical worksheet: Multi location business digitization
Multi-site rollouts fail in the gap between a head office standard and what a branch actually does on a Saturday. Complete these rows with a manager from your least typical location in the room.
| Decision area | What to record |
|---|---|
| Shared Standard | The part of the process that must be the same everywhere, and the reason a branch manager would accept that |
| Local Workflow | What a site does differently that genuinely works, and what would break if you removed it |
| Central Data | Which figures head office needs, at what frequency, and what each site gets back in return for supplying them |
| Rollout | The order of sites, who trains whom, and what happens when site four reports a problem sites one to three did not have |
| Measurement | Use by site rather than in total, because one strong location can carry an average while four others never start |
Pick a difficult site for the pilot rather than a willing one. A rollout proven at the easiest location tells you very little, and the problems you avoided finding early reappear at every remaining site at once.
Related guides
- A second perspective worth having is Digital Transformation Roadmap: A 7-Step Business Guide.
- The operational half of this is in Paperless Workflow: How to Digitize Paper-Based Processes.
If How to Digitize a Multi-Location Business Without Losing Local Context is the start of a roadmap someone has to own, Discuss Your Digital Roadmap.
Ali Boran Gazel