Three sites have cleaned up three spills. Every local action is complete. Has the business addressed three isolated events, or missed one recurring problem?
Environment, health and safety (EHS) software sprawl makes that question expensive to answer. Incident descriptions live in the safety platform, maintenance details sit elsewhere, and a spreadsheet joins the local action lists for the monthly review. Each site can explain its own closure. Nobody has a reliable view of what connects them.
The extra software often arrives one sensible purchase at a time: easier capture, a reminder board, a reporting connector. Software as a service (SaaS) sprawl grows when those tools create competing versions of the investigation and its next decision.
EHS software sprawl hides between local completion and shared learning
Consider a fictional business with three sites. One reports a “transfer-line leak”, another a “slippery loading area”, and the third a “spill during unloading”. Each records cleanup and restores the work area. Separate categories and different wording keep the events apart in the local reports.
A reviewer suspects a shared equipment or maintenance factor. But one event happened before the suspected component change. A fourth, similarly worded report concerns rainwater entering through a roof. Combining everything under “spill” would produce a tidy trend and a weak explanation.
The missing work is a shared investigation that preserves those differences, tests the proposed connection and assigns follow-up where justified. Another dashboard that counts closed actions will not establish whether that work happened.
There is practitioner support for the coordination problem. In a public discussion of multi-site safety challenges, the author describes conflicting reports about the same action across three sites. Replies emphasise local relationships, capacity and accountability. It is a self-reported experience, not evidence of how widespread the problem is or proof that a particular product fails.
That distinction matters: software can make a missing decision visible. It cannot supply the time, engineering judgement or management commitment needed to act on it.
Keep the completed cleanup; link the new investigation
Reopening all three cleanup tasks would blur what actually happened. The spills were cleaned up. The possible common cause is a different question.
For this example, use a new shared investigation linked to the three incidents. If a reviewer accepts the proposed relationship, assign an investigation owner and record the evidence still needed. Approved follow-up can include a shared change and separate implementation tasks at each affected site.
| Record | What completion means | Where authority stays in this proposed workflow |
|---|---|---|
| Original incident | The reported event and subsequent corrections remain traceable | Existing EHS platform |
| Local cleanup action | The specified immediate work was completed and checked | Existing action record |
| Shared investigation | Accepted and rejected connections, causal hypotheses and findings are recorded | One designated investigation record, linked to the source incidents |
| Corrective follow-up | The approved change was implemented at the relevant sites | Existing platform's linked action records |
| Effectiveness review | The agreed evidence supports a decision about whether the change worked | Named review record with references to operational evidence |
This is a proposed operating model, not a universal safety procedure. The accountable safety owner must decide the review roles and evidence appropriate to the work.
An earlier action that explicitly claimed to prevent recurrence needs a different response from a cleanup task. Preserve its original approval and review the new evidence against that claim. Record further work or a superseding action rather than silently changing the historical meaning of “complete”.
Where tool sprawl creates extra work
Each site maintains its own interpretation. The platform says the action is complete, a spreadsheet says investigation pending, and a meeting note says maintenance is responsible. All three may describe real work, but the relationship is missing. Better software visibility means showing which question each status answers.
Evidence is assembled repeatedly. A coordinator exports incidents, collects photographs and asks maintenance for the same history before every review. Copies become stale. A useful evidence view preserves source references, retrieval dates and the version reviewed, instead of becoming another editable incident register.
Follow-up creates a second action list. A shared investigation generates tasks in a new application while site managers continue using the incumbent. Status updates now have two destinations. A connected workflow should create approved actions in the existing platform and display their returned identifiers and current status.
Reports count activity as effectiveness. A rising closure rate can coexist with repeated events. The review needs evidence from work performed after the change, including relevant exposure and exceptions. A quiet period with little or no activity provides limited assurance.
This is the software waste worth measuring. The question is less whether you have too many software tools and more whether people must repeatedly reconstruct the same decision across them.
Put a price on reconciliation, not on hypothetical prevention
SaaS spend management should include the effort needed to keep systems agreeing. Keep ordinary investigation and safety work outside the sprawl calculation: that work remains necessary whichever software you choose.
Here is an illustrative model in Australian dollars, not vendor pricing, a customer result or a market average. Assume three sites each spend four hours per month copying status into a central tracker. A coordinator spends another eight hours assembling cross-site evidence, and six hours reconciling reports. Value these separate activities at a loaded A$85 per hour. Add A$450 per month for overlapping reporting and task subscriptions and A$150 for connectors.
| Extra cost | Monthly | One year | Three years | Five years |
|---|---|---|---|---|
| Duplicate status entry: 12 hours × A$85 | A$1,020 | A$12,240 | A$36,720 | A$61,200 |
| Repeated evidence assembly: 8 hours × A$85 | A$680 | A$8,160 | A$24,480 | A$40,800 |
| Report reconciliation: 6 hours × A$85 | A$510 | A$6,120 | A$18,360 | A$30,600 |
| Overlapping subscriptions and connectors | A$600 | A$7,200 | A$21,600 | A$36,000 |
| Modelled extra cost | A$2,810 | A$33,720 | A$101,160 | A$168,600 |
The projections hold workload and prices constant and exclude tax, inflation and incident losses. Measure the activities separately to avoid counting the same hour twice. The incumbent subscription stays in every connected-workflow option; cancelling it is not part of this case.
These totals are not promised savings. Recoverable staff time is capacity, and recurring software costs fall only when a subscription or charge actually disappears. A SaaS total cost of ownership comparison must also include configuration or development, integration, permissions, assurance, training, hosting, model usage, support and maintenance.
For scale, removing half the modelled administration and A$300 of monthly subscriptions would release A$1,105 of capacity and A$300 of cash per month, before the new workflow's costs. A workflow costing more than that needs another evidenced benefit to justify it. Do not fill the gap with invented accident-prevention savings.
Test native AI before adding an AI workflow
Artificial intelligence (AI) could help find differently worded incidents and assemble evidence for a reviewer. That does not establish a need for another application.
Mitti's AI Assistant documentation already describes examining issues by site, recommending corrective actions from company documents, and creating assigned actions. Quentic describes AI support for incident patterns and root-cause analysis. These are vendor descriptions, not our hands-on assessment of either product or proof that every edition supports the whole proposed process.
Ask the incumbent to demonstrate the three-site example before building anything. Can a reviewer see the sources, retain contradictory evidence, reject the rainwater lookalike and keep completed local actions intact? Can the accepted investigation lead to approved follow-up and an effectiveness review without creating a parallel status register?
Then test restricted records and changed evidence. A summary must not disclose an incident the reader cannot access. If a source changes after review, the workflow should identify that change rather than treating the earlier approval as current.
If configuration and existing capabilities answer those questions, use them. The EHS software comparison covers vendor scope, AI evidence and price limitations; SafetyCulture alternatives examines the Mitti decision in more detail.
Software consolidation needs a clear boundary
A connected workflow is justified only by a demonstrated gap. In this proposed boundary, the incumbent continues to own incidents and action status because those records already support site execution and history. The added workflow owns proposed relationships, source references, reviewer decisions and investigation evidence.
A person reviews and approves a follow-up recommendation before an application programming interface (API) creates the action in the incumbent. Record the returned action identifier. If a request fails or its response is lost, resolve its outcome before retrying so one approved recommendation does not create duplicate work.
AI must not merge authoritative incidents, determine root cause, approve corrective changes or declare effectiveness. Its contribution is a reviewable proposal. An accountable investigator owns the conclusion.
Workflow ownership also includes access restrictions, retained evidence, recovery and a named person responsible for failed integrations. Health or other sensitive details should not travel into a cross-site view simply because the integration account can read them. Establish what each reviewer needs and may access.
This is a connected-workflow design, not a claim of a completed build or a selected incumbent. Moving the underlying safety records would be a separate decision requiring evidence about migration, continuity, retention and controls.
Start with one recurring pattern
Run a SaaS stack audit on a small set of incidents that may share a cause. Trace how someone assembled the connection, who accepted or rejected it, where follow-up was assigned and what evidence supported the effectiveness decision. Include an unrelated lookalike so the test rewards sound judgement rather than simply finding more matches.
Compare the existing process, a configured native workflow and any proposed addition. Measure reconstruction time, duplicate entry, rejected suggestions, failed action writes and follow-up still awaiting review. State which spreadsheet, duplicate register or manual step would disappear.
If nothing can be retired and the new tool only creates another view to maintain, it adds to SaaS sprawl. Simplify the proposal. The useful outcome is one shared investigation people can trust, with local work and its evidence still intact.
Continue with the corrective action workflow for the workflow direction. If the retained-record boundary is clear and the remaining job is a focused review-and-follow-up flow, Fast Start can scope that workflow around the existing system of record.
