Designing IP ICD Scripts

Table of Contents

Designing IP ICD Scripts
IP ICD Script Variables
The Start Step
The Accept Step
The Get Contact Info Step
The Get Session Info Step
The If Steps
Recording a Name
The Select Resource Step
Using Default Scripts

Designing IP ICD Scripts


Cisco IP Integrated Contact Distribution (ICD) is an automatic call distributor (ACD) for enterprise organizations.

You can use the Cisco Customer Response Applications (CRA) Editor to design scripts that take advantage of Cisco IP ICD capability.

This chapter describes the design of such a script, SessionEnabled.aef, and also serves as a good demonstration of the use of the steps from the Session palette for session management and the use of a default script that executes if an error occurs in the main script.

The sample ICD script performs the following functions:

1. Accepts a call.

2. Asks the caller to enter an account number.

3. Records the caller's name.

4. Does one of the following:

  • Connects the caller to an agent
  • Queues the call and sets a priority, based on whether or not the caller has already entered an account number on a previous attempt to connect during the same session, and/or if the main script has already failed and the caller has been re-routed back to the main script.

Figure 14-1 shows the top-level view of the sample ICD script in the Design pane of the CRA Editor.


Figure 14-1   ICD Sample Script Design Pane—Top-level View


This chapter contains the following sections:

IP ICD Script Variables

The designer begins the script design process by using the Variable pane of the CRA Editor to define script variables.

Figure 14-2 shows the variables of the sample ICD script as they appear in the Variable pane of the CRA Editor.


Figure 14-2   ICD Sample Script Variable Pane


Table 14-1 describes the variables used in the ICD sample script.

Table 14-1   Variable Descriptions for the Sample ICD Script

Variable Name Variable Type Value Function

resourceID

String

Stores the Resource ID of the chosen agent.

(See The Select Resource Step.)

CSQ

String

Stores Contact Service Queue information from which to find a resource.

(See The Select Resource Step.)

The designer marks this variable as a parameter to allow the administrator the option to change the value of this variable.

For more information, refer to the Cisco Customer Response Applications Administrator Guide.

DelayWhileQueued

Integer

30

Length of time the script will delay before sending the call back through the queue loop.

(See The Queued Output Branch.)

The designer marks this variable as a parameter to allow the administrator the option to change the value of this variable.

For more information, refer to the Cisco Customer Response Applications Administrator Guide.

WelcomePrompt

Prompt

