A hazard report is only the beginning of a safety process. Across multiple sites, the more demanding task is making sure the report reaches the right supervisor, corrective work is completed, evidence is checked, and leadership can see whether the same problem is occurring elsewhere.
For organisations managing work health and safety across multiple sites, the challenge is not simply to capture more information. It is to maintain a clear connection between what people report, the decisions managers make and the evidence leaders need to assess whether risks are being addressed. Local teams need enough flexibility to respond to their circumstances, while the organisation needs consistent expectations for accountability, follow-through and oversight.
That makes the connections between activities just as important as the activities themselves. A software evaluation should examine how a report moves through investigation, corrective action and verification, as well as what happens when work is overdue, an approval is rejected or information must be restricted. Demonstrating individual features is useful, but it does not establish that the whole process will work for the people responsible for it.
The fictional multisite example below explores these connections through a practical WHS workflow, from frontline reporting to organisational review. It sets out a proposed operating process and evaluation criteria, rather than confirmed capabilities or licensing for any particular platform. SWMS, permits, integrations and access controls must each be demonstrated and explicitly included in the agreed scope before purchase.
An organisation operates a manufacturing facility, a distribution centre and a regional warehouse. Employees report hazards locally. Supervisors investigate, action owners carry out corrective work, site managers verify completion, and WHS leadership reviews the organisation-wide picture.
External contractors also perform maintenance. Their work introduces a related process for Safe Work Method Statement (SWMS) review and, where required and supported, permit authorisation.
The organisation wants consistent minimum requirements across sites while retaining local accountability. Sensitive injury information follows a separate, restricted access pathway.
At the distribution centre, an employee notices a loose floor plate near a loading area after a trolley catches on its edge. No injury occurs, but the event could have caused harm.
The employee follows the site’s immediate safety procedure and reports the near miss, recording:
The proposed workflow routes the report to the responsible site supervisor for triage. Urgent risks follow the agreed immediate escalation process; they should not wait for a software notification.
Evaluation test: Submit reports from different sites and confirm that each reaches the correct supervisor. Check required information, acknowledgement, notification behaviour and the escalation path when the usual supervisor is unavailable.
The supervisor checks the area, speaks with the employee and records the investigation findings. The review considers both the immediate defect and contributing factors, such as inspection frequency, maintenance practices and repeated equipment movement.
The supervisor assigns a corrective action to the maintenance lead, with a due date, priority and clear acceptance criteria. In this example, completion requires securing or replacing the floor plate and checking nearby plates for similar defects.
Proposed status path: Reported → Under investigation → Action assigned → In progress.
If the action becomes overdue, the agreed process escalates it to the site manager. If investigation identifies a wider issue, WHS leadership considers whether equivalent checks are needed at the other sites.
Evaluation test: Confirm that actions remain linked to the original report, have a named owner and due date, and can be reassigned with a recorded reason. Test reminders, overdue escalation and visibility for each responsible role.
The maintenance lead completes the repair and submits photographs, a work record and the results of the nearby inspection. The action moves to Awaiting verification, rather than closing simply because the owner has marked the work complete.
The site manager checks the evidence against the acceptance criteria and, where appropriate, inspects the area. If evidence is insufficient or the repair does not address the risk, the manager returns the action with a reason and identifies the further work required.
Proposed status path: In progress → Awaiting verification → Verified and closed, or Returned for further work.
The manager also records whether follow-up is needed to check that the control remains effective. Completion evidence and control effectiveness are related, but they are not the same test.
Evaluation test: Attempt closure with missing evidence, return an action for further work, and complete a second verification cycle. Confirm the history retains the submissions, decisions, reasons and responsible people.
A maintenance contractor is scheduled to undertake related work at the manufacturing facility. For the evaluation scenario, the organisation requires a SWMS and defines the reviewers and approval stages in advance. The applicable legal and operational requirements must be assessed separately for the actual work.
The contractor submits the SWMS against the correct site, work scope and contractor record. A nominated reviewer checks it against the organisation’s agreed requirements, including task steps, hazards, controls and responsibilities.
In the test, the first submission is rejected because an agreed control is missing. The reviewer records the reason, and the contractor submits a revised version. The revised document passes the required review stages and is approved by the nominated authority.
Proposed status path: Submitted → Under review → Rejected with reasons → Revised and resubmitted → Under review → Approved.
Approval is a document-review decision. It does not replace site induction, worker consultation, implementation of controls or supervision of the work.
Evaluation test: Demonstrate the full rejection and resubmission loop, not only the successful approval path. Check version history, reviewer permissions, required approval stages, contractor visibility and what happens when the work scope changes after approval. Confirm whether the system can enforce the agreed gates or whether a documented manual control is required.
Where the work requires a permit under the organisation’s process, test the relevant permit type. Hot work or confined-space work could be separate evaluation scenarios, but they should not be assumed to apply to the floor-plate example.
Proposed status path: Draft → Submitted → Authorised → Active → Closed, with rejection, suspension or expiry paths where required.
The permit process should identify the work location, scope, authorised period, required checks, responsible authoriser and close-out requirements. At completion, the responsible person records the agreed handback checks and closure evidence.
Evaluation test: Confirm the platform supports the required permit types and authorisation rules. Test missing prerequisites, expiry, changed conditions and close-out. A generic form is not evidence of a complete permit-to-work capability.
If the required capability is not confirmed, record it as an exclusion, an agreed external process or a separately scoped requirement. Do not present it as included functionality.
Site managers need visibility into their own reports and actions. WHS leadership needs a consolidated view that can be filtered back to each site.
For this example, the proposed dashboard requirements include open and overdue actions, actions awaiting verification, recurring hazard categories, SWMS review status and permit status where supported.
Leadership can then consider whether a repeated maintenance issue warrants a coordinated response across the organisation rather than three separate local fixes.
Evaluation test: Reconcile dashboard figures to the underlying test records. Check that site filters, status definitions and access permissions behave consistently. Treat comparisons carefully: a higher reporting count alone does not establish that a site is less safe, and any rate-based comparison needs an agreed denominator.
Use a separate fictional injury record to test access. Do not use real medical information in the demonstration.
Define an access matrix before testing. An illustrative model is:
| Role | Proposed access to validate |
|---|---|
| Frontline employee | Appropriate reporting access, without access to other employees’ restricted injury information. |
| Supervisor or site manager | Operational information required for their responsibilities, without automatic access to medical details. |
| Authorised injury-management personnel | Case information and documents needed for their assigned responsibilities. |
| WHS leadership | Appropriate oversight and aggregated reporting; identifiable details only where authorised. |
| System administrator | Configuration access with explicit confirmation of any ability to view or grant access to restricted records. |
Evaluation test: Sign in as each role and attempt both permitted and prohibited actions. Test searches, direct record links, attachments, exports, dashboards and notifications. Check cross-site access and what happens when a person’s role changes. Hiding a field on one screen is not proof that its contents are restricted everywhere.
The final access model should be agreed with the organisation’s privacy, HR and
injury-management stakeholders.
The workflow demonstration should be followed by a scope confirmation, not an assumption that every requirement is included.
| Scope area | Confirm before pricing is finalised |
|---|---|
| Employees across sites | Headcount by site, employment groups, reporting needs and shared or individual access requirements. |
| Managers and administrators | Expected numbers, site-level and cross-site responsibilities, approval roles and administration rights. |
| Contractors | Active and peak volumes, contractor organisations, submission frequency and external access needs. |
| Injury management | Whether the requirement stops at injury reporting or includes case management, return-to-work processes, documents and restricted medical information. |
| SWMS | Review stages, approval authorities, versioning, rejection/resubmission rules, reapproval triggers and access requirements. |
| Permits | Required permit types, prerequisites, authorisation stages, expiry, suspension and closure requirements. |
| Training records | Inductions, competencies, refresher dates, evidence, contractor records and any learning-system connection. |
| Migration | Source systems, record volumes, attachments, history, data cleansing, mapping and validation responsibilities. |
| Microsoft integrations | Priorities for identity and single sign-on, Teams notifications, SharePoint documents, Outlook or reporting connections; specify the expected behaviour of each. |
Record each requirement as demonstrated and included, subject to configuration, requires integration or additional work, unconfirmed, or excluded. These distinctions should carry through into the commercial documents.
The real test of a multisite WHS process is what the organisation can do with what it learns. Can a hazard identified at one site prompt preventive action at another? Can a manager distinguish completed work from a control that has been checked and found effective? Can leadership see where intervention is needed without exposing sensitive information to people who should not have access?
These questions provide a stronger basis for evaluating software than a checklist of features alone. Start with the work people need to carry out, test the handovers and exceptions, and require evidence that the proposed solution supports the agreed process. Then make sure the proposal and statement of work reflect what was demonstrated, including the responsibilities, costs, dependencies and limitations.
The aim is not to make every site operate identically. It is to establish consistent standards while keeping responsibility close to the work—and to ensure that local experience informs organisation-wide decisions. That is how frontline reporting becomes more than a record of what happened: it becomes a basis for action, learning and more informed oversight.