An SOP update signed off at head office is supposed to be live everywhere within a week. In practice it lands at half the sites inside a month and at the rest sometime next quarter, if at all.
The friction is not the authoring. Head office writes procedures and head office is good at it. The friction is everything after the signature: distribution, manager attention, the training itself on a running shift, and the verification that any of it happened. This playbook is about that second half, and it applies wherever you run the same procedure at more than one address: distribution centres, production sites, branches, stores, depots.
The four phases, and the three that leak
A rollout has four phases. One, authoring: the new or revised SOP is finalised and signed off. Two, deployment: the document is turned into something a frontline worker can absorb and pushed to every site. Three, site-level instruction: people actually complete it inside their shift pattern. Four, verification: head office confirms who did it and intervenes where they did not.
Almost every multi-site operator has phase one under control. Phases two, three and four are where the time and the quality leak, and they leak in that order of severity.
Phase two: the rebuild that keeps L&D one release behind
The gap between "we have a new SOP" and "everyone is instructed on it" is usually a manual content build. Someone takes the document and rebuilds it as a deck or an authored e-learning module. That takes two to four weeks. By the time it is ready, the next revision has been signed off, and the team is structurally one rollout behind. Nobody is lazy in this picture. The queue is simply longer than the interval between changes.
The fix is to stop rebuilding. The procedure document itself is the source: it goes in, a short course comes out, in hours rather than weeks. Once that step costs hours, the rollout cycle compresses from a quarter to a week and head office stops being content-bound.
Phase three: the shift schedule is the real constraint
Deployment is the easy half. Getting every worker on every site to complete the instruction is the hard half, and the friction is predictable: the manager does not prioritise it during a busy shift, the worker forgets, and the rota has no training slot in it.
Two things move the needle. First, the format has to fit the gap that actually exists: three to five minutes, on the phone the worker already carries, no laptop and no app install. That is a slow moment at the counter, the start of a shift, a break. Second, the site manager needs the same completion view head office has. If the manager can see who on their own roster is outstanding, head office does not have to chase them, and the conversation stops being a status request and starts being a scheduling decision.
Phase four: 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 working verification view shows completion per site, days since deployment, and which sites are running late. That lets you intervene specifically: a call from the regional manager, an extra assignment on a quiet shift, an escalation to the site owner. It turns "we issued it" into "every site did it".
Half the network is a legal position, not just a delay
Here is the part most rollout advice leaves out, and it matters more in the Benelux than the generic playbooks admit.
In Belgium, Codex art. I.2-21 requires the employer to make sure every worker receives sufficient and appropriate vorming (training) relating to welzijn op het werk, aimed at their own werkpost or function. The article names the moments that trigger it: entry into service, a change of function, new work equipment, and new technology. It also says the training is repeated and adapted to evolving risks, at the employer's cost and during working hours.
Read that against a typical rollout. A new palletiser on line 3, a new scanner in receiving, a revised changeover procedure, a different chemical in the cleaning cycle: these are not merely operational updates, they are named triggers for renewed instruction. If the SOP change reached twelve of your twenty-two sites, the other ten are running new equipment or a new method with people whose last instruction described the old one.
In the Netherlands the pressure comes from a different direction. Arbowet art. 8 lid 2 requires instruction that is effective and adapted to the worker's distinct tasks, and art. 8 lid 4 requires the employer to supervise compliance with the instructions given. Supervision of something you cannot see the status of is a claim, not a fact.
So the incomplete rollout is not only an execution problem. It is the difference between a documented instruction cycle and a partial one, on exactly the trigger the law names.
The cycle time to hold yourself to
A well-run rollout moves from sign-off to verified completion across all sites in days, not quarters. That is the operating target, and it is reachable when four things are true: authoring-to-course takes hours rather than weeks, deployment is push rather than pull, site managers have their own completion view, and head office can see and act on the laggards. Miss any one of the four and the cycle time drifts back out.
Set the target explicitly per rollout, and set it differently for different content. A menu or planogram change can run on a seven-day window. A change tied to new equipment should be complete before the equipment is used, which usually means the window is set by the installation date, not by a training calendar.
Three numbers, reviewed weekly
Median time from sign-off to verified completion. Share of rollouts finished inside their own target window. Number of sites that sit in the bottom quartile more than once a quarter.
The first two measure the system. The third identifies which sites need a different conversation entirely, because a site that is always last is not having a training problem, it is having a management one. None of the three is collectable by hand at scale, which is precisely why most operators do not have them.
Running the rollout in Aristotl
The steps below are the same four phases, done in one place.
Start from the document you already signed off. Drop the SOP in as PDF, Word or PowerPoint. Aristotl reads it and returns a parsed outline of sections and procedures, which you correct inline. There is no rebuild in a slide tool.
Generate the course and review it. You get modules with knowledge checks and scenario questions tied to the content of that SOP. Edit any text, swap a question, split a module that runs long, then approve.
Assign by site and role. Target all sites, a region, or a named list, and narrow to the roles the change actually touches. Set the deadline against the operational date, not a round number. Content is translated per worker, so a mixed-language shift gets the same procedure in the language each person reads.
Push it, do not publish and hope. Every assigned worker is notified and opens it on their own phone. Site managers get their outstanding list.
Verify per site, role and version. The dashboard shows live completion sliced by site, role and course version, escalates what runs past the deadline, and exports the underlying record: every person, the timestamp, the knowledge-check result, per site. That export is the artefact you hand over when someone asks which version of the procedure a given worker was instructed on.
Bring the change you are shipping next
Take the SOP revision that is sitting in your approval queue right now. In a demo we build it into courses for the sites it affects and show you what the completion record looks like the next morning.