Ask a safety manager to describe how a hazard report travels through their organisation and you usually get a clear, confident answer. Ask them to prove that it actually travelled that way last month, and the answer gets slower.
That is not carelessness. It is what happens when a process lives in two places: written down in the management system manual, and carried out through e-mail, corridor conversations and somebody's memory. Both versions are real. They just aren't the same.
Why "we'll just e-mail it" always loses
An e-mail has no owner after it is sent. It has no due date the system knows about. It cannot tell you it was ignored. When the process is a chain of forwards, every link is a place where the chain can stop without anyone noticing — and the person best placed to notice is usually the one waiting at the far end.
The failure is almost never dramatic. Nobody refuses to act. Somebody is on leave, the message lands during a busy week, and by the time it resurfaces the corrective action is three weeks late and the audit is next Tuesday.
A process that only exists in a manual is a description. A process the system enforces is a control.
What to define before you touch any software
The useful work happens before configuration. For each process — hazard report, occurrence, finding, change management — write down four things:
- Trigger. What starts it. Be specific: "a report classified as medium or above", not "when something happens".
- Roles, not names. Who assesses, who decides, who verifies. Roles survive staff turnover; names do not.
- Information flow. Who has to know, as distinct from who has to act. Confusing the two is the most common cause of process fatigue — people stop reading notifications that never require anything of them.
- Time limits. Per step, not just for the whole process. "Closed within 90 days" tells you nothing about where the 89 days went.
Four columns on one sheet of paper. If you cannot fill them in for a process, that process is not ready to be automated — and automating it would only make the ambiguity faster.
Then let the system carry it
Once the four columns exist, the software's job is narrow and unglamorous: route the item to the role, start the clock, escalate when the clock runs out, and keep a record of who did what. No step is allowed to end in an inbox. Every step has an owner who can see it is theirs.
The practical effect is that "where does this stand?" stops being a question you have to ask anyone. It is a screen.
A test worth running
Pick your three most important safety processes. For each, ask: if the person who normally handles this step were away for two weeks, would the process stall silently, or would somebody be told? If the honest answer is "stall", the process is not yet a control.
Where organisations overshoot
The temptation, once you can define workflows, is to define all of them. Resist it. A process that people route around is worse than no process, because it produces evidence of compliance that does not reflect reality.
Start with the two or three processes where a delay actually costs you something — usually occurrence reporting and corrective actions from findings. Get those genuinely working. Add the rest when the first ones have earned trust.
Want to map one of your own processes end to end? Book a demo and we'll walk through it with your own setup.