ATT DEFINITY Generic 3 Call Vectoring/Expert Agent Instructions Manual

							Basic Call Vectoring
4-14Issue  4 Septemb er 1995
here) usually contains an announcement that provides the caller with the 
appropriate apology and subsequent directives. If the caller is successfully 
connected to AUDIX, vector processing terminates, and a message may be left 
for the specified mailbox (2000, in this case).
Finally, if the supervisor or a group of agents has an Automatic Message Waiting 
(AMW) Lamp for the mailbox used, and if the lamp lights, the relevant p arty, upon 
returning, knows a caller has left an AUDIX message.
Option with the VDN as the Coverage Point
Recall from Chapter 3 that the Vector Directory Number (VDN) can be used as 
the last point in a coverage path. This capability allows the call to first go to 
coverage and to then be processed by Call Vectoring and/ or Call Promp ting . 
The c a pability also allows you to assign AUDIX or the Message Server to a 
vector-controlled hunt group and to therefore enable access to these servers via 
a 
queue-to main split or c heck-backup split c ommand. The result of all this is that 
call handling flexibility is enhanced.
Here’s a vector, for which the VDN serves as a final coverage point, that allows 
the caller to leave a recorded message.
Figure 4-12. Leaving Recorded Messages (VDN as the 
coverage point option)
In Steps 3 and 8 of the vector, the caller is g iven the o ption of leaving a recorded 
message. However, in accord with our discussion at the beginning of this 
section, the 
queue-to main sp lit command instead of the messaging split 
command is used in each case. The advantage here is that the call is actually 
queued to the AUDIX split or to the message server split. On the other hand, a 
messaging split command does not queue the call to the split; instead (if 
VDN 1 (used in a coverage path)
Vector 1
    1. goto step 7 if time-of-day is mon 8:01 to fri 17:00
    2. goto step 13 if staffed-agents in split 10 < 1
    3. queue-to main split 10 pri 1 (AUDIX split)
    4. wait-time 20 seconds hearing ringback
    5. announcement 1000 (‘‘Please wait for voice
       mail to take your message.’’)
    6. goto step 4 if unconditionally
    7. goto step 2 if staffed-agents in split 20 < 1
    8. queue-to main split 20 pri 1 (message server split)
    9. wait-time 12 seconds hearing ringback
   10. announcement 1005 (‘‘Please wait for an attendant
       to take your message.’’)
   11. wait-time 50 seconds hearing music
   12. goto step 10 if unconditionally
   13. disconnect after announcement 1008 (‘‘We cannot
       take a message at this time.  Please call back tomorrow.’’) 
						

							Functions and Examples
Issue  4 September 1995
4-15
successful), it simp ly connects the caller to the sp lit so the caller may leave a 
message for the specified extension. However, termination to the split may turn 
out to be unsuccessful due to a factor that cannot b e “ checked” by vector 
processing. (For example, the AUDIX link might be down, or all AUDIX ports 
might be out of service.)
As a result of the queuing process, a wait-announcement loop can be included 
after each 
queue-to main split step, and the appropriate loop can be executed 
until the call is actually terminated to either an AUDIX voice port or to an available 
message service agent. In this vector, Steps 4 through 6 comp rise the first wait-
announcement loop, and Steps 10 through 12 comprise the second such loop.
Sending Calls to a Vector-Programmed Number
Earlier in this chapter, we mentioned calls can be queued to a maximum of three 
splits.  Calls can also be routed to a programmed number in the vector via a 
process known as 
interflow.
Interflow
Interflow is a p rocess that allows calls that are directed or redirected to one sp lit 
to be redirected to an internal or an external destination. For Basic Call 
Vectoring, this destination is represented by a number programmed in the 
vector.  The number is always included in the 
route-to number command, and it 
may represent any of the following destinations:
nAttendant (or attendant queue)
nLocal extension
nRemote (that is, UDP) extension
nExternal number
nVDN 
						

							Basic Call Vectoring
