Skip to main content

Supervision & Escalation

Supervision turns a monitored condition into a staged escalation ladder: "when this condition has held for T, do X; if it is still unresolved at T₂, do Y." A single engine drives five supervision conditions, each authored the same way:

ConditionWatches forClock starts atSubjectClears when
Hub offlineA hub that stays offlineThe moment it went offlineThe hubThe hub is genuinely back online
Open / close (late to close)A site still open (disarmed) past its scheduled close, or open outside its operating hoursThe site's scheduled close timeThe siteThe site arms, or re-enters its operating hours
Expected signal / FTTAn alarm communicator that misses its expected check-in (no signal of any kind / "failed to test")The moment its expected check-in window is missed (the window is set in the editor, default 24 h)The device (hub)The device reports again
Unresolved fault (Trouble)A trouble/fault (low battery, AC-power loss, siren trouble…) that stays unresolvedThe moment the fault was raisedThe faultThe fault restores
Camera issue (video loss)An opted-in camera whose stream stays faulty (Issue detected — login failed, blank frames, stuck stream — or Device Offline)The moment the fault was first seen — stage 1's delay is the confirmation window, so short hiccups never surfaceThe camera (stream)The stream has been healthy again for 15 minutes

For Hub offline, CleverCam already raises the standard E350 "Communication lost" event immediately — that is unchanged and remains the baseline alert. The escalation ladder adds follow-up actions that fire as the condition persists, so a long-running problem isn't a single notification that scrolls away. The ladder tracks the hub's actual state, not the event: it keeps escalating even after the original offline event has been closed away by queue housekeeping, and only stops when the hub is genuinely back online — which is what makes long stages (a weekly reminder) work.

Off until you set it up

There is no default ladder and nothing active out of the box — for Hub offline or any other condition. Each condition is a blank slate: open the editor, click Use suggested ladder for a sensible starter (or add stages yourself), then switch Ladder enabled on. Until an enabled ladder exists for a condition, nothing extra happens — that condition behaves exactly as before. The editor lives under Settings → Alarm Handling, which is available on control rooms running Advanced Alarm Handling, so any admin there can set a ladder up.

Camera issue is the one exception on wiring: even with an enabled ladder, a camera participates only when its Health monitoring toggle is switched on in the camera editor (site Hardware tab) — it is opt-in per camera, so nothing fires until you turn a stream on.

Where it lives​

Settings → Alarm Handling → Action plans — in the Power / comms group, the Offline escalation ladder row (shown on every "Editing plans for" tab — Classic, Residential, Business, Continuous-movement — because it is one VCR-wide ladder shared by all Site Modes, not a per-Mode setting). Click Edit plan on that row to expand the ladder editor.

The same editor is also available per site: on the site's Action plan overrides panel, the Offline escalation ladder group at the bottom opens the editor pinned to that site's override.

Pick the supervision condition from the tab strip at the top of the editor. All five are listed, and each tab shows the state of its ladder at a glance: a green dot means it is live, amber means stages are saved but the ladder is switched off, and a hollow dot means nothing is configured yet. The number beside the name is how many stages that ladder holds. Each condition is configured independently — a Hub-offline ladder and an Open/close ladder don't affect each other.

The editor has two scopes, chosen with the toggle:

  • VCR default — the ladder that applies to every site this VCR monitors (for the selected condition).
  • Per-site override — pick a site; its ladder fully replaces the VCR default for that site (most-specific wins, the same override convention as Operator Checklists). When a site has no override, the VCR default applies.

Building a ladder​

  1. Choose the supervision condition from the tab strip (Hub offline, Expected signal / FTT, Open / close, Unresolved fault, or Camera issue).
  2. Choose the scope (VCR default, or Per-site override + a site).
  3. Make sure the switch at the top right reads Live (Paused keeps the stages saved but stops them firing).
  4. Click Add a stage (or Use the suggested ladder for a sensible starter), then for each stage set:
    • Fires after — how long the condition must have held before this stage fires (a number plus a minutes / hours / days unit, in one field), measured from the condition's clock start (see the table above). For Expected signal / FTT first set the Expected check-in window (hours) field; stage delays then count from the moment that window is missed, so a 0 stage fires as soon as the device is late.
    • Then repeats — Doesn't repeat means the stage fires once per occurrence; Every day / Every week / Every 2 weeks / Every 30 days re-fires the stage on that interval for as long as the condition persists — the "still offline — weekly reminder" pattern. A ladder saved with some other interval keeps it, and the picker shows it as-is.
    • Action — what happens (see below). The Routes to column beside it is filled in for you and colour-coded, so you can scan a ladder for where each stage lands without opening anything.
    • Event code — shown for the Control-room event and Phone the client actions; the CID to raise (defaults to a code that suits the condition — E350 for hub offline, CQUIET "No test signal" for expected signal, E455 "Schedule Failed" for open/close, E750 "Video loss" for camera issue). Raising CQUIET also sends the site's app users a 🕐 "No test signal" push.
    • More options — everything specific to the chosen action folds into a drawer under the stage: the accountability toggles for Phone the client (Require a different operator, Require a different shift, Allow dispatch on no answer — see Failed-to-Test; stage 2 and later require a different operator by default), the channel chips and message/email fields for Message the client, the job priority for Service Ops, and an optional Stage name on any action. Whatever is switched on stays visible as a chip on the closed stage.
  5. Reorder stages with the ↑ / ↓ buttons, remove one with its Remove button.
  6. Click Save ladder — it stays disabled until you have actually changed something, and Discard puts the ladder back to what was last saved. Delete ladder removes the whole ladder for the current condition + scope (the other scope, if any, still applies).

