ATT DEFINITY Generic 3 Call Vectoring/Expert Agent Instructions Manual

							Expected Wait Time (EWT)
Issue  4 September 1995
6-5
To prevent inaccurate predictions when there is no historical information, 
administer the “Expected Call Handling Time” field on the Hunt Group 
form. The value in this field is then used in place of the missing historical 
data.If the value of this field does not accurately reflect the call handling 
times of the sp lit, EWT predictions may be inaccurate until some call 
history is generated. The algorithm normally requires about 30 queued 
calls to be answered from a split priority level before it reaches its 
maximum accuracy.
You c a n change the value in the “Exp ected Call Handling Time” field by 
executing a change hunt group command. Changing the value will not 
disrupt EWT predictions by overwriting EWT history. The value is stored 
and used the next time a reset system 3 or 4 is executed.
nLow call volume applications.
Sp lit priority levels where the rate of removal from queue is very low can 
only be p redicted with limited accuracy.
nSites with frequent staffing changes.
Although EWT immediately adjusts for all types of staffing changes, since 
predictions may have already b een made for c alls waiting in queue, those 
past predictions will have b een based on staffing information which is now 
out of date. Therefore, scenarios where large staffing changes are 
continually ha p pening can only be predicted with limited accuracy.
nStaffe d agents who rarely answer calls to a split.
The EWT algorithm takes account of agents in multiple splits in its 
calculation. However, suppose there are many a gents who are assigned 
to a sp lit b ut spend most of their time answering calls in their other splits. If 
a large number of these agents are moved to or from the split, then EWT 
for this split may b e temp orarily inaccurate until it adjusts to those 
changes.
nApplications with widely varying call handling times.
If the majority of calls to a split are handled within a narrow range of times 
the accuracy of any predictor will be much greater than that for a sp lit 
where call handling times are widely different.
Examples
Example 1 — EWT Routing and Passing Wait
to a VRU
The following vector illustrates routing based on the wait time of a split, as well as 
passing wait data to the VRU. Wait time is only given to the caller if the caller is 
expected to wait a total of more than 60 seconds in queue. Callers who would 
wait more than 10 minutes are told to call back later. 
						

							Advanced Vector Routing
6-6Issue  4 September 1995 
Figure 6-3. EWT Routing and Passing VRU Wait
Calls with more than 10 minutes to wait fail step 1 and are disconnected after an 
announcement asking them to call back later. If the expected wait time is less 
than 10 minutes ste p one routes the call to step 3 where it is q ueued to split 32 
and waits 20 seconds hearing ringback. After 20 seconds if the exp ected wait 
time for the call is less than 40 seconds, step 5 routes the call to an 
announcement followed b y a wait with music. If the exp ected wait time for the c all 
is equal to or greater than 40 seconds, step 6 informs the caller of the amount of 
time he or she can expect to wait b efore the call is answered.
Example 2 — Notifying Callers of Wait Time
Without a VRU
You c a n still use EWT to notify calls of their expected wait time even without a 
VRU. This can  be done using the DEFI NI TY s yst em  record ed announcements 
and by associating each recorded announcement with a time band.
       1. goto step 3 if expected-wait for split 32 pri l < 600
2. disconnect after announcement 13976
3. queue-to main split 32 pri l
4. wait-time 20 secs hearing ringback
5. goto step 7 if expected-wait for call < 40
6. converse-on split 80 pri l passing wait and none
7. announcement 11000
8. wait-time 60 secs hearing music
9. goto step 7 if unconditionally 
						

							Expected Wait Time (EWT)
