“There has to be an easier way!” I find myself saying this often as I research and analyze the streetlight reporting process at municipalities and utilities across the country. I’ve noticed some common obstacles in the streetlight outage reporting process, and have seen a few good ideas as well.

The number one issue I have run across is: who owns the light? It is impossible to report an incident until you know who owns the light. In reviewing a streetlight outage in the northeastern United States, I came up empty handed after browsing the internet to find out where to report the light and had to call the local public works department. They informed me that the local utility handles all of the city’s streetlights. This was impossible to determine without
reviewing several different organizations’ websites and making a couple of phone calls. This takes a considerable amount of time, and I can see how it would easily frustrate a customer that simply wants to report an outage for the light in front of their house. After spending a half hour trying to find this information, I was finally able to report the outage on the utility’s website. Thankfully, their site was very user friendly, with a quick reporting process that asked for minimal details, another key point to remember.

The problem of “where do I report this light?” is easily solved with the organizational trusts feature of SLO. Using organizational trusts, SLO takes streetlight data from multiple organizations serving the same region, and displays all of those light locations on the same map. When a report is submitted, SLO automatically routes that report to the proper organization. If the light is maintained by the local municipality, that organization will receive the ticket. On the other hand, if the light is maintained by the local utility, that organization will receive the ticket. But to the customer, the streetlight reporting process becomes seamless and straightforward. No longer is it necessary to research who owns what lights and figure out which phone number or website to use to submit a report. The user simply locates the light on either the municipality or utility website (as long as they are both SLO customers), or on the main SLO site, and can clearly see who the report is being submitted to. Backstage, the report is properly routed to the correct organization.

As mentioned earlier, having a simple outage reporting process is key to keeping your customers happy. I was fairly unhappy with a utility in the Midwest that had a lengthy and confusing process. After figuring out they didn’t have an online reporting tool, I had to call customer service. To report a problem with a streetlight I had to have all of the following information: address, closest cross streets, and type of light. I imagine most people wouldn’t know the type of light, so how is an outage reported without that information?

With SLO, all the details you maintain for each light in your database are tied to that light in the SLO system. Your streetlight GIS data is quickly uploaded to SLO, and each light location is represented by a light icon on the map. When your customers submit a report for one of the lights on your SLO map, all information tied to that light is submitted to you with the report. The data sent to your organization with each outage report is completely customizable, including but not limited to: light type, pole number, latitude and longitude, light wattage, and address. With SLO, you don’t need to rely on your customers to provide the information you need to send out a repair crew.

click image to enlarge

On the other hand, I found a reporting site for a city in the southwest to be quick and easy to use. It was very convenient that you could enter the address of the light or the pole number. Most people will have one piece of the information or the other.

SLO provides this benefit as well, since it does not require your customers to submit all the necessary information when reporting a light outage. With SLO, users can search for a light by browsing the map, entering a pole number, or using an address. Once the report is submitted, all of the location information is tied to the trouble ticket for ease of processing in your backend systems.

Offering a way to easily report streetlight incidents online can deliver many benefits. It helps save valuable time for call center representatives, while capturing more accurate information from the customers. Even in cases where a call still comes in, the SLO platform provides a great tool to allow the call center staff to quickly submit an accurate report on the caller’s behalf. Having more timely and accurate information avoids wasted time for field crews and extra costs when the wrong facilities are visited – and in some cases even repaired. SLO helps make it easy to capture and manage light reports online, provides a great customer experience, and enhances your back office processes and field work.

The iFactor development team continues to improve StreetLightOutages.com, making it easier than ever for users to report streetlight outages and check the status on previously reported lights, and for organizations to manage streetlight outages while keeping their customers updated on the repair progress. Our latest updates have streamlined the reporting process for users by providing more search options, quickly pinpointing a particular address or pole number, and clearly indicating poles with multiple lights. We’ve also sophisticated the management console for organizations, allowing those with administrative access the ability to export outage reports to Excel and add comments to individual light outages.

We have optimized the search bar by separating pole and address searches with button options for “Search by pole” and “Search by address”. If searching by address, a location marker on the map indicates the exact location entered. If searching by pole number, the streetlight icon for that pole is highlighted with a red circle. The circle is removed as the user pans or zooms from the current location.

