Advanced metering infrastructure (AMI) is usually justified by what it removes from the field: meter-reading routes, estimated bills, and the lag between a leak starting and a crew hearing about it. A Water Finance and Management article, Why AMI is Shifting the Conversation from Data Collection to Data Usage, by Jessica Lyman and Jeff Wetzel, starts from the same premise and then asks a narrower question: once the reads are flowing, what is the utility actually doing with them? The summary states the core benefit plainly: "Billing is more accurate and leaks can be identified sooner." The harder work begins after that sentence.
Collection Is the Easy Half
An interval meter produces a steady stream of timestamped records. Each record has to be received, validated, tied to a service point, stored, and kept for whatever period the utility's retention schedule requires. The collection side of that chain usually has a visible owner, often the vendor under contract and the information technology group that hosts the head-end system. The use side rarely does. Billing, leak detection, customer service, capital planning, and rate analysis each draw on the same records, and each asks something different of them. When no one has been assigned to decide which question comes first, the data accumulates faster than the decisions it was meant to support.
Each Benefit Asks Something Different
Billing accuracy depends on read validation. The utility needs rules for failed reads, a method for estimating gaps, a dispute path a customer can follow, and a record showing which reads were actual and which were estimated. A monthly bill can tolerate a late read, provided the gap is labeled and the correction is documented.
Leak detection asks for something else. A flag on continuous overnight flow requires a baseline of normal night use for each zone or district, a threshold that accounts for legitimate overnight demand, and a routing rule that reaches someone able to act. Tighter thresholds catch more slow leaks but generate more false alarms, and each false alarm consumes crew time. Looser thresholds conserve crew time and miss small losses. The right setting depends on local demand patterns, which a general article cannot supply. The utility should tune it, record the tuning, and revisit it when demand or zone boundaries change.
Write the Use Register First
A practical starting point is a use register: a short document listing each intended use of interval data, the owner responsible for it, the fields it needs, the latency it can tolerate, the retention period, and the roles allowed to see customer-level detail. The register does not need to be elaborate. It needs to exist before the data leaves the vendor's platform, because the default configuration of most platforms is set by the vendor, not by the utility's board or records staff.
Customer-level interval data also deserves a deliberate access decision. At the premise level, a high-resolution usage pattern can suggest when a home is occupied and when it is not. That is a privacy question, and its answers belong to the utility's governance process and its counsel. What the utility can control is who may query the data, whether those queries are logged, and whether the retention limit matches the stated use.
What to Check Before the Next Expansion
Before a new AMI phase or platform upgrade, a utility can test its readiness with a few concrete questions. Is there a written list of uses, with an owner for each? Does each use have a defined data quality standard, including how estimated reads are labeled? Does the retention schedule match what the vendor's configuration actually enforces? Who can export customer-level records, and is that access logged? When was the leak threshold last reviewed against current zone boundaries? A no to any of these does not mean the program has failed. It means collection has outpaced decisions, and the gap is cheaper to close while the system is still being configured.
The shift the title describes is ultimately a shift in responsibility. Collection can be delegated to a vendor. Usage cannot. A utility that writes down what it intends to do with each read, and checks that against what the system does, will have a more useful meter program than one that simply holds a large volume of data.