The multi-site SOP rollout playbook

A procedure is not changed on the day the document is signed. It is changed on the day the last picker on the last night shift at the smallest distribution centre does it the new way. Between those two dates sits everything that goes wrong: the PDF in a mailbox nobody reads, the printout pinned next to a scanner with page four missing, the site that never heard about it because the person who normally forwards these things was on holiday.

Most operations teams know the revision date. They do not know the floor date, and that gap is what this playbook is about.

Different changes, one event on the floor

The scanner software on the pick trucks is updated and the confirmation step moves from the end of the pick to the start. A machine guard is replaced and the cleaning sequence gains a lockout step. The handover between shifts changes what must be written down and who signs off. A recipe keeps its name and changes its allergens. A label rule takes effect on a fixed date.

Different departments own these and different budgets pay for them. From the worker's side they are the same event: something I do every day is now done differently, and somebody has to tell me clearly what changed and why. The most dangerous version is the change that looks the same, like the recipe with a new ingredient, because nobody notices they need to relearn it.

The change is what the law points at

In Belgium this is not an internal preference. Codex art. I.2-21 requires training aimed at each worker's workpost or function and names the moments it is owed: entry into service, a change of function, and the introduction of new work equipment or new technology. It adds that training is repeated and adapted to evolving risks, during working hours and at the employer's cost. A new scanner configuration is new technology. A replaced guard with a new lockout sequence is new work equipment. The trigger is the change, not a calendar.

In the Netherlands, the Arbowet asks for instruction that is effective and adapted to each worker's own tasks, and for supervision that it is followed; the instruction law guide sets out both duties. A generic annual session does not adapt to a task that changed last Tuesday. Certified sites carry the same logic: VCA question 4.1 names changes to rules and procedures as toolbox content (see toolbox meetings that land), and IFS Food 3.3.4 expects training content to be updated for product and process changes.

So an incomplete rollout is not only slow. If a change reached twelve of twenty-two sites, the other ten are running new equipment or a new method with people whose last instruction described the old one.

The four phases, and the three that leak

A rollout has four phases. Authoring: the revised SOP is finalised and signed. Deployment: it is turned into something a frontline worker can absorb and sent to every site. Site instruction: people complete it inside their shift pattern. Verification: head office confirms who did it and acts where they did not.

Almost every multi-site operator has the first phase under control. Head office writes procedures and is good at it. The time and the quality leak in the other three, in that order of severity.

Deployment: stop rebuilding the document

Ask why a change took five weeks to reach the floor and the answer is rarely "we forgot". Someone had to read the new SOP, work out what differs from the old one, write a script, build slides, get them reviewed, translate them for the sites where Dutch is not the working language, and find a slot in the schedule. That queue is longer than the interval between changes, so the training team is structurally one release behind. It is also why the second and third changes of the quarter go out as an email, which is how sites end up on different versions of the same procedure without anyone deciding they should.

The fix is to stop rebuilding. The signed document is the source; the module is derived from it, and the procedure owner's job shifts from author to reviewer.

Site instruction: teach the change, not the procedure

A rollout module is not a course on picking. The people receiving it already know how to pick. It is three to five minutes on what is different, why it is different and what the new sequence is, with questions about the moment where the old habit and the new rule now conflict, because that is the only place the change can fail.

That length is deliberate. It fits between a break and a shift start, on the phone the worker already carries, with no laptop. It arrives in the language each person reads. And the site manager needs the same view head office has: when a manager can see who on their own team is outstanding, the conversation stops being a status request and becomes a scheduling decision.

Verification: the sites you never heard from

This is where rollouts die quietly. Head office assumes it is done because nobody reported a problem. In reality several sites are incomplete, and the bottom of that distribution is where an incident, an audit or an inspection will find you. A useful verification view shows completion per site, days since the change went out and which sites are running late, so the response is specific: a call from the regional manager, a slot on a quiet shift, a conversation with the site owner.

A three-week rhythm for routine changes

A network that ships procedure changes as normal business, not as a quarterly emergency, runs them on a fixed rhythm and repeats it.

If the document needs more time, move the whole rhythm; do not compress weeks 2 and 3. Verification is the week most networks skip, and the chronic laggard sites it would have caught compound across rollouts into a real gap between what the manual says and what the floor does.

Waves inside the window

A regional or district manager controls three things within the window: the timing, the order of sites and where to spend personal attention. A wave pattern uses all three.

Break the pattern on purpose for three kinds of change. Anything regulated, such as a food safety or safety procedure, goes everywhere on day one. A recall or an emergency procedure goes everywhere at once, because speed matters more than smoothness. A launch tied to a date, like a menu change, goes live everywhere on that date, and the manager's role becomes readiness checking rather than staged adoption. A site that lands in wave 3 rollout after rollout does not have a training problem; it has a management one, and it deserves that conversation separately.

When the sites are not yours to run

In a franchise network, the site owner runs a small business: hiring, scheduling, suppliers, a P&L. A head office procedure is one more item on a list of local emergencies, and without a reason to prioritise it, it slides. That is economic rationality, not insubordination, so another email does not fix it. Three structural levers do.

First, give each owner their own view of their own sites, with the gaps visible. Data that sits only at head office is invisible to the person who can act on it. Second, connect completion to the brand-standard obligation already in the franchise agreement, and use that lever sparingly but consistently, because a clause nobody enforces is not a lever. Third, agree an escalation ladder in advance: a check-in from the regional manager, then a conversation with the franchise director, then a formal review. Framed as the same treatment for every owner, it reads as fairness rather than policing.

Three numbers, reviewed weekly

Median time from signed document to verified completion. Share of rollouts finished inside their own window. Number of sites in the bottom quarter more than once a quarter.

The first two measure the system. The third names the sites that need a different conversation. None of the three is collectable by hand at scale, which is exactly why most operators do not have them. Set the window per change: a planogram or menu update can run on seven days; a change tied to new equipment should be complete before the equipment is used, so the installation date sets the deadline, not the training calendar.

Running the rollout in Aristotl

Aristotl covers the three phases that leak, starting from the document you already signed.

Build from the signed document. The revised SOP, the work instruction or the spec sheet goes in as the source, and Aristotl drafts a short course about the change with knowledge checks tied to it. The procedure owner edits the wording on the steps that carry risk, and nothing reaches a site until you review and publish it.

Send it to the sites and teams it touches. Assign to every site, a region or a named team, with a due date set against the operational date. Each person gets it in the language they read, on their own phone, in the browser, with no laptop and no app to install. Site managers see their own sites and their own outstanding names, so head office stops acting as a switchboard.

Verify per site and version. Completion and knowledge check results are viewable per site and per version of the course in the platform. Six months later, when someone asks when the new handover protocol landed at plant two, the answer is a dated list per person against the version they completed, not a search through sent mail.

Take the SOP revision that is waiting to go out right now, ideally one like the last change that did not land cleanly, and bring it to a demo. We build the module from it and show you the per-site record you would be holding a week later.