Safety software implementation is only the beginning: How to achieve lasting employee adoption

Introducing safety management software can improve visibility, simplify reporting and help organisations respond to risks more effectively. However, purchasing and configuring a system does not automatically mean people will use it consistently.

A technically successful implementation can still fall short if employees do not understand the system, see it as additional administration or continue relying on familiar spreadsheets, emails and paper forms.

This is why employee adoption should be treated as a core part of implementation—not as something to address after the software goes live.

The objective is not simply to teach employees which buttons to press. It is to build confidence, demonstrate value and make the new system part of how safety work is completed every day.

Why safety software adoption can be difficult

Resistance to new technology is not necessarily resistance to safety.

Employees may be concerned that the system will make their jobs more complicated, increase scrutiny or create more administrative work. Others may lack confidence using digital tools or feel that the system was designed without considering how work is actually performed in the field.

Common barriers include:

• Limited consultation before implementation

• Workflows that do not reflect real workplace processes

• Too many fields or unnecessary approval steps

• Inadequate or overly generic training

• Poor communication about why the change is happening

• Limited access to devices or reliable connectivity

• A lack of visible action following employee reports

• Managers continuing to accept information through old channels

• Insufficient support after the initial rollout

These issues are often described as user resistance, but they may actually indicate a problem with the rollout, configuration or communication strategy.

Before concluding that employees simply “do not want to use the system”, organisations should examine whether the system is practical, accessible and clearly valuable to the people expected to use it.

Start with the work—not the software

A safety system should support the way work is performed while improving control, accountability and visibility.

Before configuring forms and workflows, speak with the people who will use them. This may include frontline workers, supervisors, contractors, health and safety representatives, administrators and senior leaders.

Ask questions such as:

• How are hazards and incidents currently reported?

• What makes the existing process frustrating or time-consuming?

• Where are delays most likely to occur?

• What information is genuinely needed?

• Which steps are duplicated?

• When and where will employees access the system?

• What could prevent someone from submitting a report?

• How should employees be kept informed after raising an issue?

This consultation helps the project team understand the difference between a process as it appears in a procedure and how it operates in practice.

It also gives employees an opportunity to influence the system they will be asked to use. People are generally more receptive to change when they can see that their experience has been considered.

Clearly explain what is changing—and why

Employees should not first hear about a new safety system when they receive a login email.

Communication should begin before launch and explain:

• Why the organisation is introducing the system

• Which problems it is intended to solve

• What will change for each group of users

• What will remain the same

• When the change will occur

• Where employees can find help

• How feedback will be collected and addressed

Avoid focusing the message entirely on organisational benefits such as improved reporting, governance or audit readiness. These outcomes are important, but employees also need to understand what the change means for them.

For example, the new process may allow employees to report a hazard at the time it is observed, attach a photograph from the field, avoid entering the same information multiple times or receive better visibility over what happened after the report was submitted.

The benefits should be specific, practical and relevant to the employee’s role.

Make reporting as straightforward as possible

A safety process may be comprehensive without being complicated.

When an employee notices a hazard or near miss, the initial reporting step should be clear and proportionate. Requiring too much information at the beginning can discourage reporting or lead people to postpone it until details are forgotten.

Review every field and ask:

• Is this information necessary at this stage?

• Is it relevant to the person completing the form?

• Could it be added later by a supervisor or investigator?

• Can the system automatically populate it?

• Is the wording easy to understand?

• Does the user need to see every available option?

Role-based forms and workflows can help ensure employees only encounter the information and actions relevant to them.

A frontline worker may need a short and accessible reporting form, while a safety professional may require additional investigation, classification and corrective-action fields. Presenting both users with the same complex screen can create unnecessary friction.

The aim is not to remove important information. It is to collect the right information from the right person at the right point in the process.

Test the system with real users before launch

A small pilot can reveal issues that may not be visible to the project team.

Select a representative group of users from different roles, locations, shifts and levels of digital confidence. Ask them to complete realistic activities, such as:

• Reporting a hazard

• Recording a near miss

• Completing an inspection

• Assigning a corrective action

• Uploading supporting evidence

• Reviewing an outstanding task

• Using the system from a mobile device

• Completing a task in an area with limited connectivity

Observe where users hesitate, misinterpret instructions or take unexpected steps. These are useful findings—not user failures.

Pilot feedback may identify unclear terminology, unnecessary questions, missing options or workflows that do not reflect operational reality. Resolving these issues before a wider rollout can significantly improve the first experience for the rest of the workforce.

Provide training by role

One large training session for every employee is unlikely to meet everyone’s needs.

A worker who only needs to report hazards does not require the same training as a system administrator, investigator or senior manager. Too much irrelevant information can make the system appear more complicated than it is.

Training should be based on the tasks each role is expected to complete.

For example:

Frontline employees may need to know how to submit a report, add a photograph, find a saved record and check whether an issue has been addressed.

Supervisors may need to review reports, assign actions, manage notifications and escalate overdue items.

Safety professionals may need deeper training in investigations, risk assessments, reporting, workflow management and data quality.

Senior leaders may need to understand dashboards, trends, responsibilities and how system data should inform decisions.

Training is most effective when people practise real activities in an environment that reflects their work. Short demonstrations, task-based guides, videos and refresher sessions can be more useful than a single presentation covering every function.

Build a network of local champions

Employees will often ask a colleague for help before contacting a central support team.

Local champions can provide immediate, familiar assistance during the transition. They may be supervisors, health and safety representatives, administrators or employees who are comfortable with the system and understand local processes.

