# Why field data only reaches you at the end of the day > The record of what happens in the field is created hours later, typed by someone who was not there. That is an architecture decision, not a signal problem. - Author: Marlon Trettin - Published: 2026-10-13 ยท Updated: 2026-10-13 - Language: en - Canonical: https://yowpi.com/en/blog/why-field-data-only-reaches-you-at-day-end --- The data arrives late because the record is not created where the work happens. It is created hours later, at the office, typed by someone who was not there, from paper or a photo. Billing, proof of work and every metric inherit that delay. The decision is architectural, not a matter of signal. ## TL;DR - In a paired field comparison covering 1,068 interviews, paper capture produced a 5.1% error rate against 3.1% for electronic capture. Errors introduced afterwards, while transcribing into the database, were a further 208 occurrences, equal to 9.0% of the errors recorded, and were excluded from that comparison ([PLOS ONE](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0247570)). - In the same study, paper records took up to 5 working days to reach the database. Electronic records were available on sync, and fixing an error dropped from 1 or 2 days to immediate review. - Transcription consumed 180 hours over the period, validation included, roughly 3 hours per field day. That work exists only because the record was born on paper. - Coverage is a design requirement, not a reason to keep paper. As of January 2026, 96% of UK landmass had good 4G from at least one operator, but only 84% had it from all of them ([Ofcom](https://www.ofcom.org.uk/phones-and-broadband/coverage-and-speeds/connected-nations-update-spring-2026)). ## Why is the record created far from where the work happens? Because nobody decided where it should be created. The engineer writes on the job sheet, takes a photo on their phone, sends a message if they remember. At the end of the day someone at the office opens that material and types it in. That person did not see the visit. The effect is measurable. A study published in PLOS ONE in 2021 compared two ways of recording exactly the same field work: 1,068 face-to-face interviews, 27 variables per form, randomized to reduce bias between modes. Paper finished at 5.1% error, electronic at 3.1% ([Tate and Smallwood](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0247570)). The number that matters most to anyone running an operation sits outside that comparison. The authors logged 208 data entry errors, equal to 9.0% of the errors recorded, created after the work, at the office, when paper became a database. Because those errors are specific to the paper mode, the authors removed them from the 5.1%. The real distance between the two modes is wider than the published figure. Those errors are a side effect of choosing paper, not a failure of the field team. One caveat about the source. It is research by an Australian government department into recreational fishing, with no declared commercial interest, not a company measuring its own operation. What it isolates is a structural mechanic, and that mechanic reappears in any site visit, inspection or collection round: who records, when they record, and how many hands the data passes through before it becomes a record. The percentages belong to that field, not yours. What travels is the design, not the rate. ## How long does the data take to become usable? Up to 5 working days on paper, in that study. Sheets came back to the office the same day, went through manual validation, and only then entered the database. In electronic mode the data was available as soon as the device synced. The gap that hurts more is the repair loop. Fixing an inconsistency on paper took 1 or 2 days, depending on how far the crew was from the office. Electronic review was immediate, which meant errors were caught while the information could still be recovered. After a few days, memory of what happened no longer supports the correction. The error stops being fixable and becomes a permanent record, indistinguishable from any other. Add the direct cost: 180 hours of transcription over the period, validation included, roughly 3 hours per field day. That work exists only because the record was born in the wrong place. It does not show up as a systems cost. It shows up as one person kept busy in admin. The delay contaminates everything downstream. Billing closes on data that aged in transit. The productivity metric measures a week that has already gone. And the conversation with a client about what was actually done happens with nothing to support the company's version. ## Does poor coverage still justify paper? It justifies designing for poor coverage. It does not justify paper. The constraint is real and it has a known size. As of January 2026, 96% of the UK landmass had good 4G geographic coverage from at least one mobile operator. From all operators, that figure was 84%, up three percentage points on July 2025 ([Ofcom, Connected Nations update](https://www.ofcom.org.uk/phones-and-broadband/coverage-and-speeds/connected-nations-update-spring-2026)). Read those two numbers together, because the gap between them is the one your crew actually meets. Coverage from at least one operator is not coverage from the operator your team is on. Whoever buys the SIM contract is choosing which parts of the map go dark for the field team, usually without knowing it. The same study went through this. On some days the connection failed and syncing only happened when the crew returned to the office at the end of the field day. The authors note that the device and the application hold data until a connection appears, which works around the problem in remote areas. The record still came into existence at the time and place of the work. Only the transmission waited. That is the difference that matters. Paper delays the creation of the record. Offline mode delays only the sending. ## What changes when the record is created in the field Four decisions, and none of them is which app to buy. The first is who creates the record. If it is the person who did the work, the data has a witness. If it is the admin team, the data has a version. The second is when it starts to exist. Date and time captured by the device beat a date field filled in later from memory. The third is what travels with it: photo, signature, location, meter reading. An attachment captured on the spot becomes evidence. A photo sleeping in someone's personal camera roll becomes nothing, and it leaves the company when the employee does. The fourth is where that record then lives. An internal system that accepts entries created offline, resolves the conflict when two versions arrive, and keeps a trail of who changed what. Without that destination, a field app just swaps paper for a new spreadsheet, which is the pattern described in [migrating off spreadsheets without stopping the business](/en/blog/migrating-off-spreadsheets-without-stopping). That is what [Reatop, the hospital waste management system we built for Bumerangue](/en/cases/reatop), does with collection: the weighing and compliance record is created at the collection point, with or without signal, and the back office receives it when the device syncs. ## What this looks like in a maintenance operation A scenario, to make the arithmetic concrete. The numbers below are a working hypothesis, not a client measurement. A building maintenance firm with 12 engineers, 5 visits each per day, 60 job sheets daily. Every sheet leaves on paper and comes back with a photo on the engineer's phone. One person in admin types it all up the next morning. In that setup, Monday's billing is only ready on Wednesday. When a client disputes a visit, the company goes looking for the photo across three different phones. And the average response time metric measures what was typed, not what happened. None of this is fixed by asking the team to be more careful. All the field work was done. What is missing is the place where it should have been recorded, at the moment it happened. The same reasoning applies to the quality of the number that lands on the dashboard, which we covered in [how data quality prevents wrong business decisions](/en/blog/how-data-quality-prevents-wrong-business-decisions). ## Frequently asked questions **My field team is used to paper and spreadsheets. How do we switch without stalling the operation?** One flow at a time, starting with the one that has financial consequences, usually the job sheet. Run paper and system in parallel for a few weeks, with a defined cut-off date. In the PLOS ONE study, the five field officers found paper easier to handle in the first month. After changes were made to the application and the device based on what they flagged, all of them preferred electronic capture by the end. Five people is an indication, not a measurement. **Will integrating with our ERP and existing systems be complicated?** That depends on an earlier decision: which system is the source of truth for each piece of data. Once that boundary is set, the field record feeds one destination and the others read from it. Difficult integrations are almost always integrations without that definition, with two systems each believing they own the same record. **We have no technical team to implement this, or to maintain it afterwards.** That is a scoping decision, not a blocker. What has to stay in-house is the definition of the operational rules, because nobody outside knows which field is mandatory on your inspection. Building and running it can be contracted, provided the contract includes documentation and access to what was built. ## The next step If your operation records in the evening what happened in the morning, the next move is to map where each piece of data is created and where it should be. That is what the [Operational Architecture Diagnostic](/en/contact) does in 30 minutes.