A company with field staff had no way to confirm that a scheduled visit had actually happened and the contracted work was done, or to separately account for travel between sites in payroll.
We built a portal that confirms presence via the app's geolocation or a dispatcher call, pulls travel distance and time from a mapping service by tariff zone, stores a client-signed report, logs every change, and locks a closed visit against edits.
Payroll is calculated from closed, confirmed facts - visits, travel and signed reports - and managers and staff share one auditable history where every change is on record.
A slot on the schedule doesn't prove the work was done
When employees drive to client sites every day, a manager is left with three separate questions. Was the person actually there? Did they do what the contract calls for? How much time and money went into the drive between addresses?
A spreadsheet answers only the first question, and in its weakest form: it holds a mark that a visit happened. Behind that mark could be real work, a visit without the full set of services, or a "phantom" visit that exists only in the report. If the proof lives elsewhere, then payroll and any review have to piece the picture together from the schedule, phone calls, sign-offs, and the employee's word.
The company needed a system where every closed visit leaves a verifiable trail: why it came up, who was assigned, how presence was confirmed, what the client signed, how long the drive took, and what edits were made before it was closed.
A single visit starts with a request or a contract
Take an ordinary client visit. It appears in one of two ways: the client submits a request, or the scheduled service date under a contract comes due. The manager picks the person to send and assigns the visit to a specific day. The employee sees the address and time in their own schedule.
From there the record has to travel the whole way to payroll. The employee arrives, confirms presence, performs the work the contract requires, and gets the client's signature. After review the visit is closed, and its time, travel, and documents feed into payroll.
There are two ways to check in on site
The main option is the mobile app. The employee marks the start of the visit, and the portal compares the phone's coordinates with the client's address and checks whether the device falls within an acceptable radius.
But a visit doesn't happen under ideal conditions. A site may have no internet, the app may be unavailable, and the phone may fix its location inaccurately. So there is a second path: the employee calls the office, and a dispatcher confirms the visit by hand.
The manual option doesn't masquerade as an automatic check: the history shows which method confirmed a given visit. This keeps the work flowing without a connection while never passing off a call to the dispatcher as the device's geolocation.
Travel between clients becomes part of the calculation
A field employee's work isn't only the time on site. Between two addresses they drive, and the contract may account for mileage and travel time separately.
The territory is divided into zones - cities and districts. Each pair of zones has its own payment rule. A trip may be billed in one direction and not in the other, or calculated under different terms: the system doesn't assume every route is symmetrical.
The distance and duration of a trip are taken from an external mapping service on the day of the visit. What enters the calculation is the route and traffic of that day, not an averaged figure once written into a reference table. Under the contract's rules, mileage, time, or both are paid.
This level of detail removes the argument over "how long the drive between these addresses usually takes." Instead of a rough estimate, what remains is the route, the trip date, the zones, and the rule that produced the amount.
The client confirms not just presence, but the result
Coordinates show that the phone ended up near the site. They say nothing about the work performed. So before leaving, the employee fills out a sign-off: they note what they did and get the client's signature.
The administrator checks the sign-off against the contract. If the visit was supposed to include several required actions, the document shows which of them were completed. An incomplete set of services can't be hidden behind a general "was on site" mark.
The signed sign-off becomes a second, independent confirmation of the visit. Geolocation answers the question of place; the document answers the question of what work was done. If the app didn't work and a dispatcher logged the visit, the client's signature preserves an outside confirmation that the employee really did arrive.
A closed visit can't be fixed after the fact
Before closing, plans can change: the manager moves the time, assigns a different person, or clarifies the status. The system records every such action - who changed what and when.
After closing, the visit and the signed sign-off become immutable. Neither the employee nor the administrator can quietly rewrite them. If a dispute over payment or the scope of work comes up later, the system still holds the final document and the full history of actions leading to it.
This matters both for an internal review and for an outside audit. An auditor isn't shown a spreadsheet that could have been edited yesterday: they see the assignment, the confirmation method, the client's sign-off, and the sequence of changes.
Payroll is assembled from closed facts
At the end of the pay period, the portal totals the confirmed visits, their duration, the billable travel, and the signed sign-offs. The rate is applied to data that has already been through the working process, not to a separate report from the employee.
A missing sign-off means the work isn't fully confirmed, and that shows up in the pay. The same goes for travel: it enters the total under the rules of the zones and the contract, not automatically for any movement.
For the employee this kind of calculation is more transparent too. It's clear which visits are closed, what time is counted, why a particular trip was paid, and which document is missing. A dispute can be worked through against a single history, without reconciling several versions of the schedule.
One signal can be wrong; several give context
The hardest part of the system is proving a person's physical presence outside the office. The only digital source on site is the employee's own phone, and its geolocation and connection don't guarantee perfect accuracy.
So the portal doesn't build trust on a single signal. Each mechanism answers its own question and offsets the weaknesses of the others.
| Confirmation | What it shows | What it doesn't prove on its own |
|---|---|---|
| App geolocation | The phone was within an acceptable radius of the address | That the contracted work was done in full |
| Call to the dispatcher | The visit was logged without the app or internet | The phone's exact position by coordinates |
| Client-signed sign-off | The client confirmed the work listed in the document | The correctness of the route and travel pay |
| Change log | Who changed what and when before closing | The employee's physical presence on site |
If one of the pieces of evidence is missing or disagrees with the rest, it's visible before the visit reaches the final calculation.
The manager gets not a promise of absolute accuracy, but a set of pieces of evidence that agree with one another.
Where the system's accuracy ends
The portal doesn't improve the phone's signal or invent the payment rules. The accuracy of the location check is limited by the device's coordinates, the distance and travel time come from an external mapping service, and the tariff zones, mileage, and route symmetry are set by the contract. These terms have to be configured correctly and kept up to date as things change.
The system doesn't replace the manager's oversight and doesn't declare any single technical signal the final truth. It brings the schedule, coordinates, manual confirmations, sign-offs, and edit history together into one picture - one you can make a decision from and explain to an employee, a client, or an auditor.
Oleksandr
This is a real project, presented anonymized. We deliberately change the identifying details - the industry, the specifics, anything that could point to the client - and we don't reveal the client's name or trade secrets. What stays intact is the substance: the problem we solved and the engineering approach behind it. This case study is here to show the problem and its solution - what we do and how.