Getting Staff Involved Before You Replace Their Daily Tools

Staff who use a system every day know where work pauses, where information is missing, and which informal steps keep customers served. Replacing their tools without that knowledge risks building a cleaner-looking process that fails under ordinary pressure. Involve them early to understand the work and to prepare a transition they can actually use.

Observe the work before asking for features

Ask people in different roles to walk through a recent normal task and one difficult case. Watch where they consult another file, call a colleague, or rewrite information. Ask why that step exists before removing it. A workaround may be needless duplication, but it may also be an informal check that protects an important customer promise. Include staff who handle exceptions, not only managers who view reports.

The GOV.UK user research guidance recommends turning assumptions into research questions and involving users throughout development. A small business can use brief observation and discussion rather than a large formal study. The key is to learn what people actually do before deciding how the new software should behave.

Give staff a real role in testing

Show a limited version of the new workflow and ask staff to complete realistic tasks without the developer directing every click. Include incomplete information, a changed customer request, and a handoff between roles. Record where they hesitate and what they expect the system to do. The GOV.UK guidance on moderated usability testing supports observing people perform believable tasks rather than relying only on opinions about a demonstration.

Do not promise to build every requested feature. Explain the business goal and how feedback will be judged. Staff may disagree because their roles face different consequences. A sales shortcut may create missing information for operations; a manager's reporting field may slow frontline work. Bring the affected roles together to decide a shared rule and document why it was chosen.

Prepare the change in daily work

Decide when the old tool becomes read-only, who answers questions in the first weeks, and how staff report incorrect records. Give concise training based on real tasks. Identify a few people who can help colleagues, but do not make them responsible for technical failures they cannot fix. Keep a fallback for essential work during the changeover and a process for entering temporary records later.

Make time for staff to try the system before the first busy day. A demonstration is not the same as entering a real order or correcting a mistake under time pressure. Let people practice with sample records, ask questions, and explain which instructions are unclear. A short improvement made before launch may prevent repeated interruption afterward. Managers should also model the new process rather than requesting reports from the old spreadsheet indefinitely.

Tell staff what is changing and what is still undecided. If a familiar shortcut is removed, explain the customer or business reason and the replacement step. If feedback will be reviewed later, set a date and an owner. People are more likely to report useful problems when they can see how a decision was made, even when their particular request is deferred.

Measure adoption through useful work completed, not just logins. Are staff finishing tasks in the new system, or quietly keeping a spreadsheet beside it? Ask why. Repeated workarounds may reveal missing information, unclear responsibilities, or a feature that is too hard to use. Treat those findings as evidence for targeted improvement rather than resistance to change.

Holism can help an owner translate staff knowledge into priorities while a developer uses AI and a reusable foundation to build and revise the tool. The owner decides the operating rules and explains the change; the developer remains accountable for the system's behavior. Involving staff early makes it more likely that the replacement supports the work customers depend on.