Skip to main content

The CleverResponder App

CleverResponder is the field companion app for armed-response officers, patrol drivers, and security guards — the people dispatched to a site once an event has been verified. It is a separate app from CleverAlert (which end users and clients use) and is not self-registered: a responder's access is entirely provisioned from CleverOps by a control-room admin, as described in Responders. There are no fees to the responder — the app is provided to them through their security company.

Signing In​

A responder does not create their own account. There are two ways in, and the app offers both.

One-time code (the default)​

  1. A control-room admin generates a 4-digit one-time code for the responder from the Response → Responders page in CleverOps (see Mobile Login for Responders).
  2. The responder opens CleverResponder and types the 4 digits. Nothing else is asked for — no mobile number, no username.
  3. The code expires 15 minutes after it is generated and is consumed the first time it is used, so it needs to be passed to the responder promptly and cannot be re-used or shared afterwards.
Too many wrong codes

The sign-in door limits how many wrong codes it will accept from one connection in a short window — a protection against someone guessing at the 4-digit code. A responder who types the code they were given signs in normally; the limit only bites after several failed attempts in a row, and it clears itself after 15 minutes. The limit is counted per network connection, so wrong codes typed on one network do not lock out a responder signing in from a different one — their own phone on mobile data, for example. If it does trip, the app says "Too many attempts. Wait a few minutes, then ask control room for a fresh code."

Email and password​

Anyone who holds a real CleverOps account can sign in with it directly — "Sign in with email and password" on the sign-in screen. This is the door for people who aren't crew: an owner, a fleet manager, an office manager taking a vehicle for an afternoon. They get Drive and, if it's ticked for them, Fleet — not the dispatch dashboard, which belongs to crews on shift.

Nothing is provisioned for this: it authenticates against the person's own account, so there is no code to issue and no credential stored in the app. What the account does need is a person record on the workspace, with either of:

  • CleverResponder granted on that record, or
  • a fleet entitlement for that workspace — the Manage fleet & assets capability as a company member, or Fleet ticked on the record itself. Drive and Fleet live inside this app, so a fleet manager or owner is let in for those without being made a responder. They get no unit and no Start Shift — there is nothing to dispatch them to.

A record that has neither is not enough on its own — the sign-in is refused and the account is signed straight back out, naming the tick that is missing.

The person record is the part that can't be skipped either way. Everything in the app hangs off it, and signing a vehicle out is recorded against it, so a company member who has none is still turned away until somebody creates one — which ticking the Responder role does.

This is the same rule the one-time code has always applied, and it is checked on both doors as of August 2026. Until then the email door only asked whether a person record existed at all, so a control-room operator or an office member could open the responder app without ever having been given it.

An office manager borrowing a bakkie for an afternoon is the case worth being clear about: unless they are a fleet manager, they need the Responder or Fleet role ticked. That is deliberate — it is what puts their name on the vehicle record.

A refusal is distinguished from a failed check: if the app can't reach the server to ask, it says so and invites a retry rather than claiming the account has no access.

Taking access away​

A sign-in lasts for days, so the grant is re-checked while the app is open — when it comes back to the foreground, on the pre-shift screen and on the dispatch dashboard. Untick the Responder role for somebody who is already signed in and it reaches their phone within about a minute, instead of waiting for them to sign out on their own.

What happens depends on what they have left:

  • No company left. They are signed out. If they were on shift, the shift is ended server-side first — so the control room stops showing them on duty with a live position — and anything still in the offline outbox is given a last chance to upload before the shift closes, because vehicle checks and fuel logs can only sync while a shift is open.
  • Still granted at another company. They aren't signed out; they're moved to a company they still have, with the shift ended the same way. A relief officer dropped by one company keeps working for the other.

The check is never acted on when it fails. A phone in a dead zone can't answer the question, and being offline is not the same as having access removed — so nothing happens until the app can actually ask. In practice that means a revocation reaches a responder the next time they have signal, and never evicts one mid-dispatch because the bars dropped.

Granting the app is what creates that record: People → the person → Permissions → Roles → Responder. Nothing else to do — the record attaches to the account they already have, so there is no second login and no invite to send. This is the step company owners need, and it is easy to miss: an owner is a company member, not a control-room one, so an owner starts with no person record at all and the app turns them away until the Responder role is ticked for them.

If the person's account isn't attached to their record yet, do that first from the same profile (Email sign-in → Create invite link); a record created by the tick is already attached.

The old login code and PIN is gone​

CleverResponder used to accept a durable login code + 4-digit PIN that never expired. It was removed in August 2026, in the app and on the server. It only rotated when a control-room admin refreshed it, and every person record carried one, which made it a permanent password sitting on a roster.

A phone still running an older build will get "Login codes have been retired — update CleverResponder" rather than a confusing "invalid code". Day-to-day sign-ins are the one-time code above; staff with an account use email and password.

Either way, the responder must have Responder access on their person record (see People). Without it the sign-in is refused with a message telling them to ask control room.

When the responder goes on shift, the app requests location permission. Location is used only while the app is open — to place the responder on the control-room map during a dispatch — and is never tracked continuously in the background.

Working for more than one company​

Some people are on the team at two security companies — a relief officer picking up shifts at both, an owner who also drives for a client company. That's one CleverOps account with a person record in each workspace, and until now the app resolved it to whichever record was created first and stayed there for good, so the other company's units, fleet and dispatches were unreachable.

The company the session is working for is now named under the welcome heading on the pre-shift screen. When the account has CleverResponder granted in more than one company, that line is tappable and opens a Work for sheet listing them, with the active one ticked. Companies where the person has a record but no CleverResponder tick are not listed — the switcher admits exactly who the sign-in admits. Picking another switches to it: the unit card, the Start Shift button and Fleet — the doorway and the vehicles behind it — all re-read against the new company, and dispatch notifications start arriving for it instead of the old one. Someone in only one company sees the name as a plain label with nothing to tap.

Switching is off-shift only. A shift is an open crew row against one person record in one company, and the control room is watching that record's live position — so the switcher is unavailable while on shift. End the shift first; the sheet is then one tap away on the screen it returns to.

Deleting your account​

The pre-shift screen offers Delete account under Log out, but only to someone signed in with email and password. It permanently removes that person's login — the sign-in account and the personal profile — and cannot be undone.

It is deliberately not offered on the one-time code door. That sign-in hands out a session on a roster record the company owns, not an account the responder created, so deleting it would mean deleting a company record on the company's behalf. Removing a responder there is still a control-room action in Responders.

Deleting a login does not erase the work. Shifts, dispatches, trips and vehicle checks already recorded stay with the company as its operational record; the person record simply stops pointing at an account, and CleverOps shows it as unlinked.

