Sooner or later a client asks a question you'd like to answer with certainty. Was the site covered all night? Was the rear gate checked? When did the officer actually leave? If the honest answer is "we believe so", you have an evidence problem.
A booking isn't a shift
Most rota tools can tell you that a shift was assigned. That's useful, but it answers the wrong question. The client isn't paying for an assignment. They're paying for a site that was watched, patrolled and handed over properly. The gap between "booked" and "delivered" is where most disputes live.
Closing that gap takes a record of the shift itself, built while it happens rather than reconstructed afterwards.
What a useful shift record contains
Attendance you can check
A check-in time on its own proves very little if anyone could press the button from anywhere. It becomes meaningful when it's tied to the site: the officer's location compared against a boundary you've defined for that site.
Just as important is being honest when that check isn't possible. If the officer didn't share their location, or nobody ever set the site boundary, the record should say exactly that, rather than quietly marking the check-in as verified. A record that guesses is worse than one that admits a gap, because you can't tell which parts to trust.
Patrols tied to places
"Patrols completed" isn't evidence. A useful record lists specific checkpoints on the route, with the time each one was confirmed. That lets you see the rhythm of the shift, and it makes a late or missed checkpoint obvious rather than invisible.
Welfare checks that someone watches
For lone workers, periodic welfare checks are standard practice. But a welfare check only protects anyone if a missed one triggers a response. The record should show each check, and the provider's view should flag a missed one while the shift is still running, not in a report the next morning.
Tasks and handover
Many sites have things that must happen before the shift ends: a lock-up, an alarm set, keys returned, a handover to the day team. Recording these as required tasks gives each shift a clear definition of done.
A record that can't be quietly rewritten
This is the part that's easy to overlook. If entries can be edited without a trace, the record can't settle a dispute, because either side can argue it was changed. An append-only log, where new events can be added but earlier ones aren't silently altered, is what turns a list of timestamps into evidence.
It protects officers as much as clients
It's tempting to see all of this as a way to check up on officers. In practice it cuts both ways. The officer who walked every checkpoint on a freezing night now has proof that they did. When a client disputes an invoice or claims a patrol didn't happen, the record answers for the officer instead of leaving it as their word against someone else's.
That's also why the purpose of location data needs to be narrow and clear: confirming attendance at a site during a duty session, with a defined retention period, not following people around once they've clocked off. Officers are far more willing to support a system that's honest about what it collects and why.
Watch it live, not the morning after
The biggest shift is moving from reviewing records after the fact to seeing exceptions as they happen. A missed checkpoint at 2am is a phone call you can make at 2:15am. Discovered at 9am, it's just a problem to explain.
Guardlane's operations view is built around this: active sessions, welfare status, patrol coverage and an exceptions queue for anything that hasn't happened when it should.