4-16Issue  4 Septemb er 1995
The following vectors illustrate how interflow is used:
Figure 4-13. Call Interflow
In the first vector, a branch is made to Step 8 from Step 2 if the condition in the 
latter step (
oldest call-wait in sp lit 1 > 120 seconds) is true.  If the condition is 
false, a branch is made to Step 9 from Step 3 if the condition in the latter step 
(
calls-queued in split 1 > 10) is true. If that condition is also false, the call is 
queued (Step 4), and a wait-announcement loop becomes effective (Steps 5 
through 7).
If a successful branch to Step 8 is made from Step 2, the 
route-to numb er 
command is executed.  The destination numb er (2020) in this particular 
command is a VDN.  Ac c ord ingly, vector processing terminates in the first vector 
and begins at the first step of the second vector, to which the VDN points.
Once processing control is passed to the second vector, the caller is provided 
with the appropriate announcement (Step l).  Thereafter, upon execution of the 
messaging split command in Step 2, the system attempts to either queue the call 
to the message service split or else terminate the call to a message service agent 
or to an AUDIX voice port.  If one of these attempts succeeds, the caller may 
leave a message. If none of the attempts succeed, the command fails, and 
vector processing continues at the next vector command (usually an 
announcement explaining that the necessary connection could not be made).
Service Observing
Vector initiated Service Observing is available with G3V4 and later releases. For 
a complete description of Service Observing see the 
DEFINITY C ommunications 
System Generic 3 Feature Description
, 555-230-204.
  VDN (extension=1000   name=‘‘Billing Service’’  vector=55)
  Vector 55:
      1. announcement 3001
      2. goto step 8 if oldest call-wait in split 1 pri l > 120
      3. goto step 8 if calls-queued in split 1 pri l > 10
      4. queue-to main split 1 pri t
      5. wait-time 50 seconds hearing music
      6. announcement 3002
      7. goto step 5 if unconditionally
      8. route-to number 2020 with cov n if unconditionally
  VDN (extension=2020 name=‘‘Message Service’’  vector=100)  
  Vector 100:
      1. announcement 3900 (‘‘We’re sorry, all our
         agents are busy. Please leave a message. Thank you.’’)
      2. messaging split 18 for extension 3000
      3. disconnect after announcement 2505(‘‘We cannot
       take a message at this time. Please call back tomorrow.’’) 
						

							Functions and Examples
Issue  4 September 1995
4-17
Service Observing vectors allow users to observe calls either from a remote 
location or a local station. A Service Observe button is not required. The use of a 
Service Observing vector limits users to listen-only or listen-talk observing. The 
observer cannot toggle between the two states.
Service Observing vectors can be used to observe p hysical extensions, EAS 
logical agent LoginIDs, and VDNs.
The calling permissions of the COR assigned to the Service Observing VDN in 
conjunction with the “can be observed” settings of the COR assigned to the 
destination d etermine what agents, terminals, or VDNs can be observed. For 
a d ditional information about the security requirements with Service Observing 
vectors see Appendix I, Security Issues
You c a n construct Service Observing vectors in one of four ways. Vectors can 
route calls to:
1. A Service  Observing FAC
2. The R em ot e Access extension using Call Promp ting to test against a user-
entered security code.
3. A Service Observing FAC and extension entered by the user with Call 
Promp ting enabled
4. One of several Service Observing FACs and extensions programmed into 
route-to number vector steps. In this case Call Promp ting  can be used to 
allow the observer to select the extension to be observed.
The first vector type is d isc ussed below. See Chapter 5, Call Prompting for 
examples of Service Observing vectors that use Call Promp ting. 
Service Observing FAC Vector
The following vector connects the user to a Service Observing FAC. Be aware 
that this vector does not provide security checks and should be used with great 
care and only in situations where security is not a concern.
Figure 4-14. Vector for Service Observing FAC
1. wait-time 0 secs hearing ringback
2. route-to number #12 with cov n if unconditionally (Listen-only FAC)
3. busy 
						

							Basic Call Vectoring
