How to Write a Lone Worker Escalation Procedure (Step-by-Step Guide)

By Syed Muhammad Daud Rizvi — Co-founder of TapOkie Work. Building lone worker visit check-ins and audit-ready monitoring for small teams — without enterprise lock-in.

A lone worker escalation procedure defines who gets notified when a worker misses a check-in, in what order, with what response windows, and when to involve emergency services. It turns an informal 'someone will check' into a documented, consistent chain of action every time.

What is a lone worker escalation procedure?

A lone worker escalation procedure is the written document that defines exactly what happens — and who does what — when a lone worker cannot be confirmed as safe. It is distinct from a missed check-in protocol (which is the in-the-moment manager response) because it is designed in advance, agreed by everyone involved, and applied consistently regardless of which manager is on duty that day.

Done well, an escalation procedure answers three questions before anything goes wrong:

1. Who gets notified, and in what order?
2. How long does each person have to respond before the chain moves to the next step?
3. At what point does the organisation stop trying to resolve it internally and contact emergency services?

If you cannot answer all three questions off the top of your head for your current workforce, you do not yet have a procedure — you have an intention.

Why the distinction matters

The HSE's guidance on lone working makes clear that employers must have arrangements in place to monitor lone workers and respond when something goes wrong. A verbal "someone will check on them" does not constitute an arrangement. It means the response will be inconsistent, slow, or dependent on whoever happens to notice first.

A written procedure matters for two practical reasons beyond compliance. First, it removes ambiguity under pressure — when a manager realises a worker has gone silent, the last thing they need is to be making judgment calls about who to ring and whether it's "bad enough" yet. Second, it creates a record. If an incident does occur, you will need to demonstrate that a reasonable system was in place and followed.

Designing the escalation chain

Step 1: Define the trigger

Your procedure needs a clear, objective trigger — not "if someone feels worried." Common triggers include:

• A worker fails to check in at the agreed session end time
• A session expires without the worker extending or ending it
• An SOS alert is raised from the worker's device
• The primary contact sends an alert and receives no acknowledgement within the defined window

Be specific. "Missed check-in" means different things to different people unless you define it in minutes.

Step 2: Name a primary contact

The primary contact is the first person notified when the trigger fires. This should be a named individual — not a team, not a shared inbox. They need to be:

• Available and reachable during the worker's shift (including out of hours if relevant)
• Familiar with the worker's location and work plan for that session
• Authorised to take the next steps, including calling emergency services if necessary

In practice this is often a line manager or duty manager. The key is that they are contactable, not just nominally responsible.

Step 3: Set an acknowledgement window

Once the primary contact is notified, how long do they have to acknowledge the alert and attempt to reach the worker? A common window is five to ten minutes. This needs to be short enough to matter but realistic given that the contact may be mid-task themselves.

Write it down: "The primary contact has [X] minutes to acknowledge the alert and attempt to contact the worker by phone. If no acknowledgement is received within [X] minutes, the backup contact is notified automatically."

Step 4: Name a backup contact

If the primary does not acknowledge within the window, the chain must move automatically — not wait for someone to notice. The backup contact should be:

• A different person to the primary (not the same manager covering both roles)
• Available during the same shift pattern as the primary is expected to cover
• Briefed on their role and what they are expected to do

This is where many organisations fall down. They name a primary contact and assume that is sufficient. The backup exists precisely because primary contacts are human and sometimes unreachable.

Step 5: Define the emergency services threshold

This is the most important step and the one most frequently left vague. Your procedure should state explicitly: "If the worker has not been confirmed safe within [X] minutes of the initial trigger, and neither the primary nor backup contact has been able to reach them, emergency services are contacted."

Factors that affect this threshold include the nature of the work, the location (urban vs. rural, known to have poor phone signal), and whether the worker is alone in a building, a vehicle, or an open environment. Higher risk = shorter threshold.

Include in this step: who calls emergency services, what information they need to give (last known location, vehicle registration if relevant, employer contact), and whether next of kin should be notified and at what point.

Out-of-hours cover

Out-of-hours lone working is where escalation procedures most commonly fail. If your normal duty manager is not available at 7pm or on a Saturday, the procedure cannot simply say "contact the duty manager." It needs to name who covers out of hours and confirm that person knows they are the named backup.

Document this by shift pattern or time window. Some organisations use a rota; others use a dedicated out-of-hours number. Either works — what does not work is assuming someone will figure it out.

Documenting decisions and outcomes

Every activation of the escalation procedure should generate a written record, even if it resolves quickly with a false alarm. Record at minimum:

• Date and time of the trigger
• Name of the worker and their last known location
• Who was notified and at what time
• What contact was attempted and the outcome
• Time the worker was confirmed safe, or if emergency services were involved
• Any follow-up actions

This documentation serves two purposes: it demonstrates your system is being used correctly, and it surfaces patterns (e.g., a particular site repeatedly triggering false alarms) that should prompt a review of your risk assessment or session settings.

Where monitoring technology fits in

A written escalation procedure is the governance layer. It defines the rules. But the procedure only works in practice if the monitoring system can execute the first steps automatically — alerting the primary contact, waiting for acknowledgement, and escalating to the backup if the primary does not respond.

TapOkie Work is built around this workflow. Managers receive push and email alerts when a worker's session expires or an SOS is raised. If the primary contact does not acknowledge, the system escalates to a designated backup contact. The worker's location is captured at session start and at any SOS event, giving responders the information they need without requiring continuous GPS tracking.

A system like this does not replace your written procedure — it operationalises it. The procedure tells people what to decide; the software handles the notification chain so decisions can be made quickly. See the features overview or pricing if you are evaluating options.

Reviewing and testing the procedure

A procedure that has never been tested is a procedure you cannot rely on. Build in an annual review at minimum, and a practical test — either a tabletop exercise or a planned drill — at least once a year. Check that named contacts are still in post, that out-of-hours rotas are current, and that the defined response windows are realistic based on actual experience.

Update the document whenever staffing changes, working patterns change, or a new site or task type is introduced.

Summary checklist

Before signing off your lone worker escalation procedure, confirm it covers:

• A specific, objective trigger definition
• A named primary contact who is available during working hours
• A defined acknowledgement window (in minutes, not "promptly")
• A named backup contact who is different to the primary
• An explicit threshold for contacting emergency services
• Out-of-hours cover named by shift or time window
• A record-keeping requirement for every activation
• A review date and test schedule

If any of these are missing, the procedure has a gap that will surface at exactly the wrong moment.

Related reading

• What to do when a lone worker misses a check-in
• How to write a lone worker policy
• Lone worker false alarms and session warnings
• Out-of-hours lone worker monitoring