ATT DEFINITY Generic 3 Call Vectoring/Expert Agent Instructions Manual

							Call Promp ting
5-14Issue 4 September 1995
User-Entered FAC and Extension
The following vector connects a user directly to the Service Observing FAC  and 
extension based on digits collected by Call Prompting.
Figure 5-9. Service Observing Vector with User-Entered FAC 
and Extension
Preprogrammed FAC and Extension
The following vector connects a user to a preprogrammed FAC and extension 
using Call Prompting to allow the observer to select the extension they would like 
to o bserve. In this examp le, the observer will be Service Observing a VDN.
Figure 5-10. Service Observing Vector with Preprogrammed 
FAC and Extension
Dial-Ahead Digits
Dial-ahead digits provide the caller with a means of bypassing unwanted 
announcement p rompts on the way to a cquiring the information or servicing he or 
      1. wait-time 0 secs hearing ringback
      2. collect 5 digits after announcement 2300
         (‘‘Please enter your 5-digit security code.’’)
      3. goto step 5 if digits = 12345 (security code)
      4. disconnect after announcement 2000
      5. wait-time 0 seconds hearing ringback
6. collect 6 digits after announcement 3245 (“Please enter the 
number 11 for listen-only observing or the number 12 for 
listen/talk observing followed by the number of the extension you 
would like to observe”)
7. route-to digits with coverage n
8. stop
      1. wait-time 0 secs hearing ringback
      2. collect 5 digits after announcement 2300
         (‘‘Please enter your 5-digit security code.’’)
      3. goto step 5 if digits = 12345 (security code)
      4. disconnect after announcement 2000
      5. wait-time 0 seconds hearing ringback
6. collect 1 digits after announcement 2310 (“Enter 1 to observe 
sales, 2 to observe billing”)
7. route-to number 113001 with cov n if digit = 1 (11 = listen-only
observe, 3001 = “Sales” VDN)
8. route-to number 113002 with cov n if digit = 2 (11 = listen-only
observe, 3002 = “Billing” VDN)
9. goto step 6 if unconditionally 
						

							Dial-Ahead Digits
Issue 4 September 1995
5-15
she desires. These digits are available for use only by subsequent collect digits 
commands. The digits are never used by other vector commands that operate on 
d i gits (for example, 
route-to digits, goto...if digits, etc.) until they are collected. In 
a d dition, these d i gits are not displayed as part of the CALLR-INFO button 
operation (see the next section) until they are collecte d by a 
collect digits 
command.
The vectors on the next several pages illustrate a situation where a caller can 
enter d ial-ahead digits. Note that, in this case, we are requiring the caller to have 
a touch-tone telephone. Typically an alternative handling sequence should be 
programme d in c ase the caller d oes not dial a touch tone digit b efore the timeout 
period.
Figure 5-11. Dial-Ahead Digits
 
VDN (extension=1030   name=‘‘Coastal’’   vector=30)
Vector 30:  
      1. wait-time 0 seconds hearing ringback
      2. collect 1 digits after announcement 3000
         (‘‘Thank you for calling Coastal League Baseball Hotline.
         You must have a touch-tone telephone to use this service.
         If you wish to hear the scores of yesterday’s games,
         please press 1.  If you wish to hear today’s schedule
         of games, please press 2.’’)
      3. route-to number 1031 with cov y if digit = 1
      4. route to number 1032 with cov y if digit = 2
      5. announcement 301 (‘‘Entry not understood.  Please
         try again.’’)
      6. goto step 2 if unconditionally
VDN (extension=1031   name=‘‘Scores’’   vector=31)
Vector 31:
      1. collect 1 digits after announcement 4000
         (‘‘If you wish to hear scores of games in both divisions,
         please press 3.  If you wish to hear scores for Northern
         Division games only, please press 4.  If you wish to hear
         scores for Southern Division games only, please press 5.’’)
      2. goto step 7 if digits = 3
      3. goto step 7 if digits = 4
      4. goto step 9 if digits = 5
      5. announcement 301 (‘‘Entry not understood.  Please
         try again.’’)
      6. goto step 1 if unconditionally
      7. announcement 4002 (Northern Division scores)
      8. goto step 10 if digits = 4
      9. announcement 4003 (Southern Division scores)
     10. collect 1 digits after announcement 4004 
         (‘‘If you wish to return to the main menu,
         please press 9.  Otherwise, press 0.)
     11. route-to number 1030 with cov n if digit = 9
     12. goto step 15 if digit = 0
     13. announcement 301 (’’Entry not understood.  Please
         try again.‘‘)
     14. goto step 10 if unconditionally
     15. disconnect after announcement none  
						

							Call Promp ting
