At two in the morning, a dispatcher has a fire alarm at a client site, an officer asking whether to evacuate, and a phone in her other hand. What happens next is decided entirely by whether an emergency contact tree exists and whether the numbers in it still work. If it exists and it is current, she makes one call and gets an answer. If it does not, she starts guessing — scrolling old emails, calling the account manager’s cell, waking someone who has not touched that account in a year.
The contact tree is one of the least glamorous documents in a security operation and one of the few that gets used at its worst moment. It deserves more attention than it usually gets.
What an emergency contact tree is, and what it is not
It is not a phone list. A phone list is names and numbers. An emergency contact tree answers four questions for each situation:
- Who is called first, by name and role
- In what order the alternates are tried
- How long you wait before moving to the next person
- What authority each person has — who can approve an evacuation, authorize overtime for a callout, speak to media, or tell an officer to stand down
That fourth item is what separates a working tree from a list of numbers. A dispatcher who reaches a client contact at 2 a.m. needs to know whether that person can actually decide anything. Reaching the wrong person quickly is not better than reaching the right one slowly.
Build it in three branches
Most operations need three distinct trees, because the three audiences have nothing to do with each other.
Branch one: internal chain
Field supervisor, then operations manager, then the owner or on-call executive. Short, always the same, memorized by dispatch. This branch answers “who from our company do I wake up?”
The critical design choice here is the escalation clock. Give dispatch an explicit rule: attempt, wait a stated number of rings, leave a message, move on. Without a stated wait, dispatchers do one of two bad things — they call once and give up, or they call the same person eleven times while the incident develops. Whatever wait you choose, write it down and drill it, so the decision is not being made at 2 a.m. by someone under pressure.
Branch two: client contacts, per site
This is where trees rot fastest. Every site has a primary contact, a secondary, and usually a facilities or property manager who is the person who actually answers. Contacts change jobs. Numbers get disconnected. The person who signed the contract eighteen months ago has been replaced twice.
Per site, capture: primary and at least two alternates, what each is authorized to approve, the after-hours number distinct from the desk number, and the explicit instruction for what dispatch should do if none of them answer. That last field is the one that gets left blank, and it is the one dispatch needs most. “If no client contact reaches within the escalation window, the field supervisor responds to the site and the operations manager is notified” is a real answer. A blank field means the dispatcher invents policy on the spot.
Branch three: external and specialty
Fire and police non-emergency lines for each jurisdiction your sites sit in. Alarm monitoring company and the account passcode holder. Elevator service, fire alarm service, locksmith, restoration. Poison control. The client’s own IT or security operations center if they have one.
You will not need most of these most years. You will need one of them badly, once.
Where the tree should live
A binder in the office is useless at 2 a.m. if the dispatcher is remote, and a spreadsheet on one person’s laptop is worse. Three practical rules:
It has to be reachable from wherever dispatch actually sits. If dispatch works from a console, it is on the console. If dispatch is a rotating on-call phone, the tree is in something the on-call person can open from anywhere.
Site-specific portions belong at the post. The officer at the gate should not need to route a routine “the sprinkler room is flooding” call through dispatch to find the facilities number. Put the site branch in the post orders, physically at the post, and in the officer’s app.
The client should be able to see and correct their own branch. This is the single biggest maintenance win available. When client contacts can view what you have on file through a client portal, corrections arrive from the person who actually knows — the client — instead of waiting for your account manager to notice.
The maintenance problem nobody solves
Every contact tree is accurate on the day it is built and decaying by the end of that week. There is no clever fix. There are only cadences.
Quarterly verification per account. Not “confirm the list is fine” — an actual call or email to each listed contact asking them to confirm they are still the right person and the number is still good. It takes a few minutes per account and it is the only thing that works.
Verify at every contract touchpoint. Renewal, rate change, scope change, quarterly business review. Any conversation with the client includes “let’s confirm the after-hours contacts.”
Verify after any real use. The best data you will ever get about your tree is the incident where you had to use it. If dispatch called three numbers and reached nobody, that is not bad luck, it is a finding. Fix it the next morning while it stings.
Own the internal branch by role, not by person. “On-call supervisor” is durable. “Marcus’s cell” leaves with Marcus.
Test it the way you would test a fire alarm
An untested tree is a hypothesis. Twice a year, run a callout drill: dispatch works the tree for one randomly chosen site at an inconvenient hour, without warning the contacts that it is a drill in advance — announce it as a drill on the call itself, immediately. Record how many attempts it took to reach a decision-maker, which numbers were dead, and where the dispatcher hesitated.
The results are always worse than expected the first time. That is the point.
How the tree connects to what is happening in the field
The tree is only half the system. The other half is the trigger — the moment someone decides this is an emergency worth waking people for. That decision is easier when dispatch already has facts rather than a fragmentary radio transmission.
A clean push-to-talk channel gets you the initial report. A panic alert covers the case where the officer cannot talk at all — the alert reaches dispatch with position attached, and the tree starts from there. Both feed the same question: what do I tell the person I am about to wake up?
Give dispatch a short script for the escalation call. Site name, time, nature, what the officer has already done, what you need from the person you called, and a callback number. Thirty seconds. A woken client contact who gets that script is far more likely to make a fast, correct decision than one who gets a rambling account and a question.
The version that survives contact with reality
Keep it to one page per site. Roles, not just names. An explicit wait between attempts. An explicit instruction for total no-answer. Authority noted next to each person. A verification date at the top so anyone can see at a glance how stale it is.
If the date at the top of your tree is more than a quarter old, the tree is a guess. Fix that before you refine anything else about it.
If you want to see how alerts, radio traffic and site contacts sit together where dispatch can reach them, explore CGuardPro or get in touch.