The outage reporting header has been redesigned and is now fully customizable. Organizations can select which options are to be displayed in the header, including options for Login, Help, Feedback, and My Reports. Bird’s eye view is also included, where available.

A new clustering feature has been developed that displays poles with multiple lights. If a pole includes more than one light, each light is represented by a different icon. The multiple icons are shown on the map in a set pattern. Users can mouse over each icon to find the light that they wish to report.

One of our most exciting new features is our export tool, which allows admin users to export streetlight information to a .csv file. Users may export a report of all lights in the system, or may choose to export light information by status type. The .csv file includes all information available in the grid view within the management tool.

Admin users may also update individual incident reports with comments. Multiple comments can be added for each light report, with a timestamp displayed for easy review. The organization may also elect to have comments emailed to the individual who reported the light, so customers are kept up-to-date on the repair process quickly and efficiently.

Reporting a non-working streetlight just became easier, thanks to a new online tool launched by Northern Indiana Public Service Company (NIPSCO).

Customers noticing a streetlight that is broken or burned out can conveniently visit www.NIPSCO.com/StreetlightOut and submit a request to have it fixed. An interactive map identifies all of the streetlights owned or maintained by NIPSCO. So, if a customer does not have the exact pole number, they still will be able to search for the streetlight by address or location.

“The availability of this new tool is just one of the many ways we’re working to continuously improve the services and support we provide for our customers,” said Karl Stanley, vice president of commercial operations for NIPSCO. “More importantly, the enhancements we’ve made to simplify reporting a non-working streetlight helps keep our communities safer.”

The new functionality, developed by iFactor Consulting, uses a combination of NIPSCO’s geographic information system (GIS) and Microsoft Bing Maps.

When a streetlight is reported, NIPSCO receives an incident report that includes all details related to the streetlight outage. The report contains such details as the streetlight pole number, address, wattage and light type, as well as information reported by the customer, including their name, contact information and additional notes about the outage. With this information, NIPSCO can quickly route the ticket to the appropriate department for repair. If the customer provides an email address, NIPSCO will notify the customer once the streetlight has been repaired.

The online tool also provides a status of the light, in case someone else has already reported the outage. For those customers who are unable to access the online tool, they can still call NIPSCO’s 24-hour customer service center to report the streetlight at 1-800-464-7726.

NIPSCO is the first utility in Indiana to offer this online application for reporting streetlight outages.

NIPSCO, with headquarters in Merrillville, Ind., is one of the 10 energy distribution companies of NiSource Inc. (NYSE: NI). With over 712,000 natural gas customers and 457,000 electric customers across the northern third of Indiana, NIPSCO is the largest natural gas distribution company, and the second largest electric distribution company, in the state. NiSource distribution companies serve 3.8 million natural gas and electric customers primarily in seven states. More information about NIPSCO is available at www.nipsco.com.

Thematic overlays provide shaded polygons indicating boundaries for state, county, or city/town/village. These overlays are automatically displayed based on the zoom level being used. If a user clicks on a shaded state, the map is then zoomed to the county level. If the user then clicks on the shaded country, the map is zoomed to the city/town/village level.

Incident status in report interface

A “My Reports” link is now included in the SLO reporting interface. This feature allows the authenticated user to check the status of the reported streetlight. Other useful information includes the reported date and address of the particular outage.

Service area boundaries for organizations

An additional layer is used to display the organization’s territory served. This is based on boundary information provided by the organization. The territory is shown with a blue boundary line which is displayed at overview and detailed scales.

StreetLightOutages.com (SLO) is in the final stages of system testing at PHI. For this hosted streetlight outage reporting system, PHI is embedding the map from StreetLightOutages.com in their own web site. When a PHI customer navigates to the PHI web site to report a streetlight outage, they will browse to the appropriate location, click on the street light icon and complete the incident report form before submitting the incident. The SLO map will now include an icon that clearly shows an outage at the reported location. Each streetlight location in SLO has been configured to belong to a particular utility organization. If a user happens to click on a streetlight that belongs to a neighboring utility, they will be given more information about where to go to report that outage. In the future, as more utilities sign on to SLO, the entire experience will be even more seamless to the user. Users will simply report the outage at a streetlight and SLO will route the report to the owning agency.

