An unanswered phone is predictable enough to plan for. Decide the next permitted move while the site is calm rather than leaving a reviewer to invent it at night.
The idea in view · Planning diagram
An unanswered contact is a planned branch
- Primary attempt
- Observed result
- Fallback role
- Authority confirmed
- Action acknowledged
- Unresolved duty owner
Separate attempt from ownership
Record calls and messages as attempts until the receiving party acknowledges. A delivered notification may not have been read. Define the approved acknowledgement method and who can accept responsibility for the site.
Avoid improvised escalation
The site owner should authorize fallback actions and boundaries. Do not let an unavailable routine contact cause an operator to invent a dispatch policy. Keep emergency handling separate and confirm any local requirements with the appropriate party.
Maintain availability
Review duty rosters, leave cover and role changes. Test the path during an agreed exercise using designated test contacts. If the backup fails too, keep that result open with an owner instead of marking the exercise complete because messages were sent.
Test the final branch of the tree
A contact test is incomplete if everyone answers on the first ring. Arrange an exercise in which the designated primary is intentionally unavailable. Follow the approved fallback with test contacts and record which role accepts ownership. Agree the exercise boundaries beforehand so it does not cause an unintended physical or emergency response.
Keep retry intervals and permitted actions in the actual site procedure. There is no useful universal number for every event and country. Also give routine maintenance a route of its own; a missing-feed fault may need technical support rather than the same decisions as a verified boundary event. The aim is a plan a reviewer can follow without guessing what an absent manager would authorize.
Treat an unanswered call as a planned branch
An unanswered contact is common enough to deserve a written path before an incident. Define the primary role, the approved attempt method, the next role and what remains with the reviewer while waiting. Use the service's actual agreed intervals and conditions; this article does not supply a universal retry schedule. Repeated calls to the same unavailable person are not automatically an effective escalation.
Identify the decision that needs acceptance. A camera outage may need a technical owner, while uncertain activity may need a person authorized to interpret the site schedule or arrange local action. The fallback should be appropriate to that duty. A person available to answer the phone may still lack authority to grant entry, approve an exception or accept a repair.
Distinguish attempt evidence from acknowledgement
Record the time, contact role, method and observed result of each attempt. Avoid treating a sent message, ringing call or voicemail as evidence that the recipient accepted the action. Where acknowledgement occurs through a separate system, preserve the reference and time. The record should let another person understand which decision remains unresolved.
Keep personal contact details and any sensitive message content in the approved operational system. A general review worksheet can use role aliases and outcome references. Do not copy a private contact list into every incident attachment. The plan should help people find the current controlled record, especially when a rota changes, without creating many stale copies that appear equally authoritative.
Decide what happens when the fallback is also unavailable
Exhausting the contact list is not the same as resolving the event. Agree the authorized next step, who owns the unresolved condition and how it is handed over. The action may depend on the observed situation and local procedure. Do not invent emergency dispatch authority, attendance guarantees or permission to take an action that the site has not granted.
Test the branch in an announced exercise with the relevant participants. Include a contact who answers but cannot accept the decision, because availability and authority are different. Review whether the handover record makes the open duty clear. Update the plan after the test and ensure the people relying on it know the current version and effective period.
A fictional incident with an unavailable duty manager
A reviewer sees unconfirmed activity on a restricted approach and calls the duty manager under the agreed plan. The call is unanswered. The next accepted role answers but cannot confirm the activity, so the reviewer records both outcomes and follows the authorized fallback. The record does not state that the site was notified and resolved simply because someone answered a call.
At morning handover, the open question has an owner and a clear evidence reference. The business reviews why the primary role was unavailable and whether the fallback authority was appropriate. That review may lead to a rota or scope change, followed by another test. The value of the plan is that uncertainty and ownership remain visible when the preferred path fails.
Make the call
When the first handoff fails
| Situation | Decision to make | What to ask for |
|---|---|---|
| The primary call is unanswered | Which retry or alternative channel applies | A contract-defined rule and attempt record |
| The backup also fails | Who owns escalation beyond the routine path | A named final decision role |
| A message is delivered but unread | Whether acknowledgement has occurred | The agreed affirmative response |
Before you move on
- Define an acknowledgement that counts.
- Approve retries, backups and permitted fallback actions.
- Test the full path and correct unreachable roles.
A worksheet you can actually use
Start with the blank sheet. Add one row per item, assign an owner and mark anything unresolved as pending. The completed example shows the level of detail to aim for.
Keep completed security plans private. Use aliases; keep passwords, access codes, personal contacts and footage links in your approved systems.
How to fill the worksheet
- Incident category
- Group incidents by the decision they need so a technical fault does not automatically follow the same path as uncertain activity.
- First role
- Identify the primary role with accepted authority for the location and period, not merely the first phone number listed.
- Retry rule
- Use the site's agreed attempt method and timing. This template does not prescribe a universal number of retries.
- Backup
- Name the accepted fallback and confirm that it can make the relevant decision when the primary role is unavailable.
- Final owner
- Keep an owner for the unresolved condition after the preferred path fails; exhausting the list is not incident resolution.
- Exercise result
- Record the announced exercise and observed acceptance, including any authority gap revealed when a person answered.
A worked example
Fictional exercise: the duty manager is deliberately unavailable. The deputy receives the test incident but does not acknowledge; the test remains failed until the ownership step works.
| Incident category | First role | Retry rule | Backup | Final owner | Exercise result |
|---|---|---|---|---|---|
| Gate exception | Duty manager | Contract-defined | Deputy | Operations lead | Pending |
Questions readers bring to this task
What else should you know?
Should the provider call police if nobody answers?
Only under the locally approved conditions and permitted scope. Do not use an unavailable routine contact as a blanket dispatch instruction. Have the responsible parties agree the emergency and authority-notification procedure separately.
Link to this answer ↗How many times should the reviewer retry?
Use the attempts and timing agreed for the site's duty and service rather than a generic number from an article. The plan should balance the relevant urgency, available methods and fallback roles. Record actual attempts and do not assume more retries establish a better response.
Link to this answer ↗Is voicemail enough to transfer responsibility?
Not unless the accepted procedure explicitly defines a supported handoff and the relevant evidence demonstrates it. Usually a voicemail records an attempt, not an acknowledged decision. Keep the duty open according to the agreed plan until ownership or another authorized completion condition is established.
Link to this answer ↗What if nobody can be reached?
Follow the written fallback for that condition and preserve the unresolved duty for the accepted owner or handover. If the site has no workable fallback, identify that gap during planning. A monitoring provider cannot create local authority or a guaranteed response that has not been arranged.
Link to this answer ↗Notes & sources
This article supplies no universal retry interval or emergency policy. These must be agreed for the location and service.
Reviewed October 27, 2026. The examples and worksheets are planning aids, not customer results or a statement of contracted service.
- MonitorCrew: service scope and pricing factors
Provider description of staffing, hours, handovers and scope. No comparative testing is claimed.
- CFPA Europe: Keyholder selections and duties (2024)
Role selection and response planning context. Local requirements and safety arrangements take precedence.
- Private Security Authority: monitoring centre training requirements (2018)
Historical operational handover context; local licensing requirements need separate review.