Water Utility Software: Fixing the Gaps Between Meters, Mains and Compliance

Why water utility software makes or breaks a utility operator

A water utility is four businesses stapled together. You are a manufacturer (treatment), a logistics network (distribution), a billing company (meters and revenue), and a regulated entity that files paperwork under penalty of law. Most utilities run each of those on a different system that does not know the other three exist. Sensus or Badger AMI feeds meter reads into one vendor cloud. Billing lives in Tyler Munis or Springbrook or Central Square. Work orders live in Cityworks or Lucity, or on paper if you are honest about it. GIS lives in ArcGIS. Lab results arrive as PDFs from a contract lab and get keyed into a spreadsheet that someone named "DBP Q3 FINAL v4.xlsx".

The connective tissue is a person. Usually the distribution superintendent or a long-tenured office manager who knows that meter route 14 has three accounts flagged wrong in billing because the GIS service point IDs were renumbered in 2019 and nobody backfilled it. That knowledge is not in a system. It is in a head, and that head retires.

Watch one main replacement travel through the stack. A crew replaces a 6-inch main on Elm Street. The foreman closes the work order in Cityworks. The as-built sketch goes to the GIS tech, who updates the pipe segment three weeks later when he has time. The valve exercised during the shutdown never gets logged because the valve app is a separate module nobody bought. Two customers on that block get zero-consumption reads for the next cycle because the meters were pulled and reset, and billing does not know a construction event happened, so it auto-estimates. Six weeks later, the meter tech gets a service call for a $900 catch-up bill, and the customer is standing on the counter at city hall. That entire chain is one missing data link: the work order does not know about the meter, and the meter does not know about the pipe. Nobody sold you the link. Nobody will.

Problem 1: AMI data is a firehose that nobody actually reads

You paid for AMI. Sensus FlexNet or Badger BEACON or Itron is delivering hourly interval reads on 12,000 endpoints. That is roughly 105 million reads a year sitting in a vendor portal that gives you a leak-alert flag and a consumption graph. What you actually get out of it: a monthly file to billing, and a leak alert list that your CSR ignores because it fires on 400 accounts a month and 380 are irrigation.

The AMI vendor's analytics are built to sell you the AMI. They alert on continuous flow, not on your reality. They cannot tell you that account 4471 has a continuous-flow signature consistent with a running toilet (small, 24/7, stable) versus account 8823 with a signature consistent with a service line break (large, started at 2am Tuesday, still climbing). They cannot correlate a pressure drop in zone 3 with an unbilled consumption jump on three adjacent accounts, because they do not have your zone map or your SCADA pressure data. And they will not, because that is not their product.

What a custom build does: it pulls the interval read stream via the vendor API into your own store, joins it to the GIS service point, the pressure zone, the DMA, the meter make/model/install date, and the account's own 24-month history. Then you classify. Continuous flow with a stable low rate and no seasonal correlation gets tagged as a fixture leak and drops into a customer notification queue. A step change with a matching zone pressure dip escalates to the on-call distribution supervisor with a map pin. A reverse-flow read on a commercial account with an RPZ device on file becomes a cross-connection ticket with the backflow test record attached. The AI that matters here is unglamorous: an anomaly model trained on your own 24 months of interval data learns each account's normal, so a school with zero summer usage does not fire an alert every June and a laundromat's 3am cycle does not read as a break. We have seen this take an unusable 400-alert month down to 30 to 40 actionable alerts, which is a number a CSR will actually work.

The revenue side is the part that pays for it. Apparent losses from stopped and slow meters are invisible in every off-the-shelf report because the report shows what the meter said, and the meter said very little. Join install date and cumulative volume to consumption trend and you get a ranked meter-change-out list by dollars of lost revenue, not by age. That list is the business case.

Problem 2: Work orders that do not know what an asset is

Cityworks and Lucity are real CMMS products and they are fine at the CMMS job. The break is what happens at the edges. A hydrant flow test is a work order in Cityworks, a hydrant record in ArcGIS, a flow number that fire needs, and an input to your hydraulic model in WaterCAD or InfoWater. Four homes, one event. So the flow test result gets typed in Cityworks as a note in a comment field, and it dies there. Your modeler asks for last year's flow tests and the answer is "let me export the work orders and read them."

