ATT DEFINITY Generic 3 Call Vectoring/Expert Agent Instructions Manual

							Enabling the Vector Disconnect Timer
Issue  4 Septemb er 1995
B-7
Enabling the Vector Disconnect Timer
Call Vectoring makes available a Vector Disconnect Timer, which can be set for 
any amount of time between 1 and 240 minutes inclusive.  The timer is enabled 
by selecting the timer field in the Feature-Related System-Parameters form. The 
timer is started when vector processing is started. Once the timer runs out, the 
call is dropped. The timer is canceled when vector processing terminates.
Enabling the timer allows queued calls that have not been answered within a 
determined amount of time to be dropped. For more information, refer to 
DEFI NI TY Com munications System Generic 3 Implementation, 555-230-653.
Upgrading to a Call Vectoring 
Environment
If you are already equipped with ACD and want to use Call Vectoring, the ACD 
environment must  be upgraded to a Call Vectoring environment. This involves 
installing VDNs, vectors and hunt groups for the desired Call Vectoring 
feature(s).
The set of guidelines that follows is intend e d to serve as a general procedure for 
upgrading to a Call Vectoring environment.  For c omplete details of this  process, 
refer to 
DEFINITY Communications System Generic 3 Imp lementation, 555-230-
655.
1. Verify the vector options on the Customer O ption Form.
NOTE:
This is always done by AT&T personnel.
2. Add the VDNs.
3. Evaluate the number of queue slots assigned to each split.  Usually, you 
want to assign enough queue slots to allow all calls processed by Call 
Vectoring to be queued.  (See the considerations for Basic Call Vectoring 
in Appendix C for more d etails.)
4. Change hunt-groups to be vector-controlled.
5. Administer the vectors and at least one test hunt group.
6. Test all of the vectors to be installed.
7. Change the trunk g roups, night destinations, etc., to use the VDNs.
Changing and Testing the Vector
Vectors currently being used to process calls should not be changed because 
changes would have an immediate and  uncertain effect on the treatment that the 
calls are receiving.  Instead, a new vector should always be written. 
						

							Call Vectoring Management
B-8Issue  4 September 1995 
In testing the vector, you should not consider the entire vector at once.  Rather, 
you should first figuratively divide the vector into portions, then test each of these 
portions until the entire vector is tested.
After the new vector is thoroughly tested, the vector should be brought into 
service by changing the VDN to point to the new vector.
The set of following g uidelines is intend e d to serve as a general procedure for 
changing and testing vectors. For complete details of this process, refer to 
DEFI NI TY Com munications System Generic 3 Implementation, 555-230-655.
1. Check that a current version of the translation data is available.
2. Create a new VDN that points to the new vector.  This VDN, which is 
temp orary, is necessary to test the new vector.
3. Administer the new vector.  Vector commands should be added and 
tested, one command at a time, starting with the first command. Be sure 
that each line is correct before proceeding to the next one.
4. Test the new vector with the new VDN.  This ensures the new vector will 
function correctly when the vector is installed.
5. Install the new vector by changing the old VDN’s vector assignment so 
that the VDNs now point to the new vector.  Calls that are already being 
processed by the old vector will continue to be handled by that vector until 
the vector terminates vector processing.
6. Once all the calls are handled, remove the old vector and the VDN that 
was use d for testing. 
						

							Issue  4 Septemb er 1995C-1 
C
Considerations for the Call Vectoring 
Features
Introduction
This a p pendix contains several lists of considerations you should bear in mind 
when using the Call Vectoring features.  These considerations are intended to 
help you g et the highest degree of productivity from Call Vectoring.
NOTE:
If EAS is optioned, ‘‘skill’’ replaces ‘‘split.’’
Basic Call Vectoring Considerations
The following are considerations you should keep in mind when working with 
Basic Call Vectoring:
nMake the sp lit queues large enough so that all incoming calls queue and 
are not dropped. If a queue is too small, a 
q ueue-to main split or a check-
backup split
 command might fail to queue a call due to a lack of available 
queue slots. Accordingly, it is also always a good practice to include in 
the vector a step that checks a split’s queue before queuing o ccurs and a 
corresponding step that provides alternate treatment if the queue is full.  
To check the queue size, you can use a 
g oto command (for example, goto 
Step 5 if calls- queued in split 20 pri l > 30
). The alternate treatment, which, 
if need e d, is usually accessed b y the 
goto command that checks the 
queue size, can queue the call to a backup split, make an unconditional 
Look-Ahead Interflow attempt, provide a busy signal, etc.
nA default treatment or a route-to destination step should be supplied after 
a 
route-to command in case the first destination is unavailable. 
						

							Considerations for the Call Vectoring Features
