Skip to main content

Review Queue

The Review Queue is where the CleverCam Brain hands work up to a manager. As the control room runs — operators handling events, vehicles rolling, the Brain routing alarms — patterns emerge that don't belong on any single operator's event timeline but do need a person to look at: a site that keeps dispatching, a keyholder who never answers, a recurring fault, an open/close exception, a detection pattern firing over and over. The Review Queue collects all of it in one place, with the evidence, a suggested action, and one-click ways to resolve it.

It is a top-level command center in its own right — its own nav item, directly above Performance & Reports — and it carries a live badge showing how many items are open right now, so a manager sees the workload without opening the page.

Accessing the Review Queue​

  1. Click Review Queue in the sidebar (in the More group, just above Performance & Reports).
  2. The item shows a red count badge whenever there are open items — unresolved items that aren't currently snoozed, plus burglary cases not yet signed off. The badge stays live across the whole app, so resolving or snoozing an item anywhere updates it immediately.
  3. The page opens on the Overview dashboard. Seven sub-tabs sit across the top:
    • Overview — an at-a-glance read of the queue (see below).
    • Queue — the management inbox itself.
    • Escalations — the live view of the Supervision & Escalation engine: every condition currently escalating (hub offline, failed-to-test, open/close, unresolved faults, camera issues), how long it has held, how far up its ladder it is (as ladder-progress dots), the per-stage firing timeline, and the failed-to-test phone-attempt log (who called, on which shift, and the outcome). The hero shows the open count with one chip per escalation kind — click a chip to filter to that kind. Read-only — the ladder clears itself when the condition resolves; a toggle also shows subjects cleared in the last 7 days.
    • Burglaries — confirmed-burglary casework, with a Live cases / Vault view switch: the working queue of cases in progress, and the permanent archive of every case ever signed off. See Burglaries queue and Burglary Vault.
    • Costliest clients — the operational-cost ranking behind the cost items. See Costliest clients.
    • Pattern detection — the VCR-level SOP-default and cluster-threshold policy behind the recurring-pattern items. This is the same editor documented under Settings → Pattern Detection.
    • Response SLAs — per-event response-time targets.
Advanced Alarm Handling module

The Review Queue is part of the Advanced Alarm Handling module. If a VCR does not have that module enabled, the nav item is hidden and the page is not reachable — the same gate as the Performance & Reports page.

The Overview dashboard​

The Overview is the landing view — every figure is a shortcut into the tab that works it.

  • Awaiting review — open items (matches the nav badge), the impact in queue (their modelled rand cost), reviewed this week, the oldest unreviewed item's age, how many are snoozed, and your costliest client by 90-day modelled cost.
  • Impact by category — open items grouped into manager-facing categories (operational cost, contactability, faults, recurring patterns, open/close), weighted by rand impact so the expensive problems rise to the top.
  • Review throughput — an 8-week trend of how many items you've resolved.
  • Queue age — how long open items have been waiting.
  • Costliest clients — the top sites by 90-day modelled operational cost, linking through to the full ranking.

The command center​

The Queue tab is built around a summary hero, a faceted toolbar, and the queue table.

Clava's briefing (the hero)​

The hero speaks as Clava — the same persona whose Mode gates the detectors and whose name customers already know from the auto-reply agent. Next to a large open count (green All clear at zero), Clava gives a short briefing built strictly from the queue's real numbers, never generated fiction:

  • A greeting and the state of the queue: "Good afternoon. 13 items need review (2 urgent) — about R8 821 in modelled waste."
  • Her recommendation — the single item she'd start with (the top of the queue's own severity-then-impact order) with its suggested action: "I'd start with 'Wrong password x4 on alarm responses' at Site 2 — Phone the customer on a known-good number…"
  • A muted meta line: how many items are snoozed and resolved, and the age of the oldest open item (e.g. oldest 3d).
  • A row of severity chips on the right — Urgent, Warning, Info — each with a live count. Click a chip to filter the queue to that severity; click it again to clear.

Filtering​

