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.