C-2Issue  4 Septemb er 1995 
nCalls should not b e queued to an unstaffed split (unless this is intended by 
the customer) without some alternate treatment.
nInterflow calls should not b e p ermitted to interflow back and forth between 
a remote switch vector and a local switch.  This process could cause a 
single call to use up all available trunks.
nAfter an announcement is provided, the audible feedback (such as music) 
should be re-attached.
nFor ease-of-use p urp oses, each specific vector function or operation 
should be included in a separate vector and linked via one or more 
goto 
vector
 commands.
nIn creating a vector, commands can b e chosen and arranged in a manner 
such that answer supervision is delayed as long as possible.  This should 
be done to keep down the service cost.
nThe caller should always be provided with initial feedback (usually 
ringback).
nDirect agent  calls merit special attention b e cause such calls can affect 
call queuing.  Although direct agent calls take up a queue slot, they are 
not always reported as using such a slot on CMS/BCMS reports 
(discussed in Ap pendix F).  For example, a direct agent call is never 
counted toward the total of queued calls within a split (that is, the 
calls-
queue d
 test condition has no effect on this type of call).
nIf it is necessary for a caller to hear an entire CONVERSANT sc ript before 
talking to an agent, the caller should not be queued until after the 
converse-on step is executed.
nAudible feedback should be provided prior to a c onverse-on step 
whenever a large numb er of digits are to be outpulsed to the VRU.
Call Prompting Considerations
The following list includes considerations you should keep in mind when working 
with Call Promp ting:
nTo enter the d i gits requested via the collect digits command, outside 
callers must have a touch-tone telephone.  For such callers using rotary 
dialing, a 10 second inter-digit timeout takes effect, and the 
collect digits 
command is omitted. As a precaution, a default treatment (for example, 
route-to attendant command, q ueue-to main split command) should 
always be provided in the vector sc ript unless the script is created 
exclusively for users of touch-tone telephones.
nIf a caller does not enter the full numb er of digits sp ecified in the collect 
digits
 step, a 10~second timeout occurs. Thereafter, vector processing 
continues with subsequent vector steps, and an attempt is made to 
process the call using the digits that have been collected. If the digits 
entered do not represent a valid destination, and if Automated Attendant  
						

							Look-Ahead Interflow Considerations
Issue  4 September 1995
C-3
is being implemented via a route-to d i gits command, the route-to d igits 
command fails, and vector processing continues at the next ste p, which 
should be a default treatment.
nIt may be prudent to take steps in case a route-to attendant command 
fails, such as providing a disconnect announcement.
nFrom time to time, all of the system’s touch-tone receivers might b e in use.  
As a result, you should avoid starting your main vector with a 
collect d igits 
command, since the caller on a DID or tie trunk in this case receives no 
audible feedback if he or she has to wait for a receiver to become 
available.  Accordingly, it is a good practice to include some treatment (for 
example, a 
wait-time 0 seconds hearing ringbac k step) before the initial 
collect digits step.
Look-Ahead Interflow Considerations
The following are considerations you should keep in mind when working with 
Look-Ahead Interflow:
nNever interflow to a remote vector that in turn might interflow back to the 
same local vector.  This could cause a single call to use up 
all available 
trunks.
nThe oldest-call-wait test condition should not be used in LAI vectors.  
OCW corresponds to the very next call to be answered and, as such, this 
test c ondition gives no information on the current state of c all overload (for 
example, if OCW =  30 seconds, all we know from this is that the q ueue 
was overloaded 30 seconds ago). In place of
 oldest-call-wait, use the 
EWT conditional. See Expected Wait Time (EWT) on page 6-2.
nIf an LAI call attempt is accepted by a step that contains a q ueue-to main, 
check-backup split,
 or route-to command, there is a small but finite 
interval during which the call could be answered by an agent at the 
sending switch before notification of ‘‘acceptance’’ is received by the 
sending switch.  In this case, the caller would be connected to the agent 
at the sending switch, while the agent at the receiving switch might 
receive a ‘‘phantom’’ call.  For this reason, you should consider using a 
short 
wait-time or announcement step at the receiving switch to allow the 
call to be accepted and taken out of q ueue at the sending switch. If call 
acceptance is to be based on available agents, use of a
 wait-time > 0 
seconds or an 
announcement is not recommended. A wait-time with 0 
seconds of silence might be useful in this case.
nWhen an LAI call attempt is made, the TTR (if attached) is disconnected, 
and any dial-ahead digits are discarded.  This implies that a subsequent 
collect digits command would require that the TTR be connected.
nBe sure the feedback provided by the receiving switch after a successful 
LAI attempt is consistent with what the caller has already received. 
						

							Considerations for the Call Vectoring Features
