You are here

Responder™ Integration Improves Outage Notifications

mtemc oms

Outage Management Communication Improves for MTEMC Customers Thanks to Responder Integration

Status: Completed


Hart EMC ArcGIS Online InspectionsThe needMiddle Tennessee Electric Membership Corporation (MTEMC) wanted to be able to receive and report information about outages and restorations to its members — via text, email, an app, or a web portal. 

The backgroundMTEMC is the U.S.’s 5th largest electrical distribution coop.  MTEMC powers 215,000 members in four counties. The utility manages 11,000 miles of energized line on its ArcGIS platform.  

The Challenge: 

Last year, we talked to MTEMC about their implementation through a customer engagement vendor of a new member-facing application. We worked to enable their goal of connecting their Responder™ OMS with this new customer engagement application (or, colloquially, the "member system") to allow certain components of that system's existing functionality to work with the OMS data.

In the end, through the enablement of this data, members were able to receive and report information about outages and restorations via text, email, an app, or another means - such as through a web portal.

The Solution: Responder™ Integration

SSP began its work by modifying an existing IVR integration service, utilizing it in the member system to allow users to generate reports of an outage or other hazard in a way that showed up as a call in Responder™. Since generating a call is one of the most common integration touchpoints, it made sense to genericize the IVR call functionality into an all-purpose web service that can be used by various sources.

The Responder™ configuration has also been adjusted appropriately to show the specific source of any call, so that users know whether it's coming from IVR or from the new member system. This enables members to report outages through various media, such as using a text message, app, web portal, etc.

SSP also was asked to add Planned Maintenance functionality into Responder™, with the goal of being able to send planned maintenance information to affected members. The out-of-the-box planned maintenance reports are useful, but no data is preserved after the reports are generated. This new customization allows Responder™ users to store planned maintenance events, update scheduled dates at any time, and generate the out-of-the-box member report for any planned outage.

With planned maintenance events upgraded, the integration's job is now to ensure that recent outage and maintenance data can be retrieved by the member system. We tailored this integration to work with one of the member system's existing integration points, which periodically polls a location for flat files containing current incident and planned maintenance data, and separates them by type (planned outage, reported outage, or confirmed outage). This is done by a Windows service on the OMS server.

This may seem easy enough, but there are several other requirements that are being considered:

  • The service does not directly query the database, and instead uses existing and new Responder™ data requests via its standard messaging system.
  • When the service finds a planned maintenance event where the estimated restoration date is in the past, it closes the event, so that members can be notified that the work is complete.
  • Affected member information is required for each confirmed incident, including up-to-date information on which members have been added to an incident, and which members have had their power restored. Unconfirmed incidents are sent without member information as a reported outage.
  • Updates must be tracked for several cycles (at both the incident and member level) before being considered complete, including restored outages, so that it can be ensured that the member system has retrieved the data. This requires a staging table and more complex processing around tracking cycles and the interval time between cycles. This was made to be easily configurable if the member system's  requirements change.
  • Projection is required for coordinate data to work properly with the spatial reference of the member system.
  • The service and the updated schema will remain functional if MTEMC is required to fail over to an existing Disaster Recovery environment.

The member system picks up the information on specified intervals to update its system, and when it detects certain changes, specific members can be notified. Members of a new confirmed outage, if opted in, will be notified through their preferred means of communication.

Members will also receive updates if the estimated time of restoration has changed or if no updates have been received in a given amount of time. When power is restored, members will be asked to confirm that they're back up and running. If not, a new outage will be created in Responder™.

The Results:

This integration has enabled MTEMC to implement a system to improve its channels and visibility between the utility itself and its members in a way that is mostly automated. We enjoyed working together with MTEMC to make their vision for this system possible, and we look forward to the next challenge!

Related Content:

Integrating Responder™ - Part 1, Talking to Responder™

EWEB Hires SSP for ArcFM™ and Responder™ Consulting

Creating Outage Incidents in OMS with MultiSpeak