You've got 40 locations and every one of them needs the same thing: new access points, a router swap, POS terminals, digital signage, whatever this quarter's project is. The work at each site is a few hours. The hard part is that it has to happen 40 times, in 40 buildings, in a dozen states, and every site done wrong is a return trip that eats the budget. Multi-site rollouts are a logistics problem wearing an IT costume, and staffing them is where they succeed or fail.
Traveling crew or local techs
There are two ways to staff a rollout, and the right one depends on the shape of the job.
One traveling crew means the same two or three techs do every site. You get consistency for free: by site five they've seen every variation, they install the same way every time, and quality drifts upward as they learn. The costs are travel (flights, hotels, per diem stack up fast) and time. A crew doing one site a day finishes 40 sites in two months of calendar time, and if a site visit slips, everything behind it slips too.
Local techs per city means dispatching a vetted tech near each site. Travel cost drops to a truck roll. You can run ten sites in parallel and finish the whole rollout in a week or two. The trade is consistency: 40 sites might mean 25 different techs, each doing the job once, and the first time someone does anything is when mistakes happen. Without tight process, you get 40 slightly different installs and a support mess that lasts for years.
Our rough rule: dense clusters of sites, complex work, or anything requiring deep product knowledge favors a traveling crew. Wide geography, simple repeatable work, and tight deadlines favor local techs. Big rollouts often mix both, a traveling lead plus local hands, especially for the first few sites while the process gets debugged.
The runbook is the real product
With local techs, the runbook does the job the traveling crew's experience would have done. Before any tech walks into site one, there should be a document that assumes nothing:
- Photos of what the finished install looks like, from the actual pilot site.
- Exact steps in order, including the boring ones: where to find the demarc, which port on the switch, what the label should say.
- What "working" means and how to prove it: which lights, which test page, which speed test result.
- Who to call when something on site doesn't match the document, because something won't.
Always pilot before you scale. Run sites one and two with your best people, find everything the runbook got wrong, fix the document, then release the fleet. Every rollout we've seen skip the pilot paid for it with rework across every site that followed.
Scheduling is half the job
Coordinating 40 site visits means 40 site contacts, 40 access windows, and 40 chances for someone to not show up. The things that keep it from unraveling: confirm every appointment with the site contact 24 to 48 hours ahead, ship equipment to arrive before the tech does and confirm receipt, batch sites geographically so a delayed morning doesn't kill an afternoon two hours away, and keep a couple of float days in the schedule because sites will reschedule on you. Ship spare units to a central point too. One dead-on-arrival router shouldn't cost you a second truck roll.
Photo verification and QC
If you can't stand in the room, photos are how you inspect the work. Make photo capture a required checklist step, not a favor: the rack or mount before work starts, cable runs and labels, the finished install from the same angles as the runbook photos, and the test screen proving the thing works. The tech doesn't get sign-off (and shouldn't get paid the site) until the photos are in.
Then someone technical actually reviews them, same day. This is the QC loop, and it's where remote rollouts earn their quality. A reviewer who knows the work will spot the unlabeled cable, the AP mounted behind a beam, the switch uplinked to the wrong port, while the tech is still in the parking lot and can go fix it. Catching that a week later means another dispatch. We also do a remote functional check on every site: can we reach the device, does it pull the right config, does monitoring see it. Photos prove it looks right, the remote check proves it works.
What done right looks like
A rollout that was staffed and run properly leaves evidence: every site has a photo record and a passing verification, the install at site 38 matches site 3, support tickets in the month after go-live are near zero, and nobody had to fly back anywhere. The failure signature is just as recognizable: a spreadsheet with a "revisit" column, sites that were "done" but don't check in to monitoring, and a support queue that can't tell which sites got which version of the install. The difference between the two isn't the techs. It's the runbook, the pilot, and someone checking the photos while there's still time to fix things. We staff and run these nationwide, one traveling crew or fifty local techs, and the process is the part we never skip.
Stuck on this, or want it done for you? That's the job.
Email us →