Two profiles here as well. Municipal utilities, electric co-ops, water and wastewater districts, and city or county departments, where there are few systems, the asset register usually lives in one of them and the work orders in another, and nobody is assigned to reconcile the two. And large electric utilities, where metering, outage management, work and asset management, and the geographic map are each substantial systems in their own right, the numbers get filed with a regulator, and the hardest days of the year are the ones the data was least designed for. Scale changes which gaps hurt, so the two are kept separate below.
Municipal utilities, co-ops, and city and county departments.
Asset failure prioritization
In one line: Shows which assets are actually driving outages and repeat truck rolls, so the capital plan follows the failures rather than the calendar.
Who uses it and when: whoever builds the capital plan, at budget season, on a ranked list of assets actually driving outages instead of a replace-on-age schedule. It changes one decision: which assets go into next year’s plan first.
What it does not do: it will not approve the capital plan. It ranks the assets by what is actually failing; the plan is still built by a person.
Usually already there.
It runs on the asset register and the work orders, both already captured, because GIS and the maintenance system each need them to do their own job. What is missing is agreement: there is no shared identifier between the two, so failure history and repair history cannot be joined. The work is giving every asset one identifier both systems use, which is reconciliation, not a new data programme.
The pain: “We replace on age because that is defensible, not because we know what is failing.”
What it runs on
- One row per: one outage or failure event per affected asset. One asset, one start, one restoration. Paired with one row per maintenance work order.
- Described by: asset (pole, transformer, main, pump, valve), circuit or zone, service territory, cause code, crew, date and time, weather condition, customers affected, minutes out.
- Must agree across systems: the asset, and the service location or premise. GIS, the maintenance system, and the outage system all need to point at the same physical asset with the same identifier, which is usually the entire first phase of work.
- History: you need history on asset replacement and rebuild, and on which premises are served by which asset. Both change, and both determine who was affected.
Why it usually fails: the asset register lives in GIS, the work orders live in the maintenance system, and there is no shared asset identifier between them, so failure history and repair history cannot be joined. Cause codes get chosen by whoever closes the ticket, days later, from a list built for a different purpose.
Service request triage
In one line: Routes an incoming resident request to the right department the first time, and shows which locations generate the repeat calls.
Who uses it and when: the intake staffer, the moment the request comes in, on a routed request plus a flag if that location is a repeat caller instead of finding out after the third call. It changes one decision: whether this one goes to the usual department or gets escalated as a recurring problem.
What it does not do: it will not fix the underlying issue at that address. It flags the pattern; the crew still has to go out and fix it.
Usually needs work.
It depends on requests that are already logged as they move through status. The address is free text and does not resolve to a parcel or an asset, so a block that generates a third of the calls on a line is invisible as a pattern. A reopened request also gets entered as a new one, which hides the recurring problem it is. Nothing new has to be built. Addresses get matched to parcels, and a reopened request stays linked to the original.
The pain: “Half our requests get routed twice, and the same block calls every month about something we keep patching.”
What it runs on
- One row per: one status event on one request. Opened, assigned, reassigned, closed, reopened, each with a timestamp. Paired with one row per request carrying its milestone dates.
- Described by: request type, location and parcel, department, assigned crew, intake channel, priority, date opened, date closed, resolution.
- Must agree across systems: location above everything. The address on the request has to resolve to a parcel and to the asset that serves it, or the repeat-call pattern is invisible.
- History: you need history on the request type list. A request filed three years ago has to keep the category it was filed under, or year-over-year comparisons quietly break.
Why it usually fails: the address is free text and does not tie to a parcel or an asset, so nobody can see that one block generates a third of the calls on that line. A reopened request is entered as a brand new request, which makes resolution time look excellent and makes the recurring problem disappear from the data entirely.
One caution: requests carry resident identity. Decide what gets masked or aggregated before the data goes anywhere near an AI feature, not after.
Large electric utilities.
Meter read exception review
In one line: Flags the meter whose reads are wrong or missing while the bill can still be held, instead of after the customer calls.
Who uses it and when: billing staff, before the bill goes out, on a flagged read instead of a customer call after the fact. It changes one decision: whether that bill gets held for a check first.
What it does not do: it will not correct the read. It flags which one looks wrong while there is still time to check it.
Usually needs work.
It depends on meter reads, which are already captured at the interval the meter records. The field is the problem: a missing interval gets filled with an estimate written into the same field as a real read, with nothing marking which is which, and a corrected read gets written back over the original. Nothing new has to be built. A flag records whether a value is actual, estimated or edited, and the original is kept alongside any correction.
The pain: “We find out a read was bad when a customer calls about a bill several times their normal, and by then we have already sent it.”
What it runs on
- One row per: one meter, one interval, at the interval the meter actually records. Not a daily total, not a monthly read. Rolling the intervals up before you store them throws away the shape of the day, and the shape of the day is the only place most of these problems are visible.
- Described by: meter, service point, customer account, rate class, circuit and substation, transformer, geography, date and interval, and the read type: actual, estimated, or edited.
- Must agree across systems: the service point above everything. A meter is not a customer and a customer is not an address. Meters get swapped out, customers move, and the thing that stays put is the point of service. Then rate class and circuit.
- History: you need history on which meter served which service point and from when, and on which account occupied it. A read attributed to the wrong meter or the wrong tenant cannot be sorted out afterward, and it will be disputed afterward.
Why it usually fails: missing intervals get filled with an estimate, and the estimate is written into the same field as the real read with nothing marking which is which. The data then looks complete, every report runs, and the model learns that the estimate is what the meter measured. Estimates are smooth by construction, so the anomalies you were trying to catch have been smoothed away by the process meant to clean the data. The second cause: a validated or corrected read is written back over the original, so nobody can separate what the meter sent from what a person later decided it should have sent.
One caution: reads at this interval describe when a house is occupied. Decide what gets masked or aggregated, and who may see it unmasked, before the data leaves the metering system.
Restoration time and reliability reporting
In one line: Gives customers an honest restoration time, tells the operations center which jobs to send crews to first, and produces reliability figures that still say the same thing a year later.
Who uses it and when: the operations center, during the outage, on a priority order for crews and a restoration time worth publishing instead of a guess. It changes one decision: which job gets a crew sent first.
What it does not do: it will not dispatch the crew or restore the power. It gives the order and the number; the response is still run by people.
Usually needs work.
It depends on outages, which are already recorded, device by device, from detection to restoration. The customer count is the problem: it gets recalculated after the fact and written back over the original, so last year’s reported figure stops matching what was reported last year. A nested outage also gets counted twice or absorbed, depending on who wrote the query. Nothing new has to be built. The original count is kept, and nested outages get one consistent rule.
The pain: “We publish a restoration time, we miss it, and missing it costs us more trust than the outage did.”
What it runs on
- One row per: one outage on one device, from detection to restoration. Paired with one row per affected service point per outage, because the customer count is what all of the reporting is built on and it cannot be honestly reconstructed after the fact.
- Described by: device (fuse, recloser, transformer, feeder, substation), circuit, cause, weather at the time, crew, detection time, dispatch time, arrival time, restoration time, and whether this outage sat inside a larger one.
- Must agree across systems: the device and the service point. The outage system, the geographic map, and the work system all have to be naming the same physical device. Then the cause code list, which has to be one list rather than one per system.
- History: you need history on the network as it was connected at the time. Which service points were fed by which device changes with every switching operation and every rebuild, so an outage from two years ago has to be read against the configuration in force that day rather than today’s.
One thing to watch: the reliability figures you report exclude the days that qualify as major events, and whether a given day qualified is decided afterward, against a threshold calculated from several years of your own history. That means the same day can be inside the number one year and outside it the next. Store the outage record whole and apply the exclusion as a step you can re-run, never as a filter applied on the way in. Once the excluded days are gone from what you stored, no restatement is possible and nobody can follow the filed number back to anything.
Why it usually fails: the count of customers affected is recalculated after restoration, from today’s connectivity, and written back over the original. The historical number then moves every time the network is reconfigured, so last year’s reliability figures stop being the numbers that were reported last year, and nobody notices until someone compares a report to an older copy of itself. The second cause is nested outages. A device restored inside a larger event either gets counted twice or gets absorbed and disappears entirely, and which one happens depends on who wrote the query.
Storm damage assessment and crew allocation
In one line: Turns the first day of damage reports into a crew and materials plan, and leaves a record of the work that survives the cost review months later.
Who uses it and when: whoever allocates crews during the storm, from the first day of damage reports, on a crew and materials plan built from the same record the cost review will use later. It changes one decision: where the next crew goes.
What it does not do: it will not file the cost review. It leaves the record the review will be built from, months before anyone asks for it.
Usually already there.
It runs on the operating picture and the cost review, both already captured, because each audience needs its own extract to do its job during and after a storm. What is missing is agreement: the two extracts are taken at different times and never reconciled, and the map and the work system name the same asset two different ways. The work is one naming convention and one reconciled extract, which is weeks of reconciliation rather than a data programme.
The pain: “For the first two days we allocate crews off phone calls and photographs, and then we spend three months rebuilding what happened for the filing.”
What it runs on
- One row per: one damage assessment against one location or device. One assessor, one observation, one timestamp. Paired with one row per crew assignment, so hours and materials tie to a specific repair rather than to the storm as a whole.
- Described by: device and location, damage type, access constraints, crew and whether it is yours or mutual aid, equipment and materials used, assessment time, dispatch time, completion time, service points restored by that repair, and whether the cost is capital or operating.
- Must agree across systems: device, location, and crew identity. Mutual aid crews arrive from other utilities with their own employee identifiers and their own names for equipment. If they are not mapped to yours on the way in, their hours land in the ledger with nothing tying them to the work they did.
- History: keep the assessment as it was made in the field separate from what the repair turned out to be. Overwriting the first with the second erases the only record of how accurate the initial assessment was, which is the thing the feature exists to improve.
Why it usually fails: the same repair has to serve two audiences, the operating picture during the storm and the cost review afterward, and the two are almost always built from different extracts taken at different times. They never agree, and reconciling them by hand is where the three months go. The other half is scale. The map calls the asset one thing and the work system calls it another, and at this size nobody is going to reconcile them by hand, so the repair history and the asset history stay in separate worlds permanently.