Cisco Cisco Unified Customer Voice Portal 11.0(1) User Guide
C
HAPTER
1:
I
NTRODUCTION
C
ISCO
CVP
V
OICE
XML
User Guide
Flag Elements
One tool an application designer requires is a mechanism where the activities of callers can be
analyzed to determine which part of the application is the most popular, creates confusion, or
otherwise is difficult to find. To do these analyses, the developer would require knowledge on
whether a caller (or how many callers) reached a certain point in the application call flow. This
check may also be done within the call itself, changing its behavior dynamically if a caller
visited a part of the application previously. To do this, the developer would use flag elements.
analyzed to determine which part of the application is the most popular, creates confusion, or
otherwise is difficult to find. To do these analyses, the developer would require knowledge on
whether a caller (or how many callers) reached a certain point in the application call flow. This
check may also be done within the call itself, changing its behavior dynamically if a caller
visited a part of the application previously. To do this, the developer would use flag elements.
Flag Element
Records when a caller reached a certain point in the call flow.
Flag elements can be seen as “beacons”, which are triggered when a caller visits a part of the call
flow. The application designer can place these flag elements in parts of the call flow that need to
be tracked. When the flag is tripped, the application log is updated so that post-call analysis can
determine which calls reached that flag. The flag trigger is also stored within the call data so an
application can make decisions based on flags triggered by the caller.
flow. The application designer can place these flag elements in parts of the call flow that need to
be tracked. When the flag is tripped, the application log is updated so that post-call analysis can
determine which calls reached that flag. The flag trigger is also stored within the call data so an
application can make decisions based on flags triggered by the caller.
Flag elements have a single exit state and do not affect the call flow whatsoever.
Hotlinks
Many voice applications require an utterance or key press that can be produced by the caller at
any time during the call, and result in the application performing a specific action. One common
example is the utterance "operator" (and / or pressing “0”) transferring callers to a live
representative. In Cisco CVP VoiceXML, these actions are referred to as hotlinks.
any time during the call, and result in the application performing a specific action. One common
example is the utterance "operator" (and / or pressing “0”) transferring callers to a live
representative. In Cisco CVP VoiceXML, these actions are referred to as hotlinks.
Hotlink
A globally accessible utterance and / or key press that immediately
brings the call to a specific part of the call flow or throws an event.
brings the call to a specific part of the call flow or throws an event.
Hotlinks are not elements in that they do not generate VoiceXML or execute any custom code.
Instead, a hotlink acts as a pointer (or link) to direct the call somewhere or throw a VoiceXML
event when the right word or key press is detected. An application can utilize any number of
hotlinks.
Instead, a hotlink acts as a pointer (or link) to direct the call somewhere or throw a VoiceXML
event when the right word or key press is detected. An application can utilize any number of
hotlinks.
Hotevents
While hotlinks are caller utterances that trigger an action, there are times when the occurrence of
a VoiceXML event is expected to trigger an action. The event can be user-triggered (such as a
noinput event), asynchronous (which would be thrown by the voice browser), or developer-
defined (such as a hotlink that throws an event). In each case, the developer may wish to play
audio, store data, or move to another part of the call flow when the event is triggered. In Cisco
CVP VoiceXML, these are referred to as hotevents.
a VoiceXML event is expected to trigger an action. The event can be user-triggered (such as a
noinput event), asynchronous (which would be thrown by the voice browser), or developer-
defined (such as a hotlink that throws an event). In each case, the developer may wish to play
audio, store data, or move to another part of the call flow when the event is triggered. In Cisco
CVP VoiceXML, these are referred to as hotevents.
©2000 - 2005 Audium Corporation. All Rights Reserved. 1/14/05
21