GPS-Locked Field Service App Case Study: Replacing Emailed Reports with Verified Technician Visits
See how we built a GPS-locked field service app with photo validation that eliminated mismatched photos and admin data entry. Real case study with route optimization and on-device AI checks.
Case Study Highlights
Problem: Wrong photos attached to wrong locations, unusable image quality, admins manually re-entering report data
Solution: GPS-locked mobile app with in-app photo capture, AI-powered blur and luminosity checks, and digital sign-off
Systems: Custom admin platform + mobile app, integrated with existing assignment and scheduling system
Result: A field service app where every photo is GPS-verified, checked for clarity and luminosity on-site, and always attached to the right location. No more manual data entry, no more mismatches
Our client is one of the UK’s leading facilities management companies. Their pest control division runs a team of technicians who visit sites for inspections. The process worked, but it leaked time at every step. A technician would visit multiple locations in a day, take photos at each one, and email everything back to the office in a report. Some technicians were thorough: photos were clearly labelled, reports were detailed, everything matched up. Others were not. Photos would arrive in a batch with no indication of which site they belonged to, reports were filled in with the bare minimum, and the admin team was left to piece it together or chase the technician for answers.
The photos themselves were another problem. Out-of-focus shots, motion blur, underexposed images from poorly lit rooms, overexposed shots washed out by sunlight. Nobody caught these issues until an admin opened the report hours later, by which point the technician had already left the site.
Everything That Was Going Wrong
Before they came to us, the process looked something like this:
- A visit gets assigned through an internal scheduling system
- The technician gets an address and a rough timeframe
- They drive to the site, take photos on their phone, fill in a Word document template
- They email the completed report and photos back to the office
- An admin opens the document, extracts the details, and enters everything into the system
There was a template, so the reports had some structure. But “some structure” and “machine-readable” are not the same thing. The Word documents still had to be opened one by one, and an admin had to pull out the relevant fields and manually enter them into the client’s system. Technicians filled in the template with varying levels of detail and consistency, so the admin was always interpreting, not just copying. We ran into a similar workflow with an event photography agency where admins were manually branding and zipping photos that photographers uploaded to Google Drive the next day. If photos were attached to the wrong location, the admin had to figure that out and fix it. If a photo was too dark or blurry to use, they’d have to request a new one, but the technician had already left the site.
On top of that, technicians sometimes couldn’t find the address and wasted time driving around. The visit order was up to the technician, not an optimised route, so they’d criss-cross the same area twice.
The client knew exactly what they wanted: a system where the technician physically has to be at the location to file the report, where photos can never get mixed up between sites, and where the data goes straight into the system without an admin retyping it. They brought it to us at SaaS Glue.
What We Built
Two pieces: an admin platform for the office, and a mobile app for the field.
The Mobile App
Each technician opens the app in the morning and sees their visits for the day, ordered by the most efficient route. The route planning pulls from the scheduling system the client already uses, so nothing changes on the admin side of assigning work.
When a technician arrives at a site, the app checks their GPS position. If they’re not close enough to the location, they can’t start the visit. No exceptions. This was non-negotiable for the client. They’d had too many cases of reports filed from the wrong place, or filed without the technician actually being there.
Once the GPS check passes, the technician works through a set of forms specific to that visit type. Photos are taken directly inside the app, not with the phone’s camera roll. As soon as a photo is captured, an AI-powered quality checker running locally on the device scans it for blur (both motion and focus) and luminosity problems (too dark, too bright, bad exposure). This runs entirely on-device, so it works even without a network connection. If the image fails, the app tells the technician right there so they can retake it before leaving the site. No more unusable photos discovered hours later by an admin.
When everything is filled in, the technician signs the report on screen and closes the visit. The app moves them to the next location.
The Admin Platform
Admins see every visit as it happens. Reports come in structured and complete: form fields filled, photos attached to the correct location, GPS coordinates confirmed, technician signature included. The data goes straight into the system. No retyping, no assembly, no chasing technicians for missing details.
Because the photos can only be taken inside the app, at the verified location, admins know that what they’re looking at is correct. That was the whole point.
The Scheduling Integration
The client already had field service management software for assigning technicians to locations and managing schedules. We didn’t replace it. The mobile app pulls assignments from it, adds route optimisation on top, and pushes completed visit data back. The admin team kept their existing workflow for planning and dispatch. The only thing that changed was the field side of the process.
Keeping It Running
A system that connects a mobile app, an admin platform, and a scheduling system has a lot of moving parts. If any one of them drifts, the whole thing stops being trustworthy. The scheduling API might change, the on-device photo validation model might need tuning as technicians start using different phones with different camera characteristics, or a new form type might surface an edge case nobody anticipated.
We set up monitoring with Grafana and Rollbar to keep an eye on the health of each integration point and the mobile app itself. Rollbar tracks crashes, errors, and unexpected behaviour on the app side, so if something breaks on a specific device or OS version, we know about it before it affects the whole team. Grafana monitors the backend: scheduling sync status, report submission rates, and system health. If anything looks off, we get alerted before the client notices.
Security matters here more than in most projects. The system handles location data, site photos, and inspection reports that are tied to real people and real locations. Data in transit is encrypted, access to the admin platform is role-based, and the mobile app authenticates against the backend on every sync. We treat this the same way we’d treat any system where a breach wouldn’t just be embarrassing but could compromise the client’s operations and their customers’ trust.
We have an ongoing support agreement with the client. When something needs fixing, updating, or reviewing, it gets dealt with promptly instead of sitting in a backlog.
What Actually Changed
The before-and-after here is straightforward. Before: emailed reports with mismatched photos, admins retyping everything into the system, blurry or dark images discovered too late to fix. After: every photo is locked to a GPS-verified location, checked by AI for blur and luminosity on the spot, and the structured data feeds directly into the system.
Technicians spend less time on the road because the route planning cuts out the backtracking. They don’t write up reports after the fact because everything is done on-site in the app. And they don’t show up to wrong addresses anymore because the app has the location pinned.
For the admin team, the manual data entry is gone. Reports arrive structured and correct. They review rather than reconstruct.
Frequently Asked Questions – Technician Visits
Does this work with any scheduling system?
It depends on the system, but we build integrations for a living so it’s rare that we can’t connect to whatever you’re already using. If it has an API, we can probably work with it. If it doesn’t, we’ll be honest about the options.
Can technicians use it offline?
Yes. The app caches the day’s assignments and form templates, and syncs completed visits when a connection is available. GPS verification and the AI photo quality checks both run locally on the device, so the core workflow works regardless of signal.
How strict is the GPS lock?
Configurable. The client in this case wanted a tight radius, essentially “you need to be standing at the building.” Other setups might allow a wider area depending on the type of work.
How long did the build take?
About four months end to end. The MVP with GPS-locked visits, photo capture with validation, and the admin dashboard was ready in about three months. The scheduling integration added a few more weeks on top of that, as the client’s dev team had other priorities at the time so coordination took a bit longer.
What does it cost?
This covered a lot of ground: mobile app, admin platform, scheduling integration, and AI-powered photo validation. We started with a discovery phase to map out the full scope, then split the work into stages so the client could see progress and give feedback at each step. Pricing depends on how many systems are involved and how deep the integrations go. We always start with discovery and quote from there.
If you’ve got a workflow that relies on manual steps, email chains, or people re-entering data that should flow automatically, drop us a message. At SaaS Glue, we’ll have a look and tell you straight what we think.
You can also see more of our work or read our manifesto to understand how we approach these problems.