Guard Duty Verification: Patrol, Pocket Book and Occurrence Records

AVES guard duty verification: patrol, Pocket Book and occurrence records

Written by

Kaviarasan

in

, ,

The Problem

Ask ten site managers to define security guard duties and you’ll get ten overlapping but slightly different answers. Patrol the perimeter. Log activity. Report anything unusual. Respond to incidents. Every one of these falls under the same umbrella. For what those duties actually are by site type, see security guard duties and responsibilities; this piece is about proving they happened.

Here’s the part most people miss. The duties themselves are not the hard part. Proving they happened is.

A guard who walked the full route, checked every gate and noted a broken light on the way has done real work. But if none of it got written down, that work is invisible from the client’s side, indistinguishable from work skipped entirely. That gap between “the work happened” and “the work is provable” is where most client disputes, missed maintenance and liability exposure come from.

This is the exact problem worth solving before it costs you a contract.

Why It Matters

Security contracts are won and renewed on evidence, not effort. A guard company that can hand a client a timestamped account of exactly which duties were carried out, where and when has a fundamentally different conversation than one that says “trust us, they were there.”

This changes how you should evaluate any security guard management system in this space.

Contract defensibility. A verified record answers “what happened at 2 a.m.” in seconds. A paper trail answers in days, if at all.

Guard accountability. Digitising the record reveals the difference between a thorough guard and one cutting corners, data invisible in a handwritten log.

Liability protection. A documented occurrence report or Pocket Book entry is often the only thing standing between a security company and a disputed claim.

None of this is about catching guards doing something wrong. It’s about giving everyone, guards included, a record that protects them when a shift gets questioned later.

Step-by-Step: How Core Duties Get Verified in AVES

You don’t have to take this on faith. Here is exactly how duty verification works across a shift.

Duty verification inside AVES runs through patrol verification, a random selfie check, the Pocket Book, daily occurrence reporting and a live supervisor dashboard. Together, these cover a full shift’s worth of evidence.

Step 1

Patrol verification proves the route was walked and that the guard was actually there. The guard scans a waypoint’s QR code in the app. Before the scan counts, AVES checks the phone’s GPS against that waypoint’s stored coordinates and its configured radius, 50 meters by default. A scan from outside that radius gets rejected with the actual distance shown, for example “You are 180m away. Must be within 50m,” and duplicate scans of the same waypoint are rejected too.

Every attempt, successful or not, gets written to a scan log with GPS and timestamp. A completed patrol isn’t a claim. It’s a GPS-validated, time-stamped record of the round, failed attempts included.

Step 2

Random selfie checks confirm it’s the assigned guard, not just the assigned phone. Waypoints can be flagged to always require a selfie and AVES also triggers one at random so the guard can’t predict which checkpoint will ask. That verifies the person on shift, not just a device in someone’s pocket.

Step 3

The Pocket Book, AVES’s electronic guard logbook, replaces the paper notebook. Instead of a pocketbook that lives in a drawer, guards log activity in the app as a free-text message with a date and time. Each entry also records who submitted it and when it was submitted, separately from the date and time the guard assigns to the event itself, so a note written at the end of shift about something that happened at 2:15 a.m. shows both timestamps clearly.

The message field is deliberately open, with no categories or tags. Forcing routine shift notes into dropdowns is how you end up with a logbook where every entry just says “general.”

Step 4

Daily occurrence reporting captures the structured account. An occurrence record carries the recording date and time, the time the event actually occurred, location, who reported it, nature of incident, a description, action taken, whether follow-up is required and a supervisor name plus supervisor remark. This is the formal write-up, the document you hand to a client or pull up six months later with a supervisor’s sign-off already attached.

Occurrences are filterable by date range, location, nature and reporting user and they roll into the Daily Occurrence report for export.

Step 5

Supervisors see patrol status without asking anyone. The admin dashboard breaks patrols into Pending, In Progress and Completed, alongside open incidents and charts daily incident and patrol counts across the last seven days. An “action required” count combines open incidents with pending and in-progress patrols in a single number.

It updates live. Each waypoint scan pushes to the dashboard with a current completed-of-total count and the final scan pushes a completion event with total distance covered. Supervisors watch the shift happen in real time instead of reading about them afterward.

Settings Explained

Here’s what each setting controls and the real gap it exists to close.

