A single-site launch is a communications exercise. You tell everyone, you help the ones who get stuck, and by week two you know whether it worked.
Twelve sites is a different problem. You are not launching once with twelve times the people, you are launching twelve times with twelve different managers, twelve different rosters, and twelve different levels of interest in what head office has sent them this month.
The Failure Mode
Two or three sites will take it up enthusiastically. Six or seven will do it because they were told to. Two will do nothing at all, and because the company-wide number looks acceptable, nobody notices for a quarter.
The dead sites are not a communications problem you can fix with another email. They are usually a manager who was never sold on it, and that is fixable but not by broadcast.
By the time a site has been dark for three months, restarting it costs more than launching it did. Staff there have already formed the view that this was another thing head office announced and forgot.
Sequence, Do Not Big-Bang
Launching everywhere on the same Monday feels efficient and is not. You get one shot at each site and no chance to learn between them.
| Wave | Sites | Purpose |
|---|---|---|
| Wave 1, week 1 | 1 site, ideally a mid-performing one | Find the problems with your own data and your own comms |
| Wave 2, week 3 | 2 to 3 sites, mixed | Test the fixes, produce internal proof |
| Wave 3, week 5 | The rest, in groups by region | Roll with a briefing that has already been road-tested |
Do not pilot at your best site. It will succeed for reasons that do not transfer, and you will learn nothing except that good sites are good.
One Named Person Per Site
Not a committee, not "the store manager" as a role. A person, by name, who has agreed to it. Their job is small: send the first ten recognitions and answer questions for a fortnight.
In practice this is the single highest-return thing in a multi-site rollout. Sites with a named champion activate roughly twice as fast as sites without one, and the gap does not close over time — it widens.
Budget By Site, Not By Company
A single company-wide pool means the sites that move fast consume it and the slow sites get nothing left. Worse, it makes the reporting useless: you cannot tell whether a site is underspending because it is disengaged or because the pool ran dry.
- Allocate per site, per period, proportional to headcount.
- Leave a central discretionary pool for the sites that need a push.
- Let unspent site budget lapse rather than roll — rolling rewards inactivity with a bigger balance next quarter.
What To Watch, And When
| Checkpoint | Look at | Act if |
|---|---|---|
| Day 3 | Recognitions sent by the champion | Zero |
| Day 7 | Activation rate for that site | Below 35% |
| Day 30 | Activation, and first redemption | Below 60%, or no redemptions |
| Day 90 | Monthly active users | Below half the company median |
Every one of those is a per-site number. Looking at the company average at day 30 will tell you the rollout is fine right up until it is not.
Rosters, Not Email
Whatever the comms plan says, the channel that works in a multi-site business is the one already used to run the site: the roster board, the pre-shift huddle, the group chat the team actually reads.
A poster by the time clock outperforms an all-staff email by a wide margin, because the all-staff email goes to an address half the workforce does not have. That is the same root cause as most single-site failures, just multiplied.
Timing
Do not launch into a peak. Retail in November, hospitality over summer, logistics in the pre-Christmas run — a site in the middle of its busiest month will not adopt anything, and you will have burned the launch.
The quiet six weeks after a peak is the best window. People have capacity, and the timing reads as recognition for the period they have just come through.
Rolling out across more than one site?
Send us the site list and headcounts and we will draft the wave plan.