& Tricks
Application Design
Application Design 
More Transaction Page Tips & Tricks
If you're like me, you probably learn what you need to know about something to get stuff done. Sometimes, though, it pays to go deeper. Site Builder is no different; we designed it so that it would make simple things simple and sophisticated things possible.
Eliminate perceived delays while fetching pages from transactions
If you regularly use Transaction Pages in a Voice Site, your application may suffer from "latency disease." This is the caller perception that your application is sluggish, as they hear a "percolating" sound while the Angel system waits for your transaction scripts to respond.
A good way to reduce this is to mask the delay by playing audio while the dynamic content is being retrieved.
In the "Prompts" tab of a Transaction Page you will find two sections:
- Initial Prompts. These are played fully to the caller while the system is executing the Transaction Page.
- Wait Prompt. If the transaction takes longer than the total playtime of the Initial Prompts, the Wait Prompt will play in a loop, "padding" the silence that would otherwise occur.
Let's say your application calls for an initial lookup based on Caller ID that determines whether to play the "new user" or "existing user" menu. If this takes 3 or 4 seconds to find out, and you have no Prompts defined for the Transaction Page, the user will hear some silence, then some "percolating," and finally the menu that corresponds to their Caller ID. As you can imagine, this would sound a little clunky.
However, if you define Initial Prompts, the caller could hear a generic greeting such as "Thanks for calling the Acme Corporation! Our customers always come first! Be sure to check our weekly specials. ." While the system was playing the first part, it was also fetching the second part. As it finished playing the first, the second was ready. Although the caller has waited 1 or 2 seconds more, their perception is of a much snappier application.
The general rule to remember is that callers perceive applications that make them wait in silence as more sluggish than applications that make them wait while playing a non-patterned message.
If you've gotta fail, fail gracefully.
There's an old joke about a guy who was so proud that on one occasion he tripped as he was climbing some stairs. When asked what happened, he said: "Oh, I was just testing the soles of my new shoes!"
If, on occasion, your server decides to "test its new shoes" on you, Angel offers a way for your Voice Site to recover with some grace.
The most common ways an application call flow gets interrupted by a Transaction Page are:
- The transaction server has become unreachable. This could be due to a crash, a slowdown, or connectivity problems.
- The transaction server makes an unexpected response. This could be due to a code change or a runtime exception (e.g. the hard drive is full, the database is not responding). In most cases, your server will respond with a HTTP 500 line in the HTTP response header.
When Angel detects any of these conditions, it will take the caller to a voice page that you can determine:
You can get quite creative with what to do when a transaction fails. Some common best practices, in order of preference:
- Pretend like nothing happened and switch to a backup server. This is the ultimate error recovery procedure. If you can afford a backup system, you could take the caller to another Transaction Page that resubmits the variable information needed and re-executes the failed operation. With this tip, the caller experience can be quite seamless!
- Give the caller an alternative way to achieve their task. Is there another way to get to the same result? If the caller wants to know where their order is, but your order database is down, maybe an operator can access yesterday's order printouts and find the information that the caller needs. In that case, an operator transfer would be appropriate.
- If you are going to hang up on the caller, at least apologize and log what happened. If you can't afford either of the previous two approaches, you can at least play a nice message to the caller, e.g.: "Hmmm… I'm sorry, but there's something wrong with our system at the moment and I can't help you with your request. I will let somebody know about it so that it can be fixed. Would you be so kind to call a little later today? Thanks!" You can also use the "Email Debugging" feature to get an email alert of the error that occurred and the data that was collected up to that point. (For more about email debugging and other tips, check out Tips for Transaction Page Users)
A minimalist approach to building dynamic Voice Sites
I recently helped a customer design an application where both the content and the structure of the application were dynamic. Each caller, depending on his or her initial responses, would get a different experience. The same caller, on different calls, would also hear different things.
How can you achieve this? The answer is quite elegant: One Transaction Page that submits itself as a variable parameter, and expects an AngelXML document, the outcome of which is a redirection to the same Transaction Page!
It is then the responsibility of the script handling the submission to implement a state machine that will help it decide what is the next state, based on the last state and the currently submitted response.
Note that the AngelXML document should be of type "Question" for it to capture a value for you. For example:
n the example, note how the response to the question is stored in the same variable submitted by the Transaction Page that generated the question, and how the document, no matter what the response is, always forwards to the same page. This, in effect, achieves the loop.
Another neat trick is to define the variable as a List:
In this example, we are checking the "is List" box in Site Variables and setting the Response Storage to "Remember" in the Advanced Options of the Transaction Page. Thus, the variable will store an array of chronologically ordered responses: "[response1, response2, response3]." With this information, you may be able to dramatically simplify the state machine that handles the transitions for the application.
If your application calls for more than 20 interactions per call, you may have to introduce two Transaction Pages and randomly switch between them, as the Angel system has some "infinite loop" prevention measures built in. These are designed to save you from situations where a caller may have forgotten that they are on the line with your Voice Site, as the system will eventually hang up on the caller after a number of inactive interactions.
I hope you find the tips in this article useful. These are tools I have been able to apply to solve many design problems. As always, if you're working on an IVR project we'd love to talk to you! Give us a call at 888-692-6435 and say "Developer Hotline".
Sam Aparicio