Patrol route setup. Admins build patrol templates as checkpoints and each checkpoint contains waypoints. Every waypoint carries its own coordinates, a GPS radius, a QR code and an optional “always require selfie” flag. Templates are then assigned to guards.

Waypoint radius. This is the scan tolerance per waypoint, 50 meters by default. Tighten it for indoor checkpoints where GPS is naturally less precise and loosen it for large outdoor sites or unreliable-signal areas. Too tight and it rejects scans from guards genuinely standing at the checkpoint.

Selfie-required waypoints. Flag the high-sensitivity checkpoints where you always want photo verification. Random selfie prompts still run regardless of this setting, so this only adds guaranteed checks on top of the random ones.

Occurrence filters and export. Occurrences filter by date range, location, nature of incident and reporting user and export through the Daily Occurrence report. Nature of incident is free text, not a fixed category list, so agree on site wording up front. “Unusual activity” and “suspicious activity” won’t group together in a filter if half your guards type one and half type the other.

Module permissions. Pocket Book, patrol and occurrence access are controlled per role.

Best Practices and Benchmarks

Set your own patrol completion baseline from your first month, then hold to it, using AVES’s Completed, Pending and In Progress counts plus the 7-day trend rather than an industry figure that may not fit your sites. If completion drops below your baseline, check route length against the shift window first. An incomplete patrol is usually a route that can’t be walked in the time available, not a guard cutting corners.

Review rejected scans, not just completed patrols. The scan log records out-of-radius attempts with the measured distance. A waypoint that generates the same 60-meter rejection night after night usually has bad stored coordinates or a radius set too tight and the fix is a config change, not a conversation with the guard.

Agree on occurrence wording per site. Because nature of incident is free text, a short, shared vocabulary posted where guards can see it is what makes the filter actually useful later. Without it, the field is searchable in theory and useless in practice.

Let the Pocket Book stay unstructured, but escalate what shouldn’t be there. Routine notes belong in free text, but a recurring or worsening observation, like a repeated “flickering light” note, should graduate to a full occurrence report with action taken and a supervisor remark. Getting that escalation path right is what separates basic guard management software from a system built around how shifts actually run on site.

Common Mistakes

These look harmless at setup and turn into real problems a few months in.

Treating the Pocket Book as a diary nobody reads. Digitizing a paper habit without anyone actually reviewing entries just moves the same problem online.

Reusing one waypoint radius across every site. A radius set for a small indoor office and reused on a sprawling outdoor yard rejects scans from guards standing exactly where they should be, which trains everyone to distrust the system.

Leaving occurrence wording inconsistent across guards. Free text is flexible by design, but with no shared vocabulary, filtering reports later becomes guesswork instead of a real search.

Not connecting patrol, Pocket Book and occurrence data for supervisors. Reviewing these as three separate reports instead of one shift view makes it easy to miss the full picture of a guard shift.

FAQ

Do guards need three separate apps for patrol, the Pocket Book and occurrence recording?

No. All of these live in the same AVES field app, accessible from the shift home screen, so the record never gets split across disconnected tools.

Can Pocket Book entries be edited after submission?

Original entries stay locked once submitted, which preserves an accurate audit trail for supervisors and clients. Guards can add follow-up notes rather than editing the original.

What happens if a guard is somewhere without signal?

Core field actions, including patrol scans, Pocket Book entries and occurrence notes, save locally and sync automatically once the device reconnects. AVES’s offline support covers these core actions, not the full platform.

How is an occurrence different from an incident?

An occurrence is the structured write-up, with nature of incident, description, action taken and supervisor remark. It sits above a quick Pocket Book note and can escalate into a full incident report when severity calls for it.

Do all security guard services need this level of documentation?

Any security guard services under a client contract benefit, but sites with strict compliance needs, like hospitals or industrial facilities, see the biggest drop in disputes once shifts are logged this way.

Related Features

These modules don’t work in isolation. Here’s where to look next.

The Next Step

You’ve now seen exactly how AVES turns a guard shift into a record that actually holds up when someone asks a question about it, using patrol verification, a random selfie check, the Pocket Book and daily occurrence reporting inside one security guard management system instead of scattered tools.

Want to see patrol, Pocket Book and occurrence tracking working together on a real shift? Book a live walkthrough of AVES

CONTACT US

Website : https://avessecurity.com

Linkedin: https://www.linkedin.com/company/aves-security-management-system/

Instagram: https://www.instagram.com/avessecurity/

More posts