P[ICDWelcome.wav

Welcomes the caller.

(See The Play Prompt Step.)

The designer marks this variable as a parameter to allow the administrator the option to change the value of this variable.

For more information, refer to the Cisco Customer Response Applications Administrator Guide.

session

Session

null

Stores session information for the call.

(See The Get Contact Info Step.)

failureCount

Integer

0

Stores the number of times a call has failed.

(See The Session Steps)

accountNum

String

Stores the account number entered by the caller.

(See The Play Prompt Step.)

session2

Session

null

Stores previous session information based on the accountNum variable.

(See The Session Steps.)

prompted

Boolean

false

Stores information to determine whether or not the caller has heard WelcomePrompt.

(See The First If Step.)

language

Language

English
(United States) (en_US)

Stores the language selection made by the caller.

(See The Third If Step.)

name

Document

null

Stores the spoken name of the caller.

(See Recording a Name)

queued

Boolean

false

Stores the information used to determine whether or not the call has been queued. This information will be useful in the default script to determine whether or not the main script failed while in or outside of queue.

(See The Connected Output Branch and The Queued Output Branch.)

The Start Step

The designer begins to build the sample script by choosing File > New from the CRA Editor menu bar. The CRA Editor places a Start step in the Design pane of the CRA Editor window.

The Start Step needs no configuration and has no customizer window.

The Accept Step

The designer continues to build the sample script by dragging an Accept step (from the Contact palette in the Palette pane) to the Design pane of the CRA Editor window, as shown in Figure 14-1 .

The script uses an Accept step to accept a contact, in this case a telephone call.

The Get Contact Info Step

The designer continues to build the sample script by adding a Get Contact Info step, which determines whether or not contact information already exists for this caller (based on a previous call).

The Get Contact Info step extracts information from the Session object and stores it in a Session variable named session.

The Get Session Info Step

The designer continues to build the sample script by adding a Get Session Info step, which evaluates the value of session, attempting to retrieve previous information collected from the caller, who may have been disconnected during a previous call or transferred back into the ICD queue by an agent. A caller can be transferred back into the queue if the script fails, in which case the Cisco CRA system falls back to the default script (see Using Default Scripts), or if an agent routes the call back to the route point.

Figure 14-3 shows the configured Context tab of the Get Session Info customizer window.


Figure 14-3   Get Session Info Customizer Window—Configured Context Tab



Note   This chapter describes the variables listed in the Context tab of the Get Session Info customizer window as they are populated by subsequent steps in the script. If this call is the first time the caller has called, the session variable is empty and the prompted variable is null.

The If Steps

The designer continues the sample script by adding a series of If steps to test to find out if a caller has already entered information.

If the caller has made a previous call within the configured session timeout, which is typically 30 minutes, and has already entered information, then the script can retrieve this information, saving the caller from the inconvenience of re-entering it. In this case, the script collects the account number of the caller and then attempts to retrieve the session that corresponded with that previous call.

If an agent transferred the call back into the queue managed by this script, then the session that stores all the collected information is still associated with the call. The series of If steps at the beginning of the script verifies this fact, after having retrieved this information from the session using the Get Session Info step.

Figure 14-4 shows the scripting under the first three If steps in the beginning of the sample ICD script.


Figure 14-4   If Steps


This section contains the following steps:

The First If Step

The designer adds the first If step to evaluate the expression, prompted==null; or, the value of the prompted variable (which was obtained from the session) is equal to null.

The script uses the Boolean prompted variable to determine whether or not the caller has heard the WelcomePrompt prompt (which plays later in the script).

If the expression is true, then the Set step under the True output branch has not executed yet, because when it does execute, it sets the value of prompted to false. (See Figure 14-4 .)


Note   A false value, when tested by a subsequent If step, tells the script that the caller has already entered an account number, and the script falls through to a Select Resource step to attempt to connect to an agent.

The Second If Step

The designer adds a second If step to evaluate the expression, failureCount==null; or, the value of the failureCount variable (which was obtained from the session) is equal to null.

The script uses the failureCount Integer variable to determine how many times the call has failed. If the expression is true, this tells the script that this is the first time for this call, and the Set step initializes the value of failureCount to 0. (See Figure 14-4 .) This information will be useful later in the script to determine priority of queueing and in the associated default script to determine if the call has failed more then once in the main script.

If this expression is false, then the value of failureCount is not changed.

The Third If Step

The designer adds a third If step to evaluate the expression, language!=null; or, the value of the language variable (which was obtained from the session) is not equal to null.

Later in the script, the script gives the caller the choice to set the value of the language variable to either American English or North American Spanish. If the expression is true, the language variable has been set (and therefore, this is not the first pass for this caller), and the Set Contact Info step under the True output branch updates the language context of the call to the language selected by the caller in a previous attempt.

If the expression is false, the language preference has not been determined yet, and its value remains unchanged.

The Fourth If Step

The designer adds a fourth If step to evaluate the expression, prompted==false; or, the value of the prompted variable is false.

As mentioned above (see The First If Step), if this expression is true, this is the first pass of the caller, and the script continues to the subsequent steps that prompt the caller to enter an account number, choose a language for the call, and record a name.

Figure 14-5 shows the scripting under the True output branch of this If step.


Figure 14-5   Steps Under the True Output Branch of the If Step


If this expression is false, the steps under the True output branch of this If step have already been executed on a previous attempt, and the script can send the caller directly to the Select Resource step to be connected to an agent or placed in queue.

The True output branch of the fourth If step contains the following steps:

The Play Prompt Step

The Play Prompt step under the True output branch of If step plays back the prompt WelcomePrompt, which welcomes the caller.

The Get Digit String Step

After this Play Prompt step executes, the Get Digit String step prompts the caller to enter an account number and then receives caller input.

The designer configures the Get Digit String customizer window as follows:

  • General tab
    • Contact—Triggering Contact

The contact that triggered the script remains the contact for this step.

  • Result Digit String—accountNum

The accountNum variable stores the digits entered by the caller (and is used by the subsequent Session steps).

  • Interruptible—Yes

External events can interrupt the execution of this step.

  • Prompt tab
    • Prompt—P[ICDEnterAccountNum]

This prompt asks the caller to enter an account number.

Barge In—Yes

The caller can enter an account number without first having to listen to the playback of the entire prompt.

  • Continue on Prompt Errors—Yes

In the event of a prompt error, the script continues to play back the next prompt in the sequence, or waits for caller input if the last prompt has been played.

  • Input tab
    • Input Length—10

The minimum number of digits required before the step returns automatically is 10. (This minimum number applies only to non-ASR channels; however, with ASR channels no more digits than specified will be returned.)

  • Terminating Key—#

The key the caller can use to indicate completion of input.

  • Cancel Key—*

The key the caller can use to start over. (The cancel key works only until the script reaches the maximum number of retries.)

  • Maximum Retries—3

The step makes 3 retries to receive valid input before executing the Unsuccessful output branch.

  • Initial Timeout (in sec)—5

The system waits 5 seconds for initial input from the caller before executing the Timeout output branch (after the maximum number of retries has been reached).

  • Interdigit Timeout (in sec)—3

The system waits 3 seconds for the caller to enter the next digit, after receiving initial input from the caller, before executing the Timeout output branch (after the maximum number of retries has been reached).

(Does not apply for ASR channels.)

  • Flush Input Buffer—No

The system saves previously entered input while the caller types ahead.

  • DTMF Buffer on Retry—Yes

The script clears the DTMF buffer, erasing previously-entered digits whenever the step makes a new attempt at collecting caller input.

  • Filter tab
    • All options are checked except "*" and "#"

The step treats the numbers from 0 to 9 as valid entries, and treats the keys "*" and "#" as invalid digits to collect.

The Get Digit String step has three output branches (see Figure 14-6 ):

  • Successful—If the Successful output branch executes, the script uses a series of Session steps as described in the next section.
  • Timeout—If the Timeout output branch executes, a Set step sets the accountNum to null, meaning that the account number was not received, and so the script treats the call as new.
  • Unsuccessful—If the Unsuccessful output branch executes, a Set step sets the accountNum to null, meaning that the account number was not received, and so the script treats the call as new.

Figure 14-6   Get Digit String Step—Output Branches


The Session Steps

This section describes the session management tasks accomplished by the scripting under the Successful output branch of the Get Digit String step.

The script determines whether or not the caller has made a recent call and previously entered all the necessary information, in which case a session may already exist. The script uses the account number to map the current call to any previous session information. The subsequent steps attempt to retrieve the previous session and if found, associate this new call contact with the original session.

Figure 14-7 shows the scripting under the Successful output branch of the Get Digit String step.


Figure 14-7   Get Digit String Step—Successful Output Branch


The Get Session step under the Annotate step attempts to get previous session information based on the accountNum variable, and to store it in the session2 variable. (This information is useful to the subsequent If step, which tests to determine whether or not session information existed for the previous call.)

Figure 14-8 shows the configured Get Session customizer window.


Figure 14-8   Configured Get Session Customizer Window


The If step under the Get Session step evaluates the expression session2!=null; or, the session2 variable is not null.

If this expression is true, session information does exist for the previous call, and the script uses the following steps under the True output branch of the If step (see Figure 14-8 ) in order to re-associate the current call to this older session:

  • Set step— Sets the value of the session variable to equal the session2 variable.

The session variable is used by subsequent steps in the script so that from this step on, the script uses only the previous session information.

  • Set Contact Info step—Associates the new call to the old session and deletes the temporary blank session that the script automatically associated with the new call.
  • Get Session Info step—Uses the session variable to retrieve values for the failureCount and language variables (used by subsequent If steps).
  • If step—Evaluates the expression failureCount==null; or, the value of the failureCount variable is equal to null.
    • If the True output branch executes and failureCount is empty, the call has not failed before this step, and a Set step initializes the value to 0.
    • If the False output branch executes and failureCount has already been assigned a value, then this value is left unchanged and is subsequently used to determine the queuing priority to assign to this call.

If the expression session2!=null is false, then session information no longer exists, and the Session Mapping step adds new mapping for this session.

The script then continues with the temporary session object that the script originally associated with this call, and then re-populates the information by collecting it from the caller. The script maps the new session using the account number so that the script can retrieve it later for another call from the same customer.

Figure 14-9 shows the configured Session Mapping customizer window.


Figure 14-9   Configured Session Mapping Customizer Window


After the steps under the Get Digit String step execute, a Set step sets the value of the prompted variable to true. (See Figure 14-10 .)


Figure 14-10   Set Step Scripting


Under the Set step, a Set Session Info step adds context information for this session, in order to record the account number, the current failure count and the fact that the caller has already been prompted.

The special context attributes "_ccdrVar1" and "__ccdrVar2" store the account number and the failure count to make these values available to historical reports for this particular call.

Figure 14-11 shows the configured Context tab of the Set Session Info customizer window.


Figure 14-11   Set Session Info Customizer Window—Configured Context Tab


The Set Session Info step adds the context information described in Table 14-2.

Table 14-2   Set Session Info Properties

Attribute Value Description

Prompted

prompted

Stores the value that indicates whether or not the caller has previously heard the welcoming prompt.

AccountNum

accountNum

Caller account number

__ccdrVar1

accountNum

Places the specified variable values in the Contact Call Detail Record (CCDR) for this call. (You can write a custom report to display these values.)

__ccdrVar2

failureCount

Places the specified variable values in the Contact Call Detail Record (CCDR) for this call. (You can write a custom report to display these values.)

FailureCount

failureCount

Stores the value that indicates how many times the call has failed, in order to set queueing priority (or in the default script, to decide if the script attempts to queue the caller again by re-routing the call back to the main script or announces that "we are experiencing problems" and requests the caller to call back later.

Choosing a Language

The next steps in the ICD sample script determine whether or not a language has been previously set, and if not, to give the caller the chance to choose a language.

Figure 14-12 shows the scripting under the If steps that allow the caller to choose between two languages for the context of the call.


Figure 14-12   Steps for Choosing a Language Under the If Step


The first If step evaluates the expression language==null; or, the value of the variable language is equal to null.

If this expression is true, no language has been set (and that this is the first pass through these steps). The Menu step then offers the caller a choice of two languages.

The designer configures the Menu step as follows:

  • General tab
    • Contact—Triggering Contact

The contact that triggered the script remains the contact for this step.

  • Options—en_US and es_US

These two branches under the Menu step provide the caller the choice of American English or North American Spanish.

  • Interruptible—Yes

External events can interrupt the execution of this step.

  • Prompt tab
    • Prompt—P[ICDSelectLanguage]

This system prompt asks the caller to choose a language.

  • Barge In—Yes

The caller can choose a language without first having to listen to the play back of the entire prompt.

  • Continue on Prompt Errors—Yes

In the event of a prompt error, the script continues to playback the next prompt in the sequence, or waits for caller input if the last prompt has been played.

  • Input tab
    • Timeout (in sec)—3

The script executes the Timeout output branch if no input is received within 3 seconds and the script has reached the maximum number of retries.

  • Maximum Retries—3

The step makes 3 attempts to receive valid input before executing the Unsuccessful output branch.

  • Flush Input Buffer—No

The system does not erase previously entered input before capturing new caller input.

The Menu step in this script has the following output branches (see Figure 14-12 ):

  • en_US—If the caller chooses this choice, a Set step sets the language variable to en_US, or American English.
  • es_US—If the caller chooses this choice, a Set step sets the language variable to es_US, or North American Spanish.
  • Timeout—If this output branch executes, the script falls through to the next If step in the script without setting a value for the language variable. The script then continues with the language the designer configured for this application.
  • Unsuccessful—If this output branch executes, the script falls through to the next If step in the script without setting a value for the language variable. The script then continues with the language the designer configured for this application.

After the Menu step executes, a Set Session Info step adds information to the session variable, as shown in Figure 14-11 .


Figure 14-13   Set Session Info Customizer Window-Context Tab


The designer configures the Attribute list in the Context tab of the Set Session Info customizer window as follows:

  • __ccdrVar3—language
  • Language—language

The next If step (see Figure 14-12 ) updates the language of the call based on caller preference. This step is useful in the event subsequent prompting or session information from a previous call changed the language.

This If step evaluates the expression language!=null; or, the value of the variable language is not equal to null.

If this expression is true, the caller has chosen a language. In this case, the Set Contact Info step then makes the information in the language variable available to the rest of the script.


Note   The script could also modify the value of the CSQ variable to account for the language chosen by the caller. For example, the system may contain one CSQ for English-speaking callers and another CSQ for Spanish speakers.

Recording a Name

Another If step evaluates the expression, name==null; or, the value of the name variable obtained from the session is equal to null.

If this expression is true, the caller has not previously recorded a name, and so the Recording step prompts the caller to do so. (See Figure 14-14 .)


Figure 14-14   Recording Step Scripting


If the Recording step is successful, the Set Session Info step adds this value of the name variable to the session so that it may be used again later; for example, to provide a more personal service.

Figure 14-15 shows the configured Context tab of the Set Session Info customizer window.


Figure 14-15   Configured Set Session Info Customizer Window—Context Tab


The Select Resource Step

The designer continues to build the sample script by adding a Select Resource step, which queues a call to a specific set of agents, based on the configuration in the CRA Administration web interface.

Figure 14-16 shows the configured Select Resource customizer window.


Figure 14-16   Configured Select Resource Customizer Window


The designer configures the Select Resource customizer window as follows:

  • Call Contact—Triggering Contact

The step connects the call that triggered the script to the available resource.

  • Resource ID—resourceID

The resourceID String variable stores the Resource ID of the chosen agent.

  • Contact Service Queue—CSQ

The CSQ String variable stores Contact Service Queue information from which to find a resource.

  • Connect—Yes

The call automatically connects the call to the available resource the instant the resource becomes available.


Note    If No is selected, the step chooses the resource, if available, but does not yet connect it. In this situation, the designer can add additional script steps to the Selected output branch before connecting the call to the resource. If the resource is unavailable, the step queues the call.

  • Timeout—12

The step waits 12 seconds before the script retrieves the contact back into the queue.


Note   For more information about the Select Resource step, refer to Chapter 13, "ICD Step Descriptions," in the Cisco Customer Response Applications Editor Step Reference Guide.

The Select Resource step has two output branches, Connected and Queued, which are described in the following sections.


Note   For more information on configuring agents, refer to the Cisco Customer Response Applications Administrator Guide.

The Connected Output Branch

When the script connects the call to an agent, the steps under the Connected output branch of the Select Resource step modify variable values and session information in order to help set priorities should the call later need to be queued.

Figure 14-17 shows the scripting under the Connected output branch of the Select Resource step.


Figure 14-17   Select Resource Step Scripting—Connected Output Branch


The following steps execute under the Connected output branch:

  • Set step—Sets the value of the queued variable to false.

This value indicates that the call has not been queued.

  • Set step—Sets the value of the variable failureCount to 0.

The failureCount variable stores the information on how many times the call has failed.

  • Set Session Info step—Updates the session variable to include the new value for the failureCount variable.

Figure 14-18 shows the configured Set Session Info customizer window.


Figure 14-18   Set Session Info Customizer Window—Context Tab


The Queued Output Branch

If the script has queued the call, a series of steps under the Queued output branch of the Select Resource step modify priority settings, depending on how many times the call has looped through these queue steps. (See Figure 14-19 .)


Figure 14-19   Select Resource Step Scripting—Queued Output Branch


The Set step under the Queued output branch sets the value of the queued variable to true.

After the Set step, a series of If steps and Set Priority steps modify call priority based on the following variables:

  • accountNum
    • If the expression accountNum!=null is true, the caller has already entered an account number, and so a Set Priority step increases the priority of the call by 1.

This allows the script to give more priority to a customer who has previously entered an account number.

    • If the expression accountNum!=null is false, the caller has not entered an account number, and so a Set Priority step decreases the priority of the call by 1.
  • failureCount
    • If the expression failureCount > 0 is true, this is means that the call has already failed, and so a Set Priority step increases the priority of the call by 1.

By increasing the priority of this caller, the script attempts to reduce the time in queue that the caller will have to spend the second time in queue.

  • If the expression failureCount > 0 is false, this is means that the call has not already failed, and the script does not modify the priority.

After these If steps, the designer establishes a loop by using a Label step named queueLoop, followed by a Play Prompt step, a Call Hold step, a Delay step, and finally a Goto step, which directs the script back to the queueLoop Label.

The Play Prompt step informs the caller that the call has been placed on hold, the Call Hold step places the call on hold, and the Delay step delays the call based on the length of time stored in the DelayWhileQueued variable (which in this script is 30 seconds).

The designer configures the Delay step to be interruptible in the event of an agent becoming available, at which point the script connects the call based on the information in the Select Resource step.

Using Default Scripts

A default script provides a final feedback to the contact regarding the system problem (and does not continue the service or restart the service).

The Application Manager can automatically invoke a default script in the following circumstances:

  • The Cisco CRA system cannot load the main script.
  • The main script terminates abnormally because of a system or script error.

All script variables from the main script can initialize the default script variables, if the designer defines them using the same name and type.

This section contains the following sections:

Default ICD Script Variables

Figure 14-20 shows the Variable pane of the Default ICD script.


Figure 14-20   Variable Pane of the Default ICD Script


Table 14-3 describes the variables used in the Default ICD script.

Table 14-3   Variable Descriptions for the Default ICD Script

Variable Name Variable Type Value Function Correspondence

CSQ

String

Stores Contact Service Queue information from which to find a resource.

(See The Select Resource Step.)

This variable is populated with the corresponding value of the variable with the same name from the main ICD script.

session

Session

null

Stores session information for the call.

(See The Get Contact Info Step.)

This variable is populated with the corresponding value of the variable with the same name from the main ICD script.

failureCount

Integer

0

Stores the number of times a call has failed.

(See The Session Steps)

This variable is populated with the corresponding value of the variable with the same name from the main ICD script.

accountNum

String

Stores the account number entered by the caller.

(See The Play Prompt Step.)

This variable is populated with the corresponding value of the variable with the same name from the main ICD script.

name

Document

null

Stores the spoken name of the caller.

(See Recording a Name)

This variable is populated with the corresponding value of the variable with the same name from the main ICD script.

active

Boolean

true

Stores information to determine whether or not the call is active.

(See Using Default Scripts.)

queued

Boolean

false

Stores the information used to determine whether or not the call has been queued.

(See The Connected Output Branch and The Queued Output Branch.)

This variable is populated with the corresponding value of the variable with the same name from the main ICD script.

extn

String

Stores the extension used by the Call Redirect step to attempt to re-queue the caller.

(See Using Default Scripts.)

Writing the Default Script

The following example describes a default script for the sample ICD script described above.

The default script performs the following function:

  • If it is the first time the call has failed, the script prompts the caller (with their name, if available), and asks the caller to stay on the line while the scripts makes another attempt to connect to an agent by transferring the caller back to the route point originally configured for the application.

In this case, the session remains associated with the new incoming call received by the main ICD script.

  • If this is the second time the call has failed, the script redirects the caller to an announcement indicating that the call cannot be connected, and then asks the caller to call back later.

Figure 14-21 shows the top level of the ICD default script as it appears in the Design pane.


Figure 14-21   ICD Default Script—Top Level


The Get Contact Info step determines whether or not the call is active (if the call is no longer active, then it means that the caller has hung up).

The If step underneath the Get Contact Info step evaluates this information, and if the call is not active, an End step underneath the True output branch of this If step ends the call. (See Figure 14-22 .)


Figure 14-22   ICD Default Script—Inactive Call


If the call is active, then the next If step determines whether or not the call is in queue. If the call is in queue, a Dequeue step dequeues the call, and a Call Unhold step takes the call off hold.


Note   It is important to remember that the script defines the queued variable with the same type and name as in the main ICD script, so that its value is populated with the last value of the corresponding variable in the ICD script.

If the call is active, then an Accept step accepts the call.

This is done to make sure that the call is accepted. If the ICD script had failed before the Accept step, the call would still be ringing and the script would not be able to provide any feedback to the caller as to the error that was encountered.

Figure 14-23 shows the scripting of these steps.


Figure 14-23   ICD Default Script—Queued Status


Because one of the main functions of this script is to determine the number of times the call has failed, the designer uses an Increment step to increase the value of the failureCount variable by 1. (See Figure 14-24 .)


Figure 14-24   ICD Default Script—Session and Name Status


The If step under the Increment step tests the value of the session variable. If the value of this variable is not null, there is session information associated with the call that needs to be updated by the Set Session Info step, which updates value of the failureCount variable.

The next If step tests for the value of the name variable. If the caller has recorded a name into this variable in the main ICD script, then a Play Prompt step plays this name, followed by a short silence.

The next steps determine which of two prompts the caller hears after the short silence, depending on whether the call has failed once or twice. (See Figure 14-25 ).


Figure 14-25   ICD Default Script—Prompts


If the value of failureCount is 1, then the Play Prompt plays a prompt explaining that there were problems in connecting, and asking the caller to stay on the line while another attempt is made to connect to an agent. The Call Redirect step then attempts to connect the caller to the extension the caller entered, using the extn variable. If this is successful, an End step ends the script.

If the value of failureCount is not 1, it must be 2, in which case the Set step sets the value of the extn variable to a user prompt that the script uses to announce that the call could not be connected and asking the caller to call back later. The Call Redirect step redirects the caller to this announcement, and an End step ends the script.