Why Field Data Goes Bad Before It Reaches the Office
The Data Was Right When Someone Saw It
The numbers are in the system. The reports run on time. Dashboards refresh, and nobody in the office asks how any of it got there. They ask what it says.
But field data rarely arrives wrong. It degrades on the way in. This piece walks through five places where that degradation happens and what, if anything, can be done about each one.
Between the Clipboard and the Keyboard
A technician writes a reading on site. Maybe it goes on a form, maybe the back of a work order, maybe a scrap of paper wedged into a clipboard. At some point that value travels back to the office and someone keys it into a system. The person typing was not the person who took the reading. They are working from handwriting, sometimes their own, often someone else’s. A seven becomes a one. A decimal shifts. Nobody notices because the number that lands in the database is plausible enough.
How often does this actually happen? There is one study worth citing carefully. In 2019, Mays and Mathias published a paper in the Journal of the American Medical Informatics Association (doi:10.1093/jamia/ocy170) examining 6,930 point-of-care glucose results that were both captured automatically from the instrument and re-typed into the record by clinic staff. Of the hand-typed entries, 260 did not match the automated result. That is 3.7 percent. Setting aside entries with stray non-numeric characters, 3.2 percent were mistranscribed numbers. Thirty-seven entries were off by more than 20 percent.
The authors are careful about what that means. Around 5 in every 1,000 results carried a clinically significant discrepancy, and they describe their overall error rate as lower than earlier measurements of transcription error in outpatient care. So this is not a horror story. It is a baseline, and a fairly optimistic one.
But here is what I keep coming back to: in that study, the correct value was already on the screen. The instrument had captured it. The staff member had the right number in front of them and still, roughly one entry in twenty-seven drifted. A value copied off a clipboard back at the office has no automated reading beside it to disagree with. There is no second column to compare against. If the typed number looks reasonable, it sticks.
Capturing data at the point of observation removes that second transcription step. It does not make typing infallible. People still fat-finger entries on a phone screen. But it eliminates one entire opportunity for a value to shift, and that opportunity is the one with no safety net under it.
Photographs Nobody Can Place
A worker takes a photo on a personal phone. It lands in a camera roll between a picture of someone’s lunch and a screenshot of weekend plans. Or it goes into a group text thread where it sits alongside twelve other photos from twelve other jobs. The photo exists. The problem is tying it to anything.
The cost shows up later, when someone needs to find the image. They scroll. They squint at backgrounds trying to figure out which site they are looking at. Where photographic evidence is written into the contract or the inspection scope, a missing image can mean a return trip to a site where the work was already done correctly. That is a truck roll and a crew’s afternoon, spent proving something that was true the first time.
A photo taken inside the form carries the job ID and a timestamp without anyone labeling it. That much works. Location metadata sounds like it should help too, but basements and steel structures break GPS the same way they break a cell signal, so treat coordinates as a bonus, not a guarantee.
Paperwork Written from Memory
A technician hits four sites before lunch. By the time they sit down with the forms at the end of the day, the visits have started to blur. Details from one stop bleed into the next. Timestamps become estimates rounded to the nearest half hour. Anything not written down at the time gets reconstructed from thin notes and whatever sticks in memory after a full day of work.
This is not carelessness. It is the predictable result of asking someone to document eight hours of field work in a single sitting. The technician remembers the problems, the callbacks, the things that broke routine. The routine stuff, the normal readings and standard conditions, all compresses into a single mental image that gets copied across forms.
These records pass a glance. They look complete. They fail under scrutiny, the kind that shows up during a dispute or a warranty claim, when someone needs to know exactly what was observed at a specific site on a specific afternoon. At that point the record does not reflect the visit. It reflects a reconstruction.
How many of your crews fill in their paperwork at the site, and how many do it from the truck at the end of the day?
Eighty Forms, and the Drift Between Them
Version drift is quieter than transcription error but just as damaging. It works like this: a company has a standard inspection form. A compliance field gets added for one client. A section gets removed for another. Someone creates a variant for a specific jurisdiction. Over time, dozens of versions exist, and whichever one is handy gets used.
Aquila Inspection Services, a Florida construction inspection company, maintained more than 80 separate inspection forms because every variation required its own version. In a published case study, co-owner Scott Porter described what that cost: “Every variation required its own form,” he explained. “Maintaining them, updating them, keeping them consistent … It took a huge amount of time and created room for user errors.”
Eighty forms means eighty things to update when a field changes. In practice, not all eighty get updated. A crew grabs an old version. A required field is missing. The data comes in incomplete and nobody realizes it until someone downstream needs the value that was never collected.
Aquila consolidated those 80-plus forms into five core forms using Appenate, each built with dynamic logic so a single template could cover multiple use cases.
The vendor matters less than the principle. When form variants collapse into a few maintained templates, version drift has nowhere to live. One form updates in one place, and every crew pulls the current version.
The Tool That Needs a Signal
Purpose-built field data tools have handled offline capture and deferred sync for years. This is standard, not a feature to shop for. The real failure happens when a team reaches for the form tool the office already owns: a Google Form, a SharePoint list, a web form on the company intranet. Those need a live connection.
On a rooftop, in a basement mechanical room, at a rural site with one bar of signal that comes and goes, the form will not submit. Entries wait. And what waits gets written somewhere else, a notebook, a text message, or nowhere at all. Gaps in the record are the one kind of data loss you cannot reconstruct afterward, because nobody remembers what they did not write down.
Before you send a tool to the field, put a phone in airplane mode and try to finish a form on it. If it will not let you, your crews already know that, and they have been working around it.
What to Do with This
Every failure described here is a gap between seeing and recording. A reading observed and re-typed later. A photo taken and separated from its context. A form filled from memory instead of from the moment. A template grabbed from the wrong pile. A tool that will not work where the work happens.
Closing that gap is the whole discipline. But it is worth being honest: the tools that close it relocate complexity rather than removing it. Someone has to build the forms, maintain the templates, configure the sync, train the crews. The work shifts from data cleanup after the fact to system design before deployment.
Five failure points. For each one, you either have a process that addresses it or you are relying on the people in the field to compensate. Worth checking which.
Kendall Kunz is Chief Revenue Officer at Appenate, a platform for mobile data collection in field operations. He writes about the practical side of getting accurate data from jobsites to dashboards.
