Field service workers do not usually disappear. The proof they were there is what goes missing. It lands in a paper log at the job site, in a text to the dispatcher, or in an app that worked fine until the phone died at the 4-hour mark.
How time gets captured in the field
A cleaning crew rotates through six buildings on a janitorial route, and there is no single time clock anywhere on that route. The crew uses whatever exists at each job site, which is rarely the same thing twice.
One site has a paper sign-in sheet on the supervisor's clipboard. At another, the supervisor texts the dispatcher at shift end with the crew count and the hours. A third site runs a digital kiosk that belongs to the building owner and does not export anywhere useful. Then there is the app the company paid for. Some workers downloaded it, some did not, and it logs correctly when the GPS cooperates and quietly drops entries when it does not.
Calling this a time-tracking failure misses what is actually wrong. It is a format problem. The hours exist, scattered across a paper log that arrives by Tuesday, a supervisor's phone, a third-party kiosk, and a cloud app that covers 65 to 70% of the workforce on any given week.
What Friday looks like
The coordinator does not spend Friday calculating payroll. The job is to reconstruct one coherent record from those four sources, apply client bill rates and worker pay rates that may have changed since last month, and hand off something both the payroll processor and the invoicing system will accept.
Take a worker who moved from Site A to Site B mid-week. The two sites carry different bill rates. The coordinator has hours in two sources, and one of them lists the wrong site. Buried in an email chain is a rate adjustment for Site C that took effect six weeks ago, and nobody is certain it has been applied since. Three workers show no hours for Monday because the paper form from that building has not shown up, so the coordinator cannot tell whether they skipped the shift or the form is still in the mail.
The six hours this week-end close eats are mostly phone calls and email threads. Once the record is clean the arithmetic takes minutes. The record is almost never clean when it lands.
The exception problem
Every payroll reconciliation splits into two buckets: clean hours and exception hours. Clean hours are the bulk of it. The coordinator knows the worker, knows the site, knows the rate, and the hours showed up in a usable format. That part takes thirty minutes.
The exceptions swallow the other five and a half hours. They are not complicated. Each one just forces a decision. Is this missing entry a no-show or a late paper form? Did this classification mismatch come from a data error or a reclassification nobody mentioned to the coordinator? Is the overtime flag a genuine event, or did two entries at the same site get counted twice?
Every one of those questions has an owner somewhere, a supervisor or the operator or the site manager, and tracking that person down on a Friday afternoon takes as long as it takes.
When the system closes the gap
A better app the workers will keep ignoring does not fix this. What fixes it is a reconciliation layer that pulls in all the existing sources, normalizes them into one ledger, and hands the coordinator a queue of exceptions instead of a spreadsheet they have to comb through alone.
We built precisely that for one commercial staffing and field service operation. The weekly tool takes paper-digitized hours, structured supervisor intake, and app sync data, then applies client bill rates and worker pay rates from an editable table the owner controls. It flags every anomaly (a shift mismatch, an unknown classification, hours past a configurable threshold) and lays them out as a numbered list, each with the source record and a fix input.
A clean week shows total hours, total invoiced, total payroll, and zero exceptions, with one click to export. A problem week shows the exception list. You fix the item, re-run, and export. The detective work stays. It just becomes specific and finite instead of an open-ended Friday-morning puzzle.
Before you build
The tool only works once the rates live somewhere other than the owner's memory. The first step in an engagement like this is getting the bill rate table and the pay rate table into a document, any document, even a CSV, and confirming it is actually current. That usually burns a day and turns up discrepancies nobody saw coming.
The second prerequisite is knowing where the paper actually comes from. If three sites still run paper logs, you need to know how those logs arrive and whether they are consistent enough to parse. Some are. Some are not, and the fix for those sits upstream, in a structured intake at the site rather than a smarter parser at the back end.
Start with a source audit. Name every time-tracking channel, count how many entries per week arrive from each, and measure the share that come in clean against the share that need a human to intervene. An afternoon of that tells you whether you are looking at a format-normalization problem or a decision-ownership problem, and those two need different solutions.