ca2.gif (4471 bytes)

IVR System Description

Introduction

In 1987 an ice storm ravaged Springfield Missouri, leaving downed power lines and interrupted electric service in its wake. Thousands of calls inundated City Utilities' customer service representatives and, because of the extent of the storm, some customers were without electrical power for up to a week.

After the storm, City Utilities General Management said that a solution had to be found. They decided to use Interactive Voice Response (IVR) technology to aid their customer service representatives during large electrical outages. Their goal was not to "replace" their customer service representatives, but rather to have an alternative way to service CU customers when representatives were not available.

I was hired to specify the system, write an RFP evaluate the bidders and recommend a solution. I choose Periphonics Corporation for many reasons including, ability to respond to all requirements of my RFP, far-sightedness in their design, and basic price/performance issues.

After Periphonics was awarded the bid I was retained to oversee the installation of the equipment and to develop and program the Electrical Outage Restoration system. The system performed well from its inception and has evolved into a sophisticated outage restoration system.

Overview of the System

Normally all calls are answered by Customer Service Representatives (CSR). When a City Utilities employee determines that a large outage has occurred s/he calls a special activation number. This number tells the caller the activation status of IVR. The caller can then enter a password if they wish to activate (or deactivate) the system. This allows anyone to check the status of IVR, but only authorized personnel to actually activate (or deactivate) the system.

IVR then sends commands to the PBX to re-route all calls from the CSR queue to the Outage Restoration System. Calls are then made to pagers and voice mailboxes, informing CU employees that the Electric Outage Restoration System has been activated (or deactivated). IVR then assumes the role of auto attendant, routing gas, water and billing questions to the proper representative while Electrical Outage calls proceed on through the system.

The caller is informed of the time they will wait to talk to a Customer Service Representative (if greater than one minute) and offered the chance to log their outage "electronically" using their touch-tone telephone. If the system does not detect touch-tones, the caller is routed to the speech recognition part of the application. Here the caller is asked to SAY their telephone number. If they still do not respond, the call is forwarded to a customer representative.

The customers phone number is entered on the "standard" (i.e. we did not have to modify any in place screens) mainframe outage restoration system screen. If a record is not found, the caller is forwarded to a customer representative.

If a record is found, the caller is asked to confirm the numeric (house number) portion of their address. This confirmation addresses two different concerns. First it makes sure that we dispatch a very valuable resource (our crews) to the proper location. Second, it reassures the reluctant caller that we indeed looked up their account and actually logged a ticket. This psychological confirmation can be very important in cutting down the calls being transferred to a CSR. The ticked is then submitted for final processing. There are two basic situations at this point.

First the ticket could be a duplicate log (of course none of you have any impatient customers that call and call and call, do you?). In this case the caller is informed that a ticket was indeed logged to their address and that we were working on the problem. The caller is then given a chance to talk to a CSR (we always want to give the customer a chance to talk to a live person). If the caller chooses to transfer their call, they are given an "updated" time in queue(just in case they don't REALLY want to talk to someone), and then transferred.

Second, a ticket can be successfully logged. A successfully logged ticket breaks down into two basic categories, special needs and a regular customer.

A special needs customer has a code on their file that indicates that there is life support equipment at their location. We respond to these customers with dialogue that indicates that not only has a ticket been logged, but also that we are aware of their situation.

A regular customer is simply informed that a ticket has been logged to their address. Both types of customers are offered the chance to talk to a Customer Service Representative. In both cases, if they choose this option, they are informed of their revised wait times, and the call is then transferred (assuming the caller doesn't hang up).

Results

The system was never designed to contend with all call possibilities. The philosophy has always been to get the largest number of calls while putting the caller through the least amount of grief. That is why calls are transferred to a Customer Service Representative anytime an exception occurs.

However, we realize that it is really in the callers best interest if they use the system to log their outage. This is why we always advise the caller of the amount of time they will wait to talk to a CSR. We feel that if the caller can log their ticket in less than one minute (average) using our system it is much better than waiting for three or eight or ten minutes (a large outage at midnight) to talk to a CSR.

Even with this philosophy, and depending on the area of the outage, the IVR can relieve our CSR call center from between 35% and 50% of the inbound calls. In the middle of the night, this frees the PBX operator (the only one answering calls) to call in CSR personnel if required, and during the day it frees CSR personnel do perform call-backs as service is restored.

The Future

At least 10% of the application is dedicated to the collection of statistics, and every enhancement has been predicated on these numbers. The speech recognition is fairly new so I will be watching those numbers very closely as the speech recognition equipment is a shared resource among all inbound lines. We currently have Primary Rate ISDN coming into our switch. Future enhancements include grabbing caller id, performing the primary lookup in our outage database and then transferring the call (if we can't find a record) or answering the call with a confirmation of house number. The easier we can make this for the customer, the higher our level of service (both actual and perceived). If the call needs to be routed to a CSR, we can look up the history of the customer, and if possible, route them to the last CSR they talked to.

We are also ready to implement an "auto-activate" feature on outage. This would automatically activate the Electric Outage Restoration System during an outage, and automatically de-activate it after the outage was under control. A manual activation could not be deactivated automatically while an automatic activation could be deactivated manually.

You can see a more technical explanation of this application if you are interested. Any comments or questions can be directed to me and I will answer as quickly as possible.

Virtually,
Todd Christell

Contents copyright © by Christell & Associates L.L.C.
This page last updated on November 29, 1998
mailto:webmaster@christell.com