An account still holding sites in the CleverAlert app is asked to leave those first (More → Leave site on each), and the shared demo account app-store reviewers use is protected from deletion so the next review still has a working login.

Going On Shift​

After signing in, a responder lands on the pre-shift screen. It shows the unit they belong to (their regular unit, set up in Response Units) and a Start Shift button. Tapping it clocks the responder onto that unit — and because a unit comes online with its first member, starting a shift is also what puts the unit on the control room's dispatch map. Someone who belongs to more than one unit, or is already crewed somewhere by a controller, is asked to choose which unit to go on shift with.

The unit card and the button follow the crew as it changes. A responder who opened the app before the controller put them on a unit does not have to close it: when they are dragged into a unit in CleverCommand, or added to a unit's crew in CleverOps, the unit and Start Shift appear on the screen within a few seconds — and disappear again if they are taken off. The screen also re-checks when the app returns to the foreground, so a change that arrived while the phone was in a pocket is picked up on the way back in.

Ending the shift (or logging out) clocks the responder off. The unit stays online while crew mates are still on it, and goes off duty automatically when the last person leaves. On the CleverOps Units board the difference is visible: a chip with a phone icon clocked on via the app, a chip with a person icon was put on by a controller.

People with no unit at all — owners, fleet managers, office staff — don't see the Start Shift button; they sign in for Drive and Fleet.

Dispatch Dashboard​

Once on shift, a responder lands on their dispatch dashboard, organized into four tabs:

  • Dispatches — active jobs currently assigned to the responder.
  • History — past dispatches and their outcomes. Tapping a completed call-out reopens it for review — see Reviewing a Completed Call-Out.
  • Suburbs — the responder's assigned patrol suburbs, sorted by priority, plus a live feed of emergency alarms happening right now inside those suburbs (see Suburb Watch).
  • Vehicle — the shift's vehicle admin: the vehicle check, ad-hoc checks, fuel logging and the mid-shift handover (see Vehicle Check). It sits last on purpose, so shift paperwork never takes the top of the screen away from live call-outs.

Above the tabs the dashboard shows the responder's unit card — the unit, its vehicle and the crew on board — and, when something captured offline is still queued, a "waiting to sync" indicator.

The dashboard only opens on shift. A controller can crew a responder onto a unit without their shift being started, and that responder still gets the unit's call-outs. A call-out only opens on shift: tapping one of those notifications while not on shift asks You're not on shift — Start your shift to open this call-out, with Start shift and Cancel. There is no way into the call-out without a shift.

  • Start shift starts the shift on the call-out's unit and runs the shift-start vehicle check, exactly as Start Shift on the pre-shift screen does. Then the call-out opens over the dashboard, so leaving it lands on the dashboard.
  • Where the check is mandatory, the unit's live call-out shows on the check as a red strip with Go to dispatch. That is the same strip as after a normal Start Shift, so a crew is never trapped behind the check. A crew who leaves the check that way is asked for it again by the dashboard once the unit has no live call-out.
  • If the shift can't be started (no signal), the prompt says so and offers Try again.
  • Cancel opens nothing.

Before this, the notification went straight into the call-out, and afterwards the crew landed on the dashboard under an ON SHIFT label with no shift behind it. A vehicle check or fuel log done from its Vehicle tab could then never be sent.

Dispatch Alerts: How a New Job Announces Itself​

Every crew member on a unit gets a push notification the moment the control room nominates or dispatches that unit — "New dispatch" — and again when a job is added to the queue behind the one they are on, when a job is reassigned to or away from the unit, and when the controller recalls the unit. The notification goes to whoever is on the unit's crew at that moment and is signed in to the app; tapping it opens the event. A crew member who is on the unit but not on shift is first asked to start their shift (see Dispatch Dashboard).

From version 1.0.6 these alerts sound the dispatch alarm, a siren bundled with the app:

  • On Android the alarm plays whether the app is open, in the background or the phone is locked, and the alert pops up over whatever is on screen. It plays on the phone's alarm volume, not its notification volume, so a phone left on silent or vibrate still sounds. The alarm stops as soon as the responder opens the app, taps the alert, or presses any dispatch button (Accept, Can't respond, Arrived, Complete); otherwise it runs for about 28 seconds (version 1.0.6: sixteen). Version 1.0.7 also made the alarm considerably louder on a phone speaker — the same siren, pitched into the range a phone speaker plays best.
  • On iPhone the alert shows as a banner with the same alarm, app open or not. It follows the phone's ringer switch and Focus settings, like any other notification sound.
  • Which sound an alert gets follows the priority the control room's systems send it with. High-priority alerts — dispatches, and emergencies in the crew's suburbs — sound the alarm. Everything else, the stand-down notice among them, arrives on a separate General channel with the phone's normal notification sound.

Android lists the two as Dispatches and General under Settings → Apps → CleverResponder → Notifications. If notifications are switched off for the app, or the Dispatches channel has been muted there, the app says so each time it is opened — "Notifications are off for CleverResponder. You will not hear new dispatches." — with a Settings button that goes straight to the right screen. The control room cannot see this from its side: a phone that is not allowed to show a notification still reports the push as delivered.

Versions before 1.0.6

Older versions of the app make no sound of their own. With the app open, a new dispatch appears in the list with a brief banner at the bottom of the screen and nothing else. With the app closed or the phone locked, Android shows the alert under a channel called Miscellaneous with the phone's default notification sound and no pop-up. Until a phone is updated, set that channel to be loud by hand: Settings → Apps → CleverResponder → Notifications → Miscellaneous, turn on Pop on screen, and pick a long, loud sound. The Miscellaneous channel only appears in that list after the phone has received its first notification.

Standing By: a Possible Dispatch​

Before any dispatch is placed, a responder may see an amber "Possible dispatch — stand by" card at the top of the dashboard. It appears when the control room has pre-staged the responder's unit as the nearest idle unit for an alarm it might dispatch on — a heads-up sent while the operator is still working the keyholder call, so the crew is oriented in case it becomes a real call-out.

This is only a possible dispatch, not a confirmed one, and it often stands down. The card shows the site and a rough distance, with a Standing by button the responder taps to let the control room know they're ready. Then one of two things happens on its own:

  • the control room resolves the alarm → the card clears and a short stand-down notification arrives; or
  • the operator dispatches → it becomes a normal job in Dispatches.

A matching "Possible dispatch — stand by" push notification is sent as well, so the heads-up reaches the responder even with the app in their pocket. Standing by is a courtesy so the nearest unit is ready — it is never an instruction to roll on its own.

Seeing Your Suburbs on a Map​

