Patrol route planning with checkpoints and proof
Patrol route planning: ordered stops, NFC or QR proof at each one, repeat schedules, and an alert the moment a round runs late.

"Patrol the property" is not an instruction. It is a hope. A patrol route is the same request written down: these stops, in this order, proven this way, finished by this time. The difference shows the first time a client asks about 3am.
A patrol route is an ordered list of stops, each with its own proof method, wrapped in a schedule and a due time. Build it once, set it to repeat, and the system watches for late and missed stops instead of a supervisor doing it. When the round is done you export a PDF showing every stop, the time it was hit and anything skipped.
What goes into a route?
Six steps, and the order matters because the walking order is what everything else hangs off.
- Create the route and name it for the thing it covers, not the shift. "Perimeter and loading dock" survives a schedule change. "Night route 2" does not.
- Add stops by dropping pins on the map, or reuse locations you have already defined.
- Name each stop the way a guard would say it out loud. North Gate. Server Room. Dumpster Corral.
- Put them in the order somebody would actually walk them. A route that zig-zags gets short-cut on the third night.
- Pick the proof method per stop. It does not have to be the same one everywhere.
- Set the scheduled start and the due time, which is what turns the route into something that can be late.
Which stops belong on the route at all is a separate question, and the one people get wrong. Where to place patrol checkpoints works through it properly.
Where should the stops actually be?
Not evenly spaced. Not wherever the tag was easy to stick.
Incidents cluster. Public policing has spent forty years proving this: the National Institute of Justice's CrimeSolutions rates hot spots policing as Effective for reducing overall crime, on the strength of exactly one observation, that crime concentrates in small places rather than spreading evenly across a map. A shopping center is not a city, so treat that as a principle rather than a proof. The principle still holds on your site.
So pull your own incident history before you place a single stop. Which door gets propped. Which corner gets slept in. Which loading bay the copper goes missing from. Those are your stops. The pretty ones by the front entrance are for the client, and it is fine to have a couple of those, but they should not be most of the route.
How do you prove the guard was there?
Six methods, and the honest answer is that you mix them. Tamper resistance and convenience trade against each other, and no site needs the maximum everywhere.
| Method | What it proves | Use it when |
|---|---|---|
| NFC scan | The phone was physically at the tag | The stop matters and you expect it to be argued about |
| QR scan | The code was in front of the camera | You want enforcement without buying and mounting tags |
| GPS proximity | The device was inside the radius you set | Outdoor stops, vehicle patrol, anywhere a tag would not survive |
| Photo capture | What the stop looked like at that moment | Condition matters: a gate, a spill, a stack of pallets |
| Filed report | The guard actually looked and wrote down what they saw | Equipment checks, occupancy counts, anything with a reading |
| Manual check-in | Somebody pressed a button | Low-stakes stops where the point is sequence, not proof |
NFC is the one worth understanding properly, because the whole tour-verification industry is built on it and the failure modes are specific. How NFC checkpoints prove the patrol happened covers tag placement, surfaces that kill read range, and what a guard does when a tag stops responding. The step-by-step version lives in NFC checkpoint procedures.
GPS proximity has its own trap: the radius. Set it too tight and a guard standing at the right door gets rejected because the building is blocking half the sky. Set it too wide and the stop can be verified from the parking lot. The same tuning problem shows up in geofencing without the false alarms.
What happens when a round runs late?
This is the part that earns the software. A supervisor cannot watch nine routes across four sites at 3am, and by morning a missed stop is just a gap in a report nobody reads.
- Due soon. A nudge while there is still time to finish, which is the alert that actually prevents misses rather than recording them.
- Overdue. The due time passed and the route is not complete.
- Missed checkpoint. A specific stop went unverified. Named, so the follow-up conversation is about one door rather than a whole shift.
- Escalation. An unanswered alert goes up the chain rather than dying in a notification tray.
An overdue round on a lone-worker post means something different from an overdue round on a staffed site. Where the guard is alone, treat it as a welfare signal and not a compliance one. Welfare check-ins for lone workers covers where that line sits.
Making routes repeat
Save the round and it comes back on a schedule, hourly, daily or weekly. Which is the whole point: you build the perimeter round once and it appears on every night shift without anybody re-entering it.
Most sites end up with a small family of routes rather than one. A day route that includes the reception desk and the visitor lot. A night route that adds the roof access and drops the areas that are occupied anyway. A winter variant that skips the path nobody has salted. Keeping them as separate saved routes beats one route with a page of exceptions in the post orders.
One caution about repetition. A route that runs at exactly 22:00, 00:00 and 02:00 for six months is a schedule anybody watching the building can learn. Vary the start times within the window, and treat the fixed-interval version as the exception rather than the default. night patrol best practices covers the rest of what goes wrong on a repeated round.
Watching one in progress
While the round is live, the map carries the guard's current position, the stops already verified, the track walked between them and the stops still ahead. Every status change is stamped with who changed it and when.
The track between stops is the underrated part. Verified stops tell you the guard was at six places. The path tells you whether they walked the perimeter or drove around it, and that is usually what a client is really asking about. Keeping that path to look at later needs location history, which is on the Pro plan and up.
What the client gets afterwards
A completion report, which is the artifact the whole exercise exists to produce.
- Completion percentage for the route
- Each verified stop, how it was proven, and the timestamp
- Stops missed or skipped, named
- A PDF carrying your company name and a map of the route
- Completion rate across the team, trended against the previous period
Send it before they ask. A monthly report showing 97 percent completion, with the three misses explained, is a renewal argument that does not need a meeting. Client reports that win renewals covers how to frame it, and proving your patrols happened covers the dashboard side.
Starting simple
Build the first route from Routes with four or five stops and GPS verification on all of them. Run it for a week. Then look at where the misses are and tighten only those stops, adding a tag where the proof needs to be harder or a required report where you need the guard to actually look at something.
Rolling out the strict version everywhere on day one is how you end up with guards who resent the tool and supervisors who turn the alerts off. Write the standing rules down as you go, in a patrol procedures protocol, so the route and the written procedure do not drift apart.
Key Takeaways
- A route is stops, order, proof method and a due time. Drop one and it stops being verifiable.
- Place stops where your incident history clusters, not evenly around the perimeter.
- Mix proof methods. NFC where it will be argued about, GPS where a tag would not survive.
- The due-soon alert prevents misses. The overdue alert only records them.
- Vary start times on a repeating round, and send the completion PDF before the client asks.
Continue Reading

NFC checkpoints prove the patrol happened
Paper logs and wands are out. An NFC checkpoint tap stamps the time and the spot, and the guard tour report writes itself for the client.

Where to place guard tour patrol checkpoints
Guard tour checkpoint placement decides what a scan proves: corner points, interior rooms, NFC versus QR versus GPS, and timing the route honestly.

Offline mode: what TeamMap does with no signal
Offline mode holds scans, reports, clock-ins and photos on the phone until signal returns. What still works, what does not, and the radio fallback.