Issue  4 September 1995
6-7
Figure 6-4. Notifying Callers of Wait-Time Without a VRU
In Ste p 1 the call is queued to split 3 at high priority. If the calls fails to get a 
queue slot in split 3, if split 3 has no working agents, or if the wait time in split 3 at 
high p riority exceeds 10 minutes, step 2 fails and the caller receives busy tone. If 
step 2 succeeds, the caller hears ringback and an announcement and is then 
sent to vector 202. Steps  1  through 4 of vector 202 determine which of five time 
bands the caller’s remaining queuing time is estimated to be within. One of five 
recorded announcements is then p layed to the caller to inform him or her of the 
expected wait time in queue.
Notice that the EWT thresholds are set lower than the times quoted in the 
recorded announcements. Callers may become upset if their actual wait time 
exceeds the time stated in the announcement. Therefore, you may want to 
program your ve ctors such that few callers ever experience wait times that 
exceed the wait time of the announcement.
VECTOR 101
1. queue-to main split 3 pri h
2. goto step 4 if expected-wait for call  280
2. goto step 11 if expected-wait for call > 165
3. goto step 9 if expected-wait for call > 110
4. goto step 7 if expected-wait for call > 55
5. announcement 3501 (“Thank you for waiting.
Your call should be answered within the next minute”)
6. goto step 14 if unconditionally
7. announcement 3502 (“Thank you for waiting.
Your call should be answered within approximately one to 
two minutes”)
8. goto step 14 if unconditionally
9. announcement 3503 (“Thank you for waiting.
Your call should be answered within approximately two to 
three minutes”)
10. goto step 14 if unconditionally
11. announcement 3504 (“Thank you for waiting.
Your call should be answered within approximately three to 
five minutes”)
12. goto step 14 if unconditionally
13. announcement 3505 (“We apologize for the delay. Due to heavy
call volume, you may have to wait longer than five minutes
to speak to a representative. If possible, we suggest that you
call between the hours of 8am and 10am for the fastest service”)
14. wait-time 120 secs hearing music
15. goto step 1 if unconditionally 
						

							Advanced Vector Routing
6-8Issue  4 September 1995 
Notice also that vector 202 can be used for any application requiring that the 
caller be notified of their remaining time in queue.
Example 3 — Using EWT to Route to the 
Best Split
With EWT, you may wish to change your normal queuing strategy of q ueuing 
calls to multiple sp lits in order to insure the call is answered in the shortest 
possible time. This strategy uses a dditional system resources and can make it 
more difficult to read and analyze split reports.
Instead, you may wish to use EWT to determine up-front, which split is b est for 
each call and avoid multiple split queuing.
In this examp le, there are two s plits, a main split (1) and a backup split (2). Either 
split can service a particular type of call. It is preferable that an agent from the 
main sp lit service the call. However, a 30-second maximum wait time is also 
desirable. The strategy in this vector is to use the backup split only if the backup 
split can answer the call within 30 seconds and the main split cannot.
Figure 6-5. EWT Routing—Routing to the Best Split
Step 1 branches to Step 5 to queue to the main split if the main sp lit can answer 
the call within 30 seconds. If the main split cannot answer the call within 30 
seconds, Step 2 checks to see if the backup split can answer the call within 30 
seconds. If it cannot, the call branches to step 5 and is queued to the main sp lit. 
If it can, the call is queued to the backup sp lit in Step 3. At this point, the call is 
queued either to the main or the backup split but not to both.
Steps 6 through 10 provide audible feedbac k to the caller while the call is in 
queue. Note that in Step 8, which is executed every two minutes, a VRU is used 
to provide the caller with his or her remaining wait time in q ueue.
       1. goto step 5 if expected-wait for split 1 pri m  30
3. check-backup split 2 pri m if unconditionally
4. goto step 6 if unconditionally
5. queue-to main split 1 pri m
6. wait-time 12 secs hearing ringback
7. announcement 3501
8. converse-on split 18 pri m passing wait and none
9. wait-time 120 secs hearing music
10. goto step 8 if unconditionally 
						

							Expected Wait Time (EWT)
Issue  4 September 1995
6-9
Factors that Effect the Value of EWT
Factors that Cause EWT for a Split Priority Level
to Increase
Most common:
nNumber of calls in queue increases
nAgents logout
nAgents go on break (AUX work mo de)
nAgents are moved to another split
nAgents with multiple splits answer an increasing number of calls in other 
splits
Other possibilities:
nAverage talk time increases
nNumber of calls at higher priority increases
nNumber of DAC calls increases
nNumber of RONA calls increases
nNumber of abandoned calls decreases
nNumber of calls queued in this sp lit but answered in another decreases
Factors that Cause EWT for a Split Priority Level
to Decrease
Most common:
nNumber of calls in queue d e creases
nAgents login (and start answering calls)
nAgents return from break (leave AUX work mode)
nAgents are moved from another sp lit
nAgents with multiple splits answer fewer calls in other splits
Other possibilities:
nAverage talk time decreases
nNumber of calls at higher priority d ecreases
nNumber of DAC calls decreases
nNumber of RONA calls decreases
nNumber of abandoned calls increases
nNumber of calls queued in this sp lit but answered in another increases 
						

							Advanced Vector Routing