Two things read the ladder back to you as you build it. Above the stages, a summary line gives the shape of the whole ladder — how many stages, when the first one fires, whether anything repeats, and how many stages reach an operator (a ladder where that says never only files paperwork). Under each stage, a sentence spells out exactly what it will do: "24 hours after the hub goes offline, file a management review item, then again every week until it clears." The stages themselves run down a time rail marked with each stage's offset (T+24h, T+48h, T+1w), with a ↻ on any stage that repeats.

The tick that drives every ladder runs about once a minute, so a stage fires within roughly a minute of its delay elapsing. Stages are paced — at most one stage fires per subject per minute, never several in the same instant. And when a ladder is enabled for a condition that has already persisted a long time (say a hub that has been offline for weeks), the engine doesn't replay the whole ladder: the earlier stages are recorded as skipped, and only the most severe stage that is already due actually fires.

Actions & where each stage goes​

Every stage picks a destination — this is how supervision honours "not everything has to land in the control room":

ActionDestinationWhat it does
Control-room eventControl roomRaises a real control-room event with the CID you pick — it routes and alerts operators like any alarm, and is escalation-tagged so it never re-triggers supervision.
Phone the clientOperator stackPuts a call task on the operator stack with a required outcome and the cross-operator accountability rule. Nothing is ever auto-dialled — an operator makes the call. Allow dispatch on no answer (in More options) makes a no answer / voicemail outcome flag the task dispatch-allowed with a prompt; the operator still initiates any dispatch.
Management reviewReview queueFiles an item in the management review queue (the offload lane) instead of the live operator queue. Severity rises with the stage (info → warning → urgent).
CRM ticketService OpsFiles one CRM ticket per incident for the technical coordinator to triage — deduped, so recurring stages and flapping conditions reuse the open ticket instead of filing another. Deliberately not auto-closed when the condition clears; a human confirms the fix.
Message the clientClientOne action, four channel chips: App push · WhatsApp · SMS · Email. App push → WhatsApp → SMS runs as a per-person fallback chain — the first channel that delivers stops the chain, and consent + STOP opt-outs are always respected. Email sends in parallel, to the auto-resolved set (site contacts + billing) or to a specific email address typed on the stage. Optional custom message text and email subject/body. WhatsApp sends nothing until the Meta template go-live — the chain simply falls through to SMS.
Service Ops jobService OpsAdds a note to the site and opens a Service Ops job to start the technician follow-up for the device. Optional per-stage job priority.
Silent logSilentRecords the stage in the audit trail with no operator-facing action — useful as an early, low-noise tracking step.

