Monday, June 16, 2008

IVR Challenges

From my first week at Capital Metro, I heard about the issues facing our IVR system. While there was no shortage of anecdotes, the bigger challenge was figuring out the root cause of the problems. There was no point in putting a band-aid on the IVR when there were structural problems with the system. However the way issues were reported did not immediately reveal the source of the problems. And to further complicate things the IVR is not a single computer running in a closet somewhere. The system is actually made up of multiple phone related servers, the phone system (both on your end and ours), scheduling data stored in one database, and multiple route and reservations data stored in other databases. All told, the IVR system is made up of about a dozen vendors' products that all have to work together to present the data that Capital Metro puts into it. So when a problem occurs we have to go through the following steps before we can figure out what is causing the problem.
  1. Understand what problem is happening


  2. Reproduce the problem consistently


  3. Trace the problem back to the one or more systems causing the problem


  4. Get the vendor(s) responsible for that/those system(s) to take ownership of the problem and solve it

The easiest problems to solve are actually content problems (when we enter data wrong or incompletely). They aren't any easier to find, but at least we are the only ones accountable for these fixes. The issue here again is the size of the system, with the tens of thousands of data elements that have to come together to make it work, we are constantly finding items that need to be fixed.

As I mentioned earlier, many of the complaints about the IVR were anecdotal (certainly valid, but not specific enough for us to reproduce and therefore be able to fix). However, in recent meetings with the riding community (both at ACCESS and Customer Service Advisory Committee group meetings) I've captured the specific issues I've heard and we've been prioritizing them to address the underlying issues. In my next blog I will lay out the priorities and the next steps that we will be undertaking to make sure the IVR gets better. However, in the remainder of this post I am going to list the issues that we have captured so far so that I can fufill the promise I made to the ACCESS and CSAC groups a few weeks ago (I haven't forgotten):

http://www.capmetro.org/blog/IVR_Issue_Log.XLS


Given the length of the list and the limitations of this blog, I am going to try to link to the Excel Spreadsheet. If this process doesn't work, we will regroup and try this a different way.