What you will learn
- How outage areas are mapped from a break location and valve isolations
- How customers are matched to an outage by address
- What messages customers need at each stage of a repair
- How boil-water and do-not-drink notices are handled
- What the system needs from the repair crew to stay accurate
What the project is
When a main breaks, the crew isolates a section by closing valves, and every customer in that isolated section loses water. The notification system takes the break location and the valve plan, maps the affected addresses, and sends those customers a message: water is off, the cause, and an estimated restoration time. As the repair progresses, updates go out: crew on site, repair underway, water returning, and any boil-water notice if one applies.
The hard part is address accuracy. A notification sent to the wrong street creates confusion, and a missed street creates angry customers who learn about the outage from neighbours. The system needs an accurate customer-to-address-to-network mapping, maintained as connections change, and a way for crews to correct the affected area when the isolation differs from the plan.
Core features
Address matching is the feature. A beautiful alert sent to the wrong customers is worse than a plain text sent to the right ones.
- Outage area mapping from break location and valve isolations, with manual correction by the crew on site.
- Customer matching by address, so only affected customers receive outage messages.
- Multi-channel alerts: SMS, email, voice, and app push, because customers do not all use the same channel.
- Repair stage updates: reported, crew dispatched, repair underway, water returning, resolved, with timestamps.
- Boil-water and advisory handling: separate notice types with clear start and end, and a lift message when the advisory ends.
- Subscription and preference management, so customers choose channels and can add a second contact, such as a tenant or a care provider.
- Outage history and reporting: duration, customers affected, and notification delivery rates, per incident.
How it is built
Build the address mapping first, with the network data the utility already has. Messaging is easy; knowing who is affected is the work.
- Network and address study: map customers to network sections and valves, and measure how accurate that mapping is today.
- Outage workflow: define how an outage is created, how its area is set and corrected, and who can update it.
- Messaging build: templates per stage, channel handling, and delivery tracking, tested with staff as recipients first.
- Crew integration: a simple update path for crews on site, because updates that require calling the office will arrive late.
- Launch and drill: run a simulated outage end to end, measure delivery rates and address accuracy, and fix the gaps before a real break.
Tech considerations
This is a messaging and mapping product. Reliability during an incident matters more than message design.
- GIS-based outage area mapping, with valve and section data kept current as the network changes.
- Customer address matching with handling for multi-unit buildings, where one connection serves many households.
- Messaging provider integration for SMS, email, and voice, with delivery tracking and retry for failed sends.
- Simple crew update tools, usable on a phone at a repair site, with offline tolerance.
- Incident records that keep every message sent, so the utility can prove what customers were told and when.
Challenges to plan for
Outage notification fails on wrong areas, stale restoration times, and advisories that never get lifted. All three are trust problems.
- Wrong affected area: an isolation plan that differs from reality notifies the wrong customers and misses the right ones.
- Optimistic restoration times: an estimated time that slips repeatedly teaches customers to ignore the next estimate.
- Advisory confusion: boil-water notices that are issued clearly but lifted quietly leave customers boiling water for weeks unnecessarily.
- Channel gaps: customers without a mobile number on file, or with a number that changed, simply never hear anything.
Who it is for, and honest limits
This fits any water utility with a distribution network, from a city system to a rural district, because every system breaks mains. It fits less well as a standalone purchase for a utility that already has a customer notification system that can be extended with outage mapping.
It does not repair mains faster. It reduces the complaint load during a repair and keeps customers informed, which is a different and real benefit. If repair times are the problem, the fix is crews and spares, not messages.
Frequently asked questions
How are affected customers identified?
By matching customer addresses to the isolated network section, using valve and section data. Crews can correct the area on site when the actual isolation differs from the plan.
What if a customer has no mobile number on file?
Email, voice calls, and app notifications cover some of the gap, but a customer with no contact details on file cannot be reached. The system should report unreachable customers per incident so the utility can improve its contact data.
How are restoration times estimated?
From the repair type, crew reports, and historical durations for similar breaks. Estimates should be labelled as estimates and updated when the crew's assessment changes, rather than left stale.
What is the difference between an outage alert and a boil-water notice?
An outage alert says water is off. A boil-water notice says water may be unsafe and must be boiled before drinking, and it needs its own issue and lift messages. The two must never be confused in one message.
Can customers report an outage through it?
Yes, and reports should feed the outage workflow: a cluster of reports from one area often reveals a break before a crew is dispatched. Duplicate reports from the same area should be grouped, not treated as separate incidents.