Every workaround in the field is a rational answer to an interface designed by someone sitting down.
Drivers and crews record work standing up, one handed, often with no signal. We build the capture and the proof for the conditions the job is actually done in.
The office system needs every row true at the same moment.
Illustrative pattern. Nothing on this page is read off this drawing, and no cell is a duration.
Three things a desk-shaped system does to a field team.
None of these is carelessness. Each is the cheapest correct move available to someone with a job to finish and a system that will not let them finish it where they stand.
The work is done and the record is not
The job finishes at a door, in a plant room or in a basement car park. The record needs a network that place does not have, so it gets written later, from memory, by someone who has since done nine more jobs.
A second system appears, and it is a phone camera
The paper docket gets photographed and sent to whoever will type it in. It is faster than the app, it works everywhere, and it produces nothing your business can query, reconcile or bill from.
The record ends up written by someone who was not there
The office closes the job from a phone call, or the week of vehicle checks is filled in on Friday afternoon. What you hold is then a claim about an event that nobody present recorded, which is precisely what a dispute or an inspection asks you to produce.
What we build, and what it has to survive.
Six capabilities, in the order they get built. The first carries the rest: if capture does not complete offline, nothing downstream of it is trustworthy.
Capture that completes with no network
The device accepts the job as finished, writes it locally first, and tells the person it is safe. Sending is the system's problem after that, not theirs. None of this gets planned off a coverage map: Ofcom predicts coverage in hundred-metre squares and says itself that such predictions are less helpful for understanding service in specific locations, which is roughly the size of a loading bay or a basement ramp. Offline is the default path, not a mode somebody has to remember to turn on.
Proof that still stands up months later
Signature, photograph, scan or a code read at the door, with the time, the place, the device and the account attached at the moment of capture rather than at the moment it finally uploads. The exception matters more than the signature. Under CMR a consignee who takes delivery without reservations is presumed to have received the goods as the consignment note describes them, and damage that is not apparent has to be reserved in writing within seven days, so "received unexamined" or "one pallet short" is the field that decides the claim. It is free text and a photograph, written at the tailgate, and it is the one most field apps do not have.
Checks and defects recorded where the check happens
DVSA accepts a daily walkaround check done on a handheld device and stored digitally, so the constraint was never permission. It is that a check completed in a yard is a different design from one completed at a desk. Defects raise themselves and go somewhere, and a clean check is recorded as a positive report that the vehicle is free from defects rather than as an absence of one.
One job, one truth, at both ends
The office and the field read the same record. Where they genuinely cannot yet, the system says which side is stale instead of showing both as current and letting two people act on different facts.
Connections into what you already run
Scheduling, stock, invoicing and payroll usually exist and usually work. The work is joining them to what actually happened in the field, not replacing them because they were easier to replace than to integrate.
Handover, so your team can change a form
Job types change when a contract changes. Whoever owns operations should be able to add a field or a photo requirement without waiting for a release, and that is a build decision made at the start or not at all.
This is not vehicle telematics and we do not build it. If your question is where the vehicle went, that is hardware and a subscription from a market that already answers it.
The job as the process has it, and the job as it is done.
One delivery, read down twice: the written process on the left, what the person actually does on the right. The chip says whether the difference is a fault or a fact to build around.
- As the process has itAccept the job on the device.As it is performed
Accepted in the yard before setting off, standing still, with signal and both hands free.
Holds - As the process has itComplete the vehicle check before first use.As it is performed
Done, and done properly, but tapped through beside the vehicle in the rain with gloves on, so every field that needs typing gets the shortest answer the form will accept.
Design around this - As the process has itNavigate to the delivery address.As it is performed
The address is right and the entrance is not. The way in is a gate at the back, and that lives in the last driver's head rather than on the job.
Fix this - As the process has itCapture the recipient's signature.As it is performed
Nobody is in. What is needed now is a photograph, a location, a named safe place and a reason, and the form has a signature box.
Fix this - As the process has itMark the job complete.As it is performed
Marked complete two floors underground, where nothing can leave the device. The office will not see it until the vehicle is above ground again.
Design around this - The process ends hereAs the process has itNot in the processAs it is performed
Photographs the paper docket and sends it to the office, because the docket is the thing the customer will dispute and the app has nowhere to put it.
Fix this - As the process has itNot in the processAs it is performed
Rings the office about the failed drop, because the app can record that it failed but not why, and somebody has to decide what happens before the next stop.
Design around this - As the process has itNot in the processAs it is performed
Writes the gate code in a personal notebook, because it is not a field on any form and it will be needed again next Tuesday.
Fix this
The three rows below the rule are worth arguing about. Two are a system missing a field. The third is a person exercising judgement, and taking that away would make things worse.
How the work runs.
The first two steps produce no software. The expensive mistake here is building against the process document instead of the actual job.
Do the round
A full shift with a driver or an engineer, including the parts nobody would put in a demo. What we are looking for is every moment the person works around the system, because each one is a requirement somebody already wrote.
Find where the record leaves the system
Every photograph texted, every call to the office, every note in a personal book. Those are the missing fields, identified by the people who needed them, at the moment they needed them.
Rebuild one job type, offline first
One job type, end to end, on the device, completing with the network switched off from the beginning. Not an offline mode added afterwards. The default path.
Rehearse the bad day
The device in a known dead zone, the app killed mid job, the same record edited from two places, the battery dying at the door. A sync design that has not been run against those is a guess.
Measure the round trip
From the moment the work finished to the moment the office could act on it. That is the number a field operation actually runs on, and almost nobody measures it today.
Widen, and hand it over
Further job types on the same foundation, added by your team where possible, with form changes owned by whoever owns operations rather than by whoever owns the release.
Before step three If the first two steps show that the constraint is scheduling or routing rather than capture, we will say so and the build gets smaller or stops. That is a legitimate outcome of the first fortnight and it is worth knowing that we treat it as one.
The one engagement that is directly this.
Most pages here reach for adjacent work. This one does not: Milo is a driver-facing fleet system we built, and every figure below is published by its own case study.
- Fewer dispatch calls, across 200+ drivers
- 80%Fewer dispatch calls, across 200+ drivers
- Accurate trip and shift logging, which is what ended the payout disputes
- 100%Accurate trip and shift logging, which is what ended the payout disputes
- Drivers on one interface, on low-end devices
- 0+Drivers on one interface, on low-end devices
- The window every figure above was measured in
- 60 daysThe window every figure above was measured in
- MiloA regional cab operator running 200+ drivers moved trip assignment, messaging, live earnings and attendance check-in onto one driver-facing app, replacing a phone-and-paper dispatch workflow.Read the case study
- VizitorArrival and contractor check-in across multiple sites, in daily use in 500+ workplaces across 15+ countries. Cited for the check-in journey and the multi-site operation, not as field or fleet work.Read the case study
Read those for what they are: evidence that a whole fleet adopted a driver-facing system on low-end devices. They are not evidence about your job types, and those numbers do not transfer.
See all case studiesWhat you are left holding.
All of it is yours at the end, and none of it needs us to stay for it to keep working.
The offline behaviour, written down
What is stored on the device, in what order it sends, what happens to two edits of one job, and what the person is shown at each point. The part most field apps leave undocumented is the part that breaks.
A proof record you could hand to a lawyer
For each completed job: what was captured, when, where, on which device, under which account, and what the person was looking at when they confirmed it.
The check and defect trail, retained
Daily checks including clean ones, defects, who reported them and what was done. A GB operator has to be able to produce a defect report and its record of repair for at least fifteen months, while a nil defect return is good practice at three, and those two numbers being different is exactly why one blanket retention setting is usually wrong.
The forms, editable by your own team
Job types and their fields, changeable without a deployment, because a contract change should not need an engineer and a release window.
The list of what we did not automate
Named, with the reason beside each one, so the next person to look at this does not spend a month rediscovering why a step is still done by hand.
What we will not build, and the number we will not give you.
We will not attach a percentage to your round, because we have no published field-operations result of our own. What we can name are the four cases where the answer is smaller work, or none yet.
A telematics system
Vehicle position, driving behaviour and engine data come from hardware and a subscription, and there is a mature market for both. We integrate with whichever one you have chosen. We will not sell you a replacement for it, and a consultancy offering to build you one should be asked why.
An app, when the problem is the schedule
If the round is planned badly, capture software makes a badly planned round easier to record. That is a scheduling problem, it has a cheaper answer than a build, and the first two steps of the sequence above are designed to catch it.
A process the operation has not settled
Where two depots do the same job two different ways and nobody has decided which is right, a build encodes the argument and makes it more expensive to finish. Settle it first, on paper, with the supervisors.
Anything that adds a step at the door
If the new system takes longer at the point of work than the paper it replaces, it will be filled in later or not at all. We would rather say that at the design stage than watch it happen to a system somebody has already paid for.
Where a figure matters to your business case, measure your own round trip first, from work finished to office able to act on it. That is what the assessment is for.
Start with a workflow assessmentWhat this connects to, and who builds it
Field work touches four other things this company does, and one thing it deliberately does not. This strip says which is which, including the row where the answer is somebody else.
- The app the field team is holdingMobile App DevelopmentThe device build itself, including the local store and the release path, is mobile app development.
- Getting a finished job into your back officeAI IntegrationJoining what happened in the field to scheduling, stock and invoicing is integration work.
- Once the record reaches the officeBack-office AutomationThe waiting between systems after the field has finished is a different problem with its own page.
- When the customer was never toldCustomer Experience AutomationThat page owns the promise made to the customer, and it routes back here when the promise fails in the field.
- Capture, proof and the offline caseField and Fleet Operations ยท you are hereWhat the person away from a desk can actually record, and what that record has to survive.
- Vehicle tracking and driving behaviourA telematics supplier, not usHardware and a subscription, from a market that already serves it well. We integrate with your choice.
Tell us about the job your team photographs instead of filling in.
There is one in every field operation. Describe it and a senior engineer will tell you whether it is a capture problem, a scheduling problem, or one form away from fixed.
What operations teams ask first.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.