(Older ladders saved with the previous per-channel actions — push to operators, Telegram, email-the-client — keep working exactly as before; they just aren't offered for new stages, and the picker keeps whichever one a saved stage uses selectable in place.)

A typical Hub offline ladder: management review at 24 h and 48 h, then a weekly repeat. A typical Expected signal / FTT ladder raises the "No test signal" event first (queue Trouble + customer push) and then runs three Phone the client stages (see below). The default Camera issue ladder: 1 h raise "Video loss" (queue Trouble) → 24 h CRM ticket → 48 h management review → weekly review while unresolved.

Failed-to-Test (FTT) contact flow​

The Expected signal / FTT condition models the classic failed-to-test contact ladder for alarm communicators (Olarm, HYYP, Ajax, FSK, RDC, FinMon, FOX, Onyyx…). The suggested ladder raises the "No test signal" (CQUIET) event the moment the check-in window is missed — it sleeps as a Trouble in the operator queue and pushes a 🕐 notification to the site's app users — followed by three "Phone the client" stages (1st, 2nd and 3rd FTT), each of which drops a task on the operator stack. An operator phones the client and records the outcome on the task. The system never dials anyone; it only creates the task.

Cross-operator accountability​

So one person can't quietly rubber-stamp every attempt, each "Phone the client" stage carries two toggles:

  • Require a different operator — the operator completing this stage must not be the operator who handled the immediately-previous attempt. On by default for stage 2 and later.
  • Require a different shift — the operator completing this stage must be on a different shift (day/night, in the VCR timezone) than the previous attempt. Off by default; turn it on for the strictest hand-over.

When an operator tries to complete a task that breaks the rule, the completion is blocked with a clear message ("…must be handled by a different operator than the previous attempt"), and the attempt is not recorded. Each completed attempt records who and which shift handled it, so the hand-over is auditable. The accountability is per occurrence — if the device recovers and later fails to test again, the ladder (and its accountability) starts fresh.

Audit trail​

Every client contact is recorded, so there is always proof the client was reached out to:

  • When a Phone the client task fires or an Email the client stage sends, an "Escalated to client" entry is written to the event audit trail (with the channel — phone or email — and the stage). The phone task's entry sits on its event timeline alongside the operator's later "client contacted" outcome.
  • The recorded call attempts (who, which shift, the outcome) live on the supervision occurrence and on the event timeline.

(Note: the Service Ops — note + job action is a service escalation, not a client one — it leaves its own audit as the site note + the new service job.)

Works for any condition

The accountability toggles and the three contact actions (phone / email / Service Ops) are general — you can use them on any of the four conditions. The sensible defaults are tuned for Expected signal / FTT.

How each condition is detected​

The engine derives every condition from data the platform already keeps — it does not add new alarm-path processing:

  • Hub offline is anchored to the hub's own online/offline state. The clock starts at the offline transition (the platform's E350, or the hub's last-seen moment), and the subject stays open for as long as the hub is offline — even after the original E350 has been closed by the 48-hour event housekeeping. Receiver-created panels that aren't linked hubs (e.g. FOX/VHF log-ingest panels) are tracked through their offline event on the site.
  • Open / close reads the site's operating hours (from the site's schedule) and its live arm state — a site that is disarmed when its schedule says it should be closed is the exception. Early-open and out-of-hours opens are caught the same way.
  • Expected signal / FTT watches every linked alarm communicator hub and compares its most recent liveness timestamp (any check-in, heartbeat or sync) against the ladder's expected check-in window. A hub that has never reported at all is skipped (a fresh installation is not a missed check-in), and a hub that already has an active offline (E350) event is handled by the Hub-offline ladder instead — a device never escalates under both at once. Because it fires on silence — before any offline event exists — it catches a dead radio 24–48 h sooner than the heartbeat-timeout backstop. The two are different paths: a Hub offline (E350) is the communicator or its cloud telling us it went dark, handled as an ordinary alarm-type event — it sleeps through the hold window set on the Hub / device offline Action Plan (default 10 min) before it reaches the verification stack, and its R350 closes it; Expected signal / FTT fires on silence and only ever runs this ladder.
  • Unresolved fault watches the trouble signals (low battery, AC-power loss, siren trouble and similar) that surface on the CleverCommand Trouble board — escalating one that nobody clears.
  • Camera issue watches the live stream status the hub already reports for every camera (Issue detected with its specific cause — camera login failed, blank frames, stuck stream — or Device Offline), for streams whose Health monitoring toggle is on. The clock starts when the fault is first seen, so stage 1's delay is the confirmation window — the hub's own retry/recovery gets a chance first, and short RTSP hiccups or reboots never reach the control room. The raised event carries the specific cause (e.g. "Front Gate — has lost video (Camera login failed)"). Anti-noise rules are built in: a camera on an offline hub is the Hub-offline ladder's problem (this ladder freezes rather than double-firing); recovery must hold 15 minutes before the incident resolves; and a re-fail within 60 minutes of recovering resumes the same incident instead of raising a fresh event. On a genuine recovery, an R750 "Video restored" lands in the site timeline, paired to the original event per camera.

What the operator sees​

Stages that target the control room appear in CleverCommand: a Raise an event stage shows up as a fresh event in the queue, Push to operators notifies on-app team members, and Telegram posts to the VCR chat. Management — review item stages go to the management review queue rather than the live queue. See Hub Status for the operator side.

Watching it run​

Review Queue → Escalations is the live view of the engine: every open escalation subject with how long the condition has held, its ladder progress (e.g. stage 2 of 3 · 2 fired), the per-stage firing timeline (including catch-up skips), and the failed-to-test phone-attempt log. A toggle shows subjects cleared in the last 7 days. The engine itself is watchdogged — if the supervision tick stops completing, an urgent "Supervision engine stalled" item is filed automatically (and auto-resolves on recovery).

When the ladder stops​

The ladder stops as soon as the condition clears (see the Clears when column above), and the escalation's own artefacts are tidied up automatically: any control-room events or "Phone the client" tasks the ladder raised for that subject are closed with an "Escalation auto-closed — the supervised condition resolved" audit entry, so nothing stale lingers in the operator queue after a hub recovers.

A "Phone the client" task carries a mandatory call-outcome item, and a mandatory item normally has to be answered before the event can be completed. When the condition resolves before anyone got to the call, that obligation is lifted with it: the item is marked Released with an "Outstanding tasks released" entry on the event, and the event completes normally. The row stays visible and still tickable — release records that the task stopped being required, not that it was done — so if an operator did speak to the client they can still put that on the record. An item that was already answered is never touched; the operator's outcome stands.

note

Release is what stops a recovered condition leaving an un-closeable card behind. Before 29 August 2026 the event was deactivated but the mandatory item stayed binding, so an operator who had opened the card could neither answer it (the call was moot) nor complete the event, and it sat in the queue until the seven-day sweep. If you see an old card in that state, recording any call outcome on it still clears it.

Each non-repeating stage fires at most once per occurrence (repeating stages re-fire on their interval); if the same condition recurs later, the ladder starts fresh.