Preparing staff for a new system: training, super users, and go-live support

Reference article · 5 min read

Most of the risk in a new agency system sits with people rather than software. Data can reconcile and interfaces can pass their tests, and the rollout still goes badly on the first Monday when a clerk who has done the same task for years cannot find the screen that replaced it.

Staff readiness is the part of a project easiest to postpone and hardest to recover once the date passes. Treat it as its own workstream with named owners and deliverables: super users, a map of how each role's day changes, training, reference material, and extra help at launch.

Name super users early and protect their time

A super user is the person other staff in a department already ask when something is confusing. That is standing, not job title, and supervisors usually know who it is.

• Cover every unit, location, and shift. One super user for an office with a counter, a phone queue, and a night shift is short in at least two places. Name backups.
• Get release time in writing. The work competes with a full caseload. Ask the department head to agree to specific hours, and say what will not get done during them.
• Bring them in during configuration. Those who sat through configuration and acceptance testing can explain why the system works the way it does.
• Keep the role after go-live. They become the first line of support, and the people who train new hires once the vendor leaves.

Map how the work changes, not what the software does

A vendor demonstration walks through features. Staff need to see their own day. Before training is designed, map each role: the tasks they perform, the steps each takes today, the steps it takes in the new system, what disappears, and what is new.

That map becomes the outline for training and reference material. It shows where the new system is more work for one group, often because it is less work for another downstream; say so plainly rather than letting people find out at go-live. It also flags the informal workarounds a department has built over the years, a shared spreadsheet, a paper log, an email folder, each needing a decision before cutover.

Sequence training close enough to go-live to stick

Training delivered months early is forgotten. Training delivered in the final days leaves no room to fix what it reveals. Separate three things:

1. An awareness briefing, earlier. Short, with no hands on a keyboard: what is changing, when, why, and who to ask.
2. Role-based hands-on training, close to cutover. In the weeks before go-live, in a training environment loaded with converted data that resembles real records.
3. Open practice and refreshers, in the final days. A lab with super users present, plus a sandbox that stays available after go-live.

Check each department's calendar and avoid peaks such as a filing deadline, an enrollment window, or a budget close. Track attendance, and plan make-up sessions for staff on leave and for people hired between training and go-live.

Write reference material for counter and phone staff

Manuals do not get read at a counter with someone waiting. What gets used is one page per task, in the agency's own vocabulary, with screenshots of its own screens. Include a few sentences staff can use to explain a longer wait to the public.

• One task per page. Numbered steps, exact screen names, and the points where staff have a choice.
• Written or reviewed by super users. Vendor documentation describes the product. Local documentation describes the job.
• A known-issues page. When this happens, do this. Include accepted workarounds and remove them as they are fixed.
• An owner and a change log. Material with no owner goes stale and staff stop trusting it.

Publish it on the intranet and keep printed copies at the counter.

Staff the launch more heavily than a normal day

The first days generate questions faster than a normal help desk queue absorbs them.

• Free super users from normal duties and have them roving, not at their own desks.
• Use one intake channel for issues, triaged daily, with a visible log so staff see their reports going somewhere.
• Hold a short daily check-in with department leads during the first week, then taper it.
• If policy allows, reduce scheduled workload for the first days and tell the public what to expect through signage and a website notice.
• Cover every shift where operations run around the clock.

Watch for the quiet failure mode: staff who go back to paper or keep the old process alive in a spreadsheet. That signals a gap, not a discipline problem. Find the task that is not working and decide whether to fix it, retrain, or accept it.

What to ask vendors and put in the contract

• Who delivers the training. Whether trainers come from the implementation team or a separate group, and how they learn your configuration.
• Train-the-trainer terms. Deep training for super users, plus the right for agency staff to deliver it afterward.
• Materials in editable form. Source files the agency can modify and reuse at no added cost, and recordings that meet the accessibility standards your agency follows.
• A training environment. Available before training begins, refreshable with converted data, and kept after go-live.
• A defined support period. Duration, hours, onsite or remote coverage, named staff, and response times, in the contract rather than a slide.
• Payment tied to its end. Hold back a portion until the support period closes, not at cutover.

Allowable terms vary by jurisdiction and funding source. Confirm specifics with your purchasing office and counsel.

HQT is a technology and software company serving United States state and local government agencies, including implementation and rollout support.

Frequently asked questions