Your assets are in the field, they outlive the software written for them, and every visit costs a van. We build for that shape of problem.
Estates in this sector are layered: equipment bought fifteen years apart, speaking different protocols, none of it replaceable on a software timetable. We build the ingestion layer to absorb that rather than fight it, normalising each source into one shape and keeping the raw payload so a decoding mistake can be re-run rather than lost. New hardware becomes another adapter instead of another system.
An app that needs a connection is an app your crews will stop using, because the places that need visiting are the places with no signal. We build offline first: the job, the history and the forms come down with the van, the work is recorded where it happens, and the sync resolves when coverage returns. Photographs, readings and sign offs attach to the asset, so the next person to visit it knows what the last one found.
Readings are worth more as an alarm than as a report. We put thresholds and pattern checks on the data as it arrives, so an unusual consumption or a stalled meter opens a job the same day rather than surfacing in a monthly review. The same record then produces the regulatory reporting directly, which removes the quarterly exercise of rebuilding numbers in a spreadsheet and hoping the exports lined up.
Data from the field arrives wrong often enough that treating it as fact is the most expensive assumption in this sector. Clocks drift, so intervals land in the wrong hour. A meter exchange produces a reading lower than the last one and a consumption figure that is negative. A comms failure leaves a gap, which is not the same as zero usage, and a device that reboots will happily send the same interval twice. So validation runs on the way in: against the previous read, against a plausible range for that asset, against the calendar, with the failures held for review rather than silently corrected into something tidier. Estimates stay labelled as estimates all the way to the customer, because an estimate presented as a reading becomes a complaint, then a credit, then a regulatory statistic.
Every decision in a system like this is worth testing against whether it removes a visit or causes one. A wasted journey is a crew, a vehicle, a booked appointment window and an annoyed customer, and the usual causes are dull ones: the wrong part on board, no access to the site, a job raised without the asset details, or work that needed an isolation and a permit nobody arranged. So the scheduling has to know what the job genuinely requires, the app has to carry the asset history and the last engineer's photographs, and the safety documents, permits and lone worker check-ins have to be part of the job rather than a separate paper process living in the cab. The measure worth watching is jobs completed on the first visit.
One layer that normalises whatever the estate sends and keeps the raw payload, so a decoding mistake can be re-run rather than lost. New hardware becomes another adapter instead of another system.
What you own, where it is, which generation it belongs to and what has been done to it. Most utilities have three partial versions of this and no agreed one.
Offline first, because the assets that need visiting are the ones without coverage. The job, the history and the forms travel with the van and the sync resolves on the way back.
Jobs matched to crews by skill, certification, geography and the parts already on the van, with the appointment window treated as a promise to a customer rather than an internal estimate.
Thresholds and pattern checks on readings as they arrive, so an unusual consumption or a stalled device opens a job the same day instead of surfacing in a monthly review.
Regulatory returns and internal reporting generated from the record, with the lineage kept, so a challenged figure can be traced back to the readings it was built from.
The control side of the estate, kept deliberately apart from anything office facing. We read from it where a read only path exists, and we do not ask for more than that without a very good reason.
Whatever gathers reads from the field, on its own schedule, in whichever generation of protocol the devices speak. Its collection window sets the earliest moment anything downstream can be true.
Where an asset actually is and what it connects to. Positions recorded to the nearest street rather than the nearest metre will send a crew to the wrong side of a road.
EAM, CMMS or field service platforms holding maintenance regimes and job history. We build against them so a job raised by an alarm lands in the queue crews already work from.
Where a reading turns into money. This is why validation matters upstream, because a bad read reaches the customer as a bill and comes back as a complaint with a deadline attached.
Submissions and exchanges with whoever settles your market, on formats and deadlines you do not control. Late or rejected files are expensive in a way internal reporting never is.
Not the whole estate. Take the generation causing the most manual work, get it landing cleanly with its raw payload kept, and use it to prove the pattern before repeating it.
Four weeks with a real crew tells you more than a specification will. It also finds the forms that exist only because a form has always existed.
Every operation has one. Detecting it from data you already collect usually pays for the work before the wider platform is anywhere near finished.
Somebody assembles it from exports and hopes the extracts lined up. Generating it from the record removes a recurring week and an annual risk at the same time.
Yes, and that is the design assumption rather than a complication. One ingestion layer normalises each source into a single shape and keeps the raw payload, so a decoding mistake can be re-run rather than lost. New hardware becomes another adapter instead of another system to maintain.
It is built offline first, because the assets that need visiting are usually the ones with no coverage. The job, the history and the forms travel with the van, work is recorded where it happens, and the sync resolves on return. Photographs, readings and sign-offs attach to the asset so the next visit starts informed.
That is what turns readings into something worth collecting. Thresholds and pattern checks run as the data arrives, so an unusual consumption or a stalled meter opens a job the same day rather than appearing in a monthly review. It also changes the economics of a van visit, since fewer of them are wasted.
By generating it from the record rather than assembling it from exports. If the reporting questions are known when the ingestion is designed, the quarterly exercise of rebuilding numbers in a spreadsheet and hoping the extracts lined up simply stops being necessary.
As few as possible, and never the control side. The pattern we build to runs one way: devices and telemetry push into a collection layer, that layer is kept apart from anything office facing, and the reporting people actually use reads from a copy rather than from the equipment. Kit installed a decade ago cannot be patched, often has credentials that cannot be changed, and was designed on the assumption that being on a private network was security in itself. Treat it accordingly. Where remote access is genuinely needed for maintenance, it goes through a controlled path with named accounts and logging, and it is switched off between uses rather than left open because turning it on again is inconvenient.
We start read only and stay there unless there is a strong case, because a system that can operate plant carries a different class of risk from one that reports on it. If control is genuinely required it needs interlocks, an explicit confirmation path, a complete record of who commanded what, defined behaviour when the link drops mid-command, and sign-off from whoever owns operational safety rather than from IT. It usually needs the device vendor involved as well. Most requests for control turn out on inspection to be requests for faster information, which is a smaller and considerably safer piece of work. We would rather build that and say so than take on a switching capability nobody has assessed.
Ask three specific questions before accepting that. Whether a documented export or API exists under licence and at what price. Whether the head end system can write the data out in any form at all, including a nightly file. And whether your contract already entitles you to your own readings, which it sometimes quietly does. Vendors are usually protecting the platform rather than the data, and a file drop is often available where an integration is not. If all three answers are genuinely no, the honest options are a gateway or converter where one exists, a different device on new installations, or accepting manual collection for that generation while it is retired. We will not quote for an integration we have not confirmed can be built.
More than people expect, and it is better decided than discovered. Interval data from a large estate grows steadily and never stops, and the raw payloads we keep for reprocessing roughly double the volume. Throwing the raw away is the wrong saving, because those payloads are what let a decoding error be corrected months later without a site visit. Tiering is the right answer: recent data where queries need to be fast, older data compressed and aggregated to the resolution anybody actually asks for, and raw payloads in cheap storage with a retrieval time measured in hours rather than seconds. Agree the retention period against your regulatory obligations first, then size the storage to it and put a figure in front of finance early.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
