Customer Go-Live Checklist for Field and Industrial Software Vendors
A go-live checklist for teams that sell apps used by technicians, site crews and plant staff: what must be true before go-live, on go-live day, and in the first 30 days, so the rollout sticks and the customer renews.
A field software go-live succeeds or fails on unglamorous details: accounts that work on day one, phones that can scan on site, champions who know every task, short training on every worker's phone, and an end date for the paper process. Use this checklist with each customer. Most items are quick; skipping them is what turns a launch into three weeks of support tickets.
It's written for vendor teams (implementation, customer success, onboarding) selling apps for maintenance, safety and permits, inspections, field service or site operations.
Two weeks before go-live
System
- Every user account created, with the right role and site
- Permissions tested by logging in as each role and doing one real task
- Master data loaded and checked: assets, locations, checklists, permit types
- Integrations tested end to end (ERP, HR, SSO) with real records
- Production and test environments match (screens, fields, workflows)
Devices and site
- The app installed and signed in on the actual phones or tablets crews will use
- Connectivity checked where the work happens (plant rooms, basements, remote sites), with offline behavior tested
- Camera and QR/NFC scanning tested in real lighting, on real tags
- Shared-device rules agreed (who logs out, how passwords get reset on night shift)
People
- Champions named per site and per shift (see train-the-trainer for software vendors)
- Champions have completed every task for every role in the test environment
- One short walkthrough per role and task, built from the real screens and ready to send to phones
- One-page champion checklist: each person completes each task once, observed
- Training language agreed per crew (see training field workers in other languages)
The week of go-live
- Role walkthroughs sent to every crew's chat group by their own supervisor, 2–3 days before (templates: sharing training on WhatsApp)
- Short briefing per shift on day one: why the change helps them, then one walkthrough on a phone in front of the crew
- Every person completes each of their tasks once in the live app, watched by a champion
- One support channel and a named contact, with response time agreed
- Issue log started: every problem, which site, which role, status
- End date for the old process announced (paper, spreadsheets, WhatsApp photos)
Re-send the specific walkthrough at the moment someone first does the task: "Closing your first job today? Here's the 2-minute version." It does more than any session held the week before.
The first 30 days
Weekly, per site:
- Usage share: work done in the app ÷ all work done
- Rework: submissions sent back, and why
- Coverage: share of each role that has completed each task
- Support questions per site (should fall every week)
Act on it:
- Lowest site gets a call or visit; find the specific blocker (why frontline workers don't use the new app lists the usual five)
- Walkthroughs updated wherever a step is often done wrong
- Old process actually switched off on the agreed date
- New joiners get the role walkthroughs on day one, as part of the customer's onboarding
At day 30: hand-over
- Per-site adoption summary shared with the customer's sponsor
- Champions confirmed as the long-term first line of support
- Training material location and owner agreed; the customer knows how to request updates when the app changes
- Renewal and expansion owner knows which sites are healthy and which need help
The three items teams skip most
- Testing on the real devices, on site. Everything works on the office Wi-Fi.
- An end date for the old way. Without it, adoption plateaus at 60%.
- Material that outlives the visit. If nothing is on people's phones, training is gone in two weeks, and new joiners never get it.
For the customer-side plan, see the software rollout training plan. To see what role-based walkthroughs look like on a phone, open the field teams page.
Frequently asked questions
What should a software go-live checklist include?
Readiness of the system (accounts, permissions, devices, data), readiness of people (champions trained, role-based material on phones, crews briefed), the go-live plan itself (support channel, who to call, end date for the old process), and how adoption will be measured in the first 30 days.
When should end users be trained before go-live?
As close to go-live as possible: a few days before, with short role-specific material on their phones, then hands-on during go-live week when they do each task for real. Training weeks before go-live is mostly forgotten by the first real job.
What are the most common reasons field software go-lives fail?
Accounts and permissions not ready on day one, phones or connectivity on site not tested, training that wasn't role-specific or came too early, no champion at a site, and the old paper process still being accepted after go-live.
How do you measure whether a go-live was successful?
Track per site, weekly for the first 30 days: the share of work done in the new app versus the old process, rework rates on submissions, the share of people in each role who have completed each task, and support questions per site. Success is high usage and falling support volume, not a smooth launch day.