Three faceted controls narrow the queue. They compose — status, then category, then severity, then search — and a Clear filters button appears whenever any facet is active.

  • Status switch — a segmented control with Active (default — open items), Snoozed, Resolved, and All. The category and severity counts are always calculated within the status view you're looking at, so they never mislead.

  • Category pills — one pill per category actually present, each with a count, most-populated first, plus All. Categories group the Brain's raw item kinds into what a manager cares about:

    CategoryWhat it flags
    FaultsTechnical faults raised from live event handling (e.g. sensor/battery/supervision faults).
    CostSites dispatching far more than their peers — an operational-cost prompt.
    ContactabilityVehicles rolled without reaching a customer or keyholder, or a contact who rarely answers.
    Open / CloseOpen/close (arm/disarm) exceptions — e.g. a site late to close.
    PatternsA detection pattern that has matched the same site repeatedly.
    SupervisionHub-offline / supervision escalations that stayed unresolved.
    VerificationKeyholder-verification exceptions — e.g. a wrong password entered on an event challenge.

    The pills are self-maintaining: a brand-new detector added to the Brain gets its own pill and count automatically (falling back to Other until it's categorised).

  • Search — free-text over the item title, site name, description, and category.

Next to the status switch, a By site / Flat segmented control chooses the table's shape (see below). Typing in the search box always shows the flat list — a text match on two of a site's five items shouldn't hide behind a collapsed group — so the control disarms while a search is active.

Grouped by site (the default view)​

By default the queue folds into one expandable row per site, because items cluster on sites in practice and the unit of managerial action is the site: five fault items on one site are one problem ("this site has chronic faults"), and a site carrying cost, contactability and open/close items at once reads as "this is a problem client" — an insight the flat list hides.

Each group header carries:

  • the site name (linking to the site's page) and the number of items in the group,
  • the group's worst severity as a chip and the row's coloured left edge,
  • category chips showing what kinds of problems the site has (with a count per kind, e.g. Faults ×5),
  • the summed modelled impact of the site's open items and the age of its oldest open item,
  • a Resolve all button that closes every open item in the group with the default No action reason. It's a two-click control — the first click arms it ("Resolve 4 items?"), the second fires — so a stray click can't clear a site.

Click a header (or press Enter/Space on it) to expand the group and work its items exactly as in the flat list — every item keeps its own Resolve, Snooze and expanded detail. Groups sort by the same severity → impact → newest rule as the items themselves, so the top group always contains the item Clava's briefing recommends starting with. When only one group exists it starts expanded.

Items that aren't tied to a single site (for example an area-wide outage rollup) collect in a Fleet-wide group so they can never fall out of the grouped view. The category and severity filters keep the grouping — a group then shows only its matching items, and its header counts describe that subset. Prefer the old presentation? Switch the toolbar control to Flat.

The queue table​

Each row shows the severity (with a coloured left edge on the row for instant triage), the category (icon + label), the title, the site, when it was created (a relative age like 2d ago; hover for the exact timestamp), the suggested action, the modelled impact in Rand (hover for the arithmetic), a status pill, and — on unresolved rows — a trailing actions column with one-click Resolve and Snooze buttons. Rows are keyboard-operable: Enter or Space expands a focused row, and the action buttons can be tabbed to and pressed without touching the mouse. Rows sort with unresolved first, then by severity (urgent → warning → info), then by impact (most expensive first; unpriced items after priced ones), then newest — so money ranks within a severity band, and an urgent security item never sinks below an expensive info item.

Every item carries a Rand price​

The Brain prices each item's evidence with the same cost model behind Costliest clients: counts × unit costs. Dispatch-priced items (Cost, Contactability, over-dispatch) use this control room's measured average dispatch cost — reaction labour plus transport aggregated nightly from its real dispatches over the last 90 days — falling back to the model default (reaction minutes × officer rate) until measured data exists. Operator-time items (patterns, faults, wrong password) use the model's per-event and per-call seconds.

The hero shows the total: "≈ R8 821 modelled waste" across open items. The expanded row shows the arithmetic — "R5 365.79 — 19 × no-contact dispatch @ R282.41 (this control room's measured 90-day dispatch cost)" — so the number is auditable, not oracular. Prices update automatically as an item's counts grow, and the rates are tuned in Settings → Cost model (under Operations).

Any item that has recurred shows an occurrence count next to its title (· 4x · last 2h ago); a one-off stays quiet. Recurring-pattern rows additionally carry a pattern-type chip (e.g. Alarm after power-fail, Chronic no-answer), and a red Re-surfaced chip appears when the daily cron has woken a snoozed row back up because the pattern kept firing.

Repeats fold into one item​

The queue tracks problems, not events. When the same signal recurs — the clearest example is a wrong password from the same keyholder at the same site — the queue does not stack a new row per event. Instead one item per (control room, site, keyholder) absorbs each occurrence: its count goes up, its severity escalates (info on the first occurrence, warning at 3, urgent at 5), and the event is appended to an Occurrences timeline in the item's detail view. A single wrong password is visible but quiet — a typo and coercion look identical by design, so the first one is never hidden — while a repeat pattern climbs the queue on its own.

Three rules keep the counting honest:

  • Replays never double-count. Each occurrence is deduplicated by its event, so a retried webhook or a second delivery of the same signal changes nothing.
  • Resolved history stays closed. Resolving an item ends it; the next occurrence opens a fresh item at info ×1 rather than reviving old history.
  • Quiet items close themselves. The nightly job auto-resolves an open, un-snoozed pattern item (wrong password / recurring patterns) with no occurrence in 30 days as pattern_stopped — the active queue only ever shows live problems, and the resolved view keeps the record.

All of these numbers — the escalation counts, each pattern's threshold and window, and the quiet-close period — are per-control-room settings with a live preview, on the Pattern detection tab. The values above are the shipped defaults.

Actioning an item​

Click any row to expand it. The detail strip shows the full description, the originating event id (when set), an Occurrences timeline on aggregated items (one line per event: time, event id, channel), and the evidence — the figures that made the detector fire, laid out as labelled values, with the raw payload behind a Raw evidence disclosure — plus the action controls appropriate to that item.

The site name on every row links straight through to that site's page.

One-click actions: Log technical ticket / Request call-back​

Every open item has a Take action section with two buttons that turn the suggested action into real work, prefilled from the item's evidence:

  • Log technical ticket files a ticket on the Tickets board (category Task, domain Technical) with the item's description, suggested action, occurrence count and a back-reference to the item and event.
  • Request call-back files a Follow up ticket due in 4 hours, with the keyholder's name and number prefilled where known — a ready-made call task for whoever works the ticket queue.

Filing is idempotent: while the ticket is live, the buttons are replaced by a chip showing Ticket #N — open (or promoted to a job, with a link to the job). Clicking again can never create a duplicate.

The loop closes itself. When the ticket is marked Done, the review item auto-resolves as ticket_resolved. If the office promotes the ticket to a service job instead, the item keeps tracking the job and auto-resolves as job_completed when the job completes. If the ticket is dismissed or archived without being done, the item stays open and the buttons re-arm. Nobody has to remember to come back and close the review item — finishing the work finishes it.

Jobs are never created directly from the queue: promote the ticket from the Tickets board as usual, so jobs keep one creation path.

Resolve​

The Resolve button in the row's trailing actions column closes the item in one click, recording a No action resolution — the fast path for items that just needed eyes on them. For any other outcome, expand the row: the resolution form has a Resolution dropdown (SOP changed, Service call booked, Contact updated, No action), an optional note of up to 1000 characters, and Mark resolved. Either way, resolving stamps who resolved it, when and why, clears any snooze, and moves the item to the resolved view. An item can only be resolved once — a second attempt reports that it is already resolved rather than overwriting the first resolution.

Snooze​

Every unresolved item has a Snooze button in the row's trailing actions column (next to Resolve). The snooze modal offers a duration (7 / 14 / 30 days, Until resolved, or a custom date, which must be in the future), an optional reason for the audit trail, and a preview of the resulting local time. Snoozed items drop out of the Active view until they elapse — or until the nightly fn_review_snoozes job (00:30 UTC) resurfaces them because the underlying pattern fired again during the snooze window (that's the red Re-surfaced chip).

Time-zone handling

Custom snooze dates are entered in your local time and stored as UTC; the modal's preview line echoes the local time so you can verify before saving.

Resolve with a SOP variant (pattern items)​

When a recurring-pattern item is open and you pick SOP changed, the form reveals a variant picker for that pattern. Choose the new branch (e.g. Auto-resolve when delta matches, Skip chronic contact), optionally set an expiry, and — for high-risk variants — tick Client confirmation captured. Apply variant + resolve calls the fn_apply_sop_variant RPC, which atomically writes a new active override on the site's Site SOP panel, supersedes any prior override for that pattern, closes the item, and back-fills the link so the SOP History panel can point back to this item.

After the variant applies, a Let the customer know dialog opens (on VCRs with the CRM module): a prefilled, plain-language notice describing what now applies at the site — e.g. "If an alarm is received and none of your listed contacts can be reached, the alarm will be logged and closed without a response call-out". The message is fully editable; pick email and/or WhatsApp/SMS recipients (saved customer contacts or typed numbers), optionally include a secure 30-day link to the customer portal, and Send notice. Closing the dialog skips the notice — the variant is already applied either way. Every send is recorded on the customer's CRM activity timeline.

Message customer — the diplomatic heads-up​

Every open item on a site (on VCRs with the CRM module) also carries a Message customer section with a Send a heads-up button. It opens the same dialog in warning mode: a prefilled, deliberately diplomatic note that describes the recurring issue in customer terms (never in control-room cost terms), asks for the customer's help resolving it, and mentions that handling may have to be adjusted if the pattern continues — for pattern items it names the next step of that pattern's variant ladder as the example (e.g. "…for example: logging and closing alarms without a response call-out when none of your contacts can be reached"). Edit the wording freely, pick recipients, and send by email and/or WhatsApp (SMS fallback), optionally with the customer-portal link. The send is logged to the customer's CRM activity timeline with a back-reference to the review item; the item itself stays open — the heads-up is a nudge, not a resolution.

Delivery respects the messaging consent rails: texts only go out when the control room's customer texting is enabled by CleverCam, and a recipient who has replied STOP is never messaged.

Tighten a site (cost / contactability items)​

Cost and contactability items carry an extra Tighten this site control: pick an alarm (burglary, panic, ac_mains, hub_offline, tamper) and a preset — Require keyholder call, no auto-dispatch, Route to review queue, or Log a ticket — then Apply & resolve. This writes a one-click per-site Action Plan override (via fn_apply_site_tightening) and resolves the item in the same action. It's a shortcut for the same override you can edit by hand on the Site SOP panel.

Paging​

The queue loads the 100 newest items at a time. When there are more, a line under the table reads "Showing the 100 newest of 240 items" with a Load more button. The hero counts, category pills and severity chips describe what has been loaded, which is why that line is always visible rather than hidden behind a scroll.

Realtime​

The queue subscribes to inserts and updates for the current VCR, so new items appear at the top without a refresh and the nightly auto-resurface flows through live (the status chip flips and the red Re-surfaced badge appears). A self-update guard stops your own actions being applied twice from realtime echoes.

Below the queue, a secondary panel summarises over-dispatch consent captured this calendar month — how many consent prompts were raised before a vehicle was rolled without a verified event, how many were authorized vs not obtained, and the top channel used (operator attestation, manual call, WhatsApp, etc.). It's supporting governance context rather than a headline, which is why it sits under the queue.

When the queue is empty, Clava still reports​

A caught-up queue isn't a blank table. Clava's all-clear states what she did with real numbers from the last 7 days — "All clear. 3 items were resolved in the last 7 days — 2 closed themselves when the work finished or the pattern stopped. Nothing needs you right now." A brand-new control room instead gets her introduction: what she watches and what will appear here.

Clava's Monday briefing (weekly digest)​

For managers who don't open the page, Clava can email the same briefing every Monday morning: the state of the queue in items and Rand, the item she'd start with, the top five open items by severity-then-impact with their prices, and last week's raised/resolved counts — every figure computed from the live queue by the same function family that drives the hero, so page and inbox always agree. The email carries the control room's brand colour and a button straight to the Review Queue.

  • Opt-in, off by default. Enable it per control room under Pattern detection → Clava's detectors → Delivery → Clava's Monday briefing. Preview shows exactly what the next briefing would contain and the address it would go to.
  • Recipient is the control room's support email, falling back to the billing email; a room with neither is skipped.
  • No noise: a week with an empty queue and no activity sends nothing at all.

Sites shared between control rooms​

A site can be connected to more than one control room, and an alarm at that site can be worked by more than one at once — one may auto-notify the customer while another phones the keyholder. When a signal arrives that names no particular control room, the most important example being a wrong password entered on an alarm response, the queue raises one item per control room holding that event. Both rooms see it, both can action it, and neither can lose it because the other one was assumed to own it.

This matters more than it sounds. Without it an item like that belongs to nobody: the room that closes the alarm never learns the password was wrong. Each room's copy is its own aggregate — repeats from the same keyholder fold into it per the rules above, and a replayed event never counts twice in any room.

Who can see and action items​

Review items name your clients and describe their weaknesses, so the database only ever returns the items belonging to control rooms you manage. Someone who is not on your team — an app customer, a keyholder, another security company — receives nothing at all, not even an empty page.

Resolving and snoozing are checked the same way on the server: both go through RPCs (fn_resolve_management_event, fn_snooze_management_event) that verify you manage the item's control room before writing anything. If the check fails, the queue stays on screen and tells you why in a banner above it.

Who can action items

Actioning items (resolve, snooze, tighten, variants) requires the Review queue capability or VCR settings. Owners, members who have never been scoped, and operator supervisors hold every capability, so nothing changes for them; a scoped member without the capability — or an operator browsing the queue — sees the controls disabled with a read-only banner. The capability is granted per member under Roles and Permissions.