How to train your staff on new software so they actually use it

Staff use new software when training is built around their actual jobs, happens right before they need it, and is followed by real help on the floor in the first weeks. Feature tours and one long session a month before launch don't work. People forget, go back to the old way, and the new system becomes the thing you pay for and nobody uses.

Our founder has worked as an Epic credentialed trainer and EMR consultant at U.S. hospitals since 2010. Hospital go-lives are about as high-pressure as software rollouts get, and the lessons below scale down to a ten-person business just fine.

Train on tasks, not features

Nobody needs a tour of every menu. A receptionist needs to book, reschedule and check in a customer. A technician needs to see today's jobs and close one out. A bookkeeper needs to send an invoice and record a payment.

1. List each role in your business.
2. For each role, list the five to ten tasks they do most often.
3. Build the training around those tasks, in the order they happen during a normal day.
4. Use realistic examples: your services, your kind of customers, your prices.

If a feature doesn't show up in anyone's task list, leave it out of training. People can learn it later when they need it.

Pick super-users early

Pick one or two people who learn the system before everyone else and go deeper. They shouldn't be chosen because they're the youngest or the "computer person"; pick people others already go to with questions, and who are patient about it.

Give them:

• Access to the system weeks before everyone else.
• Time in their schedule to learn it, not "when it's quiet."
• A direct line to whoever set up the system or to the vendor's support.
• Permission to say "I don't know, let me find out."

Super-users answer the small questions that would otherwise go unasked, and they hear the complaints you won't.

One tip sheet per task, one page each

A tip sheet is a single page that shows how to do one task: the goal, numbered steps, screenshots where they help, and the one or two mistakes people usually make. One task per page, so people can find it in five seconds.

• Title it with the task, in plain words: "Reschedule an appointment," not "Calendar module."
• Keep it to one page. If it needs two, it's two tasks.
• Store them where people already look: printed at the desk, pinned in your team chat, or in a shared folder.
• Update them when the screens change. An outdated tip sheet is worse than none.

Short sessions, close to go-live

Train in short sessions, with people doing the tasks themselves rather than watching. Schedule them as close to go-live as you realistically can, so the gap between learning and using is days, not weeks.

There's research behind this. A 2013 review of learning techniques by Dunlosky and colleagues, published by the Association for Psychological Science, gave practice testing and spreading practice out over time its highest utility rating, while rereading and highlighting rated low. For software, that means: have people actually do the task, then do it again a few days later, rather than reading the manual.

Give them a safe place to practice

People learn faster when they aren't afraid of breaking something. Many systems offer a test or sandbox environment, or a demo account. If yours doesn't, set up test records clearly marked as fake ("TEST Customer") and delete them before go-live.

Write practice exercises that mirror a real day: "A customer calls to move Thursday's appointment to next week and add a second service. Do it." Then check the result together.

At-the-elbow support in the first weeks

This is the part hospital go-lives get right and most small rollouts skip. For the first days after launch, someone who knows the system should be physically (or at least instantly) available while people work, not in a meeting, not "email me if you have issues."

• Plan the go-live for a lighter week if you can.
• Schedule extra time for common tasks at first. Everything takes longer for a while.
• Have super-users on hand and visible.
• Keep a running list of every question and problem. It becomes your next round of tip sheets and fixes.

Scale the support down as the questions slow down, not on a fixed date.

Measure whether they're actually using it

Training attendance tells you nothing. Use what the system records:

• Are people logging in?
• Are jobs, bookings and invoices being created in the new system?
• Is anyone still keeping a paper list or the old spreadsheet "just in case"?

Workarounds aren't defiance. They're a sign the system, the setup or the training doesn't fit how the work really happens. Find out why.

Close the loop on feedback

Give people one easy place to report problems and suggest changes, and then visibly act on it. Fix a confusing setting, add a missing tip sheet, adjust a workflow. When staff see their feedback change things, they keep giving it. When it disappears, they go quiet and go back to the old way.

Before you train, make sure the data is right

Training fails fast when people open the new system and their customers are missing or wrong. If you're moving from an old tool, see how to switch software without losing data, and if you're also adding automation, our guide to automating quotes and bookings.

Good training is boring and specific: real tasks, one page at a time, and help right there when people need it. If you'd rather have it done for you, write to [email protected] or see our systems and training service.

Sources

• Which Study Strategies Make the Grade? (Association for Psychological Science)