4-18Issue  4 Septemb er 1995
In this vector the caller is connected to a listen-only Service Observing FAC. 
Once connected, the user must dial the extension number to be observed. To 
observe in a listen/talk mode, the observer would dial a different VDN.
Branching/Programming
Basic Call Vectoring provides several programming methods that affect the 
processing flow within the vector.  These methods, which are implemented via 
Call Vectoring commands, include the following:
nUnconditional branching
nConditional branching
nStopping vector processing
The following sections explain these programming methods.
Unconditional Branching
Unconditional branching is a method that always passes control from the c urrent 
vector step to either a preceding or subsequent vector step or to another vector.  
This type of branching is enabled via the 
g oto step and goto vector commands, 
each with a condition of 
unconditionally assigned.
Unconditional branching is illustrated in the following vector.
Figure 4-15. Unconditional Branching
The unconditional branch statement in Step 7 establishes an apparent ‘‘endless 
loop’’ involving Steps 5 through 7.  The loop, however, really is not endless, since 
vector processing terminates if an agent answers the call.  Vector processing 
also terminates when the system recognizes the caller has abandoned the call.
Conditional Branching
Conditional branching is a method that c onditionally passes control from the 
current vector step to either a preceding or subsequent vector step or to a 
different vector.  This type of branching is enabled via the 
goto step and goto 
      1. goto step 8 if calls-queued in split 3 pri m > 10
      2. queue-to main split 3 pri m
      3. wait-time 12 seconds hearing ringback
      4. announcement 3001
      5. wait-time 30 seconds hearing music
      6. announcement 3002
      7. goto step 5 if unconditionally
      8. busy 
						

							Functions and Examples
Issue  4 September 1995
4-19
vector commands, each with one of the following conditions assigned and 
tested:  
available-agents, staffed-agents, calls-queued, oldest call-waiting, or 
time-of-day. When Advanced Vector Routing is enabled, additional conditions 
can be tested: 
rolling-asa, c ounted-calls, expected-wait. See Chapter 6, 
Advanced Vector Routing  for more information. When ANI and II-Digits Routing 
is enabled, the 
ani and ii-digits conditions can also be teste d with a goto 
command. See, Chapter 7, ANI and II-Digits Routing for more information. If the 
command’s condition is not met, control is p assed to the step that follows.
Conditional branching is illustrated in the following vector.
Figure 4-16. Conditional Branching
In this vector, a conditional  branch test statement appears in steps 1, 2 and 3. If 
the call is placed during non-business hours (b etween 5:00 p.m. and 8:00 a.m.) 
on any day of the week, the 
goto vector command in Step 1 routes the call to 
vector 100. However, if the call is placed during b usiness hours, control is 
passed to Step 2, where the 
goto vector command there c hecks whether the c all 
is placed during the weekend. If this is the case, the call is route d to vector 200. 
If not, control is passed to Step 3, where the 
goto step command checks for the 
number of calls queued to the main split. If the number of calls is greater than 5, 
control is passed to 
busy in Step 8. If the number of calls is 5 or less, the call is 
queued (Step 4). Thereafter, an announcement-wait cycle (Steps 5 through 7) is 
implemented until an agent answers the call or the call is abandoned.
Stopping Vector Processing
Basic Call Vectoring provides a specific command that stops vector processing. 
The 
sto p command halts the processing of any subsequent vector ste ps. If a call 
is not queued when ve ctor processing stops, the call is dropped and tracked as 
an “abandon” by the Call Management System (CMS) and/or BCMS. After the 
stop command is processed, any calls that are already queued remain queued, 
and any wait treatment (silence, ringback, system music , or alternate 
audio/music source) is continued.
      1. goto vector 100 if time-of-day is all 17:00 to all 8:00
      2. goto vector 200 if time-of-day is fri 17:00 to mon 8:00
      3. goto step 8 if calls-queued in split 1 pri l > 5
      4. queue-to main split 1 pri l
      5. announcement 4000
      6. wait-time 60 seconds hearing ringback
      7. goto step 5 if unconditionally
      8. busy 
						

							Basic Call Vectoring
4-20Issue  4 Septemb er 1995
The following vector illustrates how vector processing is stopped via the stop 
command.
Figure 4-17. Stopping Vector Processing
If the 
sto p command is reached, the queued caller will c ontinue to hear ringback. 
Also, if the 
stop command in Step 5 is executed, Step 6 is not executed 
immediately thereafter. The latter ste p can b e executed only if the 
goto command 
in Step 1 succeeds.
Note that an 
imp lied stop follows the last step within a vector. In addition, a 
vector will stop processing whenever 1,000 vector steps have been processed.
Vector Chaining
Multiple vectors can be c hained together to enhance processing capabilities.  In 
this regard, the following points involving two Basic Call Vectoring commands 
should be noted:
nRoute-to number.  If this c ommand is used to point to a VDN, the following 
happens:
1. Vector processing continues at the first ste p in the vector assigned 
to the routed-to VDN.
2. Call (if queued) is dequeued.
3. Wait treatment (if any) is disabled.
Processing then continues in the receiving vector at Step 1.
nGoto vector.  If this command is used, the following happens:
1. Vector processing continues at the first step in the branched-to 
vector.
2. Call (if queued) remains in queue.
3. Wait treatment (if any) is continued.
Processing then continues in the receiving vector at Step 1.
      1. goto step 6 if calls-queued in split 21 pri m > 10
      2. queue-to main split 21 pri m
      3. announcement 4000
      4. wait-time 30 seconds hearing ringback
      5. stop
      6. busy 
						

							Issue 4 September 19955-1  
