Abstract:
An IVR system designer receives design specification data (which may be either state definition data or IVR system document data) and stores it in a database. A design specification report can be generated based on the stored design specification data. The report may correspond to a chosen period of time or it may correspond to chosen version of the IVR system. It may provide one or more of the following: a summary of a state within the IVR system, a listing of the previous states that lead to the current state, prompts for the state, inputs for the state, a listing of decision outcomes, key performance indicator triggers for the state, global commands that are active in the state, business units for which the state is applicable, a sample dialogues listing, test scripts listing for testing the IVR system, a change history listing for the system, a design flow diagram for the system, or pseudo-code listing for a portion of the system.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of Invention 
     The present invention relates to interactive voice response (“IVR”) systems, and more particularly to maintaining the IVR system specification, which includes both the data for the various state definitions as well as documentation for the IVR system. 
     2. Description of Related Art 
     Interactive Voice Response (“IVR”) systems allow a consumer to use a telephone keypad or voice commands to receive self service with a company&#39;s contact center without assistance from a contact center agent. For example, a customer of a credit card company may call its toll-free number, type or say her account number and a PIN, and hear information about her current balance, available credit, and next payment due date. By enabling customers to help themselves, IVR systems enable a contact center to handle more customers at one time than the available contact center agents could handle directly. 
     While IVR systems provide useful contact center functionality, they are not simple for a company to design, build, and maintain. IVR systems often have complicated, web-like, structures of content and numerous user touch-points. There are often different owners (including business and IT personnel) within a company for the various types of content needed to operate an IVR system. These business owners use differing techniques for documenting and maintaining their piece of the system. For example, the system test team may keep the scripts necessary for system and regression testing in one or more spreadsheets. The marketing team may use Visio or another graphical application to visually show the design flow for the customer experience when using the IVR system. A business analyst may maintain a word processing document to capture the details for each step or menu concerning payments. Other groups, with overlapping responsibilities, may use other forms of documentation. 
     The complicated interconnections within the IVR system, the supporting specifications for the system and the fact that the system is owned by a wide-spread group of business owners makes changing the system difficult. Even a small change to the IVR system requires multiple contacts to the business owners, who then are entrusted to each update their own documents to reflect the change. When changes are made to the system, its complicated nature makes it difficult to closely track the changes over time. The IVR administrator may try to manually compile a document of changes made to the IVR system between two versions. However, this manual process is inconvenient, time consuming, and ripe for mistakes. 
       FIG. 1  illustrates the prior art&#39;s approach to maintaining the design of an IVR system. In such systems, a single change that is to introduced to the IVR requires manual changes  105  to one or more of the following types of IVR system documentation: the design flow document  110 , the test scripts document  120 , the change history document  125 , the recording prompt list document  130 , the state definition details document  135 , and/or the sample dialogues document  140 . Some of these ( 110  for example) may be VISIO, POWERPOINT or other graphical files. Some ( 120  for example) may be EXCEL or other spreadsheets. Some of these documents ( 125 ,  130 ,  135 ,  140  for example) may be WORD or other word processing documents. Of course, this list of documentation is merely representative of documents that may be maintained. It is to be understood that different companies may maintain information about their IVR systems using different types of documents than the representative ones shown in  FIG. 1 . Regardless, if any of these manual changes  105  are missed, the reference data is no longer accurate. Since the various documents are owned by different groups, it is not difficult for this to happen. 
     What is needed is a system for centralizing the IVR system specification for an IVR system that is usually stored in several different applications, such as word processor, a spreadsheet application and a graphical application. What is a needed is a system that enables a change in the IVR system (whether it be a change to some state definition data or a change to IVR system documentation) to be entered once and yet reflected throughout the data and documentation for the system. Finally, what is needed is a system for tracking changes that can easily and accurately report modifications made to the IVR system specification for a specific time period or between two specified versions. 
     BRIEF SUMMARY OF THE INVENTION 
     According to one aspect of the invention, a method and system for designing an IVR system receives IVR system specification data from one or more computer users, which is then stored in a database. The IVR system specification data may be either state definition data or IVR system documentation data. A design specification report can be generated based on the stored state definition data and IVR system documentation. The system may also receive and store state definition design changes or IVR system documentation changes for the IVR system so that a subsequently run report reflects the design or documentation changes. 
     According to another aspect of the invention, the design specification report may correspond to a chosen period of time or it may correspond to chosen version of the IVR system. 
     According to another aspect of the invention, the design specification report may provide one or more of the following: a summary of the definition for a state within the IVR system, a listing of the previous states that lead to the current state, prompts for the state, inputs for the state, a listing of decision outcomes, key performance indicator triggers for the state, global commands that are active in the state, business units for which the state is applicable, a sample dialogues listing, test scripts listing for testing the IVR system, a change history listing for the IVR system, a design flow diagram for the IVR system, or pseudo-code listing for a portion of the IVR system. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates the prior art&#39;s approach to maintaining the IVR system. 
         FIG. 2  is a block diagram of one embodiment of the invention. 
         FIG. 3  illustrates the invention&#39;s approach to maintaining the design of an IVR system specification. 
         FIG. 4  illustrates a computer screen that allows state definition information to be viewed, and modified. 
         FIG. 5  ( 5 A- 5 I) is a mock-up of a design specification report  310 . 
         FIG. 6  is diagram showing the database tables for one embodiment of the invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     In the following detailed description of the preferred embodiments of the invention, reference is made to the accompanying drawings in which is shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention. 
     In one embodiment, the invention can be implemented as a series of users using computers  205  to access an IVR designer application  210  (either locally or over a network) that stores IVR system specification data in an IVR design database  215 . The IVR design database  215  includes state definition data  220  and IVR system documentation data  225 .  FIG. 2  is a block diagram for such an embodiment.  FIG. 3  illustrates the invention&#39;s approach to maintaining the IVR system specification. The prior art system shown in  FIG. 1  required multiple manual changes to describe a single change in the IVR system. As shown in  FIG. 3 , a single IVR specification change  305  may be entered in the IVR designer application  210 . This IVR specification change may be concerned with either state definition data and/or IVR system documentation. The application  210  can then generate a design specification report  310 . This report may contain enhanced versions of the one or more design specification reports used in the prior art, such as: the design flow document  110 , the global commands summary document  315 , the test scripts document  120 , the change history document  125 , the recording prompt list document  130 , the state details document  135 , the sample dialogues document  140  and the previous states document  320 . 
     The invention offers several advantages over prior methods of maintaining IVR system specification data. In one real life implementation, the invention reduces design time by 10-15%. It enables faster turnaround on updates for business reviews and improves documentation accuracy by 300%. The test script creation phase is reduced by 40-50% and initial code generation time is reduced by 10%. 
     As one skilled in the art will recognize, the IVR designer application  210  can be developed using one of many types of databases and database interfaces. For example, the ACCESS database program developed by MICROSOFT can be used. In another embodiment, an ORACLE database may be accessed via a GUI that is custom-built using JAVA. One skilled in the art will recognize that there are many approaches to take to build the present invention. 
     In an embodiment using MICROSOFT ACCESS,  FIG. 4  illustrates a computer screen  405  that allows state definition data to be viewed and modified. In this embodiment, each state of the IVR system is described centrally through such a screen  405 . (One skilled in the art will recognize that there are many approaches in implementing the present invention in a database and presenting the data to the user.) In  FIG. 4 , each IVR state is assigned a state name  410  and a type  415 . The type classifies the state. For example, a state may be only audio that is played to the customer. Or the state may be a decision point. Yet another type of state is a call to the database to retrieve or store data. 
     The module to which the state is associated is also chosen  420 . The module is a logical grouping of states, such as “main menu” or “payment”. The screen also includes a prompt section  425  lists details for the prompts that are present in the state. For example, the prompts may be stored as WAV files that are played to the customer. 
     The decisions section  430  lists the decision rules that the IVR implements for the current state. The type of the state (see element  415 ) dictates the type of decisions that are available. For a decision-style state, the decisions  430  show conditions that cause movement to other states in the system. The decisions section  430  for an audio state lists which of the pre-recorded prompts are played. If the state is a call to the database, the decisions  430  are what action to take based on the results of the database query. 
     The inputs section  435  details the keypad entries or voice commands, if any, that are available in the current state. In  FIG. 4 , the GoToAgent state allows the customer to press “0” to be transferred to an agent. 
     The key performance indicators (KPIs) section  440  documents the KPIs that are captured based on data from the present state. 
     The next section lists the available global commands  445 . Global commands are those commands that are widely available in the IVR system. For example, “main menu”, “help” and “operator” may be global commands. While these commands are widespread, they are not available everywhere. For example, in the middle of a transaction, the IVR may not accept a command to jump to the main menu. The global commands section  445  of  FIG. 4  documents which of the commands are available for the present state. The global commands section  445  is not something that was maintained in prior systems. 
     The technical activities section  450  lists technical information about the state. The notes section  455  allows users to keep track of notes for the state. These sections  450  and  445  may include a high level summary of what the state accomplishes. One of these sections may document which web services are used in connection with the state. One skilled in the art will recognize that other types of data may be stored here. 
     The previous states section  460  shows, based on the inputs and decisions, which states can cause a customer to enter the current state. This is important to know in order to fully understand how and why the state is being presented to the customer. 
     The screen of  FIG. 4  summarizes data for a particular state in the IVR system.  FIG. 5  illustrates a hypothetical IVR design specification report  310  generated by the present invention&#39;s application  210  for reporting on the definition data for one or more states, or for reporting various IVR system documentation. It is important to realize that  FIG. 5  (consisting of  FIGS. 5A through 5I ) is a mock-up of a report to demonstrate to the reader the type of information that can be reported from the IVR design database  215 . While the report mocked up in  FIG. 5  includes a change history  125 , a global commands summary  115 , sample dialogues  140 , state definition summaries for each state in the module  135  and an appendix, in a real application, the design specification report  310  may include only sections that contain data relevant to the module being reported on, or other those sections that a particular user wishes to generate. For example, the user may choose to generate just a state definitions section  135  or the sample dialogues section  140 , for example. It is also clear to one skilled in the art that the design specification report  310  can be formatted in numerous ways. 
     In some embodiments, the user may choose a beginning and ending version. The IVR designer application  210  generates the report  310  showing only those changes that were introduced between the beginning and ending versions of the IVR system. In other embodiments, the user may choose a beginning and ending date. The report  310  can be run to show changes introduced between these specific beginning and ending dates. The report in  FIG. 5  shows only changes made between system version  2 . 1  and system version  2 . 2  (see,  FIG. 5A ). 
       FIG. 5B  is the change history report  125  that can be formatted to summarize changes made to the IVR system specification (i.e., either the state definition data or the IVR system documentation). In this example, it can readily be seen that the global commands for the “Add New Customer” state and the inputs for the “Change Customer Profile” state were both modified on the third of March. 
       FIG. 5C  summarize the global commands for the various states. In this example, it is shown that the “help” command is only available when in state ChooseLanguage and ChangeProfile states. 
       FIG. 5D  is the sample dialogues report  140 . It can summarize the dialogues used in the system, which IVR states the dialogues are connected to, and what conditions must be present for the dialogues to play. For example, if the user is in the ChangeServices state and has indicated that she wants to stop her premium service, the IVR system may ask “Are you sure you want to discontinue receiving the premium services?” 
       FIGS. 5E ,  5 G and  5 G form the state details summary report  135 . In this example, three states (i.e., Account Summary, ChooseLanguage and WelcomeState) are included.  FIG. 5H  is the appendix, which may include other information. In the example shown, API information is included as well as pseudo-code for the WelcomeState. 
       FIG. 5I  is the design flow report  110 , which may graphically display the customer experience flow of the system. In some embodiments, this report may insert a VISIO or other graphic file that is produced manually. In other embodiments, the IVR designer application  210  may include functionality to push all relevant changes from its database to a graphics program so that the design flow  110  is automatically changed which each changed introduced by the users. 
     As has been discussed above, the design specification report  310  in  FIG. 5  is generated based on data in an ACCESS or other database  215 .  FIG. 6  is diagram showing the database tables for one embodiment of the invention. In other embodiments, other tables and table structures can be developed. One skilled in the art will recognize that in the embodiment shown in  FIG. 6 , the StateDefinition table stores the primary information for each IVR state, and that the other tables store information regarding the prompts, KPIs, Inputs, etc. Forms (such as the one shown in  FIG. 4 ), queries and reports (such as  FIG. 5 ) can be built based on these database tables to enable users to maintain and document IVR system specification.