How to keep twelve locations answering the same way

Multi-site businesses have a consistency problem that is not really about technology. Every location answers the phone slightly differently, because every location is staffed by different people who learned the job from different people. Over enough sites, “slightly” compounds into a brand problem and, occasionally, a legal one.

The instinct is to centralise. The instinct is half right.

Draw the line in the right place

The useful split is between what must be identical and what must be local. Getting this wrong in either direction causes predictable damage.

Head office should own:

• Policy. Refunds, cancellations, complaint handling, anything with a threshold.
• Tone and the answers to brand-level questions.
• What escalates, and to whom.
• Compliance language — the sentences that must appear verbatim.

The site should own:

• Its diary. Nobody at head office knows that Thursday afternoon is blocked for a delivery.
• Its number, and the local details attached to it — parking, access, the door code.
• Its staff, and who picks up an escalation.
• Local pricing where pricing is genuinely local.

The failure mode of over-centralising is a system that confidently tells a customer there is a 15:30 slot at a site that closed early for a training day. The failure mode of over-devolving is twelve different refund policies.

Rollout is where this actually breaks

The theory is easy. The reason multi-site consistency projects stall is that rolling out to site thirteen is as much work as site one, so it never finishes.

The thing that fixes this is inheritance: the rulebook is defined once, each site inherits it, and a site only stores its differences. Opening a new location means creating it, attaching its number and diary, and overriding whatever is genuinely different. That should be an afternoon, not a project.

If your rollout cost is flat per site, you will get to about site five and stop.

The reporting that actually gets used

Once every location answers the same way, you get something you did not have before: comparable data. Not “site 4 seems busy” but the same questions, counted the same way, across every site.

The two reports that earn their keep:

1. What is asked, by site. Differences here are real signal. If one location gets triple the “where do I park” traffic, that is a signage problem, and you have just found it without visiting.
2. What escalated, by site and by rule. This tells you where the rulebook is under-specified. A rule that escalates constantly at every site is a rule that should have an answer.

Start with one site, not twelve

The mistake is designing the whole multi-site structure before proving the rulebook. Run one location properly for a fortnight, and let it generate the list of things you had not written down — because there will be twenty, and they are easier to find at one site than at twelve.

Then the rollout is copying something known to work, which is a much easier project to finish.