6-10Issue  4 September 1995 
Rolling Average Speed of Answer 
(ASA) 
Rolling ASA Routing allows you to make routing decisions based on the current 
average time that it takes for a call to be answered in a split or VDN. In this way, 
a vector can route a call to the VDN or sp lit where it is likely to be answered most 
quickly. 
The Average Speed of Answer used for vector routing is called “rolling” ASA to 
differentiate it from the “interval” ASA that is recorded in BCMS and CMS reports. 
Rolling ASA is a running calculation that does not take into account the 15-
minute, half-hour, or hour BCMS/CMS reporting intervals. It does not reflect 
interval boundaries. On the other hand, the “interval” ASA used for BCMS/CMS 
reporting is calculated on reporting interval boundaries and clears to zero at the 
start of each reporting interval.
The Rolling Average Speed of Answer for a split or VDN is calculated based on 
the speed of answer for all calls recorded since system start-up. When rolling 
ASA is calculated, each call is given a weighted value that is g reater than the call 
that preceded it. In this way the most recent calls contribute the most to the 
average. Approximately 95% of the value of rolling ASA is obtained from the last 
ten calls.
The rolling ASA for a split or VDN is recalculated every time a call is answered so 
that it always reflects the most recently available data. Calls that are not 
answered, for example calls that receive a forced busy, are not considered for 
the rolling ASA calculation.
The rolling ASA is calculated for an entire split or VDN. The calculation d oes not 
consider the priority levels of answered calls.
The following sections explain what is included in the rolling ASA calculation for a 
split or VDN.
Rolling ASA Split Calculation
The rolling ASA for a split is the average time it takes for a call to be answered 
from the time the call attempts termination to the split until it is answered in that 
split. Rolling ASA includes the time the call is waiting in queue and the time it is 
ringing at a voice terminal.
If the call is answered in another split or the call is abandoned by the caller 
before it is answered, rolling ASA is not recorded for the call. If a call flows into a 
split from another split, the time queued and ring time for the previous split are 
not included. If a call is queued in multiple splits, only the rolling ASA for the sp lit 
in which the call is answered is impacted. 
						

							Rolling Average Speed of Answer (ASA)
Issue  4 September 1995
6-11
Rolling ASA VDN Calculation
The rolling ASA for a VDN is the average time it takes for a call to be answered 
from the time it starts processing within the specified VDN  until  it  is  answered. It 
includes any time sp ent in vector processing including time sp ent in 
announcements administered as vector steps. If the call is answered by an 
agent, it includes the time the call is waiting in queue and the time it is ringing at 
the agent’s voice terminal.
The rolling ASA for a VDN only includes data from calls answered in that VDN. If 
a c all flows b etween VDNs, only the time s pent within the answering VDN is used 
in the calculation. For examp le, if a call is placed to VDN1 and after ten seconds 
routes to VDN2 and is then answered in VDN2 after five seconds, the ASA for the 
call is recorded in VDN2 as five seconds. Nothing is recorded for VDN1 since the 
call was not answered there.
The VDN for a vector step can be specified in three ways: a VDN numb er, the 
value “latest,” or the value “active.” The “latest” VDN is the VDN that is currently 
processing the call. The value is not affecte d b y VDN override. The “active” VDN 
is the VDN of record. That is, it is the called VDN as modified by override rules. 
For exam ple, if a call routes from a VDN with override set to 
yes then the new 
VDN is the active VDN. If a c all routes from a VDN with override set to 
no then the 
previous VDN is the active VDN.
Rolling ASA Considerations
Because of its greater accuracy and greater flexibility, EWT is recommended 
over rolling ASA as a  predictor of split/skill waiting time. However, rolling ASA is 
provided for those who may have a special requirement or wish to use the more 
traditional ASA measurement.
Normally rolling ASA conditionals should not be used to prevent calls queuing to 
the main split/skill or being answered in the principal VDN. Rather, rolling ASA 
should be used to see whether vector processing should attempt to queue the 
call to additional splits/skills if the main split/skill does not currently meet the 
targeted threshold. If no calls are b eing answered in the main split/skill or VDN, 
the value of rolling ASA will not change. This c ould result in all future calls being 
locked out of the main split/skill or VDN unless there are other call vectors in the 
system directing calls to them.
If you wish to implement a call flow that decides whether or not to queue a call to 
a main split/skill, use the EWT feature.
Example
The following example combines VDN and split ASA routing. 
						

							Advanced Vector Routing