The Suburbs tab lists the unit's suburbs as coloured chips in priority order, and a List / Map toggle switches that strip to a map of the same suburbs — each one drawn as a shaded boundary in its own colour, with the responder's live position on top. It's for orienting a crew ("where does my patch actually end?"), and it uses the boundaries the control room drew in CleverOps, so a suburb with no boundary on file simply isn't drawn. The toggle only appears once at least one suburb has a boundary.

Those same boundaries also label each call-out with its patrol suburb. Every dispatch card in Dispatches and History shows the suburb the site falls in, underneath the address. A card with no suburb label is the useful case: that job is outside every suburb the unit is assigned to — an assist off their own patch.

"Get a headstart" alerts​

When an emergency alarm reaches the control room at a site inside one of the unit's suburbs, the on-shift crew get a "Get a headstart — Open CleverResponder for details" push, so they can think about the route before the control room decides who to send. It is a heads-up, not a dispatch.

So that it stays worth reading, it is only sent when it can help:

  • Emergencies only — a low battery, a communications fault, a restore or a routine signal never sends one.
  • Not to a crew already on a call-out — a unit en route or on scene is left alone. If the control room queues it for the new alarm, the dispatch alert says so.
  • Once per site in ten minutes — a zone that keeps tripping at the same site does not send a second heads-up within ten minutes.

Before 24 September 2026 every awake signal from a site in the patch sent one, which added up to several an hour per phone in a busy area.

Suburb Watch: Emergencies in Your Patrol Suburbs​

The Suburbs tab does more than list the suburbs a unit covers — underneath the suburb chips it carries a live Suburb Watch feed of emergency alarms happening right now inside those suburbs. Unlike a "possible dispatch", this is automatic and suburb-based: whenever an emergency alarm reaches the control room at a site that falls inside one of the unit's assigned suburbs, it appears here for the on-shift crew — no operator action required.

  • Emergency only. The feed lists emergency alarms (intrusion, panic, duress, camera-verified activity) — including mobile panics sent from the CleverAlert app's Location Panic feature, tagged Mobile panic. It deliberately excludes non-emergency signals such as power failures, offline devices, and low-battery notices, so the crew only sees things worth their attention.
  • On-shift, suburb-assigned crews only. An alarm only reaches units assigned to that suburb whose crew is currently on shift. For a mobile panic, which has no site, this is worked out from the sender's live coordinates at the moment the panic is sent, checked against each unit's patrol suburb boundary.
  • A heads-up, not a dispatch. Each entry shows the site (or, for a mobile panic, "Live location"), the suburb, a priority and confidence tag (e.g. Camera-verified, Panel: panic, Mobile panic), and how long ago it came in. Tapping one opens a read-only detail sheet with any alarm snapshot and a clear reminder: the control room runs the call and will dispatch if needed. The entry clears itself once the control room actions the event.

A "Emergency in your suburb" push notification is sent for every in-suburb emergency, so the heads-up reaches the crew even with the app pocketed.

Pre-dispatch (optional, per unit)​

By default the feed is read-only — new crews see the heads-up but take no action, so it can never be mistaken for a real dispatch. For experienced units, a control-room manager can enable Allow pre-dispatch on the unit in CleverOps (see Response Units → Suburb Watch and Pre-dispatch). When enabled, the detail sheet gains a "Pre-dispatch — I'm responding" button. Tapping it is a soft self-mobilise signal: it tells the control room the crew is heading that way (logged on the event timeline) but does not create a formal dispatch and does not move the unit through the dispatch workflow. The operator still owns the call and dispatches formally if warranted.

Working a Dispatch​

When CleverCommand dispatches a verified event to a responder, it arrives with the same AI-classified snapshot and site context the control-room operator already saw — the responder isn't working blind. The event screen shows the site address at the top, with a Navigate button right beside it. The responder moves the dispatch through a simple workflow, one tap per stage:

  1. Accept & respond — accepting is rolling: the dispatch goes en-route immediately and the dispatched time is stamped, so response-time reporting covers dispatches the responder accepted themselves, not just ones an operator rolled from the control room.
  2. Mark on scene on arrival.
  3. Close it out with an outcome — All in order or Problem at site.

The Site Brief​

Under the address, a Site brief card carries the standing instructions for that site: the response instructions captured on the site record, and any note from control room kept against the site for responders. It only appears when there is something on file, and it collapses long text behind Show more so it can't push the workflow buttons off screen.

Under the brief, a People at this site card lists the people on the site record with their photos, so a responder recognises who they meet at the gate. On a panic, duress or medical event — and only then — each person's card also opens their medical alerts: conditions, allergies, blood group, medication, mobility, their medical aid (scheme, membership number, the main member and ID number, or "No medical aid — state patient"), their ambulance membership with a tap-to-call number for the service, and their emergency contact and doctor, both tap-to-call. On a burglary alarm the responder sees faces and names only.

The brief carries instructions only. Keyholder contact stays with the control room — a responder who needs the keyholder asks their controller, so the operator running the call remains the single point of contact.

Premises on a Shared Panel​

Some sites are one alarm panel shared by several households — a farm with cottages, a complex with units. In CleverOps such a site is put in premises mode, and each of its partitions becomes a named premises with its own address line, pin, photo and directions. When a call-out is attributed to one of those premises, the app leads with the premises rather than the site:

  • The dispatch card and the event screen's location header name the premises first — "North Cottage · Uitkyk Farm". The card shows the premises' own address line in place of the site address; the location header shows it on its own line above the site address.
  • Take me there navigates to the premises' own pin when it has one, otherwise to the site pin as usual.
  • Pictures shows the premises photo in place of the site photo when one is on file.
  • The site brief card opens with a Premises block — the premises name, its address line and its directions ("second gate on the left") — above the control room's note.

Panel-wide events (mains fail, low battery, panel tamper) and ordinary sites look exactly as they always did.

When a Dispatch is Stood Down​

Most cancelled dispatches aren't recalls at all: the control room resolves the alarm while the crew is still on the way. The app now says so — a Stood down notice reading "The control room resolved this alarm — no further action needed", in neutral colours rather than alarm red. A genuine operator recall still shows as Dispatch recalled along with whatever the controller wrote, and a crew's own decline shows as Dispatch declined.

Declining a Dispatch​

A responder who can't take a nominated dispatch taps Can't respond instead of accepting. The dispatch is cancelled with a note recording the decline, and a Dispatch declined entry is added to the event timeline in CleverCommand. The operator also gets a prominent toast the moment the decline lands — naming the unit and prompting them to nominate another — so they can re-roll immediately instead of waiting on a dispatch that is never coming.

One Call-Out at a Time​

A unit rolls to one call-out at a time. While the crew is still on another call-out — on the way or on scene — a new nomination shows Finish your current call-out first. in place of Accept — I'm going; I can't go still works. If the crew finished the other call-out with no signal, that finish is sent first when they accept, so a crew that has finished is never told to finish.