Same with valves. You are supposed to exercise every valve on a cycle. The valve turn count, the direction, whether it seated, whether it broke, and which valves are now known-bad and therefore excluded from your next shutdown plan. That last one is operational gold and it lives in a foreman's memory. When a main breaks at midnight and the crew closes the valve grid from the map, the map does not say valve 3117 has been broken since 2021. So they close it, it does not seat, and 200 more customers lose water than needed. That is a boil-water advisory footprint decided by a data gap.

What a custom build does: the asset is the spine, not the work order. Every pipe, valve, hydrant, meter, pump and tank gets a record with a condition state that changes based on events. A failed valve-exercise attempt writes a condition flag directly to the valve, which propagates to the shutdown planner so the next isolation trace routes around it. The break history writes to the pipe segment, and a segment with three breaks in five years floats to the top of your CIP renewal list with the actual repair cost summed from the work orders, not from a guess. Where AI helps: a break-likelihood score per segment trained on your material, install year, soil, pressure, and break history is genuinely better than the age-based ranking your engineer is using now, and it is honest about uncertainty. It is not clairvoyance. It reads more of your own history than any engineer has time to.

Problem 3: Compliance reporting is a manual archaeology project every quarter

This is the one that keeps a utility director awake. Your monthly operating report, your DBP sampling, your Lead and Copper service line inventory, your CCR, your bacteriological results. The lab emails a PDF. Somebody opens it, reads a number, types it into a spreadsheet, and the spreadsheet feeds the state portal submission. One typo is a violation. One missed sampling window is a violation. One sample site that no longer exists because the house was demolished is a violation when you cannot collect there.

No off-the-shelf tool fixes this because your state's requirements are your state's. The vendors build to the federal floor and leave the state layer to you. And the LCRR service line inventory in particular exposed how bad the data situation is: utilities were asked to state the material of every service line on both sides of the meter, and the honest answer was in a filing cabinet of 1950s tap cards.

What a custom build does, concretely. Lab result PDFs get parsed on arrival, and document extraction is legitimately good at this now: contract lab reports are semi-structured, they vary by lab, and a model reads the analyte, the result, the units, the method, the collection date and the sample site ID reliably enough that a human only reviews exceptions instead of keying everything. The extracted result lands against the sample site record, which knows its own sampling schedule, so a missed window fires an alert 10 days before it is a violation rather than after. Running averages for DBP compliance calculate continuously instead of at quarter end, so you see a location trending toward the MCL in month two and can flush the dead-end main, rather than finding out in month four that you already exceeded. Service line inventory becomes a real record with a material, a basis of evidence, and a photo from the field, so when a crew potholes at 14 Maple they update the line from "unknown" to "copper, verified, photo attached" from a phone in the trench, and the state submission generates from the data instead of from an intern.

Problem 4: The customer-facing side is a phone that rings

High bill complaints, service start and stop, leak questions, payment arrangements, dig-safe locates. Your CSR handles all of it by phone between 8 and 4:30. After 4:30 the answering service takes a message and the on-call guy calls back.

The billing vendors sell a customer portal. It shows a balance and a pay button. It does not show the customer the hourly interval data that proves their leak started on the 14th at 3am, which is the single thing that ends a high-bill argument in two minutes instead of twenty, because the portal is billing's and the interval data is AMI's, and the two vendors have no reason to talk.

What a custom build does: one portal fed by both. The customer sees their own hourly curve with the leak window shaded. The CSR sees the same screen the customer sees, so the call is a shared document instead of a debate. Service start and stop is a form that creates the work order, schedules the meter read, and confirms the date, with no phone call. Where AI helps after hours: a scoped assistant that answers from your actual account data (balance, last read, leak status, next bill date) and books a service appointment against the real crew calendar handles the routine calls at 9pm. It escalates anything about no water, discolored water, or a possible main break straight to the on-call number, because that judgment call should never be automated away. We scope those escalation rules first, before anything else, and put them in writing.

