Project · Energy & utilities
Energy field operations platform
Giving 260 field technicians an offline-first inspection and asset-capture tool that replaced paper forms and improved the quality of maintenance data.
The operating problem.
An energy operator’s field technicians carried paper inspection forms and re-entered results into the maintenance system at the end of each shift. The process was slow, prone to transcription error and produced an incomplete asset history.
Connectivity across the service area was unreliable. Any mobile solution had to work offline for a full shift and synchronise safely when the technician returned to a connected location.
The operational technology estate could not be replaced. The new platform had to integrate with the existing maintenance system and respect the constraints of the operational environment.
The challenge.
The visible problem was fragmented technology. The underlying problem was a process that depended on individual compensation.
- Paper forms produced inconsistent data and no photographic evidence.
- Technicians lost time re-entering information after a shift.
- Asset identifiers differed between the field, the maintenance system and the GIS.
- Supervisors had no view of work in progress or incomplete inspections.
What we found
The field crew was not resistant to digital tools. They were resistant to tools that slowed them down or lost data. The design had to be faster than paper for the common task and reliable in poor connectivity.
Asset identity was the hardest data problem. A technician might identify an asset by location, label or equipment type, while the maintenance system used a different identifier. A single scan or lookup had to resolve to the right record.
Safety evidence was a critical requirement. Photos, timestamps and location had to be captured in a way that could be trusted and retained.
How the work was structured.
Each stage produced a decision or an artefact that the next stage could rely on.
Shadow field work
We accompanied technicians on representative inspections, including remote sites and poor-connectivity areas.
Design the offline model
Define what data is available offline, how changes are queued, how conflicts are detected and how the user is informed.
Build the field app
Structured inspection forms, asset scanning, photo capture, safety observations and task status.
Integrate with maintenance
A controlled interface that created work orders and inspection records in the existing system of record.
Stage the rollout
One region and one inspection type first, with a support bridge and a paper fallback during the transition.
Difficult problems and how we resolved them.
The delivery was not a straight line. These are the issues that required a design decision rather than a task.
Offline synchronisation created conflicting edits.
We designed the app around an append-only event model for field observations, with conflict detection only where the same field was edited in two places. The user saw a clear resolution screen rather than a silent overwrite. Most conflicts disappeared because the data model avoided shared mutable records.
Asset identification was unreliable in the field.
We combined QR scanning, location proximity and a searchable asset hierarchy. Where the scan did not match, the technician could select from nearby assets. Every selection was recorded so that the master data function could correct the underlying record.
The maintenance system could not accept the full inspection payload.
We split the integration into a work-order interface and an inspection archive. The work order carried the operational summary; the full evidence pack was stored in the platform and linked from the maintenance record.
Technicians were sceptical after a previous mobile rollout.
We ran the pilot with volunteers and measured time per inspection against paper. The first version reduced the form to the fields that were actually used, removed duplicate entry and worked offline. The pilot participants became the advocates for the wider rollout.
The result in operational terms.
Measures were agreed with the client before delivery and compared against a baseline. The figures below are client-reported.
Technicians completed inspections in the app and synchronised automatically, removing the end-of-shift data entry. The time saved was redirected into additional inspections and follow-up work.
The quality of asset history improved because every inspection produced a structured record with photos and location. Maintenance planning had better evidence for recurring faults and service intervals.
What we would do differently.
Every engagement produces lessons. A project page that only reports success is not useful to the next client.
- Offline design is a data-model problem before it is a mobile problem.
- Field adoption depends on speed and reliability, not feature count.
- Asset master data requires an ongoing ownership model, not a one-off cleanup.
These lessons have been incorporated into how we scope and run similar engagements. They are part of the reason the approach pages are specific about decision points and exit criteria.
The disciplines behind the result.
Projects rarely use one capability in isolation. The links below show where the work sits.
Offline is a data design problem first.
The field application worked because the offline model was designed before the mobile interface. We defined which records could be created offline, how events were queued, which fields could conflict and how the user would resolve a conflict. The mobile screens followed from that model.
Delivery groups often treat offline as a synchronisation feature added to an online application. That approach produces silent overwrites, duplicate records and a user experience that becomes unpredictable when connectivity is poor. In field operations, connectivity is not an edge case; it is the normal condition.
The lesson is to design the data model for disconnected work, then design the interface for the task. The technology is secondary to those decisions.
Have a similar constraint?
Tell us what is not working. We will help you define a first step that produces evidence, not just activity.