C-4Issue  4 Septemb er 1995 
nIt is perfectly acceptable for a vector to route a call over an ISDN-PRI 
facility to a destination that is not a VDN. In such a case, the sending 
switch treats the call like a Look-Ahead Interflow call. Generic ISDN 
processing at the receiving switch causes the call to be accepted.  The 
DNIS name is i gnored.
nIf a Look-Ahead Interflow call terminates to a VDN on a receiving switch 
where the Look-Ahead Interflow option is 
not enabled, intelligent interflow 
still results.  However, any relevant DNIS information is ignored, and 
intelligent interflow to far-end switches is not possible.
nThe LAI timeout in the sending switch occurs after two minutes.
nT-1 equipment might modify the ISDN D-channel that is used for Look-
Ahead Interflow. If multiplexors are introduced into the ISDN-PRI circuit, 
bit compression and echo cancellation must be turned off for the D-
channel.
Adjunct Routing Considerations
The following are considerations you should keep in mind when working with 
Adjunct Routing:
nDepending upon your application, you may want to include a second 
adjunct routing step in your ve ctor in case the first such step fails.
nIf you include an announcement step imme diately after an adjunct routing 
step, be sure the announcement does not contain any information 
essential to the c aller (such as further instructions) since the step following 
the 
adjunct routin g step immediately terminates the moment the switch 
receives a destination from the ASAI adjunct.
nIf you include a wait-time step after an adjunct routing step, it is a good 
idea to specify either 
ringback or music (and not silence) as the feedback. 
If the caller does not hear any feedback, he or she might give up on the 
call and hang up.
nThe second step after the adjunct routing step  could  (and, in many cases, 
should) be implemented as a default treatment in case the host 
application or ASAI link is d own. The step containing this d efault treatment 
(for exam ple, 
route-to number 0 if unconditionally) executes immediately if 
the ASAI link is d own and if the ste p is preceded by either a 
wait-time or 
an 
announcement step.  On the other hand, if the host application is down, 
the default step executes only if the application does not respond with a 
route within 20 seconds. 
						

							VDN Return Destination Considerations