6-12Issue  4 September 1995 
Figure 6-6. Rolling ASA Routing
Step 1 queues the call to the main sp lit. If the main split is currently answering 
calls within the target time of 30 seconds Step 2 bypasses all of the backup splits 
and goes directly to the announcement in Step 6. The assumption is that the call 
will be handled by split 10 within the time constraints. However, if the call is not 
answered by the time vector processing reaches Step 8, the backup sp lits are 
checked at that time. 
If the rolling ASA for the main split is greater than 30 seconds, Steps 3, 4, and 5 
check backup splits. The call is queued to any of these splits that have a rolling 
ASA of 30 seconds or less. If the call still is not answered by the time vector 
processing reaches Step 8, then the backup splits are checked again.
VDN Calls 
VDN Calls routing allows you to make routing decisions based on the number of 
incoming trunk calls that are currently active in a VDN. With  the  VDN Calls 
conditional, a vector can be used to limit the number of simultaneous calls made 
to a particular VDN. For examp le, if a service agency is contracted to handle 100 
simultaneous calls for a client, calls in excess of that number can be routed to a 
busy ste p.
When Advanced Vector Routing  is  enabled,  a count of active incoming trunk 
calls is kept for each VDN. The VDN counter is incremented each time an 
incoming call is placed to the VDN. It is decremented each time an incoming call 
is released. A call is considered active in a VDN from the time the call routes to 
the VDN  until  all  parties on the call have b een dropped and the call is released. 
NOTE:
The call is counted for the originally called VDN only. When a call is routed 
to another VDN, the call counter for the subsequent VDN  is  not 
incremented. And, the call counter for the original VDN is not decremented.
       1. queue-to main split 10 pri h
       2. goto step 6 if rolling-asa for split 10 
						

							VDN Calls
Issue  4 September 1995
6-13
As with other  Advanced Vector Routing conditionals, the VDN for a goto step can 
be specified in three ways: a VDN numb er, the value “latest,” or the value 
“active.” 
The following section d escribes which calls are included in the VDN Calls counts 
and which are not.
Counted Calls
The VDN call count includes:
nIncoming trunk calls that route directly to the VDN.
nIn coming trunk night service calls where the VDN is the night service 
destination.
nCalls that c over or forward to the VDN if it is the first VDN routed to and the 
call is an incoming trunk call.
nAlready counted calls that are conferenced with counted or not counted 
calls from the same VDN.
The VDN call count does not include:
nInternal calls to the VDN.
nCalls that are transferred to the VDN.
nCalls redirected to their VDN return destination.
nConferenced calls previously counted on different VDNs.
Example
The following example shows how the counted-calls conditional can be used to 
route calls.
Figure 6-7. VDN Calls Routing
If more than 100 calls are active in VDN 1234, the caller will hear busy tone and 
vector processing is terminate d. If 100 or fewer calls are active, the call queues 
to split 60.
       1. goto step 3 if counted-calls to vdn 1234 
						

							Issue  4 September 19957-1 
7
ANI and II-Digits Routing
Introduction
ANI and ii-d igits allow you to make vector routing decisions based on the caller 
identity and the type of the originating line.
Command Set
ANI and ii-d igits are both used for conditional branching with the goto step. The 
following table illustrates the commands used in ANI/II-Digits Routing .
ANI Routing
ANI routing allows you to make routing d e cisions based on incoming or internal 
caller identity. In this way, calls from a particular customer can receive unique 
routing, local calls can b e routed differently from long distance calls, or calls from 
different geographical areas can receive different routing. See ANI Routing 
Examp le later in this section for more information. ANI also can be compared 
against entries in a Vector Routing Table. See Vector Routing Tables with ANI 
later in this section for more information.
Table 7-1. ANI/II-Digits Routing Command Set
Command 
Category Action Taken Command
BRANCHING/ 
PROGRAMMINGGo to a vector step.
Go to another vector.
goto step
goto vector