Incident reporting software
Something goes wrong on a job. Someone is hurt, or nearly hurt, or work is damaged, or a member of the public is involved. The first version of the story is a phone call. The second is written that evening, from memory, by someone who was not there. By the time anyone asks for the record, the names, the time and the photos have softened.
An incident report is the account you can still trust next month. It is written by the people who were there, close to the time, and it stays with the job and the people it concerns.
This page is about reporting an incident. Method statements, and who has acknowledged them, are covered in RAMS software. Tickets and expiry dates are covered in training records and a competence matrix.
What a late report loses
- The time becomes "sometime after lunch" instead of a time you could check.
- Witnesses were there, and nobody took their names.
- Photos were taken, then lived on a phone.
- Two accounts disagree, and you cannot tell which was written first.
- The action you promised has no owner and no date, so it fades.
What to write down
- When and where, and which job or site.
- What happened, in plain words, from the person who was there. Separate what they saw from what they concluded.
- Who was involved, and who saw it.
- What was done at the time, and what still needs doing, with a name against it.
- Photos and any other evidence, on the report, not on a personal phone.
A near miss is worth the same page. The injury did not happen. The condition that would have caused it did. If you only write the ones that hurt, you only learn afterwards. The job the report belongs to is covered in job management software. The person who was there, and the sheet for that visit, are covered in field service software.
What to look for
- A short form people will fill in on the day, not a long document they postpone.
- The report findable from the job, the site and the person.
- What has been closed, and what is still open, with a name on the open part.
- A record that does not depend on one manager's inbox.
How Atlas OS® helps
Atlas OS® is a complete business operating system for any business, anywhere, in any sector. The operating system behind your business. It is in development. You cannot switch it on as a finished product today.
An incident report should sit with the job and the people it concerns, with the other records of that work. Documents can be attached to the job or site, and the team sees them on the job. RAMS acknowledgements and training expiries have their own guides. This page is the shape of the incident record. It is not a finished form you can switch on today.
Run it. Connect it. Control it. Prove it.
Common questions
What should an incident report include?
When and where, which job or site, what happened in plain words, who was involved, who saw it, what was done at the time, and what still needs doing, with a name against it. Photos belong on the report.
Why write it the same day?
The first account is a phone call. The written one, done that evening by someone who was not there, has already softened. Names, times and photos are hardest to recover later.
Should a near miss be written down?
Yes. The injury did not happen. The condition that would have caused it did. If you only record the ones that hurt, you only learn afterwards.
Is incident reporting switched on in Atlas OS?
No. Atlas OS is in development. An incident report should sit with the job and the people it concerns. This page is the shape of that record. It is not a finished form you can switch on today.
How do I get early access?
Atlas OS is in development and coming soon. Join the waitlist and we will email you when it opens.
Get early access
If you want an incident written down while the facts are still fresh, join the waitlist. We will email you when Atlas OS opens.