Rethinking IVR development


Previously I’d written about the lack of software development methodology in creating contact center applications such as self-service IVRs and routing logic. Since a lot of IVR developers are self-taught, without formal software engineering background, or forced by circumstance to take on the task, I believe a good way to approach this is to start from the very basics of software development. Set aside methodology for a moment and just simply contemplate on what an application is.

Like a Story

Who doesn’t love a good story? An introduction that hooks your attention, progresses to a climax that prevents you from setting down the book, and finally a conclusion that satisfies your curious appetite.

An application also has a beginning, middle, and ending. The beginning is taking some sort of data as input, the middle is to process that input, and the ending is the result of the execution. So in your mind just think of the app you’re creating as a simple outline for a story, with a beginning, middle, and ending. From that you will add a variety of elements to the outline, expand plots, and finish a complete story.

MVC

No, I’m not referring to “most valuable customer.” MVC is the famous Model-View-Controller design pattern, first conceived way back in 1979 by the brainiacs of Xerox PARC. You may already know that Xerox PARC was credited with the invention of the mouse, GUI (graphical user interface), and Ethernet. But equally important was its contributions to software development, like object-oriented programming (OOP), the Smalltalk programming language, and of course, MVC (from Wikipedia):

The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its associated views so they can refresh.

Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made. Also, the ActiveRecord is an accepted design pattern which merges domain logic and data access code – a model which knows how to persist itself.

The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

The controller receives input and initiates a response by making calls on model objects.

This is a very popular pattern when it comes to web app development. Next time you’re doing some online shopping think about all the facets of the experience and what has to come together to make it all work.

Now close your eyes and imagine how it would work without visual elements and only using your ears. In other words, think of your IVR app as a web app, but without the browser and only caters to blind users.

Keep It Simple, Stupid!

Be conscious of the KISS principle, in designing the presentation (i.e. IVR menus and voice prompts) and in coding the business logic. Remember, your users are blind and their browser is a numeric keypad.

Learn to love abstraction. Break up big problems into smaller chunks, perfecting a chunk at a time. Refactor your code in order to simplify it, not only to you the developer, but also to others who may need to read it one day. That means grouping similar logic into functions or subroutines. Always comment your code and update documentation.

Write your app as if writing a story. Carefully craft the main characters, build upon subplots, be concise and clear, etc.

I used to write IVR apps with a sequential mindset, meaning that I’ll string up menu after menu. It made for hairy looking apps and difficult to navigate through the code when needing to make changes.

Then I learned from someone to code it like a state machine (or a wheel). Analyze the call flow to find logical abstractions. Create a label for each abstraction (e.g. Greeting, AskForCustNum, ProcessCustNum, etc.). In the code keep a variable to update the labels as you develop the whole call flow in the IVR as a gigantic loop. Here’s what I mean in pseudo-code:

// Initialize the state machine

SET state_label = ‘Greeting’

WHILE state_label NOT-EQUAL-TO ‘End’

IF state_label IS ‘Greeting’ THEN      // Greeting menu

{ play greeting prompt }

SET state_label = ‘AskForCustNum’

IF state_label IS ‘AskForCustNum’ THEN       // Get customer number menu and input

{ ask for customer number; get customer input }

SET state_label IS ‘ProcessCustNum’

.

.

.

IF state_label = ‘End’ THEN       // End of call flow

{ play thank you prompt }

EXIT WHILE

Obviously IVRs aren’t programmed like this anymore, so this would require some translation to whatever IVR development tool you’re using. But notice that this will flatten out the menu tree to make the app more readable, plus changes to the call flow can be made easily by just modifying the variable state_label accordingly. For example, in order to bypass the greeting all you have to do is initialize state_label to ‘AskForCustNum’ or whatever new entry point you want — there’s no need to move blocks around or reconnect any lines.

Conclusion

In any IVR development project it makes sense to step back a bit and soak in the broader picture before diving head first into the programming aspects. Write code as if writing prose, and always keep simplicity and abstraction in mind to ensure that not only you will enjoy the development process, but also others in the future.

Advertisements

8 thoughts on “Rethinking IVR development

  1. Eugene, good to see others using state models. We use state modeling for IVR applications starting with the discussion of call flow with the application stakeholders. These discussions often drift into considerations of what is said (dialogue & persona) vs. what is done (business logic) and the use of a state model helps keep the client focused on the business requirements. Our state modeling notation carries directly into application modeling. We keep our IVR applications simple, with each state performing a discrete unit of work, e.g. “get account number”. Transitions from one state to another occur via a transition condition, which is a test that returns a true or false value, e.g. gotValidAccountNumber. A true value results in the transition to the connected state. Rather than a procedural approach we typically use event triggers to invoke the state manager and its associated state transition map.

    For a good introduction see Shlaer & Mellor “Object Lifecycles: Modeling the World in States”.

    Like

  2. Eugene, good to see others using state models. We use state modeling for IVR applications starting with the discussion of call flow with the application stakeholders. These discussions often drift into considerations of what is said (dialogue & persona) vs. what is done (business logic) and the use of a state model helps keep the client focused on the business requirements. Our state modeling notation carries directly into application modeling. We keep our IVR applications simple, with each state performing a discrete unit of work, e.g. “get account number”. Transitions from one state to another occur via a transition condition, which is a test that returns a true or false value, e.g. gotValidAccountNumber. A true value results in the transition to the connected state. Rather than a procedural approach we typically use event triggers to invoke the state manager and its associated state transition map.

    For a good introduction see Shlaer & Mellor “Object Lifecycles: Modeling the World in States”.

    Like

  3. Another benefit to this approach is that the process flow diagram maps 1:1 to the VUI, which maps 1:1 to the apppication which maps 1:1 to the detail table of a call reporting database. I create a master-detail database were the detail table consists of all the different states in the application along with the result of the state SUCCESS/FAILURE and any collected data. The result is the customer can map the VUI 1:1 to the database to see the caller’s experience on the call. This also helps out a lot in the debugging of the application as well.

    Like

  4. Another benefit to this approach is that the process flow diagram maps 1:1 to the VUI, which maps 1:1 to the apppication which maps 1:1 to the detail table of a call reporting database. I create a master-detail database were the detail table consists of all the different states in the application along with the result of the state SUCCESS/FAILURE and any collected data. The result is the customer can map the VUI 1:1 to the database to see the caller’s experience on the call. This also helps out a lot in the debugging of the application as well.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s