What this costs and how long it takes

Across 2,000+ projects at Digital Heroes, our honest bands for this category: a focused first release runs $60,000 to $130,000 and ships in 12 to 16 weeks. For a water utility that first release is usually AMI ingestion plus the asset spine plus one high-value workflow, typically leak triage or compliance sampling, because those show a number to the board fastest. A full platform with SCADA historian integration, field mobile with offline support, hydraulic model exchange, the customer portal and automated state submissions runs $150,000 to $400,000 phased over 6 to 12 months.

What drives price up specifically here. SCADA integration is the big one: if your historian is a Wonderware or Ignition instance sitting behind an air gap on the OT network, the integration is a security architecture conversation before it is a code conversation, and that conversation adds 3 to 5 weeks and a real dollar amount. Second, GIS data quality: if your service points and your billing accounts do not share a reliable key, somebody is doing a reconciliation project, and on a 12,000-connection system that is 4 to 6 weeks of matching and field verification before the good part starts. Budget for it rather than discovering it in week 9. Third, the number of state-specific report formats you need generated. Each one is a discrete build. Fourth, the age of your billing system: a modern Tyler Munis instance has an API. A 2008 AS/400 billing system has a nightly flat file and a prayer, and everything you build has to live with that latency.

What does not drive price: the number of connections, mostly. The work is the same at 8,000 as at 40,000. Which is why the math gets better the bigger you are.

Build versus buy: where the line actually is

Buy, genuinely, if you are under roughly 3,000 connections with one pressure zone, your compliance load is a monthly operating report and quarterly bacts, and your crew is four people. Cityworks or a hosted package plus your AMI vendor's portal is the right answer, and anyone telling you to build is selling you something. The overhead of owning software will eat the benefit.

Build when you hit these signals, and they are concrete. One: someone on your staff maintains a spreadsheet that joins data from two vendor systems, and that spreadsheet is load-bearing for a decision or a filing. That spreadsheet is a system you already built, badly, with no backup and no owner. Two: you have asked two vendors for an integration and both quoted you a data export. Three: your non-revenue water is above 15% and you cannot say with confidence how much is real loss versus apparent loss, because the answer requires joining AMI data to production meters to the DMA map and no single tool holds all three. Four: you are running multiple systems, whether that is a regional authority with several treatment plants or a utility that acquired a neighboring district, and every acquisition means another billing system and another set of workarounds. That is the case where custom wins hardest, because the off-the-shelf products are priced and designed per-system and you are trying to operate as one.

The position we take: the middle is where the pain is. Small utilities should buy. Very large utilities have already built. The 8,000 to 60,000 connection utility is being served by products designed for someone else, and is quietly paying for the gap in staff hours, apparent losses, and regulatory exposure.

How to choose a developer for water utility software

First, ask what data model they would propose for a service line, before you sign anything. If the answer does not immediately distinguish the utility-side material from the customer-side material, and does not include a basis-of-evidence field, they have not read the LCRR and they will learn on your money. The service line is the sharpest domain test in this category because it is where regulation, GIS and the physical world disagree.

Second, ask specifically what they have integrated. Not "we do integrations." Name the system: have they pulled from a Sensus FlexNet API, a Badger BEACON export, a Tyler Munis instance, an ArcGIS feature service, an Ignition historian via OPC. If they have not touched utility systems, they will discover that AMI vendor APIs are rate-limited and rewrite the ingestion layer in month four. Ask who has actually stood in a pump station.

Third, ask what happens when SCADA is involved. The right answer includes the words read-only and a one-way data diode or equivalent, and a refusal to put any control path through the application. A developer who is casual about the OT network boundary is a developer who has never been near one. That conversation should make them slower and more careful, not faster.

Fourth, get code ownership and a data exit in the contract, in writing, at signing. You own the repository, you own the database, and there is a documented export. You are a public entity with a 40-year asset horizon and a vendor that folds should cost you a migration, not your operating history.