IVR Maintenance & Programming Part 1

Off and on for the past few weeks I have been working on analyzing all of the programming of our IVR/ACD system in order to validate and streamline all of the code. I have received several questions regarding standardization and best practices for IVR programming and I will share the knowledge and lessons I have learned here.

I have worked on several different IVR platforms for many different business models and what I have found is that few system administrators if any use any kind of known standardization when it comes to creating call flows, dial plans, messaging or the naming convention while programming their IVR. Most programmers use their past experience and their own common sense which is not common from person to person. This is fine if you have the same system administrator for the life of the switch and perhaps the company but how likely is this to happen anywhere.

I do not know of any universal standard for mapping out call flows within an IVR. However, there are industry best practices and easy ways to help the next person that comes along to figure out what has been done within the system that has to make changes or updates to the switch.

The first place to start to ensure that your IVR programming is understandable and easily accessible is in the documentation itself. You can never have too much documentation when it comes to IVR programming.

I suggest using Visio for all of your flows but also back that up with an Excel file for all of the specific information behind the flows. If you are familiar with IVR terminology, you know that there are DNIS, Vectors, VDN, Messages and a whole lot of other acronyms to deal with and some of them overlap when you program a flow. You can not always show this programming in the Visio flow to any understandable degree without creating a Visio flow that is three screens wide and four screens tall or by using Arial 6pt font. That is where the Excel files come in. You can show all of the flows and corresponding coding very easily in Excel where it is understandable to anyone who views the file.

Even if you have the latest and greatest IVR where all of the information is very user friendly and can be read and understood by anyone I still suggest backing up all of the flows and programming in external documentation just in case there is a catastrophic failure within your switch where it is not recoverable.

Another area where I have found that improvements can be made is in the naming convention, formatting and standardization. A lot of switch admins tend to name the pieces of a call flow in a manner that make since to them but do not always make it a standard naming convention across all projects or programs.

I suggest breaking the names down by program, project and identifier. e.g. xyz_new_opt1 (xyz=program, new=project, opt1=option 1). For messages you can name them based on whether or not they are a generic message for a specific project or a universal message that is used across all projects and/or programs e.g. xyz_new_hld = hold message specific to the new project under the xyz program where as uni_mon_msg = universal monitoring message that is used on all projects/programs.

You can come up with you own naming convention that fits your switch type, business model and how many projects that you have. The important thing is to keep the naming standardized across all projects and coding so that they are easily identifiable.

In Part 2 of this article I will discuss more best practices and key pieces that you must have programmed into your switch to allow for continuity in your business.

Posted in : Call Center
Tags: , , , , , ,

Leave a Reply