5-16Issue 4 September 1995
Figure 5-12. Dial-Ahead Digits 
Step 2 in the first vector gives the caller two options, each of which provides 
different information. The caller is prompted to enter either 1 or 2, depending on 
what information he or she wishes to hear. Once the caller enters a digit, the d igit 
is collected b y the 
collect d igits c ommand. Thereafter, an attempt is made b y the 
route-to number command to route the call to the appropriate vector (Step 3 or 
4). If the caller enters a d i git other than 
1 or 2, the appropriate announcement is 
provided (Step 5), and the digit entry cycle is repeated (Step 6).
Let’s suppose that the caller, when prompted, enters 
1. In such a case, the 
second vector is accessed.
In Ste p 1 of this vector, the caller is g iven three o ptions that supplement the 
original option provid e d in the first vector. The caller is prompted to enter either 
3, 4, or 5, depending on what information he or she wishes to hear. If the caller 
enters an incorrect digit, the customary digit correction routine is implemented 
(Steps 5 and 6). Once an appropriate d i git is entered, the call is routed—this time 
via use of a 
g oto ste p command (Step 2, 3, or 4)—to the appropriate 
announcement (Ste p 7 or Step 9).
In Step 10 of the second vector, the caller is once again prompted. Specifically, 
the caller is given the choice of returning to the main menu provided in the first 
VDN (extension=1032   name=Schedule   vector=32)
Vector 32
      1. collect 1 digits after announcement 5000
         (‘‘If you wish to hear today’s schedule of games in
         both divisions, please press 6.  If you wish to hear
         today’s schedule of games in the Northern Division
         only, please press 7.  If you wish to hear today’s
         schedule of games in the Southern Division only,
         please press 8.’’)
      2. goto step 7 if digits = 6
      3. goto step 7 if digits = 7
      4. goto step 9 if digits = 8
      5. announcement 301 (‘‘Entry not understood.  Please
         try again.’’)
      6. goto step 1 if unconditionally
      7. announcement 5002 (Northern Division schedule)
      8. goto step 10 if digits = 7
      9. announcement 5003 (Southern Division schedule)
     10. collect 1 digits after announcement 4004 
         (‘‘If you wish to return to the main menu,
         please press 9.  Otherwise, press 0.)
     11. route-to number 1030 with cov n if digit = 9
     12. goto step 15 if digits = 0
     13. announcement 301 (’’Entry not understood.  Please
         try again.‘‘)
     14. goto step 10 if unconditionally
     15. disconnect after announcement none 
						

							Dial-Ahead Digits
Issue 4 September 1995
5-17
vector or of terminating the phone call. If the caller selects the former option (b y 
entering 
9), the call is routed to the first vector, and the entire process is 
repeated. 
Note the third vector is similar in design to the second vector. The  major 
difference is the information provided and the requested d i git entries.
In our example, we have just seen that the caller has to go through at least two 
sets of o ptions to get the information he or she wants. Each option set is 
introduced by an announcement. However, b e cause of the “dial-ahead” digit 
capability, the caller can bypass the announcements if he or she so chooses. 
Thus, in our example, the c aller could enter 
1 and 5 within a matter of seconds to 
hear yesterday’s Southern Division scores.
The caller may enter digits while he or she is being q ueued for an announcement 
or while the announcement is playing. If digits are entered during an 
announcement, the announcement is disconnected or removed from the queue.
Collection of dial-ahead digits continues until one of the following occurs:
nVector processing stops or is terminated.
nSum of the digits c ollected for the current collect digits command plus the 
dial-ahead digits exceeds the switch storage limit of 24.   Any additional 
d i gits are discarded until storage is freed up by a subsequent 
collect 
digits
 command.