Once the user has successfully submitted the incident, the SLO application will send a notification to a PHI endpoint that has been configured to receive secure notifications from SLO. The notification includes information about the outage, a reverse-geocoded street address and which, if any, streetlight is associated with that outage. At that point the outage handling process is handed off to PHI’s internal work management system to dispatch a crew to repair the streetlight. When the streetlight has been repaired, PHI’s work management system makes a web service call to SLO to tell it that the streetlight has been repaired. Once SLO receives the “all clear” message from the work management system, the incident icon will be removed from the map.

By implementing StreetLightOutages.com, PHI hopes to simplify the streetlight outage reporting process. Having a map with “smart” streetlight icons will ensure that the request is routed to the right utility company.

StreetLightOutages.com now supports both PUT and POST request methods for new incident requests. The POST request provides the form parameters in standard HTML form format as key and value pairs in the request body. The PUT request sends the information as a web service call as structured XML data in the request payload. You can find additional details an examples in the integration Help section.

There are 2 different options available in StreetLightOutages.com for embedding content on your website – iframes and ASP.Net code. The iframes approach is the easiest to implement, and allows you to use a single tag in existing HTML code to access the functionality, such as:

To use ASP.Net embedding, you must update the code on your web server to include calls which access and deliver the dynamic content from StreetLightOutages.com. With this approach, all content delivered to the users web browsers comes from your server. When you implement the ASP.Net approach, the developer is responsible for making sure that none of the local page content conflicts with the content needed for the StreetLightOutages.com code.

You can obtain sample code for either option through the administration pages on StreetLightOutages.com under the “Main” configuration tab.

The public API for creating and maintain asset locations in the StreetLightOutages.com platform is still under development. We are planning to create an API which will support a bulk replacement of all assets as well as operations to insert, update and delete individual assets in the system. This combination will allow integration with your internal asset systems using either a transactional or batch approach. We will update this post with references to the documentation on this API as it becomes available. We welcome your comments and ideas on this functionality.

Until the API is in place, paying customers of StreetLightOutages.com receive free batch loading of asset files up to once per month. To request an upload, open a support ticket at support.ifactorconsulting.com. The technician will provide information on the accepted file formats and procedures to upload your data.

Chris Pendleton, the evangelist for Bing Maps at Microsoft, had a look at StreetLightOutages.com and created a nice post to summarize the functionality. He even managed to embed a live SLO frame on the blog posting!! You can see it firsthand here.

StreetLightOutages.com allows any number of organizations to establish an electronic agreement called a trust. Once StreetLightOutages.com is configured with the trust, existing asset and incident data from each organization become visible to the other. The visibility means that an asset uploaded by one organization will be visible on the map of a second. The display of the asset, including the mouse-over information, will still include all of the details defined in the source organization. Perhaps an example will help:

1. Two organizations share street light maintenance in a region. One is a city, which we will call SLOVille and the other is a county, known as SLOLand.

2. SLOVille registers with StreeLightOutages.com and uploads a new set of street light assets. This includes a light in the corner of the park which we will call Light A.

3. SLOLand registers for StreetLightOutages.com and uploads a new set of assets. This set includes a certain light shown below which we’ll call Light B.

4. SLOLand deploys the StreetLightoutages.com portal on its web page using the standard iframe code

5. When a user navigates into the vicinity of Light A and Light B, they cannot see light B. Even though they are in the right area on the map, the light is owned by SLOVille, while the map is owned by SLOLand, so the data is not shared.

7. Now when a user navigates to the location of Light A and Light B on this map, they can see both assets, even though the map is deployed as SLOLand.

8. The user can click on either light to report an incident. If the user clicks on Light B, she will see the incident reporting form configured for SLOLand. If the user clicks on Light A, the form for SLOVille is displayed.

9. When the user submits the incident form, the integration rules (email, web services, etc.) of the organization that OWNS the asset is used to process the resulting form. This means that the resulting request is automatically routed to the correct organization, with no specific input from the end user except selecting the correct asset.

10. SLOVille can also create a trust to SLOLand. This will allow light B to show on maps deployed on the SLOVille website. But this is optional – so either one way or two way sharing of data can occur.

11. Both SLOVille and SLOLand save time dealing with reports that do not belong to their organization. The user gets faster service thanks to more accurate data and greater efficiencies and available to both organizations.