How to introduce a staff app without creating another job

Choose a problem staff recognise

Start with something concrete: people cannot find the current procedure, a delivery issue is lost between shifts or the team writes the same completion note twice. Avoid introducing an app as an abstract instruction to be more organised.

A restaurant manager described being excluded from existing group texts because of their phone setup. That example shows why access is part of the workflow, not a minor setup detail. If the intended user cannot reach the information during work, the system has failed before training starts.

Show what changes for one person

Walk through one job from beginning to end using the actual shop device. Explain where the person starts, what they enter and what happens next. Compare that with the current process and identify the step that will stop.

Ask the people doing the task where the new process is awkward. HSE's worker-involvement guidance concerns safety consultation; it is a useful reference when a change affects safety procedures. The small software pilot proposed here is an operational suggestion, not a prescribed consultation method.

Further reading: HSE: consulting and involving workers

Test access before judging adoption

Check login, screen size, Wi-Fi coverage and whether the device is available when the task occurs. If using a shared device, explain how the business expects people to identify the person completing work. Follow your privacy and access arrangements rather than sharing a manager's personal account.

Do not assume everybody should use their own phone. Agree a workable option with the team and confirm that training and use fit the working day. An instruction hidden in a personal notification at home is a poor substitute for a shift briefing.

• Can a first-time user find the task?
• Is the shared device charged and in reach?
• Can staff recover from an ordinary mistake?
• What happens if the connection fails?
• Which existing record is being replaced?

Run one complete cycle

Original example: a small shop pilots a digital closing task for one week. Staff complete the task on the counter tablet; the supervisor checks the result and follows up exceptions. The pilot includes both a quiet evening and a busier one.

Measure the friction you can observe: duplicate entries, failed logins, unanswered questions and work that disappears between shifts. Do not declare success because accounts were created. Ask a less confident user to demonstrate the workflow without coaching.

One-workflow pilot
Problem to solve:
Task and users:
Old step being replaced:
Access or device needed:
Fallback during an outage:
Questions raised during use:
Change before wider rollout:

Retire duplication and expand carefully

Once the workflow is reliable and appropriate records are preserved, stop requiring the same information in two places. Explain which record is now authoritative. Keeping paper, chat and app versions indefinitely encourages people to choose whichever is easiest and leaves conflicting histories.

Add the next workflow only when the first one works for the people doing it. If it does not, change the setup or stop the pilot. Useful adoption comes from a clearer working day, not from asking employees to demonstrate enthusiasm for software.