Outcomes Resolve the Event​

The outcome does more than close the dispatch — it flows straight back to the operator's board. Either button moves the event's card in CleverCommand to the Resolved column, and that resolved state sticks: the card stays there awaiting the operator's final close-out. The two buttons resolve it differently:

  • All in order logs a false alarm and resolves the event as unconfirmed / in-order — if a fresh alarm image arrives afterwards, the event automatically reopens on the operator's board for re-verification.
  • Problem at site logs a resolved problem and resolves the event as an attended problem — it stays resolved, with no auto-reopen.

The responder's outcome never hard-closes the event — an operator still completes it.

CleverResponder includes in-app turn-by-turn navigation to get the responder to the incident — tap Navigate at the top of the event screen, next to the site address. A one-tap hand-off to Google Maps is also available if the responder prefers to use that instead.

Mobile Panic Dispatches​

A mobile panic — sent from a CleverAlert app user's Location Panic feature — has no site, so it's dispatched a little differently:

  • The event screen's location header shows "Live location" in place of a site name and address, with the sender's live coordinates underneath instead of a street address.
  • Navigate targets the sender's current position, not a fixed point. While the panic is active, the header keeps following the sender as they move (a live update roughly every 20 seconds) and shows an "updated Xs ago" hint. Tapping Navigate always uses the freshest position available at that moment.
  • The event screen also shows a Panic sender card — the same identity CleverCommand's operator sees: a selfie, a tap-to-call phone number, a prominent vehicle registration, make/model/colour, a vehicle photo, an emergency contact, and any medical notes. Every field is optional — only what the sender filled in in CleverAlert appears.

The panic-first Home's App SOS (a site panic that streams the sender's live position) gets the same treatment on a normal site call-out: the location header keeps the site's name but follows the live points, so Navigate goes to the person, and the Panic sender card appears with their profile.

People on Site​

Under the site brief, dispatched call-outs show a People on site card: the site's keyholders and app users with their names, roles and ID photos, and a "Pressed the panic" pill on whoever raised an app emergency. On panic, medical and duress events (the server decides — never the app) each person's MED ALERT line appears too: conditions, allergies, blood group, medication, with the person's own emergency contact and doctor as tap-to-call numbers. Keyholder phone numbers are deliberately absent — phoning keyholders stays with the control room.

Everything else about working the dispatch — Accept & respond, Mark on scene, and closing it out with an outcome — works the same as any other dispatch.

On-Scene Checklist​

Before closing out a dispatch, the responder works through an on-scene checklist that can require photo capture and QR-code scans — confirming they actually walked the site, not just that they arrived. The QR scanner deliberately never displays the code value it expects — the responder has to find and scan the physical checkpoint, and whether the scan matched is recorded for the control room to see.

Reviewing a Completed Call-Out​

Completing a call-out doesn't erase it from the app. The responder can reopen a completed call-out from the History tab and review the on-scene checklist they submitted: each item shows its recorded response, the card carries a muted Read-only pill, and the action buttons and editors are gone — everything is there to look back on, but nothing can be changed after completion.

Incident Report​

The responder can file an incident report on the spot, recording whether the property was accessed, any damage, signs of forced entry, notes, and photos. This report is not just local to the app — it appears back in CleverCommand for the control room to review, so the loop from dispatch to resolution is a single connected record.

On scene, the finish buttons wait for the report (the bar reads Send your report, then you can finish.). They appear the moment the report is sent. Once sent, the report's button reads Update report; on a checklist-driven report it sends only the answers that changed since the last send.

No signal on site​

The standard report works in a dead zone. Add photo keeps each picture on the phone the moment it is taken — nothing has to upload first, so nothing is lost for want of signal — and Send report keeps the whole report on the phone when it cannot reach the control room. The snackbar says No signal. Your report and photos are saved on your phone and send by themselves when you have signal., the card collapses to Report saved on your phone (It sends to the control room by itself when you have signal), and the finish buttons unlock exactly as for a sent report. The report and its photos go by themselves as soon as the phone has signal again — Try now on the card sends at once — and the card then reads Report sent. With signal, Send report works as it always did. Photos still waiting show a small upload badge on their thumbnail.

I have arrived and the finish buttons work the same way. With no signal, the tap is kept on the phone with its own time and position and the bar moves on as though it had landed, so a crew that arrives in a dead zone can still write the report and take photos. A line on the bar says what is waiting — Arrival saved on your phone. It sends when you have signal. — and after finishing it reads You finished this call-out, Saved on your phone. It sends to the control room by itself when you have signal., with Back to my dispatches. A finish never overtakes the report or arrival before it. Accept & respond and Can't respond still need signal: a control room waiting on a nomination has to know at once.

What was saved on the phone reaches the control room with when and where it happened, not when signal came back: each photo sits on the event timeline at the time and place it was taken, the report at the time and place it was written, and the arrival and finish at the moments they were tapped — the times response reporting uses. If the control room has moved the call-out on in the meantime — recalled it, or finished it — a saved arrival or finish is simply dropped; the report is still filed. A report the server refuses outright — because the responder is no longer on that unit — stays on the phone and the card reads Report not sent with a Copy button, to give it to the control room another way.

A call-out that has been opened on the phone before also opens without signal: the site, address and Navigate, the buttons, the report and the last updates are shown as they were last seen, and replaced with live ones once the phone has signal. The same goes for the call-out's card in My Dispatches. A call-out never opened on the phone says No signal — This call-out opens by itself when your phone has signal again. — with Try again.

A checklist-driven report keeps its photos on the phone the same way, but sending it needs signal (checklist answers are only accepted while the dispatch is live): with none, it says so and keeps everything for the next Send report.

Photos carry their date and time​

Every photo taken for a call-out — on the report or an on-scene checklist — has the date and time it was taken printed along its bottom edge in a dark band, plus the GPS position when the phone has a fix from the last few minutes, the way a phone camera's own timestamp does it. The stamp is part of the picture, so it goes wherever the photo goes — forwarded, printed or saved out of a report — and a customer can see the photo is not an old one. The time is the phone's own clock, in 24-hour time. Vehicle-check and fuel-slip photos are not stamped.

Unsent reports are kept​

What the responder types into a report is saved on the phone as they go, one draft per dispatch, so an app restart mid-report does not lose it. The draft is removed once the report is sent; a draft nobody comes back to is discarded after three days.

If the control room closes the call-out while a report is still unsent, the event page stays put instead of jumping back to the dashboard. A Control room closed this call-out banner says the report is still there, with Copy report (puts everything unsent on the clipboard, to send another way) and Show report (scrolls to it). Leaving the page then asks first — Leave without sending?, with Stay and Leave — because a closed call-out cannot be opened again. The same happens if the responder is taken off the unit mid-report. With nothing unsent, the page goes back to the dashboard as before.