5
Call Prompting
Introduction
Call Promp ting  provides flexible call handling based on information collected 
from a calling party.  This information comes in the form of d ialed digits 
originating from an internal or external touch-tone telephone, or from an internal 
rotary telephone. In effect, Call Prompting allows for the temporary transfer of call 
management control to the caller.
With Voice Response Integration (VRI), digits may be returned to the switch by a 
Voice Response Unit (VRU) script accessed via a 
c onverse-on split command. 
Such digits can also be used for call management.
Call Prompting may b e used in various applications to achieve a better and more 
flexible handling of telephone calls. 
						

							Call Promp ting
5-2Issue 4 September 1995
Command Set
The following table illustrates the commands used for Call Prompting:
Touch-Tone Collection Requirements
Before the DEFINITY  syst em can accept the touch-tone digits entered by a Call 
Promp ting user, the switch must be equipped with a “collection resource.” The 
resource used for collecting and interpreting touch-tone d i gits is a unit of 
hardware called a Touch-Tone Receiver (TTR). These TTRs are provid e d on the 
TN744 call c lassifier and TN2182 tone d etector (G3V4 and later releases), one of 
which is required for Call Prompting.
For new systems, the number of required TTRs is configured according to two 
sources, as follows:
nCustomer input to the AT&T Ac c ount Team
nAccount team input to the DOSS /A TT OM S configuration
Table 5-1. Call Prompting Command Set
Command 
Category Action Taken Command
INFORMATION 
COLLECTIONCollect information from the calling 
party or from a Voice Response  Unit 
(VRU).
collect digits 
TREATMENT Play an announcement.
Delay with audible feedback of 
silence, ringback, system music , or 
an alternate audio/music source.
announcement
wait-time
ROUTING Leave a message.
Route the call to a number 
programme d in the vector.
Route the call to digits sup plied by 
the calling party.messaging split
route-to number
route-to digits
BRANCHING/ 
PROGRAMMINGGo to a vector step.
Go to another vector.
Stop vector processing.goto step
goto vector
stop 
						

							Call Promp ting  Digit Entry
Issue 4 September 1995
5-3
For existing systems that are a d ding a Call Prompting a p plication, the AT&T 
Account Team  recommends  the  appropriate number of TTRs based on two 
factors, as follows:
nAccount team input to the DOSS /A TT OM S configuration
nApplication review by the AT&T Design Center
Outside callers must have a touch-tone phone to enter the digits requested via 
the 
c ollect digits command. For callers using rotary dialing, the Call Promp ting 
timeout takes effect, the 
collect digits command times out, and vector 
processing continues at the next step. As a precaution, the customer should 
always provide a default treatment (for example, 
route-to attendant command, 
queue-to main split command) in the vector script unless the script is created 
exclusively for users of touch-tone telephones.
NOTE:
With G3V4 a n d later releases, the Call Prompting inter-digit timeout can be 
administered for any number of seconds from 4 to 10. This value is 
administered on the Feature-Related System Parameters form. See 
DEFINITY Communications System Generic 3 Version 4 Imp lementation, 
555-230-655 or 
DEFINITY Communications System Generic 3 V2/V3 
Imp lementation
, 555-230-653, for instructions.
Provisions for users of rotary p hones are illustrate d in the vector scripts in this 
chapter.
Call Prompting Digit Entry
The touch-tone digits entered by a Call Promp ting user are collected via the 
collect digits command.  This command allows the system to collect up to 24 
d i gits from a touch-tone phone. Sixteen of these digits may be collected 
immediately, while any remaining digits are stored as dial-ahead digits 
(explained later in this chapter).
Call Promp ting  allows some flexibility in entering digits.  Specifically, the caller 
can  do the following:
nRemove incorrect digits strings
nEnter variable-length digit strings
nEnter dial-ahead digits
The following sections explain these processes.