Incident reporting software, and the near misses it should be catching

The short answer

Incident reporting software exists to do three things: let someone record what happened quickly enough that they actually do it, route that record to whoever has to investigate and sign it off, and keep the evidence in a state where it can be produced months later. Everything else a vendor shows you is in service of those three, or is decoration.

The part most organisations get wrong is not the software. It is the threshold. A system that only ever receives injuries will never tell you anything you did not already know, because by the time there is an injury the information arrives too late to act on. The reports worth having are the ones where nobody was hurt — and those only arrive if reporting is quick, blame-free and visibly leads somewhere.

First, a disambiguation: this is not IT incident management

Search for "incident management software" and most of what comes back is IT service management — products for outages, service tickets, major incidents, security breaches, on-call rotas and escalation policies. That is a different discipline with a different buyer, and the two categories share a word and very little else.

This page is about workplace health and safety: a worker is injured, a load swings, a substance is spilled, a machine guard is bypassed, somebody trips on a cable and does not fall. If a demo opens with an incident priority matrix and an on-call schedule, you are in the wrong aisle. If it opens with a photo taken at the scene and a corrective action with an owner and a due date, you are in the right one.

What counts as an incident

A workable internal definition is anything unplanned that caused harm, or could have. That phrasing is doing deliberate work: the second half is what brings in the events that have no injury attached and therefore no obvious reason to be written down.

• Injuries and illnesses — from first aid through to anything requiring treatment, time off, restricted duties or a hospital visit.
• Near misses — the same event with the harm removed by luck or timing. The load that swung and hit nothing.
• Property and plant damage — often the only visible trace of a process that was about to hurt somebody.
• Environmental events — spills, discharges, uncontrolled releases, which usually carry their own notification duties to a different regulator.
• Unsafe conditions and acts found before anything happened — the missing guard, the bypassed interlock, the expired ticket.
• Security and aggression — in many sectors this is the most common source of harm to staff, and it is routinely left out of the incident definition.

Keep this internal threshold deliberately wide, and keep it entirely separate from the regulator's threshold, which is far narrower. Those are two different decisions, and collapsing them into one is the most common structural mistake in incident management.

Why near misses are the ones that matter most

A near miss is an injury that did not happen, for reasons that usually had nothing to do with the controls in place. The same sequence, a second earlier or a step to the left, is a hospital visit. That makes near misses the only category of incident that arrives before the harm — which is the entire value proposition of reporting them.

They are also the hardest to collect, for three reasons that are worth naming because only one of them is a software problem:

A practical test of whether your reporting culture is working: when near-miss numbers go up, does the organisation treat that as good news? If a rising count is read as deteriorating safety rather than rising trust, the number will come back down — and not because anything got safer.

The legal floor, by country

Every jurisdiction draws a narrow line around events that must be notified to a regulator, usually deaths, serious injuries needing hospital treatment, certain specified injuries, and a defined list of dangerous occurrences. Everything else is recorded internally and never goes anywhere. The thresholds, clocks and routes differ, and each deserves reading properly rather than summarising:

• New Zealand — notifiable events under HSWA, and what WorkSafe asks for in the first 24 hours. What WorkSafe asks for after a notifiable event.
• Australia — notifiable incidents under the harmonised WHS Act, the duty to preserve the site, and where Victoria differs. WHS incident notification.
• United Kingdom — RIDDOR 2013: the categories, the 10-day and 15-day clocks, and the over-three-day injury that is recorded but not reported. RIDDOR reporting guide.
• United States — 29 CFR Part 1904: the 300 Log, the recording criteria, and the eight-hour and twenty-four-hour reporting clocks. OSHA compliance and recordkeeping.

What a report has to contain to survive an investigation

Months later, an investigator, an insurer or a regulator reads the record cold. What they are looking for is whether it was written at the time, by someone who was there, and whether anything happened as a result.

• When it happened and when it was reported — as two separate timestamps. The gap between them is itself evidence.
• Where, precisely — site, area, and the specific plant or task, not just the depot name.
• What happened, factually — a description of events rather than a conclusion about fault.
• Photographs taken at the scene — the single most valuable field, and the one most often missing because the record was written later at a desk.
• Who was involved and who witnessed it, with their accounts captured separately rather than merged into one narrative.
• Immediate action taken — what was done to make it safe before anyone investigated anything.
• The investigation and its root cause, in whatever method your organisation uses, attached to the record rather than filed separately.
• Corrective actions with an owner, a due date and evidence of closure — the part auditors sample first and the part most often left open.
• Sign-off — who reviewed it, whether they sent it back for more, and when they accepted it.

Read that list again and notice how much of it is about time: written at the scene, actioned promptly, closed with evidence, reviewed by a second person. A system that captures the same fields a week later, from memory, produces a record that technically exists and evidentially does very little.

What to look for in software

• Does it work offline, at the scene? Incidents happen in basements, paddocks, tunnels and plant rooms. If the form needs coverage, the report gets written later and loses most of its value. Ask to see a submission with the device in flight mode.
• How long does a near-miss report take? Time it in the demo, on a phone, as a field worker rather than an administrator. Two minutes is the target; anything above five suppresses volume.
• Can you change the form? Your incident form has to match your work and your jurisdiction. A fixed form designed for somebody else's regulator will be worked around within a month.
• Does the corrective action live inside the record? If actions are a separate module that someone copies the detail into, they drift, and the audit trail breaks at the join.
• Is there a real review step? Specifically, can a reviewer send a thin investigation back? Sign-off with no return path is a rubber stamp.
• Can it report by site? Multi-site organisations need the site manager to see their site and the group to see the group, without building two systems.
• Can you get the records out, in five years? Retention outlasts software contracts. Ask about export before you sign — we wrote a vendor-neutral guide to that question: how to get your HSEQ data out of any system.

How Teammate handles it

The incident is captured on a form you build, rather than on a fixed incident screen designed around somebody else's jurisdiction. Every field type is available, sub-forms carry the detail, and the whole form works on a phone offline at the scene, syncing when coverage returns. That last point matters more than it sounds: the account written at the time, by the person who was there, is the one that holds up months later.

From submission the record moves:

• Send it for investigation. Reassign the form to an investigator, who picks it up in their own list of assigned work rather than in an email thread.
• Root-cause analysis inside the record. Build the method your organisation uses into the investigation form, so the event, the cause and the evidence sit in one object instead of three.
• Reviewed, returned and signed off. Nominate approvers and reviewers; they review, return it for more if it is thin, and sign it off.
• Corrective actions assigned from inside the form, each with an owner, a due date and its evidence of closure, staying attached to the record that raised them.
• Report generated and sent. Export or email the finished report to a client, an insurer, a head office or a regulator — individually or in bulk from the register, as PDF or Excel.
• Reporting across every record by site, date range, category and owner, role-aware so a site manager sees their site and the group sees the group.

Around that sit the records an investigator asks for next: the risk register the event should have been predicted by, training and competency records with expiry dates, the chemical register and its safety data sheets, and controlled documents at their current approved version.

One point of clarity, because it is a fair question to put to any vendor: statutory sheets such as the OSHA 300 Log are prescribed documents with their own layout, and Teammate is the record and evidence system behind them rather than a generator of those forms. The OSHA page sets out exactly where that line falls.

Questions we get asked