The control room can also finish a call-out the crew is on before their report is in. A standard report can still be sent then: the bar reads This call-out is finished with Write your report (Your report can still be sent.) above Back to my dispatches, and if the event is closed the page stays with the banner above, as for a report being written, until the report is sent or the crew chooses to leave. That applies once the crew has reached the scene and the app knows no report is on file or waiting to send.

A stand-down after the crew has arrived treats the two kinds of report differently:

  • The standard report (the switches, notes and photos above) stays on screen and can still be sent.
  • A checklist-driven report cannot be — checklist answers are only accepted while the dispatch is live. The card turns read-only with a Not sent notice and a Copy report button. An on-scene checklist answer that was half-typed stays visible as Not sent: … so it can be copied too.

Going On/Off Shift​

Responders toggle their own shift status in the app. Going on shift requests location permission if it hasn't been granted yet.

While on shift, the app records the responder's position at key dispatch moments — accepting a job (en route), arriving on scene, and completing it — and when the control room requests a one-off locate while the app is open. It does not track location continuously or in the background; going off shift ends the shift.

The shift button only appears for crew. Start Shift, and the unit card above it, are shown to people crewed on a unit — a person on the unit's crew list in Units. Anybody else who can sign in — an owner, a fleet manager, an office manager — gets the same screen without them: Drive a vehicle and, if it is ticked for them, Fleet. Going on shift with no unit put them on a dispatch dashboard with nothing to dispatch against, so the button is not offered. Adding somebody to a unit's crew in CleverOps, or a controller dragging them into a unit in CleverCommand, is what brings it back — and it follows live: the pre-shift screen picks up the change within a few seconds while it is open, or as soon as the app comes back to the foreground, with no reopen and no new sign-in. Taking them off the crew, or dragging them out of the unit, removes the unit card and the button the same way.

If the phone can't report its position — location switched off, or permission refused — the dashboard shows a "Control room can't see your position" banner with a one-tap fix (re-ask for permission, or open the phone's settings when it has been blocked outright). This matters because those fixes are the control room's only view of the person, as distinct from the vehicle the tracker covers; previously a refused permission failed silently and the crew stayed invisible for the whole shift with nobody on either side knowing. A missed GPS fix in a basement or parkade isn't flagged — that's normal and resolves itself.

Everything the Responder Logs is Geotagged​

Every record CleverResponder writes carries where the responder was when they wrote it: timeline notes, each checklist answer, every photo and QR scan, the incident report, vehicle checks and fuel logs. A report can therefore show not just what a crew recorded on a call-out but where they were standing for each entry.

  • Each entry is placed separately. Ticking six checklist items over ten minutes while walking a perimeter records six positions, not one.
  • Photos and QR scans carry the position they were captured at — not where they were uploaded. The position comes from the phone's GPS alone, which needs no signal, so a photo taken in a dead zone and uploaded later still reports the spot it was taken.
  • Vehicle checks and fuel logs work the same way offline. The position is fixed when the crew fills the entry in, so a check queued at a site and synced an hour later in another town still reports the site.
  • The time of the fix is stored alongside it, so anyone reading a report can see how fresh the position was rather than trusting a pin blindly.
  • Nothing is guessed. If there's no usable recent fix, the entry is stored with no position at all rather than an approximate one. Entries made off shift are never geotagged.

Because every logged action refreshes the position, working a call-out also keeps the crew's marker live on the control room's unit map. Between actions the phone doesn't report — a marker older than five minutes is treated as stale in CleverCommand and the crew is assumed to be in their vehicle, which the vehicle tracker covers. When ending a shift (or logging out while on shift), the app asks for an optional closing odometer for the vehicle — the reading closes the shift's trip in the fleet log (see Vehicles → Trip sheets) and can be left blank. When a responder starts a shift, CleverResponder also prompts them for a quick vehicle check — advisory, and skippable.

Vehicle Check​

When a responder starts a shift, CleverResponder prompts them to run a quick vehicle check. They first confirm which vehicle they're in — shown with its registration, and switchable to any response vehicle they may drive (a vehicle whose tag is not offered as a response vehicle, or is restricted to another department's people, is not on the list; the unit's own vehicle always is) — so the check is never recorded against the wrong vehicle. The vehicle they confirm becomes the vehicle for that shift: every later check, ad-hoc check, and fuel entry defaults to it, so the crew never has to re-pick it. The check is advisory — it never blocks going on shift, and the responder can tap Skip / do later and finish it from the dashboard's Vehicle tab.

The check runs through the inspection items the company configured in CleverOps (see Vehicles → Vehicle Check List) — typically tyres, lights, body condition, firearm & equipment, and a photo of the vehicle — plus the current odometer reading and fuel level. Photo items open the camera, and the photos are stored as evidence against that vehicle. The Vehicle tab shows whether the shift's check is done or still pending, along with the recorded odometer and fuel level.

Every check is filed against the vehicle, building a per-vehicle inspection history the control room can review in the fleet vehicle view (see Vehicles → Vehicle Detail).

Changing Vehicle Mid-Shift (Handover)​

If a crew swaps vehicles partway through a shift — a breakdown, a handover, a spare taken out — they tap Change vehicle / handover on the Vehicle tab and pick the new vehicle. CleverResponder then:

  • closes the trip on the vehicle they're leaving, at that vehicle's last odometer reading;
  • starts a fresh trip on the new vehicle (they can enter its current odometer, or leave it blank to use its last known reading); and
  • makes the new vehicle the shift vehicle for the whole crew, so every later check and fuel entry defaults to it.

The unit card on the dashboard and the Vehicle tab both show the current shift vehicle, and both trips appear on their respective vehicles' Trip sheets in CleverOps. Because switching is one deliberate action rather than a per-entry override, the fleet log stays accurate without the control room having to reassign anything after the fact.

Reporting an Issue Any Time​

Beyond the shift-start check, a responder can start a new vehicle check at any time from the "New check / Report an issue" button on the Vehicle tab — for an emergency, an accident, or something they missed earlier. These ad-hoc checks are added to the same per-vehicle history, and accident or emergency reports are flagged for a supervisor to review.

Logging Fuel​

From the same Vehicle tab, a responder taps Log fuel to record a fill — fuel type (petrol/diesel), litres, cost, odometer, and station — and photograph the slip. A Filled to full tank toggle (on by default) marks whether the tank was filled right up; leave it off for a partial fill so it doesn't skew the vehicle's fuel economy. The entry and slip appear on the vehicle's Fuel tab in CleverOps (where the control room can also add fills by hand), and the odometer reading feeds the vehicle's mileage without ever moving backwards.

