Water loss is an absence. That is why nobody sees it. What is a solution?

Rural water systems rarely fail abruptly. A leak presents as a slow divergence between what a system should deliver and what it does.

The conventional alternative to measurement is a monthly manual reading, taken by a technician trained to operate a tap rather than to interpret a trend. Losses surface only when a tank runs dry or the revenue fails to reconcile. By then the leak is months old and nobody can say when it began.

Non-revenue water is hard to see because it is an absence. There is no incident, no complaint, no line in the ledger. Water is produced, water is not paid for, and the gap sits unmeasured until it becomes a shortage. As the operator we carry both sides of that gap: the revenue those litres should have earned, and the cost of the repair when it is finally found. Deferral is not available to us. The only real variable is whether we find the leak while it is still small.

              

Over the past 6 months we have been embedding PULSE, eWATER's maintenance platform, across water systems in four Kenyan counties. What follows is less about the software than about what it takes to make an alert worth acting on.

What the alerts do

PULSE reads flow rate, battery voltage and connectivity from each tap continuously, and converts divergence into named faults: a tap flowing below its acceptable band, a tank emptying repeatedly, a suspected supply leak, an asset that has stopped responding.

Two properties make this operationally useful rather than merely informative. The first is severity: every fault carries a graded magnitude. A system-wide flow collapse or an empty tank is critical. A single tap below its band is high but survivable. A low-grade communication fault is low. The second is routing: severity determines who receives the job. Routine faults go to the technician responsible for that system; the most severe escalate to the Service Delivery Officer, because they usually indicate something wider than one tap.

How a technician responds

The practical change is that a technician begins the day with a sequence rather than a list.

Critical faults move immediately. A tap below its flow band is real work, but it can be grouped into the next planned visit rather than triggering its own journey. Low-grade connectivity issues wait. Routes are built around magnitude, not around whoever reported loudest.

On arrival, the technician records a diagnosis and the resolving action taken. That closes the loop, because the system learns what a given fault signature actually turned out to be.

This is where operations become affordable. Journeys are ordered, repairs happen while they are still small repairs, and no day is consumed by the wrong problem.

Refining the alerts

None of this worked on default settings.

Early thresholds classified functioning taps as faulty. Technicians were dispatched to sites where nothing was wrong, and a technician sent out twice for nothing starts discounting the third alert. False positives do not merely waste a journey; they erode the credibility of the system producing them.

Correcting this was joint work between the field teams and the eWATER engineers, case by case: what the sensor recorded, what the technician found at the tap, and what the rule should therefore say. Flow bands were rebroadened. Clearing rules that assumed frequent tap use were rewritten for low-usage taps. Severity levels were reassigned so that escalation meant something. Where a rule could not be made reliable, it was switched off rather than left to generate noise.

What gets remembered

There is a second absence in rural water operations, and it behaves like the first.

Most schemes hold their maintenance history in the memory of whoever happens to be the technician. He knows which tap has failed twice, which asset struggles at the end of the dry season, which fault was misdiagnosed last year. When he leaves, that knowledge leaves with him, and nobody records the loss. The next technician starts from zero and repeats work already done.

Every fault in PULSE now carries a diagnosis and a resolving action, and that history is retained rather than expiring after a week. The test I apply is simple: could a technician arriving at an unfamiliar system read its last twelve months and be useful on day one? That is the standard worth building toward.

The record is also exportable, which matters more than it sounds. A dashboard shows what is broken now. A dataset shows what keeps breaking, and those are different questions. Repeated failure at one asset points to a design or supply problem rather than a maintenance one. Response times, measured across hundreds of jobs, give an evidence-based benchmark rather than a target chosen by convention, and a defensible basis for assessing technician performance.

Visibility runs in both directions. It shows where work is not being done, and it makes diligent work legible, which in most rural systems it currently is not.

Four counties of fault data is also the kind of evidence base that county governments and regulators rarely hold. Used well, it is a sector asset rather than a company one.

What it does not do

The platform records what happens at the tap. It does not explain why a household stopped collecting water, whether a source is yielding less than it did, or what is happening upstream in the catchment. Those still require people on the ground asking questions. Data narrows the search. It does not end it.

What next?

Every fault attributable to an asset. Every response attributable to a person. Every recurring failure visible as a pattern rather than remembered as a nuisance. None of this requires new technology; it requires operators willing to treat their own operational data as an asset and to build the judgement needed to interpret it. That is an achievable standard, and until it becomes the ordinary expectation, rural systems will continue to discover their losses as shortages.