Every hotel has stories.
The guest who tried to enter the wrong room at 2am, the suitcase that disappeared from reception and then mysteriously reappeared, the fire door that somebody keeps wedging open.
The contractor who definitely had permission to be there, although nobody could quite remember who gave it.
Some stories become incidents. And most incidents eventually become a line in a log.
That's where something slightly strange happens.
A real event, involving people, decisions, locations, timings and consequences, gets compressed into a few sentences.
"22:47. Disturbance reported on third floor. Security attended. Situation resolved."
Job done. Except, perhaps, it isn't.
Becauseincident management report is useful for recording what happened.
The more interesting question is what happens to the information afterwards.
The security log was designed to remember what people forget
There is nothing inherently wrong with a security log. In fact, the idea is remarkably sensible.
Hotels operate continuously. Staff change shifts. Managers go home. Security officers finish for the evening. Tomorrow's team needs to know what happened yesterday.
So we write things down.
For decades, the Daily Occurrence Book did exactly that. A chronological memory of the building.
Who arrived, what happened, what was noticed, what action was taken.
For an individual hotel operating relatively independently, that can work surprisingly well.
The weakness appears when we start asking the logbook to do something it was never really designed to do: help us understand patterns.
A book is excellent at telling you what happened at 10:42pm on Thursday.
It is considerably less enthusiastic about telling you that something similar has happened on seven Thursdays in the past three months.
A daily occurrence book records events. Patterns require something else
Consider a hotel that experiences three relatively minor incidents.
One guest reports somebody trying their bedroom door.
A few weeks later, another guest reports suspicious behaviour in the same corridor.
Later still, security challenges somebody who cannot explain why they are on that floor.
Individually, none of these necessarily looks remarkable.
They might be recorded by different people, on different shifts, in different weeks. A daily occurrence log can capture all three perfectly.
The harder part is recognising that they might be connected. This is one of the peculiarities of incident management.
The significant event is not always significant when viewed on its own. Sometimes importance only becomes visible through repetition.
One broken light is maintenance. Five incidents beside the same poorly lit entrance might be something else entirely. One aggressive guest is unfortunate.
Regular aggression at the same time every Saturday night might suggest an operational problem worth addressing.
The information has always been there. The challenge is being able to see it.
Incident tracking has a problem with human memory
Human beings are very good at noticing unusual things. We are less good at remembering precisely how often they occur.
Ask somebody working in a hotel: “Have we had many incidents in the car park recently?”
and you may get: "It feels like we have."
That isn't bad security operations by management. It is simply how memory works.
Recent events feel more important. Dramatic incidents are easier to remember. Small events disappear surprisingly quickly.
Good incident tracking gives an organisation something more useful than memory. It gives it perspective.
Are incidents increasing? Are they happening at particular times? Are certain locations repeatedly involved? Are the same types of incident appearing across several properties? Are actions taken after an incident actually reducing recurrence?
Incident tracking software shouldn't just create a better filing cabinet
Most security incident logs are written immediately after something has happened. Which makes sense.
But perhaps their real audience isn't the person completing them. It's whoever needs the information next.
The next security officer. The night manager. The hotel manager reviewing yesterday's activity. The regional security director comparing properties.
Or the team trying to understand why the same incident keeps happening.
Seen this way, reporting isn't simply documenting the past. It's a handover to the future and a guide in how to shape future security operations.
And the quality of that handover determines how much useful information survives.
“Security attended. Situation resolved.”
may be perfectly accurate. It just doesn't leave much behind.
Perhaps an incident report shouldn't be the end of the story
There is something reassuring about writing an incident down.
It feels complete. Something happened. We responded. We recorded it.
And sometimes that is exactly right. Not every lost umbrella requires a strategic review.
But the purpose of security incident management reporting shouldn't simply be to create an immaculate historical record of everything that has already gone wrong.
The bigger opportunity is to make tomorrow slightly less surprising. Because somewhere inside hundreds of completely ordinary incident reports might be something worth noticing.
A recurring location.
A recurring time.
A recurring behaviour.
A recurring weakness.
The individual entries might look insignificant. The pattern might not.
The book behind the desk was designed to make sure the hotel didn't forget what happened.
Robust incident management should help it understand what those incidents are trying to tell it, and how to change your security operations in preparation for what might happen tomorrow.