Working Offline (Dead Zones)​

Vehicle checks and fuel logs work without signal, and so does a call-out's report, arrival and finish (see No signal on site). When a responder submits a check or a fuel log in a dead zone, it is saved on the phone — answers, odometer, fuel level, and any photos — and uploads automatically the moment signal returns. Nothing is lost, and there's no error to work around: they see "saved" either way.

  • Photos are captured to the phone straight away and uploaded on reconnect, so a photo taken with no signal isn't lost. Every photo is shrunk to under 200 KB as it is taken — still large enough to read a plate or panel damage, small enough to send on one bar — so a check with a dozen pictures uploads in seconds rather than sitting in the queue all shift.
  • A fuel log saved with no signal is filed with the time the responder tapped Log fuel, not the time signal came back. So it shows at the right time in the Filled column of the vehicle's Fuel tab (see Vehicles → Vehicle Detail), and the fill-to-fill economy stays in odometer order. The time comes from the phone's clock. If that clock is ahead, the fill is recorded at the moment it reached the control room. If the time is more than 48 hours back, the fill is recorded as 48 hours ago.
  • The dashboard shows a "waiting to sync" indicator whenever something is still queued, with the count. It clears itself once everything uploads; tapping it retries immediately.
  • Queued items sync in the background whenever the app senses it may be back online (opening the app, pulling to refresh, periodically while on shift, or the moment anything on screen loads again after failing).
  • If an item can't be sent — most often because the shift it belongs to has since been closed on the system, or, for a call-out report, the responder is no longer on that unit — the indicator turns red and says so, instead of continuing to promise it will upload when signal returns. It says so even while other items are still waiting for signal.
  • A vehicle check or fuel log can only be sent in the shift it was saved in, and a shift that has ended cannot be picked up again: Start Shift always begins a new one. So when a check or fuel log belongs to a shift that has ended, or was saved while the responder was not on shift at all, the red indicator says which. Tapping it opens Waiting on this phone. This lists each item with the time it was saved and, for a fuel log, its litres, cost, odometer and station. Anything that can never be sent has Remove, which asks first. If the control room still needs the entry, such as a fuel fill, give them the details before removing it. They can add a fill by hand on the vehicle's Fuel tab. Items that are only waiting for signal show Waiting for signal, with Try again.
  • Log fuel, the vehicle check and New check / Report an issue open only while the responder is on shift. Otherwise the app says Start your shift first.

Because vehicle data can only be filed while on shift — and a call-out report only while the responder is still on the unit — syncing happens during the shift it was captured in, the usual case being signal returning as the crew drives out of a dead zone. If a responder tries to end their shift while something still hasn't synced, CleverResponder warns them and offers to keep the shift open until they have signal — with Copy reports when a call-out report is among them — so nothing is dropped by booking off too early. Ending anyway removes what is left, including any items from earlier that were already marked as unable to send.

A shift left open for more than 16 hours is closed automatically by the system. A phone that was in a dead zone through that has no way to know, so anything still queued from that shift can no longer be filed — this is the case the red indicator above is for.

Drive: Signing a Vehicle Out​

Every person who can sign in can take a vehicle, whether or not they are crewed on a unit. It's the Drive a vehicle card on the screen before you start a shift, and a car icon in the dashboard header once you're on one.

The reason it exists: the vehicle trackers have always known exactly where a vehicle went, and nothing at all about who was driving it. Signing a vehicle out closes that gap — every trip the tracker records while you have it is filed under your name.

Taking one​

  1. Open Drive. You see every active vehicle you may drive in the company the session is working for — all of them for a fleet manager, or where no vehicle tag has been restricted to particular people; somebody on the team at two companies sees one company's vehicles at a time, and moves between them with the Work for switcher — and for each one whether it's free or who currently has it. A vehicle somebody else holds can't be tapped — it names them, so you know who to go and find. A vehicle that is somebody's assigned vehicle but not in their hands can be taken — it says whose it is, and the trips are yours for as long as you have it. Your own assigned vehicle says Your vehicle and needs no signing out.
  2. Tap a free vehicle. You're asked what it's for (optional — "Site inspection", "Parts run") and reminded that everything it records while you have it will be logged against your name.
  3. Fill in the pre-drive check: the odometer, fuel level, and the same inspection items a crew's vehicle check uses, configured in Vehicles → Vehicle Check List. Photo items open the camera. Answers file against the vehicle's inspection history exactly like a crew's do, as a Pre-drive check under your name. Type the odometer and pick the fuel level at the top of the check — that is the reading the vehicle's record uses.
  4. Tap Start driving.

Changed your mind before sending the check? Tap I'm not taking it after all and the vehicle is free again — as long as it hasn't moved. Once the tracker has seen it drive, it is a drive, and a drive is handed back rather than cancelled. A sign-out you simply walked away from closes itself after four hours if the vehicle never moved.

Bringing it back​

Open Drive again and tap Hand it back. You get the same checklist with a closing odometer, which is required — that reading is what closes the drive and sets its distance. It files as a Hand-back check. Until you send it, the vehicle is still yours; opening the hand-back screen and walking away doesn't release it.

If the closing reading is lower than the opening one, the app shows you both numbers and asks you to confirm rather than silently accepting it — a wrong odometer follows a vehicle around.

Opened the hand-back and never sent it? The vehicle stays yours, and Drive says so. If nothing drives it for twelve hours after that, it is closed for you.

A vehicle that is yours​

The fleet manager can make a vehicle yours from CleverOps. It sits at the top of Drive as Your vehicle, with who assigned it. There is nothing to sign out or hand back: every trip it records is yours, unless somebody signs it out for a drive — then the trips are theirs until they hand it back. You can still take another vehicle for a drive underneath it. Give it up for good ends the assignment; the fleet manager can also reassign or take it back from the desk.

A vehicle the control room signed out to you for a drive shows Signed out by whoever did it, and is handed back the normal way.

Your drives​

Underneath, your own history for that company: each vehicle, when you had it, what you wrote down, and — separately — what the tracker independently recorded: distance and trip count. The two are shown side by side rather than reconciled. A gap between them is information, not an error.

If you're a crew member​

You don't need to do anything. Your shift-start vehicle check already signs the vehicle out to you, and your end-of-shift closing odometer hands it back. That drive appears in Drive as read-only, marked on shift — it's released by ending your shift, not from this screen, because two places to hand back one vehicle is how you end up with two different closing readings.

You can still use Drive to take a second vehicle mid-shift if you genuinely need one; your shift vehicle stays on the Vehicle tab.

What it needs​

Whoever takes a vehicle needs a person record in that workspace — the drive is recorded against it, which is the whole point of the surface. Anybody who can sign in has one by definition, so in practice this only decides who can sign in at all: see Email and password. Fleet managers and owners are let in for Drive without being made responders; everybody else needs the Responder or Fleet role ticked.

