Onboarding Field Staff to New Software: A 2-Week Plan

Onboarding field staff to new software works when you teach four tasks, not a system. Give each engineer one 20-minute session on their own phone, on a real job, covering only: open today's work, log time, add a photo or note, and mark the job done. Run paper and app in parallel for two weeks. Switch paper off on day 11 once every person has completed those four tasks unaided on three separate jobs. Measure adoption in week three, not week one. The rollout is the project. The software is just the tool you happen to be rolling out.

Why onboarding field staff to new software fails, and the software doesn't

Most systems bought by small trades firms are perfectly capable. They fail because a busy owner buys on a Friday, emails a login link on a Monday, and expects six people who have used paper job sheets for eleven years to work it out between jobs. Nobody has ten minutes. Nobody asks for help in front of the group. Within a fortnight the office is re-typing paper sheets into the system and everyone agrees the software is rubbish.

Two rules underpin everything below. Teach tasks, not features: an engineer does not need to know what the system can do, only what they do on a Tuesday at a customer's door. And never run two systems for more than two weeks, because past a fortnight parallel running becomes permanent.

Week 0: what you do before anyone sees the app

Every hour here saves three later. Do this yourself, before you mention the system to the team.

• Load real data. Your actual customers, price list and job types. If the first job an engineer opens is called "Test Customer 1", you have taught them the system is a toy.
• Run five real jobs through it yourself. Book, schedule, do, log, invoice. You will find three things that annoy you. Fix them now: those same three will be why your team quits the app.
• Switch off every feature you are not using on day one. A field app with four buttons gets used. One with fourteen gets closed.
• Sort logins and phones in advance. Nobody should spend their session resetting a password. Old handsets, no storage, mobile data off to save money: fix the hardware before you blame the person.
• Decide your kill criteria now, before you are emotionally invested.

The four things an engineer must be able to do before you switch off paper

This is the whole curriculum. Everything else can wait months.

Notice what is not on that list: quotes, scheduling, inspection forms, service agreements, reporting. Those are office tasks or month-two tasks. Teach an engineer eleven things and they remember none. Teach four, and the fifth becomes easy because they now trust the thing in their pocket. The bar is behavioural: not "they watched a video", not "they said they got it", but four tasks unaided on three separate real jobs. That is the gate.

The 20-minute first session

One person at a time. Never a group, never a classroom. Do it in the van, on their phone, on a real job they are about to do, and let them hold the phone throughout. If you hold the phone, they learn nothing and you have performed a demo. The script, roughly to the minute:

• 0–2 min. Say the honest thing. "This is so you stop writing the same job twice and stop getting rung at half seven at night. It is not to check up on you." If a geofenced time clock is part of it, say so now, plainly, and say what it is and is not used for. If they hear it later from a colleague, you have lost the rollout.
• 2–5 min. They open the app and read today's job. You say nothing. Let the silence run. Where they hesitate is your real training need.
• 5–12 min. They do the job. Clock on, log materials, photos, note. You stand there and only answer questions.
• 12–16 min. They close the job. Then show the one thing that pays them back: the office can invoice this today, so nobody rings them tonight.
• 16–20 min. Two answers. "What happens if I have no signal?" and "What if I get it wrong?" Answer both concretely. Then: "Ring me, not the office, for the next two weeks." Mean it.

Six engineers is two hours of your week. That is the entire training budget, and it beats a full-day group session everyone forgets by Thursday.

Days 1 to 14: the parallel run

Keep the paper. Genuinely keep it. Telling nervous people their safety net is gone on day one guarantees resistance.

• Days 1–3. App and paper, both. You do the 20-minute sessions. Nobody is corrected on anything except the four tasks.
• Days 4–5. First look at the data. You will find someone photographing the paper sheet instead of filling in the app, and someone logging eight hours in one lump at 17:00. Both are training gaps, not attitude. Fix them in a two-minute call, one to one.
• Day 5, Friday, 15 minutes. Ask one question: "What is annoying about it?" Fix the top two before Monday, and say you fixed them because they asked. This converts more sceptics than any training.
• Days 6–10. Track it: every person, four tasks unaided, three real jobs. Most get there by day eight.
• Day 11. Paper stops. Announce it on day 8, not day 11. Collect the pads. If someone brings a job sheet in on day 12, hand it back unread and offer ten minutes in the van. Kind, and completely immovable.
• Days 12–14. The fifth feature. Now, and only now, add digital inspection forms, additional-work capture, whatever your trade needs. They trust the app; they will accept one more button.

The rule that makes day 11 stick: the office must not accept work in the old format. If one person in the office keeps re-typing paper sheets "just to help Dave", Dave will still be on paper at Christmas, and so will two others. The rollout dies in the office, not the van.

How to handle the one person who refuses

You have one. Usually your best engineer, usually the longest-serving, usually the one everyone else listens to. Work out which refusal it is.

• Fear, dressed as contempt. "This is a waste of time" almost always means "I will look stupid in front of the apprentice." The most common one by a distance. Fix it privately: thirty minutes alone with you, nobody watching them tap a screen, and they usually come out fine.
• Surveillance, and they are not wrong to ask. Answer straight, no marketing. Say what is recorded, who sees it, what it is used for. Then behave that way for six months. Say the time clock is not for monitoring and then mention someone's arrival time in a meeting, and you have proved the sceptic right permanently.
• Actual friction. Sometimes the refuser is your best tester. "I have to tap seven times to log a cable" is a real fault. Fix it, then tell them you fixed it because of them. You have just converted your loudest voice into your advocate.
• A genuine barrier. Reading difficulty, poor eyesight, second language, a phone from 2018. All fixable, none of them attitude. Voice notes and a language switch solve more of these than people expect.

If it is none of those and simply refusal, it stops being a software conversation on day 11 and becomes a work-instruction one: this is how the job is recorded here now, and the office cannot invoice without it. Have it calmly, one to one, once. Firms that let one person stay on paper always end up with three, and then the whole thing collapses back.

What to measure in week three

Week one measures novelty. Week two measures your training. Week three is the first honest signal: the push is over and people have settled into whatever they will actually do forever. Five numbers, all already in the system.

• Jobs closed in the app, as a percentage of all jobs. Under 90% by week three and you have a person or a process problem. Find which. Do not retrain everyone because one person is stuck.
• Time between job finished and job closed. The honest adoption metric. Closed on site means adopted. Closed at 21:00 in a batch of six means they are still on paper and typing it up later, which is worse than before you started.
• Photos or notes per job. Evidence attached at the point of work is what wins the disputed invoice three months from now.
• Days from job done to invoice sent. The number the whole exercise exists for. If it has not moved, your bottleneck was never the engineers. It was the office, and you have automated the wrong half of the business.
• Calls to the office asking "where am I going?" Count them for one day and compare with the day you counted in week zero. You did count in week zero, didn't you.

Review these once, for twenty minutes. Then leave the team alone. Weekly adoption dashboards for a six-person firm are theatre.

Where the tool actually helps

Software cannot fix a rollout, but the wrong software guarantees it fails. Three things matter for the people in vans: it works with no signal and queues the work until there is some, closing a job is four taps not fourteen, and the office runs the same system so nothing is re-typed. OdinTask is built that way on purpose. Whatever you pick, test those three in week 0 with your own five jobs before you put it in anyone's hands.

The whole method, short

Two hours of one-to-one training. One honest conversation about monitoring. One hard date for paper, defended by the office. Five numbers in week three. That is why the firm down the road with the same software got a completely different result.

Want to try the plan on a system built for it? Start a 14-day free trial — conveniently, exactly the length of the rollout above.