Champions can:

• Answer common questions

• Demonstrate tasks during toolbox meetings

• Identify recurring points of confusion

• Encourage use of the agreed process

• Escalate configuration or training issues

• Share examples of how the system is improving safety work

Champions should not become a substitute for proper training or support. Their role is to reinforce the change locally and help the implementation team understand what is happening across different parts of the organisation.

Ensure leaders use and support the system

Employees will quickly notice when leaders promote a new system but continue accepting reports through email, paper or informal conversations.

During the transition, managers may need to redirect information into the agreed process. This does not mean refusing to listen to an employee who raises a concern. It means ensuring the concern is recorded, assigned and managed through the system so it does not disappear.

Leaders can reinforce adoption by:

• Referring to system data during meetings

• Reviewing overdue actions

• Recognising useful reports and observations

• Asking what has been learned from recent events

• Following up on recurring hazards

• Using dashboards to guide priorities

• Holding action owners accountable

• Demonstrating that employee reports lead to decisions

Consistent leadership behaviour shows that the system is not a temporary project or an optional administrative tool. It is part of how the organisation manages safety.

Close the loop with employees

One of the fastest ways to weaken reporting is to make employees feel that nothing happens after they submit information.

Even when a reported issue cannot be resolved immediately, employees should receive appropriate acknowledgement and updates. Depending on the organisation and the nature of the report, this may include:

• Confirmation that the report was received

• Notification that an action has been assigned

• An explanation of any immediate controls

• Progress updates

• Confirmation that the matter has been closed

• A summary of what changed as a result

Closing the loop demonstrates that reporting has value.

Organisations can also share broader outcomes through toolbox meetings, safety communications or dashboards. For example:

• “Reports from the loading area led to revised traffic controls.”

• “Inspection findings identified a recurring equipment issue that has now been addressed.”

• “Employee feedback helped simplify the mobile hazard form.”

• “Near-miss reports resulted in additional verification of a critical control.”

When employees see that their contribution leads to action, continued participation becomes more likely.

Plan for the period after go-live

Go-live is a milestone, not the end of the implementation.

The first weeks and months provide important information about how the system performs under real operating conditions. Organisations should actively review adoption rather than waiting for complaints or low reporting numbers to reveal a problem.

Useful indicators may include:

• Number of active users

• Reporting levels across locations or teams

• Time taken to submit common forms

• Incomplete or abandoned records

• Overdue actions

• Repeated help requests

• Use of mobile and desktop channels

• Participation in inspections or verification activities

• Differences in adoption between business units

• Employee feedback about usability

These measures need to be interpreted carefully. An increase in hazard or near-miss reporting after implementation may reflect improved engagement and visibility—not worsening safety performance.

Similarly, a low number of support requests does not always indicate a successful rollout. Employees may have returned to old processes rather than asking for assistance.

Use both system data and direct employee feedback to understand what is happening.

Remove the old process at the right time

Running old and new systems indefinitely can undermine adoption.

If employees can continue using spreadsheets, paper forms or shared inboxes, the new system may remain secondary. This creates duplicate records, inconsistent data and confusion over which source is authoritative.

A transition period may be necessary, but it should have clear boundaries.

Communicate:

• When the new system becomes the official process

• Which previous tools will be retired

• How existing records will be handled

• What employees should do if the system is temporarily unavailable

• Who can approve exceptions

Before removing an old process, ensure the replacement is functional, accessible and supported. Employees should not be forced into a new system while unresolved technical or operational barriers remain.

Treat feedback as part of continuous improvement

No configuration will be perfect from the first day.

As employees use the system, they may identify opportunities to simplify wording, remove unnecessary steps, adjust notifications or improve access to information. This feedback should be reviewed through a controlled process.

Not every request will result in a change. Some fields or approvals may be necessary for legal, operational or risk-management reasons. However, employees should understand that their feedback has been considered.

It can be helpful to maintain a visible improvement process showing:

• Feedback received

• Issues under review

• Changes approved

• Changes completed

• Suggestions that cannot be implemented and why

This supports trust while preventing uncontrolled changes to important safety processes.

What successful adoption looks like

Successful adoption is not measured solely by the number of people who have logged in.

A safety system is becoming embedded when:

• Employees use it without needing repeated reminders

• Reports contain useful and timely information

• Supervisors respond consistently

• Actions are assigned and completed

• Leaders use the data in decision-making

• Employees can see the outcomes of their reports

• Workarounds and duplicate processes decline

• Feedback leads to practical system improvements

• The system supports safety conversations rather than replacing them

Technology should strengthen the connection between identifying a risk and taking action. It should make responsibilities clearer, information easier to access and important issues harder to overlook.

Software adoption is a people-centred process

The effectiveness of safety software depends on more than its technical capabilities.

Organisations need to consider how the system fits into everyday work, how the change is communicated and whether employees believe using it will make a meaningful difference.

Consulting employees, designing practical workflows, providing role-specific training, supporting users after launch and visibly responding to reports can turn a software rollout into a lasting improvement in safety management.

myosh provides a configurable HSEQ management platform with mobile and offline capabilities, interactive dashboards and integrated modules that can be adapted to an organisation’s processes. Combined with thoughtful implementation, training and ongoing user feedback, this flexibility can help organisations build a safety system that people can use confidently and consistently.

The goal is not simply to implement new technology. It is to create a reliable process that employees trust, leaders support and the organisation continually improves.

‍