Issue  4 September 1995
C-5
VDN Return Destination 
Considerations
The VDN Return Destination feature allows an incoming trunk c all to be placed 
back in vector processing after all parties, except the originator, drop. This 
feature is activated through switch administration of the VDN form. It is an 
optional system feature, and as such, it must be optioned on the System-
Parameters/Customer-Options form.
A new field added to the VDN form will allow the user to enter a VDN extension as 
a Return Destination. In this section, the VDN which has the Return Destination 
field administered will be called the VDN with this feature active. The Return 
Destination VDN (the one specified in the new field) will be referred to as the 
Return Destination.
Every incoming trunk c all which is processed through a VDN with this feature 
active will be placed back in vector processing when all parties on the call, 
except the originator, drop. For this feature, the originator is the incoming party 
which originate d the call at the time the call entered the VDN with this feature 
active.
The VDN that the call will be placed in (when the originator is the only remaining 
party) is determined by the Return Destination. This VDN may be the same or 
different than the original VDN.
This feature is used to keep the call active and give the caller the opportunity to 
signal the need for sequence dialing (by entering a #).  There are two ways this 
can happen:
1. When the destination drops on its own (after having answered), the call 
will go to the Return Destination which will have a collect digits  vector 
step.  This step will try to collect the # sign entered by the caller.
2. When the call is not answered, the caller enters the # to request 
sequence calling (this # will be collected by the ASAI-Requested Digit 
Collection feature). This # is reported to the adjunct. The adjunct 
requests the third_party_d rop (or third_party_end_call) for the d estination, 
and at that point the call goes to the Return Destination.
The VDN Return Destination and ASAI-Requested Digit Collection features may 
be used independently, with the following rules:
1. If there is no ASAI request to collect digits, but a Return Destination is 
provided: when all p arties, except the originator, drop, the switch will route 
the call with only one party active (the caller) to the Return Destination. At 
this point, the call enters vector processing for the VDN specified by the 
Return Destination.
2. If a request is made to collect digits but there is no Return Destination 
provided: the switch will collect the digits and  pass them on to the ASAI 
adjunct.  It will be up to the adjunct to take action. However, if the action  
						

							Considerations for the Call Vectoring Features
C-6Issue  4 Septemb er 1995 
taken by the adjunct is to drop one party on the call, the switch will drop 
the other party as well and clear the call (it cannot retain a call with only 
one party, if there is no Return Destination for further processing).*
User Scenario — Remote Access with Host
Provided Security
A customer may use the VDN Return Destination feature to provide a more 
flexible remote access feature together with host based call security. The remote 
user/caller does not have to call b a ck into the switch when multiple destinations 
need to be reached nor does the caller have to enter his/her identification every 
time a new destination is desired.  For example, a customer can program the 
following vector that is accessed by dialing a VDN that has a Return Destination 
administered.
Figure C-1. Sample Return Destination Vector with Remote 
Access
In this scenario, a remote caller will call into the switch by d ialing the VDN 
administered with the Return Destination. The vector executed will promp t the 
caller to enter an identification number and a password that will be passed, via 
the adjunct routing vector command, to the host for validation. The host can keep 
track of invalid attemp ts or decide to de-activate or activate certain identification 
numbers based on customer set  criteria.
After the host b ased security is passed (the host sends an Abort to cancel the 
switch Route request; otherwise, the host routes the call to an exc eption 
destination/VDN), the switch will collect digits for the destination that the caller 
wants to reach (vector step 4 above). The host receives the number entered by 
the caller (vector step 5 above) and validates the entered number to check if  the 
caller is allowed to reach the sp ecified destination. If so, the host routes the call 
to the desired (dialed) destination.
1. collect 8 digits after announcement 1001 (Please enter
     your identification number and password followed by # sign)
2. adjunct routing link 1221
3. wait-time 6 seconds hearing silence
4. collect 16 digits after announcement 1002 (Please enter the 
     telephone number of your destination followed by # sign)
5. adjunct routing link 1222
6. wait-time 6 seconds hearing silence
7. disconnect after announcement 1003 (We are sorry, but we are 
     experiencing technical difficulties at this time, please try 
     again later) 
						

							VDN Return Destination Considerations
Issue  4 September 1995
C-7
If the host security is not passed, the host will route the call to an appropriate 
alternate destination (e.g., announcement with security violation message) and 
log the invalid call attempt.
If the host is not available, the call will be disconnected after an announcement 
(vector step 7 above).
After the called destination d isconnects from the call, the caller can remain on 
the line to be connected to the Return Destination. A sample Return Destination 
vector is as follows:
Figure C-2. Sample Return Destination Vector with Disconnect
The caller, once connected to the Return Destination, can enter a second 
destination/p hone number to connect to. The host performs the same  validation 
on the destination number as in the first d estination and routes the call as 
appropriate (destination entered by caller or alternate destination). Note that the 
host can also provide reports on all the destinations and times reached by each 
remote user.
In the Return Destination vector, it is recommended that the first vector command 
give the caller the opportunity to disconnect from the call rather than immediately 
routing the call to some destination. If the call was imme diately routed and then 
the caller decided to hang-up, the destination that the call was route d to would 
ring, alerting the called party, but then no one would be on the line at the other 
end (this could be confusing to customers, and could be misinterpreted as a 
problem with the feature). Vector commands such as wait, collect after 
announcement, and announcement can provide the caller with the o p portunity 
to disconnect before the call is routed. As an example, an announcement 
command with the recording Please hang-up to end your call, or remain on the 
line if you wish to place another call  instructs the caller to disc onnect, b efore the 
call is routed.
1. collect 16 digits after announcement 1002 (Please enter the 
     telephone number of your destination followed by # sign)
2. adjunct routing link 1221
3. wait-time 6 seconds hearing silence
4. disconnect after announcement 1003 (We are sorry, but we are 
     experiencing technical difficulties at this time, please 
     try again later) 
						

							Considerations for the Call Vectoring Features
C-8Issue  4 Septemb er 1995 
User Scenario — Saving in Trunk Facilities
Between Call Centers
A customer can also use VDN Return Destination to return a call to a local agent 
after the call is transferred to a remote destination (call). This will eliminate the 
need for the remote a gent to transfer the caller back to a local agent and will 
save in switch trunk facilities, since each time the call is transferred back to a 
local agent an additional trunk is being used by the call.
For exam ple, calls can be received at the local call through a VDN that has the 
return d estination administered. These  calls will b e delivered to an agent on the 
local switch. If the local agent transfers the call to a remote destination (because 
the caller needed to talk to an agent on the remote switch), the call will return to 
the Return Destination after the remote switch drops the call. The remote switch 
agent must inform the caller to remain on the line after they are finished and the 
remote agent just needs to disc onnect from the call (hang up).
The Return Destination for this scenario should include an announcement 
vector command at the beginning to inform the caller to disc onnect from the call, 
if they do not want to be reconnected to an agent on the local switch. A samp le 
Return Destination vector will be as follows:
Figure C-3. Sample Return Destination Vector with 
Announcement
1. announcement 1004 (Please remain on the line, if you want 
     to talk a to another representative)
2. queue-to main split 101 pri m 
3. announcement 1005 (All our representatives are busy, 
     please wait)
4. wait-time 60 secs hearing silence
5. goto step 3 if unconditionally