Drive needs signal. Unlike vehicle checks and fuel logs, it does not work offline — the workspace allows only one person to hold a vehicle at a time, and a claim queued on a phone couldn't enforce that. Two people would each be told the same bakkie was theirs.

Fleet (owners and fleet managers)​

Most people who open CleverResponder are a crew, and the Vehicle tab covers what they need: their vehicle, on this shift. Owners and fleet managers have the other job — where is everything, what is it doing, and where has it been — so they get an extra surface called Fleet.

Fleet is off for everyone by default. It appears for:

  • anyone holding the Fleet role on their person record (see People) — its own chip, no Responder role needed; and
  • company members who already hold the Manage fleet & vehicles capability — the existing fleet-manager and owner definition. They don't need the tick.

Nobody else can reach it, and turning it on for a person does not change anything else about what they can do. It shows one company at a time — the company the session is working for, the same one the unit card and Start Shift read against. Somebody on the team at two companies sees each fleet on its own, and moves between them with the Work for switcher on the pre-shift screen rather than through anything inside Fleet; when an account has more than one, the company is named under the Fleet heading so there is never a doubt about whose vehicles are on the list. It is read-only: vehicle records, trackers and trip-sheet corrections are still edited in CleverOps. The one thing Fleet can do to a vehicle is ask its dashcam for a picture, or for a clip of what just happened, and that needs a permission of its own.

Where to find it:

  • Before going on shift — a Fleet card on the screen where the responder starts their shift. A fleet manager who never crews a unit still gets in.
  • On shift — a truck icon in the dashboard header, next to the theme toggle.

The Fleet List​

Every vehicle in that company for a fleet manager; for somebody who holds only the Fleet role, the vehicles they may drive — which is every vehicle until the fleet manager restricts a vehicle tag to particular people. Ordered so the ones doing something come first: moving, then stationary, then anything that has stopped reporting, then vehicles with no tracker fitted. Each card shows the call sign and registration, a live status pill, the unit and crew currently on it, whether it is on a call-out, how long ago its tracker last reported, distance covered in the last 24 hours, and warnings for a service that is due or paperwork that has expired.

A search box matches on registration, call sign, crew, unit, tag or make. Filter chips narrow to Moving, Stationary, No signal, No tracker, or Needs attention — the last being anything with a service due or expired licence disc, roadworthy or insurance. A Cameras chip appears only in a fleet that actually has dashcams fitted, and vehicles that have one carry a Camera chip on their card, greyed to Camera offline when the camera is not currently connected.

Above the list, a strip counts moving / stationary / dark vehicles, how many are on a call-out, and the fleet's total distance over the last 24 hours.

Live Map​

The same vehicles as labelled markers, coloured by status, with the call sign readable on the map rather than hidden behind a tap. Tap a marker to open a preview card, and again to open the vehicle. Vehicles with no tracker (or no fix yet) are counted underneath the map so it never quietly under-reports the fleet.

Both views refresh themselves roughly every 20 seconds while the screen is open — deliberately slower than a tracker reports, so the app isn't burning battery re-fetching the same fix.

The maps that sit inside a scrolling screen — this Live Map, a vehicle's Trips map and the Suburbs map — take any drag or pinch that starts on them, so they pan and zoom instead of scrolling the page. To scroll past a map, drag from outside it. Maps follow the app's light or dark theme and switch when it changes.

One Vehicle​

Tapping a vehicle opens four tabs — five if it has a dashcam fitted, which inserts Cameras directly after Live:

  • Live — a following map (it keeps the vehicle centred as new positions arrive, at whatever zoom you leave it on), current speed and heading, ignition, last report, distance in the last 24 hours, which unit and crew have it, any call-out it is on, and its recent inspections and fuel entries.
  • Trips — what the vehicle actually did, reconstructed from its tracker. Pick a date range (today, 7, 30 or 90 days) and the trips appear grouped by day. Tapping one draws its route and zooms the map to fit it; ticking several draws them together for comparison, framed to fit them all. A single route is shaded by speed; several routes get one colour each. Points puts every recorded fix on the map — tap one for its exact time and speed. Stops are marked, and each trip is labelled with how it ended (ignition off, device went silent, power lost, auto-closed) and how much of its distance was on a call-out. Stat tiles total the range: distance, driving vs idle time, trips, top speed, harsh events. Copy report puts a plain-text summary of the selected trips on the clipboard for pasting into a message.
  • Sheets — the paperwork lane: trip sheets with driver, odometer readings, distance and purpose. Deliberately separate from Trips, because one is what the tracker recorded and the other is what a person wrote down.
  • Details — make, model, year, colour, fleet number, tags, odometer and service targets, licence disc / roadworthy / insurance expiry dates, and the tracker fitted to it.

A vehicle with no tracker still appears everywhere — its Trips tab explains that trips come from a tracker, and its Sheets tab keeps working, because those are written by hand.

Nothing on this surface is estimated. A trip with no recorded positions says so rather than drawing a straight line between its endpoints, and a trip that has not been attributed to a call-out or patrol area shows no percentage rather than a zero.

Cameras​

A dashcam is a tracker with lenses: the same vehicle, the same trips, the same paperwork. So a camera-equipped vehicle behaves exactly like any other everywhere above, and gains one extra tab.

The tab appears only on a vehicle that has a dashcam fitted. On every other vehicle there is no Cameras tab at all rather than an empty one.

At the top, whether the camera itself is connected. This is deliberately not the same line as the tracker's last report in the header: a dashcam can be sending position perfectly while its camera connection is down, and only the camera connection can answer a request. Alongside it: when it was last heard from, whether it is streaming right now, and how many requests are still waiting.

Below that, pick a camera — 1 · Road or 2 · Cabin — then:

  • Live view opens the picture full screen. It takes a few seconds: the app asks the camera to start streaming and then waits for the first frame, and it says which of those it is doing rather than showing a frozen black rectangle. Turn the phone sideways for a bigger view. Switch between road and cabin without leaving the screen; the old channel is closed before the new one opens. The stream carries the sound from the camera's microphone as well as the picture.
  • Snapshot asks for a single still. It arrives in Footage below, newest first, usually within a few seconds.
  • Save the last 30 seconds keeps a clip of what just happened — see Keeping a moment below.
  • What's on the card asks the camera to list what it has recorded in the last 24 hours.
  • Camera check asks the camera how many lenses it has. Until it has answered, both cameras are offered and the app says why.

Live view runs over the vehicle's mobile data, so a stream you opened is closed the moment you leave the screen, press Stop live view, or send the app to the background — a phone that goes into a pocket does not keep paying for a picture nobody is watching. It reopens by itself when you come back.