NOTE:
Any asterisk (*) and pound sign (#) digits dialed ahead count toward 
the 24 digit limit, as do any dial-ahead digits entered after the 
asterisk or pound sign digit. 
nThe TTR required by the user to collect d igits has b een disconnected. This 
happens whenever one of the following conditions is true:
— Successful or unsuccessful 
route-to number step is encountered 
during vector processing, 
except where the number routed to is a 
VDN extension.
— Successful or unsuccessful 
route-to d i gits step is encountered 
during vector processing, except where the number routed to is a 
VDN extension.
— Successful or unsuccessful 
adjunct routing step is encountered 
during vector processing.
— Successful or unsuccessful 
converse-on step is encountered 
during vector processing.
— Call Prompting timeout o ccurs, during which time the caller has not 
dialed any a d ditional digits, asterisks (*) or p ound signs (#).
— Vector processing stops or is terminated. 
						

							Call Promp ting
5-18Issue 4 September 1995
NOTE:
When the TTR is disconnected due to a route-to number, route-to 
digits, converse-on
 or an adjunct routing step, all dial-ahead digits 
will be discarded. This means that following a failed 
route-to, 
converse
 or adjunct routing step, a subsequent c ollect digits step 
always requires the user to enter digits.
The caller who enters dial-ahead digits no doubt knows which d i gits to enter 
ahead of time due to his or her familiarity with the service provided. Once the 
caller masters the digit sequence relevant to a particular service, the dial-ahead 
d i git cap a bility saves time and also eliminates much of the redundancy 
associated with automatic telephone servicing.
ASAI-Requested Digit Collection
The ASAI-requested d igit collection feature gives an adjunct the ability to request 
that a DTMF tone detector (TN744 or TN 2182) be connected for the purpose of 
detecting user-entered digits. The digits collected as a result of this feature are 
passed to ASAI monitoring and/or controlling adjuncts for action. The switch 
handles these digits like dial-ahead digits. This feature allows the caller to 
request Sequence Dialing after the call has been routed to the final destination 
and has resulted in an unanswered call (busy, no answer, etc).
Note that these d i gits are not necessarily collected while the call is in vector 
processing. They are sent to an ASAI adjunct, and/or they may b e used by Call 
Promp ting features.
ASAI Adjunct Routing and Call Promp ting features must be enabled on the 
switch for this feature to work. 
						

							ASAI-Provid e d Dial-Ahead Digits
Issue 4 September 1995
5-19
ASAI-Provided Dial-Ahead Digits
The ASAI-provided digits feature allows an adjunct to include digits in a Route 
Sel e c t
 c a pability. These d i gits are treated as d ial-ahead digits for the call. Dial-
ahead digits are stored in a dial-ahead digit buffer and can be collected (one at 
a time or in groups) using the “collect digits” ve ctor command(s). Although the 
adjunct may send more than 24 digits in a Route Select, only the first 24 (or 24-x) 
digits are retained as dial-ahead digits
*. An application can use this capability to 
specify the d igits that the switch should pass to the VRU as part of the 
c onverse-
on
 vector step.
* The maximum number of dial-ahead digits that can be stored in the buffer is d ependent 
on the number of digits already colle cted for the call by a previous “collect digits” vector 
c ommand. If ’x’ digits were collected by vector processing prior to executing an “a djunct 
routing ” vector c ommand , the ’x’ digits collected reduces the maximum number of digits 
that can be stored as dial-ahead digits as a result of a Route Sele ct. The rest is b e 
discarded. 
						

							Issue  4 September 19956-1 
6
Advanced Vector Routing
Introduction
Advanced Vector Routing  adds significantly to the conditional routing 
capabilities of Basic Call Vectoring. Specifically, it adds the following conditions 
for routing calls.
nExpected Wait Time (expected-wait)
nRolling Average Speed of Answer (rolling-asa)
nVDN Calls (counted-calls)
Command Set
The following table illustrates the commands used in Advanced Vector Routing.
Table 6-1. Advanced Vector Routing Command Set
Command 
Category Action Taken Command
ROUTINGQueue the call to a backup ACD split.
check-backup 
split
BRANCHING/ 
PROGRAMMINGGo to a vector step.
Go to another vector.goto step
goto vector 
						

							Advanced Vector Routing
6-2Issue  4 September 1995 
Expected Wait Time (EWT)
EWT Routing allows you to make routing d ecisions based on the time that a caller 
can expect to wait in queue. This wait time can be predicted for a split or for a 
call. When predicted for a split, the wait time indicates the amount of time the 
caller can expect to wait if the call is queued to the specified split. When 
predicted for a call, the wait time indicates the time remaining that the caller can 
expect to wait in queue until the call is serviced from the queue. The exp ected 
wait time can also be passed to a VRU so that a caller can be notified of his or 
her exp ected time in queue. The 
exp ected-wait conditional can be used with 
either the 
goto or c heck-backup commands.
Call vectoring offers several conditionals that can be used to estimate the time a 
caller will be d elayed waiting in q ueue, for example, EWT, rolling ASA and Oldest 
Call Waiting (OCW). EWT is  the  most accurate of these conditionals. It takes into 
account more real-time and historical information than the other predictors. For 
example, priority level, position in queue, number of working agents, etc.
EWT is very responsive to changing call center conditions. For example, it 
adjusts instantly to any staffing changes in the sp lit; if an agent moves into or out 
of auxiliary work mode, the wait time predictions adjust immediately.
EWT does not include the time in a call vector before the call enters a queue. It 
also does not include the time the call rings at a voice terminal after it is removed 
from the q ueue.
See When to Use Wait Time Predictions later in this chapter for a description of 
when the predictions are most accurate and the circumstances that will limit their 
accuracy.
EWT for a Split
The EWT for a split is the time that a new call would be expected to remain in 
queue if it were q ueued to the split at the sp ecified priority level. It is generally 
used to determine if a call should be queued to the split.
For exam ple, the following vector uses EWT for a sp lit to determine if a call 
should be queued to that split.
Figure 6-1. EWT for a Split
If there are agents available, EWT is zero.
1. goto step 3 if expected-wait for split 1 pri l < 600
2. busy
3. queue-to main split 1 pri l
4. announcement 3001
5. wait-time 998 secs hearing music 
						

							Expected Wait Time (EWT)
Issue  4 September 1995
6-3
EWT is infinite if:
nThere are no lo g ged-in agents
nAll logged-in agents are in AUX work mo de
nThe split queue is full
nThere is no split queue and all agents are busy
nThe split queue is locked
EWT for a Call
EWT for a call is the remaining time a caller can exp ect to wait before his or her 
call is serviced from queue. If the call is queued to multiple splits, the remaining 
queue time for each of the splits is calculated, and the shortest of these is taken 
as the call’s EWT.
For a call to have an expected wait time it must be queued to at least one sp lit. If 
it is not queued, or if it is queued to splits that are not staffe d, the EWT value is 
infinite.
The following example uses EWT for a call to determine the treatment the call will 
receive.
Figure 6-2. EWT for a Call
Passing EWT to a VRU
As state d, the Expected Wait Time for a call can be passed to a VRU so that a 
caller can be notified of his or her expected time in queue. EWT is  passed to  the 
VRU with the 
converse-on command as “wait” data. The value outpulsed to the 
VRU is the expected wait time of the call in seconds. The VRU can then convert 
the seconds to a spoken message probably rounding up to minutes or 
converting to minutes and seconds. The expected wait is calculated after the 
VRU port answers the call, so queuing to a converse split does not adversely 
impact the EW T value passed to the VRU.
The wait time p ass e d to the VRU is the most accurate prediction possible. On the 
average 50% of the time the actual wait time will b e shorter  and 50% of the time it 
will be longer. It is recommended that VRU applications make an u pwards 
adjustment of the p rediction so that the majority of callers receive a predicted 
wait time that is equal to or greater than their actual wait time.
1. queue-to main split 1 pri m
2. check-backup split 2 pri m if expected-wait < 30
3. goto step 5 if expected-wait for call < 9999
4. busy
5. announcement 3001
6. wait-time 998 secs hearing music 
						

							Advanced Vector Routing
6-4Issue  4 September 1995 
The VRU can also announce exp ected wait time to a caller periodically 
throughout the time that a call is in queue. In this way, the caller can observe his 
or her p rogress up the queue. However, this a pproach should be used with 
caution. Circumstances such as a reduction in the number of agents or a sudden 
influx of higher priority calls could cause the caller’s expected wait time to 
increase from one announcement to the next.
If the call is not queued or if it is queued only to splits that are unstaffed or splits 
where all a gents are in AUX work mode, the end-of-string character “#” is the 
only data item outpulsed.
The EWT Algorithm
EWT is calculated using an algorithm that is based on the number of calls in a 
queue at a particular priority level and the rate of service of  calls from the q ueue 
at that p riority level. It adjusts for many other factors such as multiple split 
queuing, call handling times, and the impact of direct agent calls on the wait time 
of other calls to the split. The algorithm adjusts EWT immediately for changes in 
staffing, such as agents logging in or taking breaks in AUX work mode.
Since changes occur constantly in a call center, and since EWT cannot predict 
the future, the accuracy of the EWT predictions will be in proportion to the rate at 
which call s are serviced from the queue and the level of sta bility achieved in the 
call center between the time that the prediction is made and the time that the call 
is serviced from queue.
When to Use Wait Time Predictions
Wait time predictions are best suited for medium or high volume call scenarios. 
In general, the potential accuracy of a wait time predictor increases as the rate of 
removal from  queue increases. It is recommended that EWT be used when the 
rate of removal from queue at a given split priority level is at least one call every 
30 seconds.
Predictions can be made for a split with multiple priority levels in use as long as 
the majority of calls are d elivered to the lower priority levels. If the majority of c alls 
are queued at the higher priority levels, any predictions made for the lower 
priority levels may not be accurate.
The following list describes circumstances that will limit the accuracy of the wait 
time predictions.
nImmediately after a system restart or when a new split is administered.
The EWT algorithm uses a combination of historical and real-time 
information to make predictions. When  no  historical  information exists, 
such as when a new split is added or a reset system 3 or 4 is completed, 
there is the potential for inaccuracies.