This is a proposed field exercise from the PatrolTech team, not a certification or a claim that every product will pass. Use a test site, demo data and an authorised route. Fifteen minutes is a starting agenda; extend it if your environment needs more time.

Minutes 0–3: agree what must be observable

Choose two test checkpoints and one supervisor. Write down the expected route, the phone used and the normal reporting workflow. Do not put real client details into screenshots that you intend to share.

Start with a daily activity report template. Record the visit sequence separately from the system's upload sequence. That gives the reviewer something concrete to compare.

Minutes 3–7: remove connectivity deliberately

After confirming that the test route is available on the phone, enable airplane mode in a safe test setting. Record a visit and a sample incident with a short note. If the device or workflow needs another preparation step, document it rather than assuming it happened automatically.

Before reconnecting, ask: can the operator tell whether the record is saved locally, awaiting delivery or failed? A reassuring animation is not enough evidence. Keep the on-device observation and the expected visit time on the test sheet.

Minutes 7–11: reconnect and reconcile

Restore connectivity. Compare the phone and dashboard with the expected sequence. Record the actual result of each check; leave anything you cannot inspect as “not observable”.

Do not alter the phone clock or interrupt a live guarding assignment to force an edge case. Repeat under controlled conditions if something is unclear.

Minutes 11–15: hand the record to someone else

Ask the supervisor to describe the visit and the sample incident without asking the operator to fill in the story. Use the incident report template to separate observations, actions, notifications and follow-up.

A useful result is a short decision log: observed, not observable, or needs follow-up, with the supporting record for each finding. Avoid turning those observations into an unsupported overall “pass”.

Turn the exercise into a buying requirement

If a field mattered during the test, put it in the guard tour RFP template and ask each supplier to demonstrate it. Use the same scenario for each product. The QR, NFC and Bluetooth decision matrix helps frame the checkpoint discussion; it does not replace testing on your own devices.

For Spanish-speaking teams, the supervisor kit brings together three PDF templates, two official videos and practical guides.

Try it with PatrolTech

PatrolTech records QR/NFC checkpoint visits and incidents, including offline workflows. Use the exercise above to document what you actually observe in your configuration.

Published by PatrolTech / Ingenieros Web SL, Madrid. The linked resource sites form part of our content network. Official images illustrate the product and are not test results. Business contact: info@patroltech.app.

This collection brings together existing PatrolTech field resources. Choose the part that matches your next decision; the full templates and articles stay at their original addresses.

1. Close a shift without losing the open issues

Pair the daily activity report template with the incident report template. The activity report gives the chronology of the shift. The incident report holds the detail of one event. Reference the incident number from the shift log so the next supervisor can move between the two records.

Try this with a fictional site before changing your live process: could someone who was not there identify the location, the observation, the action already taken and the next owner? That is a more useful acceptance test than counting form fields.

Both resources have two-page PDF formats. Their landing pages request a work email to send the files. You can browse the five-template catalogue before choosing one.

2. Turn a sales demonstration into a buying test

Use the guard tour software RFP template to organise questions about functional requirements, security, pricing, support and a proof of concept. It includes a scoring rubric so your team can compare answers using the same structure.

Give every vendor the same short scenario: configure a site, record several checkpoints, report an incident, go offline, reconnect and retrieve the record. Ask them to demonstrate the sequence. Keep your own notes about what you observed and what still needs confirmation.

3. Choose checkpoint technology before ordering labels

Read the QR, NFC and Bluetooth decision matrix. Use it to frame a practical test at your own site: the phones your team actually carries, an outdoor checkpoint, a low-light location and an area with weak coverage.

A label specification does not tell you how a workflow feels during a real round. Start with a small pilot and write down the acceptance criteria before buying a large batch.

4. Keep event time and arrival time separate

Our earlier field note explains why visit time is not sync time. Include that distinction when reviewing an offline demonstration and when preparing shift handover notes. A record arriving later in a dashboard should not silently become a different account of when the event happened.

See the workflow in PatrolTech

PatrolTech records QR/NFC checkpoint visits, incident photos and notes, with offline recording and a web management dashboard. Its permanent Free plan includes 5 checkpoints and unlimited guards.

Watch the complete English demo, explore the tutorial library, or find our public integration repositories. For official apps, professional networks and contact details, visit About PatrolTech.

Start with the document or test you need today. You can evaluate the digital workflow against that same task afterwards.

Put the kit to work

Use our 15-minute guard tour acceptance test as a short agenda for a supervised demonstration. It includes an evidence table for reconciling offline visits, incidents and shift handover.

This field note offers a review checklist for supervisors evaluating an offline patrol workflow. It is written by the PatrolTech team. The times below are illustrative; they are not records from a customer site.

Start with two questions

For each event, ask when the phone recorded the activity and when the server received it. Those timestamps describe different parts of the workflow. A report should make their meaning clear.

Imagine a checkpoint visit recorded at 22:10. The phone reconnects and uploads the event at 22:35. If a supervisor treats 22:35 as the visit time, the review may classify the patrol incorrectly. Conversely, a timestamp on its own does not establish everything that happened at the site.

Use the timestamp definitions documented by your software, and check the report's timezone before comparing it with shift schedules. Device clock settings and clock changes also deserve attention during a pilot. Do not assume that every system handles them in the same way.

Test the whole path before deployment

Use a demonstration account or an agreed test route. Keep the exercise separate from live safety or emergency procedures.

1. Record a normal checkpoint visit while connected and note what the app and dashboard display.
2. Turn off connectivity on the test phone and record another visit, following the product's documented offline procedure.
3. Add a sample incident with a clearly labelled test note. If photos are part of your workflow, use a non-sensitive test image.
4. Restore connectivity and follow the documented synchronization steps.
5. Compare the phone, dashboard and exported report. Check timestamps, checkpoint identity, notes and any retry behaviour.

The useful result is an observed workflow: what remains visible while offline, what confirms successful upload and what the supervisor sees afterward. Do not infer successful synchronization merely because the phone has a signal again.

Make handover explicit

A short handover checklist can prevent a missing upload from becoming an unexplained gap:

• Confirm which phone and account were used for the shift.
• Check for pending records or visible sync errors using the app's documented controls.
• Confirm that the expected route and checkpoint records appear in the dashboard.
• Escalate unresolved gaps with the relevant route, shift and observed error details.
• Preserve unsynced data. Avoid clearing app storage, reinstalling or replacing the device until the recovery procedure is understood.

A missing record requires investigation. It should not automatically become a conclusion about an officer's conduct. Review it alongside post orders, incident notes and the system's documented behaviour.

Keep evidence proportional

A QR or NFC scan records a checkpoint interaction. It does not, by itself, prove that every inspection task was completed. Site procedures should specify what needs a scan, a checklist entry, a photo or an escalation. Collect only information needed for that purpose.

For a product example, PatrolTech's official demonstration introduces the patrol app and dashboard. PatrolTech guard tour software supports QR/NFC checkpoint recording, offline patrols and incident reports. Confirm the current app-specific steps in the tutorial library before running a pilot.

Published by Ingenieros Web SL, the company behind PatrolTech. Questions about this guide: info@patroltech.app.

A short test agenda

Use the 15-minute acceptance test to turn these checks into a repeatable demonstration with an evidence table and follow-up decisions.