A camera nobody is watching stops itself. While a live view is open the app quietly tells the server it is still there; ten seconds after the last viewer stops saying so — including a phone that died or an app that was killed, which never get the chance to close anything — the camera is told to stop streaming. That is the safety net, not the main path: closing the view yourself stops it immediately.

And no stream runs longer than three minutes, even one you are watching. That limit is the backstop for everything the ten-second rule cannot see — a stop that never reached the camera, a stream opened by something that never checked in — so it does not depend on any app being alive to enforce it. The controls count it down — Stops automatically in 2:41 — and when it fires the screen says so and offers Watch again, which starts a fresh three minutes.

The countdown is the server's, not the phone's, which matters when you have joined a camera somebody else opened: you are told what is actually left of that stream, not three minutes from when you arrived.

You can watch a camera somebody else already opened. A stream belongs to the camera, not to the person looking at it: an operator in CleverOps and a responder in the app can watch the same one at the same time, and neither has to wait for the other. So the app checks before it asks. If the camera is already streaming, it simply joins — no request is sent — and the button reads Leave this view instead of Stop live view, because backing out must not take the control room's picture down mid-incident. If it was not streaming, this app opened it and this app closes it. The status line above the camera picker names the camera that is already streaming, when the device has reported one.

When no picture comes, the screen says why. A camera that has just been asked usually needs a few seconds, so the app keeps asking and shows how long it has been waiting. If the video never arrives, it stops and says No picture from this camera, with the likely reason: the camera is not connected, the vehicle is parked out of coverage, or that camera is not fitted. If the video has reached our server but the video player on the phone keeps failing on it, waiting will not help, so the app stops after three tries and says This phone could not play the camera's stream. Both notices have Show details, which gives the player's own error and what the server answered, and Copy details, so support gets the exact wording. Try again starts over.

Footage shows what the camera has already sent: the newest still or clip large, and everything before it as thumbnails. Tap any of them to open it full screen — stills pinch to zoom, clips play with a scrub bar. These arrive two ways: a snapshot somebody asked for, or an upload the camera made by itself when it raised an event.

Requests is the log of everything asked of this camera — what was asked, by whom (yours are marked), and where it got to: waiting for the camera, sent to the camera, camera answered, or failed. Nothing here is a live call. The camera is asked and the request is queued, so if the camera is offline the app says so and holds the request for five minutes in case it comes back rather than pretending it went through.

Who can operate a camera. Seeing that a vehicle has one, and seeing the footage it has already sent, comes with Fleet. Asking it for a snapshot or a live picture additionally needs the Cameras tick on the person's Roles & access — it is the same permission an operator's Live view grants on the Control Room page, because watching a site's cameras and a vehicle's is the same act, and owners and fleet managers hold it without the tick. Without it the tab still shows the camera and its footage and says plainly why the buttons are not there. Every request is recorded against the name of the person who made it.

Settings changes, pulling a whole recording off the card, and messaging the driver's screen are not offered on the phone — those stay in CleverOps. Keeping a moment is the bounded exception: at most a minute at a time, always of footage already recorded.

Keeping a Moment​

Live view keeps nothing. Close it and what you saw is gone, and a snapshot is a single frame of now — neither helps once the thing worth seeing has stopped happening. Save the last 30 seconds is the one action on the phone that produces evidence, and it is reachable in the two places somebody needs it: on the Cameras tab, and inside the live view itself, which is where a responder is standing when they see something worth keeping.

It opens a sheet with three things to decide: how far back (15, 30 or 60 seconds), which camera, and whether the data is worth spending. The camera sends its full-quality recording rather than the smaller picture live view uses, so the sheet states the cost before you confirm — roughly 8 MB for 15 seconds, 15 MB for 30, 30 MB for a minute, off the vehicle's own SIM. A clip can come back a little larger than the estimate.

It saves backwards, never forwards. A dashcam serves footage out of what it has already written to its memory card; it has no idea what it is about to record. Asked for a moment that has not happened yet it will cheerfully accept the request and then send nothing at all — so the app only ever asks for the seconds just gone, ending a moment ago. There is no "record the next minute" button because no camera can answer one.

Sixty seconds is the most a single request may cover, and the camera sends one clip at a time — ask again while one is still on its way and the app says so rather than queueing a second pull against the same SIM. If the camera reported no memory card within the last day, it says that instead of leaving a request to expire; an older "no card" is not trusted, and the request is sent. A request made while the camera is offline is held for ten minutes and sent the moment it reconnects; the footage itself is safe on the card either way.

The request then appears in Requests like any other, and the clip lands in Footage when it arrives. It needs the same Live view permission as the rest of the camera controls, and it is recorded against the name of the person who asked.

Who Was Driving?​

A trip gets its driver automatically when somebody signs the vehicle out — through Drive, or by starting a shift on it. If nobody did, the drive is recorded with no driver at all, and nothing is guessed. That is deliberate, and it is also why the drives you most want explained are the ones with nobody's name on them.

The person icon in the Fleet header opens the queue of those unclaimed drives. Each card shows the vehicle, when it went out, how far it went, and that nobody signed it out. The All switch widens the list to every drive, so an answer given earlier can be corrected.

Tapping Say who offers everybody the company employs — the control-room and response team and the technicians and office staff, in one searchable list, because a vehicle gets taken by whoever has the keys. Somebody else covers a contractor, a visitor, or a name you only half know. There is also a free-text "Why do you say so?", and it is the most useful field on the screen: "Piet saw him take the keys at about six" is what makes the record mean something months later.

What gets stored is your statement, with your name and the time on it — not something the vehicle reported. The two are kept apart everywhere:

  • a drive signed out properly shows a tick; one somebody vouched for shows a speech icon, who said it, when, and their reason;
  • naming a driver here never overwrites, and is never overwritten by, the automatic path. If a signed-out session later turns up naming somebody else, the card flags the disagreement in amber rather than silently picking a side — that call belongs to a person.

Seeing the queue comes with Fleet. Recording a driver needs the Manage fleet & vehicles capability, because putting a colleague's name on a drive is a serious thing to write down. Without it the queue is still readable, and the app says so instead of offering a button that would fail.

The same queue and the same rules are on the CleverOps side, on a vehicle's Camera & tracking tab.

How It Fits With CleverOps and CleverCommand​

CleverResponder is the third leg of a connected chain:

  • CleverOps is where a control-room admin manages the responder roster and issues sign-in access (see Responders).
  • CleverCommand is where an operator verifies an event and dispatches it to a responder.
  • CleverResponder is where that responder receives the dispatch, gets there, and closes it out.

An incident report or checklist filed in CleverResponder is what an operator sees read back in CleverCommand — there's no separate reconciliation step.