Automate Outage Communications Before or After Fixing GIS? Sequence by Message

The question you are actually being asked

A storm takes out a feeder at nine in the evening. By nine fifteen the phones are lit, the city council member whose street is dark has texted the general manager, and the person on the desk is answering the same question forty times with the same three words: we are working on it.

Somebody proposes automating that. Outage texts, a public map, an interactive voice response line that tells callers what you know before they reach a human. The first vendor you talk to says yes, but you need to clean up your GIS first. So does the second. So does the third. And each of them, it turns out, offers GIS data services.

That is not a coincidence, and it is not quite a lie either. The prerequisite is real. It just does not apply to every message equally, and the vendors have no reason to tell you which ones it applies to.

What the vendors concede when they are not selling

Esri's own guidance on advanced distribution management systems says the quiet part in plain language: the optimisation of ADMS capability depends on the accuracy and completeness of data that lives in GIS. The same document lists what has to be right, namely phasing, primary and secondary voltage, premise-to-transformer linkages, and asset topology that matches field connectivity.

Read that list as a municipal utility with a two-person GIS shop, and it describes a year of work. Read it as a vendor, and it describes a service line. Esri separately markets modernising IVR notifications on its Utility Network product, which is the same prerequisite sold with a different label on it.

Neither statement is wrong. What page one never does is distinguish between the outage messages that depend on that data and the ones that do not. That distinction is the whole decision, and it is mechanical rather than philosophical.

Two kinds of outage message

Every outage communication a utility sends belongs to one of two families.

The first family states a fact a device reported. Your power is out. Your power is back. A meter with a supercapacitor sends a last-gasp message to the head end when it loses supply, and a restoration message when it comes back. That signal is a device-level fact. It needs no network model, no transformer linkage, no phase data. The meter knows it is dark, and it says so. If your AMI rollout is complete and the head end is integrated to anything that can send a text, the first family is ready to automate today.

The second family states an inference the model made. Approximately 340 customers affected. Crews estimate restoration by 2 a.m. The outage on Elm is part of the larger event on the Route 9 feeder. Each of those claims requires a connectivity model that correctly says which meters hang off which transformer, which transformers hang off which feeder segment, and where the protective devices sit. If the model is wrong, the count is wrong, the nested rollup is wrong, and the estimated restoration time is built on a picture of the network that does not match the one the crew is standing in.

The Electric Energy Online piece that first laid this out for the smart grid era put it plainly: distribution network models are notoriously inaccurate at the specific meter connection level, some utilities do not model phases down to the customer, and others have no explicit connection between the customer and the transformer. That was written in 2011. In our experience the description still fits a great many municipal systems, because the GIS was built for asset records and mapping, not for tracing electrical connectivity in real time.

So the sequencing question is not before or after GIS. It is: which family of message are you willing to be wrong about in public?

The cost of being wrong is not symmetric

Automating the first family and getting it wrong is rare and cheap. The meter reported an outage that was actually a customer-side problem, or a restoration text arrived a minute before the lights came on. Customers forgive that. It reads as a system that is trying.

Automating the second family and getting it wrong is common and expensive. A public map that shows a neighbourhood restored while half of it is still dark. A count of twelve customers on an event that turns out to be three hundred, because the model had the tie switch in the wrong position. A restoration estimate that slips three times in a night. Each one trains customers to ignore the channel, and it trains council members to call the general manager directly, which is the exact behaviour the automation was bought to stop.

J.D. Power's 2025 business customer study gives the upside a number. Business customers who received five or more points of contact during an outage rated safety and reliability satisfaction 210 points higher, on a 1,000-point scale, than those who received nothing. The study does not say those contacts had to be precise. It says they had to exist. That is an argument for the first family, now.

A 2025 paper on predicting restoration times, trained on 34,000 storm events from three large utilities, adds a useful detail: overpredicting the restoration time does not hurt satisfaction as long as the overestimate stays under about eight hours. The same paper notes that every event in its data set was revised multiple times as better information arrived. Estimates that get revised are normal. Estimates that get revised because the network model put the fault on the wrong feeder are a different thing, and customers cannot tell the two apart. They just see the number move.

What we would automate first, and what we would hold

If you asked us to draw the line for a municipal electric with a completed AMI deployment and a GIS of uncertain quality, we would draw it like this.

Send automatically, today: outage confirmation to enrolled customers when their meter reports a last gasp, restoration confirmation when it reports power back, and a general acknowledgement that the utility is aware of an event in an area. Publish a map of individual meter outages if you must publish a map, with no polygons, no counts, and no boundaries the model drew.

Hold behind a person: affected-customer counts, nested event rollups, and estimated restoration times. Not forever. Until the connectivity model has been tested against reality and the number of surprises per storm has fallen to something the desk can absorb.

One caution on the first family. AMI last-gasp reporting degrades under exactly the conditions where you need it most. A large event generates thousands of simultaneous messages across a mesh network that was sized for interval reads, and some fraction of those messages never arrive. Automate the individual notification, but do not let anyone build a customer count from the sum of last-gasp messages received. That is the second family wearing the first family's coat.

What this decision reveals about the GIS work itself

Sequencing by message changes what the GIS cleanup is for, which changes how much of it you need.

If the goal is simply to make ADMS work, the vendor list is the scope. Every linkage, every phase, every substation internal. If the goal is to release the second family of messages one at a time, the scope shrinks to whatever makes the next message trustworthy. Customer-to-transformer linkage on your worst three feeders makes counts there trustworthy. Correct protective device placement makes nested rollup trustworthy. Neither requires modelling substation load flow. The cleanup gets a customer-facing milestone instead of a completion date, and the utility can stop it where the returns flatten.

This is also the point where the earlier meter work comes back. We described in what a co-op inherits when smart meters meet a legacy back office how the meter-to-transformer map ends up held in three versions across CIS, OMS and GIS, with nobody owning the disagreement. Outage communications are where that disagreement becomes visible to the public. If the three systems do not agree on which transformer a meter sits on, the affected-customer count will be wrong on the map before it is wrong anywhere else. Fixing GIS alone does not resolve that, because the outage system may be reading the linkage from somewhere else entirely.

The pattern shows up outside utilities too. A county that automates permit status notices before it fixes its intake data ends up sending confident wrong messages, which we covered in what a permit costs a county to process. And the general rule we keep returning to in when not to use AI in your business applies here without modification: automate the messages built on facts, and keep a human between the model and the public until the model has earned it.

The questions that decide it

Before you sign anything, four questions settle most of this.

Does your outage system take customer-to-transformer linkage from GIS, from CIS, or from a table somebody maintains by hand? The answer determines whether a GIS cleanup would change the count at all.

When was the last time a crew reported that the map had the wrong device open? If the answer is last storm, the second family stays with a person. If nobody can remember, you may be closer than the vendor's scope suggests.

What fraction of your meters report last gasp reliably in a large event, as opposed to a single-transformer fault? Your head-end vendor has this number, and it tells you how far the first family can be trusted.

Who is allowed to override an automated estimate at two in the morning, and does the tool let them? Automation without a manual brake is the thing that produces the screenshot on the local news.

Those questions have honest answers in your systems. Finding them takes a week inside the utility, not a page of search results. If you are trying to decide which outage messages to automate now and which to hold until the network model deserves the trust, talk to us. We do not sell GIS services, which is the only reason our answer to the sequencing question is worth anything.