I thought I was done with IVR posts. I was wrong. One of the wonderful things about the Internet is the way information gets shared behind the scenes. Since I started writing about our IVR problems I have now been contacted/referenced by two different IVR specialists that say there may be hope for what ails us.
Now I am more optimistic than most but I want to be realistic about what we can and cannot accomplish with our IVR and then I want to set the public's expectations realistically (don't worry, what the public has asked for is realistic, the gap right now is on Capital Metro's side). In order to do that we have to look at all possible options. Including the largest of all which is scrap the system all together and go in a different direction. Some have said this is the way to go. At this point I don't know if that is the right answer or not. But we won't know if we don't look at it. And we will.
To that end, I want to thank all those that have given and are giving us feedback. While no one likes to be told something they have responsibility for stinks, it is unfortunately the best way to get better. And that is what we are going to do. So please keep sending the ideas, and YES, vendors please keep contacting us so that we can eventually get to the best darned Public Transit IVR in the U.S. of A.
Okay, now for something completely different...
Read more
Showing posts with label IVR. Show all posts
Showing posts with label IVR. Show all posts
Thursday, July 3, 2008
Wednesday, July 2, 2008
IVR Solutions
So how do we fix the problems with the IVR? In a word, persistence. In a little less brevity we have a few layers to tackle and the plan is to tackle each layer in order. Naturally we want to hit the problems with the biggest impact, but some of the issue will take rebuilding the system from the ground up and some will take new software from the various vendors. Therefore, like other big Goliaths, we tackle the items that will be the quickest to resolve with the biggest payback for the effort.
- Fix the script errors as quickly as we find them. As mentioned before, the number of places that something can go wrong in a system this size is staggering. So while we are looking at the system regularly to find the errors we can, the fastest way to find the issues is to foster feedback from the community that uses the system. When we hear that there is an error in the IVR we have our team take a look and attempt to fix the problem. If it is a simple "misalignment" of the script we try to correct it immediately. If it is a more complex problem, then we often have to refer back to the vendor and are therefore more constrained by their schedules.
- Work on the source of internal data issues. Unfortunately some of the errors in the IVR system are squarely our fault. Bad data in = bad data out. When we forget to include a bus stop, or we misspell one of Austin's more creative street names, our customers feel the pain at the IVR. Along with the script errors above we will correct these as we become aware of them. But more importantly, our strategy is to work with each of the groups within Capital Metro to make sure everyone puts good data in.
- Add touch tone to every part of the script that we can. This I think is one of the biggest issues with the IVR today. When I first heard about the issues with the speech recognition, my initial reaction was to pull it. But then when I started floating the idea of dumping that feature, I had numerous reactions from people that liked that piece and that had positive interactions with the voice recognition component. In the end, the best solution seems to be ensuring that we put touch tone everywhere we can in the system along side the voice recognition, and give the callers a choice. (Shocking conclusion I know. Choices are good.)
- Rearrange the script to be simpler and easier to use. Include better structure for the voice recognition. By changing the way we approach the voice recognition prompts, by making it easier to "get out of" the IVR cycle, and by better communicating the options that a caller has at any point in the script, we believe that we will have a better product. This change will be tied in with the previous change so that what you get is a more effective tool and will allow us to better pair touch-tone and voice recognition throughout the system.
- Add additional, obvious, and beneficial functionality. This actually will be the hardest change, which is why I saved it for last. The reason new functionality is tricky is because it depends on pulling information out of other systems (sometimes 2 or 3 simultaneously) which requires coordination and boundary discussions. Of course, the easiest changes are the ones where the underlying database or application has the information you want. But it seldom seems to be that easy.
In a nutshell this is going to be a long process to fix the system. I am hoping that as we progress we can stabilize quickly, make some obvious improvements early on, and then continue to deliver a better IVR month after month into the foreseeable future. If you have ideas or suggestions, please let me know. Read more
- Fix the script errors as quickly as we find them. As mentioned before, the number of places that something can go wrong in a system this size is staggering. So while we are looking at the system regularly to find the errors we can, the fastest way to find the issues is to foster feedback from the community that uses the system. When we hear that there is an error in the IVR we have our team take a look and attempt to fix the problem. If it is a simple "misalignment" of the script we try to correct it immediately. If it is a more complex problem, then we often have to refer back to the vendor and are therefore more constrained by their schedules.
- Work on the source of internal data issues. Unfortunately some of the errors in the IVR system are squarely our fault. Bad data in = bad data out. When we forget to include a bus stop, or we misspell one of Austin's more creative street names, our customers feel the pain at the IVR. Along with the script errors above we will correct these as we become aware of them. But more importantly, our strategy is to work with each of the groups within Capital Metro to make sure everyone puts good data in.
- Add touch tone to every part of the script that we can. This I think is one of the biggest issues with the IVR today. When I first heard about the issues with the speech recognition, my initial reaction was to pull it. But then when I started floating the idea of dumping that feature, I had numerous reactions from people that liked that piece and that had positive interactions with the voice recognition component. In the end, the best solution seems to be ensuring that we put touch tone everywhere we can in the system along side the voice recognition, and give the callers a choice. (Shocking conclusion I know. Choices are good.)
- Rearrange the script to be simpler and easier to use. Include better structure for the voice recognition. By changing the way we approach the voice recognition prompts, by making it easier to "get out of" the IVR cycle, and by better communicating the options that a caller has at any point in the script, we believe that we will have a better product. This change will be tied in with the previous change so that what you get is a more effective tool and will allow us to better pair touch-tone and voice recognition throughout the system.
- Add additional, obvious, and beneficial functionality. This actually will be the hardest change, which is why I saved it for last. The reason new functionality is tricky is because it depends on pulling information out of other systems (sometimes 2 or 3 simultaneously) which requires coordination and boundary discussions. Of course, the easiest changes are the ones where the underlying database or application has the information you want. But it seldom seems to be that easy.
In a nutshell this is going to be a long process to fix the system. I am hoping that as we progress we can stabilize quickly, make some obvious improvements early on, and then continue to deliver a better IVR month after month into the foreseeable future. If you have ideas or suggestions, please let me know. Read more
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.
- Understand what problem is happening
- Reproduce the problem consistently
- Trace the problem back to the one or more systems causing the problem
- 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.
Read more
Monday, June 9, 2008
IVR Primer
I would like to begin my posts with a discussion of our IVR (Interactive Voice Response) system. For those not aware this is the “phone tree” or automated phone system that you have the choice to interact with whenever you call the Go Line (474-1200) or the STS information and reservation numbers. For the more astute readers out there the choice is not really a choice when calling after hours as the manned phone lines only offer automated options when no one is around.
To understand IVR’s one needs to understand the nature of call centers. IVR’s were invented to try to deal with the explosive growth of inbound calls that companies experience as their customer base grows without increasing call center staffing in a linear fashion. Many calls are common and request simple information that can be easily automated. The theory is that if you can answer these simple questions with an automated system, then you will need fewer people to respond to the types of questions that only a human can handle (and thereby lower the cost associated with customer or business growth). The problem comes when more complex questions are pushed to the IVR’s and/or the callers come to prefer the IVR and thus depend on it to answer more complex questions. The result in either case is a frustrated caller and a potentially lost rider. Like most things in life, the trick is in finding the balance between the purpose for which IVR’s were built, and the need to handle more calls on a daily basis.
For example, when a rider calls in to find out what hours the customer service line is automated, an IVR can and should handle this type of call. But when a rider calls in to find out how to get from Downtown to Highland mall in the shortest time possible, an IVR will not do a good job of handling this question (a lot of human judgment and discretion is required which an IVR just can’t muster). So why do I mention all of this? The simple answer is that the Capital Metro IVR is not currently meeting our rider’s expectations at the level we would like. What I hope to go into over the next few posts is why this is the case, and more importantly, what Capital Metro is doing about the situation.
Thanks,
Kirk Talbott
CIO – Capital Metro
Read more
To understand IVR’s one needs to understand the nature of call centers. IVR’s were invented to try to deal with the explosive growth of inbound calls that companies experience as their customer base grows without increasing call center staffing in a linear fashion. Many calls are common and request simple information that can be easily automated. The theory is that if you can answer these simple questions with an automated system, then you will need fewer people to respond to the types of questions that only a human can handle (and thereby lower the cost associated with customer or business growth). The problem comes when more complex questions are pushed to the IVR’s and/or the callers come to prefer the IVR and thus depend on it to answer more complex questions. The result in either case is a frustrated caller and a potentially lost rider. Like most things in life, the trick is in finding the balance between the purpose for which IVR’s were built, and the need to handle more calls on a daily basis.
For example, when a rider calls in to find out what hours the customer service line is automated, an IVR can and should handle this type of call. But when a rider calls in to find out how to get from Downtown to Highland mall in the shortest time possible, an IVR will not do a good job of handling this question (a lot of human judgment and discretion is required which an IVR just can’t muster). So why do I mention all of this? The simple answer is that the Capital Metro IVR is not currently meeting our rider’s expectations at the level we would like. What I hope to go into over the next few posts is why this is the case, and more importantly, what Capital Metro is doing about the situation.
Thanks,
Kirk Talbott
CIO – Capital Metro
Subscribe to:
Posts (Atom)