Software Rollout Training Plan: A Go-Live Template for Multi-Site Teams
A practical training plan for rolling out software across sites and shifts: what to prepare before go-live, how to run go-live week, the 30 days after, and how train-the-trainer works when your users are on the shop floor, not at a desk.
A rollout training plan answers four questions: who uses the software, what each of them has to do in it, who teaches them, and how you'll know it worked. For multi-site, multi-shift rollouts the plan that holds up is train-the-trainer. The central team (or the vendor) trains a champion at each site, every role gets short task-based material on their phone, crews are trained hands-on during go-live week, and you track adoption in the system for 30 days. Below is the template, phase by phase.
This is written for rollouts where most users aren't at a desk: maintenance, safety and permit systems, inspections, site management, field service. It also works for office software, but that's where the usual approach (a webinar and a help center) already works reasonably well.
The plan on one page
| Phase | When | Who | Output |
|---|---|---|---|
| Map | 4–6 weeks before | Project lead + site supervisors | Roles × tasks list |
| Build | 3–4 weeks before | Project lead / vendor | One walkthrough per task per role, plus a champion checklist |
| Champions | 1–2 weeks before | Vendor → site champions | Every champion has done every task in a test environment |
| Pre-go-live | 2–3 days before | Champions → crews | Each person has their role's walkthroughs on their phone |
| Go-live week | Week 1 | Champions on site | Each person completes each task once, observed |
| Hypercare | Days 1–30 | Champions + central team | Daily issue log, weekly adoption numbers per site |
Phase 1: Map roles and tasks
Get a supervisor from a representative site in a room for an hour and fill in this grid:
- Rows: every role that will touch the software (requester, approver, technician, supervisor, planner, contractor, admin).
- Columns: the tasks each role does in a normal week.
Most rollouts end up with 4–6 roles and 3–6 tasks per role. That grid is your training scope. Anything not on it (reports, settings, rare edge cases) gets a help article, not training time.
Also note, per site: shift patterns, languages spoken, phone types, connectivity on the floor, and how many contractors rotate through. These decide the format.
Phase 2: Build the material
For each task on the grid, make one short walkthrough of the real screens, with where to tap and one line per step. Store them by role, so a technician gets the technician set and nothing else. (How to build one from screenshots.)
Also build:
- A champion checklist: "Each person on your crew completes these tasks once while you watch," with the walkthrough link next to each task.
- A one-line "why" for crews. What problem the new system fixes for them (no more chasing paper permits, no more re-entering data at end of shift). Adoption is mostly about this sentence.
- Translations, if crews work in other languages. One walkthrough per language beats bilingual screens.
Build the material in the test environment, then re-check the screens against production the week before go-live. Small UI changes between environments are the most common reason training material looks "wrong" on day one.
Phase 3: Train the champions
Pick one or two champions per site and shift, usually supervisors or a respected senior technician. Then:
- Run a session (on site or remote) where each champion completes every task on the grid themselves, in the test environment.
- Give them the full set of walkthroughs and the checklist.
- Agree how they escalate issues during go-live: a named contact and one chat group, not a ticket portal.
The champion doesn't need to be a good trainer. With task walkthroughs they only need to send a link, watch someone do the task, and know who to call.
Phase 4: Before go-live
Two to three days out, champions send each crew member their role's walkthroughs, in the channel the crew already uses (usually a chat group, see sharing training on WhatsApp), with the one-line why and the go-live date.
Don't expect everyone to go through them. The point is that the material is already on their phone when they need it.
Phase 5: Go-live week
This is where training actually happens:
- Short briefing per shift (10 minutes): the why, then the champion taps through one walkthrough on a phone in front of the crew.
- Observed first run: each person does each of their tasks once in the live system while the champion watches. Tick it off on the checklist.
- Keep paper as a fallback, but timeboxed. Set an end date for the old process, or nobody switches.
Expect the same few problems at every site: logins, permissions, phones that can't scan, a step everyone misreads. Log them in one place and fix the material the same day.
Phase 6: The first 30 days
Track these per site, weekly:
- Adoption: share of work done in the system vs. the old process.
- Quality: submissions rejected or sent back, and why.
- Support load: questions per site per week. Should fall steadily.
- Training reach: whether each role has opened their walkthroughs, if your tool reports it.
A site that lags on adoption usually has one specific problem: a missing champion, a step nobody understands, a supervisor still accepting paper. Fix that problem, re-send the relevant walkthrough, and check again next week.
New joiners after go-live
Six months later, most of your users will be people who weren't there for go-live. Make the role walkthroughs part of every new joiner's first day, sent by their supervisor. This is where task-based phone walkthroughs pay off most: they keep working with nobody from the project team around.
Related: how to train field workers on a new app, customer onboarding process, and the field teams walkthrough page.
If you’re the vendor running this for customers, see train-the-trainer for software vendors and the customer go-live checklist.
Frequently asked questions
What should a software rollout training plan include?
The roles that will use the software and the tasks each role performs, the training material for each task, who trains whom (usually vendor to site champions, champions to crews), a schedule tied to go-live, what support looks like for the first 30 days, and the adoption numbers that tell you training worked.
What is train-the-trainer in a software rollout?
A model where the vendor or central team trains a small group of champions at each site, typically supervisors, and gives them the material to train their own crews. It scales training across sites and shifts without the vendor being present for every session, and leaves someone on site who can answer questions after go-live.
How long before go-live should training start?
Train site champions one to two weeks before go-live, so they've used the software themselves. Send end users their role-specific material a few days before go-live, then train them hands-on during go-live week, at the point they first do each task for real. Training much earlier than that is mostly forgotten.
How do you measure whether rollout training worked?
Measure adoption in the software itself rather than training attendance: the share of work done in the new system instead of the old process, error and rework rates on submissions, and support requests per site. Compare sites to find where training needs to be repeated.