Who Should Receive After-Hours Security Notifications in a Multi-Site Business?
A business with eleven sites across two states had exactly one person on the after-hours alarm notification list for each location, the site manager. It worked fine for years, until an alarm triggered at 2am at one site on a night its manager happened to be on a flight, phone off, six hours from landing. The alert sat unanswered for the entire flight. Nobody else even knew it had gone off, because nobody else was ever meant to.
A competitor running a similar footprint had built something different, not out of any particular incident, just because someone early on had asked an obvious question nobody at the first business ever had: what happens if the one person on this list doesn’t answer. Every site on their list had a primary contact, a secondary contact, and a regional fallback, in that order, with each step triggering automatically if the one before it didn’t respond within a set window. An alarm at 2am reached someone, every time, because the list was never built around the assumption that one specific person would always be reachable.
Neither business had done anything wrong with their actual alarm systems. The gap wasn’t the hardware. It was that one had built a notification list assuming everyone would always answer, and the other had built one assuming, correctly, that eventually someone wouldn’t.
When the first business eventually reviewed what happened, the most uncomfortable part wasn’t the six-hour gap itself, it was realising that nobody had ever actually asked what the plan was if the site manager didn’t pick up. The list had been created once, years earlier, by whoever set up the alarm system at the time, and never revisited since, not because anyone decided a single contact was sufficient, but because nobody had ever decided anything about it at all. That’s usually how this gap actually forms. It’s rarely a deliberate choice to run a thin list. It’s a list that was never designed in the first place, just populated once and left alone.
Why a Single-Contact List Fails Precisely When It Matters Most
The flaw in a one-person-per-site list isn’t that it’s wrong most of the time, it’s that it only fails on the nights it actually matters, because the nights someone’s unreachable, travelling, unwell, asleep with a phone on silent, are randomly distributed and completely unrelated to whether that particular night happens to be the one with a genuine incident. A notification system only earns its purpose on the nights it’s tested by something real, and a single point of contact is a system that’s never actually been tested until the one night it fails.
Building an Actual Escalation List, Not Just a Contact List
Run your current setup against these checks, site by site, and you’ll know quickly whether what you have is a genuine escalation structure or just a list of names.
Does every site have more than one person on the list, in a defined order. A primary contact, a clearly named secondary, and ideally a third, someone who’s structurally different from the first two, not just another staff member at the same site who might be unreachable for the same reasons.
Is there an actual regional or area-level fallback above individual site contacts. If both the primary and secondary for a specific site are unreachable, does the alert climb to someone with visibility across multiple sites, an area manager, operations lead, rather than simply going unanswered once the site-specific list is exhausted.
Does escalation happen automatically after a defined time, not manually. If the first contact doesn’t acknowledge within a set window, five minutes, ten minutes, whatever’s appropriate, the next person on the list should be notified without anyone having to notice the first attempt failed and manually chase it.
Is the list actually matched to who’s realistically contactable at 2am, not just who’s senior. A regional manager who travels constantly for work might be the wrong person to have high on an after-hours list despite their seniority, while a site supervisor who lives locally and keeps regular hours might be a more reliable second contact than their title would suggest.
Is the list reviewed on a schedule, not just updated when someone happens to remember. Staff change roles, leave the business, or move location, and a notification list built two years ago drifts out of date exactly the way any other contact list does if nobody’s assigned to actually check it.
Does the notification differentiate by what actually triggered it. A door-forced alert during a period of active theft risk deserves a different urgency and response than a low-battery sensor fault, and a list treating every trigger identically either causes alert fatigue on minor issues or under-reacts to serious ones.
Does the list use more than one communication channel. A call-only notification fails silently if a phone’s on silent or the call goes to voicemail. Pairing a call with an SMS or app-based push notification gives someone two separate chances to notice, rather than relying on a single channel to work perfectly every time.
Get Lachlanreeves Writer’s stories in your inbox
Join Medium for free to get updates from this writer.
Has everyone on the list actually been told they’re on it, and what’s expected of them. Being listed as a contact and knowing you’re the contact, with a clear sense of what acknowledging an alert actually involves, are two different things. A list is only as good as whether the people on it know their role well enough to act on it at 2am without hesitating.
What Each Part of the Structure Actually Prevents
Having more than one contact per site prevents the exact failure in the story above, one unreachable person meaning nobody hears about it at all. A regional fallback above site level prevents a site-specific list from being a dead end, giving the alert somewhere to go even when an entire local team happens to be unreachable at once. Automatic time-based escalation prevents the gap from depending on someone else noticing a non-response and remembering to act on it manually, which is an unreliable safeguard precisely because it relies on human attention at 2am. Matching contacts to actual reachability rather than seniority prevents a list that looks appropriate on an org chart from being practically useless the one time it’s tested. Regular review prevents the list from quietly going stale the same way any contact list does, a departed employee’s number sitting there uselessly is a gap nobody notices until an alert actually needs to reach someone. And differentiating by trigger type prevents both alert fatigue that causes people to start ignoring notifications altogether, and under-response to the alerts that genuinely need immediate action. Using more than one communication channel prevents the specific failure of a single missed call meaning nobody ever knew the alert happened at all, since a second channel gives a genuine second chance for it to be noticed. And actually briefing everyone on the list prevents the awkward, costly delay of someone realising, in the moment, that they’re not sure what they’re actually meant to do, which turns what should be a fast response into a confused one right when speed matters most.
When a Simpler List Is Genuinely Fine
A single-site business with one or two owner-operators who are consistently contactable doesn’t need a multi-tier escalation structure, there’s no meaningful “what if the one person isn’t reachable” scenario to design around when the business itself is that small. It also matters less where every site already has an on-site or nearby overnight presence, a manned security desk, live-in management, that would catch an issue independently of the notification list entirely. This matters most specifically for multi-site businesses spread across enough distance or time zones that a single point of failure at one site can’t be caught informally by anyone else noticing.
Common Mistakes
The first mistake is building the list around organisational seniority rather than actual after-hours reachability, putting a regional director first because of their title rather than because they’re realistically the person most likely to answer at 2am.
The second is never testing whether escalation actually triggers automatically, assuming it does because it was set up that way once, without confirming the timing and handoff still work as intended.
The third is letting the list go stale by tying updates to nothing, no scheduled review, no trigger tied to staff changes, so it silently drifts further from reality every month nobody checks it.
The fourth is treating every alert as equally urgent, or equally unimportant, rather than building differentiated response paths, which either burns out the people on the list with constant low-priority pings or dulls their response to the alerts that actually matter.
The fifth is adding someone to the list without ever actually telling them, or without confirming they understand what a response actually requires of them. A name on a spreadsheet isn’t the same as a person who knows, ahead of time, that they might get a call at 2am and exactly what they’re supposed to do when it comes.
Getting This Structured Properly
Building a notification list that actually holds up under real conditions is easier with an outside review than trying to catch every gap internally. A full-service security provider can review your current escalation structure across every site and flag exactly where a single point of failure or a stale contact is sitting, before it’s tested by an actual incident. Where the response genuinely needs feet on the ground rather than just a phone call, coordinating your notification structure with an actual security services provider means an unanswered alert doesn’t just sit unresolved, it triggers an actual physical response. A genuinely established full-service security partner in Australia will ask how your escalation list is actually structured, not just who’s listed as the primary contact, because that structure is what determines whether an alert reaches someone on the night it matters. If your business runs more than one site, it’s worth reviewing this directly with whoever provides your commercial security services rather than assuming the current list would hold up if it were ever genuinely tested.
Frequently Asked Questions
How many people should realistically be on an escalation list for one site? Three is generally enough for most sites, a primary, a secondary, and a regional or area-level fallback. More than that tends to create confusion about who’s actually responsible for responding first, without meaningfully improving reliability.
Should the business owner always be on every site’s list? Not necessarily as a first contact. An owner overseeing multiple sites is often better placed as a higher-level fallback than as the first person contacted for every individual site, otherwise they become a single point of failure across the entire business rather than just one location.
How often should the notification list actually be reviewed? At minimum, every time there’s a relevant staff change, a departure, a role change, a relocation, plus a standing review on a set schedule, quarterly is reasonable for most multi-site operations, so the list doesn’t rely on someone remembering to update it.
Does this matter as much for low-risk sites, like a small storage unit compared to a busy retail location? The escalation structure still matters, but the response and urgency can reasonably differ. A lower-risk site might tolerate a longer escalation window than a site with higher value stock or higher foot traffic, the principle of having a working fallback still applies either way.
Is it worth actually testing the escalation list, or is reviewing it on paper enough? A genuine test, triggering a real notification and timing how it actually escalates, catches problems a paper review never will, an outdated number, a channel that isn’t actually delivering alerts, a fallback that doesn’t trigger the way it’s supposed to. It’s worth doing at least once, deliberately, rather than assuming the structure works because it was designed correctly on paper.
The Bottom Line
A notification list only proves itself on the one night it’s actually tested by something real, and a single point of contact is a system that’s untested by design until that night arrives. Build the escalation, more than one contact, automatic time-based handoff, a regional fallback above the site level, and the list stops depending on one specific person always being reachable, which was never a safe assumption to build a security response around in the first place.
Does your business currently have more than one person who’d actually get an after-hours alert, or has it never really been tested? I’d be genuinely interested to hear how your list is actually structured.
