Your Field Team Still Runs on Paper. Here's What Replacing It Actually Costs

Where paper actually costs money

Paper itself costs almost nothing. Here's the deal: what costs money is everything that happens to the information after it's written down. Someone re-typing it into another system. Someone misreading handwriting. An invoice waiting for a ticket to physically make it back to the office. A job logged from memory at the end of a long shift because the paperwork got left in the truck. None of that shows up as a line item on its own. All of it shows up later — as staff time, correction time, and cash that arrives slower than it should.

The clearest version of this is re-keying, and you can spot it in your own office this week. Every time a field worker fills out a paper ticket, and someone later types that same information into an invoicing system, a scheduling tool, or a spreadsheet — you are paying twice for one piece of information. Once to capture it. Once to transfer it. That transfer step is also where transcription errors get introduced: a wrong quantity, a misread part number, an address copied incorrectly. Each error then has to be caught and corrected by someone else, later, when it costs more to fix than it would have the first time.

What the number looks like once you add it up for a month

A daily figure is easy to shrug off. Extend it out and it usually isn't small. Take the same illustrative math — 80 minutes a day of re-entry for a 20-job crew — across a 22-day working month, and you get roughly 29 hours. Close to four full working days, spent moving information a field worker already wrote down once. That's before adding the hours lost to correcting errors or chasing down a dispute with no evidence behind it. Run your own daily figure out to a month, then to a year. Then you decide whether the problem is big enough to act on.

Disputes with no evidence cost more than the job itself

When a customer disputes whether a job was done, whether it was done correctly, or what time a crew arrived and left — a paper record backed only by a signature on a clipboard is weak evidence. It proves someone signed something. Not what actually happened at the site. A timestamped photo of the completed work, a GPS-verified arrival and departure time, and a digital signature captured on-site turn a dispute from a memory contest into a records check. That difference matters most on the jobs where a dispute is expensive: warranty claims, insurance work, a customer who disputes the invoice outright. Memory is the weakest part of any manual process — and a dispute is exactly the moment someone ends up relying on it.

How to calculate your own number, not a vendor's

A vendor's ROI calculator is built to produce one thing: a number that justifies their product, using assumptions about your business that are rarely stated and rarely true for your specific crew. Building your own takes about the same effort — and gives you a number you can defend to a business partner or an accountant. It holds up regardless of which vendor, or whether any vendor, you end up choosing. It also changes every sales conversation you have after it, because you arrive with the arithmetic already done.

1. 1Count how many field tasks — jobs, visits, deliveries, inspections — your team completes on an average day.
2. 2Time how long the paper-to-system re-entry takes for one ticket, from landing on a desk to being fully entered.
3. 3Multiply tasks per day by re-entry minutes, then by the fully-loaded hourly cost of the person doing the entry. That's your daily admin cost.
4. 4Separately, estimate the hours per month spent chasing disputed jobs, correcting transcription errors, or recreating a ticket that was lost or illegible.
5. 5Add the two figures and multiply by 12 for an annual number. That's the figure a field app has to beat — not a number from a sales deck.

Native, cross-platform, or PWA — a business decision, not a technical one

The technical choice between a native app, a cross-platform app, and a browser-based progressive web app (PWA) matters less than which one fits how your crew actually works. Which puts the decision in your hands, not a developer's — it needs no technical knowledge, only your constraints stated plainly. Treat it as a cost-versus-capability trade-off. Not a question of which option is more modern.

• Native (built separately for iOS and Android) gives the most reliable access to the phone's camera, GPS, and offline storage — usually the smoothest experience, at the highest build and maintenance cost, since it's effectively two applications.
• Cross-platform (one codebase producing both an iOS and an Android app) covers most field-service needs — offline storage, camera, GPS — at a lower cost than native, with a small trade-off in how deeply it can use device-specific features.
• A progressive web app (a mobile-optimized website that can be added to a home screen) is the cheapest and fastest to build. But it has real limits on offline storage and hardware access that matter a great deal for field work specifically.
• The right answer depends on how much your workflow needs real offline storage and hardware access, versus how much it needs to be inexpensive to build and maintain. Not on which option sounds more advanced.

Offline capability is not a nice-to-have for real field work

An app that assumes a working internet connection is an app built for an office. Not a job site. Basements, rural routes, parking structures, plenty of ordinary neighborhoods — they all have dead zones, and you know exactly where yours are. A field app that can't save a completed job until it finds signal again is an app your crew will stop trusting the first time it loses an hour of work. Offline capability means the app captures everything locally on the device the moment it happens, and syncs automatically the next time it has a connection, with nothing lost in between. For real field work, this is not a feature to compare. It's a minimum requirement to screen for before looking at anything else.

When a field app is not worth it — the honest section

Paper being irritating does not automatically make a field app the right call. Here are four real conditions under which the cost won't be recovered — the ones a vendor with something to sell you is unlikely to raise first. Check your own crew against them before anyone quotes you.

• Low job volume: Anito's own published diagnosis guidance uses about 15 field tasks a day as the rough line below which a native app may not recover its cost within 12 months. Treat that as a starting point to test against your own numbers, not a hard rule. If your crew handles meaningfully fewer field tasks than that, the fixed cost of building and maintaining an app is spread across too few jobs to pay for itself in a reasonable time.
• Highly variable work: if no two jobs follow a similar pattern, a structured digital form fights the work instead of fitting it. Your crew will find workarounds that put you back on paper anyway — with extra software layered on top.
• A crew that will not adopt it: an app that gets left uninstalled or ignored in favor of the old paper habit is worse than doing nothing. Now you've paid for software, and you're still running on paper underneath it.
• A workflow that changes faster than you can afford to update the app: if your process is still being figured out, building rigid software around it locks in a version of the process that may be wrong in three months.

There's a fifth condition that rarely makes it into an ROI spreadsheet: adoption. The most common way a field app fails isn't a technical failure. It's a crew that quietly goes back to paper because the app was slower, confusing, or built around what the office wanted to see — rather than what the person standing at the job actually needed to do in under a minute, with greasy hands, in bad light, with a customer waiting. That's the crew being right, not difficult. An app has to be faster than paper at the exact moment someone is using it, or it loses to the clipboard every time, regardless of how good the reporting looks afterward.

A simple way to test before you commit

None of this requires a finished app, a developer on retainer, or a signed contract. It requires one afternoon, one paper form digitized by hand, and a willingness to find out the honest answer — including the answer that paper is still the right tool for now. You can run the whole thing yourself, before anyone quotes you a number.

1. 1Pick your single most common field task and sketch, on paper, exactly what a digital version of that one form would need to capture.
2. 2Have one or two field workers try filling it out on a phone — including with the WiFi turned off — before any real development starts.
3. 3Ask them directly what was slower than the paper version, not only what was different.
4. 4Estimate the cost using your own numbers from the calculation above, not a vendor's average.
5. 5Only then make the call: build the smallest possible version first, or accept the honest answer that paper is still the right tool for a crew your size.