ATT DEFINITY Generic 3 Call Vectoring/Expert Agent Instructions Manual

							Functional Differences for G2 and G3 Call Vectoring 
and EAS
E-8Issue  4 September 1995 
General Call Vectoring Functional 
Differences
This table provides an overview of general differences for Call Vectoring 
operations b etween the Generic 2 and Generic 3 switches.
Table E-7. General Call Vectoring Functional Differences
TOPIC GENERIC 3 GENERIC 2
General ACD Split q ueue size is administered 
on a per split basis with a 
system-wide maximum of calls. 
In G3i, this maximum is 1,000 
c alls; in G3s PBP and G3vs PBP, 
this maximum is 200 calls; in 
G3r, the maximum is 10,500 
c alls.  Call q ueue space for the 
appropriate maximum number 
of calls must be d istributed on a 
p reassigned basis over all 
assigned hunt groups and 
(vector-controlled or nonvector-
c ontrolled) ACD splits.  In G3i, 
G3s PBP, or G3vs PBP, the 
maximum queue space that  can 
b e allocated for any one split 
and/or hunt group is 200; in G3r, 
it is 999.There is no limit to the size of 
individual split queues.
An a gent may be concurrently 
lo g ged into three splits at a time.An agent may be logged into 
only one split at a time.
The agent hears the same zip 
tone signal for calls that are 
q ueued to the main split as well 
as for intraflowed/interflowed 
c alls.One burst zip tone is provid e d 
for c alls that are queued to the 
main split.  Two burst zip tones 
are provided for intraflowed 
calls (via the 
c heck backup 
split
 command), and three 
b urst zip tones are provided 
for interflowed calls (via Look-
Ahead Interflow).
ACD Split  Strateg y A split or a hunt group can be 
accessed by either a call vector 
or a group extension. This allows 
for both vector calls and 
nonvector calls in a single split’s 
q ueue.When Call Vectoring is 
optioned, sp lits do not have 
extensions.  All access to 
splits must go through a Call 
Vector via 
queue to main split 
or 
check backup split 
commands. 
						

							General Call Vectoring Functional Differences
Issue  4 Septemb er 1995
E-9
Non-vector-controlled splits can 
specify redirection treatment 
(such as Call Coverage, Call 
Forwarding, etc.) and 
announcement treatment.Only vector-controlled sp lits 
are available when Call 
Vectoring is active.
VDN 
Access/CapacityCOR checking is used for 
access to a VDN and for routing 
to a station.No restriction checking is used 
to access a VDN. NOTE: Both 
G2 and G3 use the Facility 
Restriction Level (FRL) 
associated with the VDN for 
outgoing trunk calls.
COR checking is used when 
routing locally from a vector.No restriction check is 
imp lemented for local routing.
A maximum of 500 VDNs [G3i 
(R3 CMS)], 100 VDNs [G3s PBP 
(R3 CMS), G3vs PBP (R3 CMS)], 
or 20000 VDNs [G3r (R3 CMS)] 
c an be used.The maximum numb er of 
VDNs is limited only by the 
numb er of extensions c a pacity 
(32K).  
Voice Mailbox
messaging split command is 
used.Calls are routed to a 
messaging sp lit via a route to 
another VDN assigned to a 
vector with a queue to AUDIX.
Misc ellaneous Changes made to vector 
administration take effect upon 
submission. These changes can 
affect current calls.A ‘‘scratch’’ pad is used for 
vector changes. 
Consequently, only new calls 
that enter the vector receive 
the treatment specified in the 
corrected vector. Vector 
p rocessing for existing calls is 
comp leted in the old vector.
Table E-7. General Call Vectoring Functional Differences
TOPIC GENERIC 3 GENERIC 2 
						

							Functional Differences for G2 and G3 Call Vectoring 
and EAS
E-10Issue  4 September 1995 
Differences in Defining/Interpreting 
Split Flows
Split flows are defined and/or interpreted according to the switch version and the 
management system involved. The following sections illustrate how split flow 
interpretation differs within the G1/G3 and G2 switch versions and according to 
two management systems, including R3 CMS and R2 CMS.
NOTE:
BCMS is not available on G2 (with or without vectoring). An existing vector can not be 
c opied to another blank vector. 
(This cap a bility, however, is 
available via CMS 
administration.)These capabilities are 
p rovided by the switch 
a dministration.
Either the VDN or the final 
d estination (but not both) is 
p rovided in the CDR record. Variable format CDR (formerly 
SMDR) records can be used. 
Consequently, both the VDN 
and the final destination can 
b e provided. NOTE: CDR 
records allow the VDN to be 
specified in the calling party 
field.
Blank steps are allowed in 
vectors, and blank vectors (with 
no steps defined) may exist.Blank steps or blank vectors 
are not allowed (CMS also 
d oes not support this).
Trunk groups can b e assigned to 
VDNs 
only via switch 
administration.Trunks groups can be 
assigned to VDNs via CMS 
a dministration.
Vector processing is limited to a 
maximum of 1,000 ste p 
executions for a call.  Once this 
maximum is reached, 
p rocessing stops. There is an 
implied wait of one second for 
every seven executed steps.Separate 1,000 step counters 
are provided for execution of 
g oto step commands and 
check backup split retries. If 
either counter exceeds 1,000, 
the call is forced 
d isconnected.  Only 
check 
b ackup split
 retries are 
counted on internal calls.
Table E-7. General Call Vectoring Functional Differences
TOPIC GENERIC 3 GENERIC 2 
						

							Differences in Defining/Interpreting Split Flows
Issue  4 September 1995
E-11
R3 CMS Standards
The following tables illustrate how split flows that occur in the G1/G3 and G2 
versions of the switch are interp reted vis-a-vis R3 CMS:
When a call is not answered [d ue to a(n) outflow, abandon, busy, or  disconnect], 
the call’s disposition is tracked for the primary split.  On R3 CMS, the other splits 
to which the call is queued tracks a dequeue when the call outflows, abandons, 
is given busy treatment, or is d isconnected.
If the primary sp lit in a VDN is unmeasured, a(n) outflow, abandon, busy, or 
disconnect is not tracked for the call. Also, an answer is not tracked if the call is 
answered by an agent in the primary split.
R2 CMS Standards
For single split queuing, R2 CMS tracks split inflows and outflows according to 
the definitions provided in the previous section for ‘‘G2/traditional ACD.’’
However, when multiple split queuing is involved, a call can look like two or three 
separate calls to R2 CMS. As a result, if a call is queued to multiple splits and is 
then answered by an agent in one of these splits, an 
inflow is not tracked in R2 
CMS. However, if a call is 
requeued to one or more splits (via a route to 
Table E-8. R3 CMS Standards for Interpreting Split Flows
Flow Type Switch  Version Interpretation
Inflow G1/G3 with 
vectoringCalls answered by a sp lit other than a 
p rimary split.
NOTE: A primary sp lit is the first split to 
which a call queues.
G2/traditional ACD Calls that intraflow from one split’s queue 
to another sp lit’s queue (that is, calls that 
q ueue to a split after having been 
p reviously queued to another split).
Outflow G1/G3 with 
vectoringCalls that are dequeued from a primary 
s plit via a 
route to or messaging split 
c ommand, or by being answered by an 
agent in another split to which the call is 
also queued.
G2/traditional ACD Calls that are taken out of a split’s queue 
and then sent to another destination.
Dequeue G1/G3 with 
vectoringCalls that are dequeued from any sp lit 
other than the primary sp lit in a VDN.
G2/traditional ACD (Not used.) 
						

							Functional Differences for G2 and G3 Call Vectoring 
and EAS
E-12Issue  4 September 1995 
command, for example), an inflow is trac ked only in the first split to which the call 
requeues
.
Also, when multiple split queuing is involved, R2 CMS tracks an 
outflow in those 
splits to which the call queues and from which it eventually dequeues without 
being answered there. In effect, then, R2 CMS tracks an outflow in the same 
situations where R3 CMS tracks a dequeue.
Differences Between G2 and G3r EAS
This section lists the differences between release G2 and G3r for EAS.
nCapacities:
nG2.2 does not have logical agent capabilities.
— Voice terminals are preassigned to default skill groups (g roups  
ending in zero).
— Agents sharing voice terminals must have the same default skill 
group.
— The voice terminal extension is used to provide a name, COR, and 
coverage path.
nG3 logical agent provides the following:
— Any voice terminal can be used as an ACD terminal for any skills.
— Agents can be reached by dialing their login IDs.
— Name, COR, and coverage path follow the agent to the voice 
terminal  currently logged into.
nG2.2 does not support Direct Agent Calling.
nG2.2 does not support Call Promp ting.
nG2.2 login procedure is: dial feature access code, dial login ID twice. G3 
login procedure is: dial feature access code, dial login ID,  dial optional 
password.
nG2.2 restricts agents with multiple skills to skills in the same skill  tens 
group (for example, skill 20-29). G3 allows agent to be in any combination 
of skills.G2.2 G3r
Measured Agents 1023 5200 
Total Agents 2048 5200 (each agent 
in one skill)
Skills/agent 5 (1 default +  4 ad d itional) 4
Skill Groups 600 (numbered 10-609) 255 
						

							Differences Between G2 and G3r EAS
Issue  4 September 1995
E-13
nG2.2 restricts calls queuing to multiple skills simultaneously to skills in the 
same skill tens group. This also a p plies to VDN skills. G3 allows calls to 
queue to any three skills simultaneously.
nG2.2 administers agents to a default skill and the agents enter their  other 
skills after lo g ging in. G3 administers all of the agents’ skills, and the 
agents are log g ed into  all of their assigned skills during login.  G3 agents 
cannot change their skills.
nCMS can only change an agent’s default skill on G2.2 (when the agent is  
unstaffed). CMS can change all skills for an agent on G3 (c hange affected 
the next  time the agent logs in).
nG2.2 does not support primary/secondary skills for agents.  This also  
implies G2.2 d oes not sup port expert agent distribution (EAD). G3 does 
support primary/secondary agent skill assignments and EAD.
nOn G2.2, when a change is made to a VDN  skill preference, only new 
calls  to the VDN will be impacted by the change.   On G3 when a change 
is ma de to  a VDN  preference,  existing calls will be impacted as they 
encounter a vector  step that references the VDN skill preference. 
						

							Issue  4 September 1995F-1 
F
Interactions Between Call 
Vectoring/EAS and BCMS/CMS
Introduction
Call Vectoring and EAS interact with a management information system that 
helps to monitor and report on the activity within Call Vectoring and EAS. In most 
cases, the management system is either the Call Management System (CMS) or 
the Basic Call Management System  (BCMS).
CMS, which resides on an adjunct processor, collects and processes ACD 
information to generate various reports. BCMS performs the same duties. The 
main difference between CMS and BCMS is that the latter resides on the 
customer switch.  Also, it should be noted that CMS reporting capabilities are 
much more extensive than those of BCMS.
This chapter is intended to illustrate how these management systems interpret 
and report on activity within Call Vectoring and EAS.  Special emphasis is placed 
on interpreting and reporting on this activity as it occurs within splits d uring a 
series of Call Vectoring or EAS events.
NOTE:
The manual pages in Appendix A p rovide a summary of the CMS/BCMS 
interactions with each Call Vectoring command (where a p plicable). 
						

							Interactions Between Call Vectoring/EAS and 
BCMS/CMS
F-2Issue  4 Septemb er 1995 
BCMS/CMS Tracking in a Call 
Vectoring Environment
Tracking is the identifying of various call flows and other actions relevant to call 
handling. For our p urposes, there are three classes of call flows: sp lit flows, VDN 
flows, and vector flows. Also, we are most concerned with tracking in the Call 
Vectoring environment. The specific types of call flows and actions in this 
environment that are tracked by BCMS/CMS include the following:
nInflows (flow ins)
nOutflows (flow outs)
nDequeues
nAbandons
nAnswers
nBusies
nDisconnects
The split supervisor can use VDN and vector flows to evaluate how effective 
vector programming is at the site in question. The  supervisor can use split flows 
to d etermine the manner in which the splits at the site are handling incoming 
telephone calls.
Defining and Interpreting Call Flows
The manner in which specific call flows are defined and interpreted depends 
upon the call flow class in question, the management system in effect, and the 
version of the DEFINITY  switch b eing used.  Management systems include 
R3  
CMS, R2 CMS
, and BCMS.
The following sections define and interpret sp ecific call flows according to these 
parameters.
Answered and Abandons
The most important tracking items for most VDNs and vectors are the number of 
calls answered and the numb er of  calls abandoned. R3  CMS  provides VDN 
profiles that show when calls are answered and abandoned. Ten service level 
intervals are administered for these profiles.  These  intervals can have smaller 
time intervals around the time most calls are answered and when most call 
abandon to get more detailed information.
This data can be used to determine what an acceptable service level is for most 
callers.  The percentage answered within the administered acceptable service 
level is also shown on the Call Profile reports.  For VDNs, the calculation is ACD 
calls answered and nonACD calls connected within the service level divid e d by 
calls offered to the VDN (including calls that inflow to the VDN). 
						

							BCMS/CMS Tracking in a Call Vectoring Environment
Issue  4 September 1995
F-3
For split/skill statistics, the calculation is ACD calls answered within the service 
level divided by calls queued to the split/skill (answered  calls, abandoned calls, 
calls that flow out, calls that dequeue).  In most  cases the VDN percentage will 
be higher then the sp lit percentage since  calls dequeued from a sp lit/skill are 
counted as answered, abandoned, or  outflows for the VDN. 
Changes made to a vector or to staffing will typically im pact the VDN call p rofile.  
Even the word ing of an announcement can impact the abandon profile. It is 
worthwhile to review the VDN’s call profile before and after any change to 
determine if the change had a positive impact.
Busies and Disconnects
Busy c alls and forced disconnects reported on CMS indicate how many calls this 
VDN/vector turned away.  If forced disconnect is used out of b usiness hours, this 
item would indicate how many c ustomers expected you to b e  operating d uring a 
specific time interval.  If b usies are given when the q ueues are full or waiting 
times are long, the numb er of busies in an interval might suggest a staffing 
change is needed.  If disconnect is used to d eny a lookahead interflow attempt, a 
large numb er of denials would indicate a busy time at multiple sites.
VDN Inflows and Outflows
The following section discusses the specific VDN flows vis-a-vis R3 CMS and 
BCMS. 
						

							Interactions Between Call Vectoring/EAS and 
BCMS/CMS
F-4Issue  4 Septemb er 1995 
R3 CMS and BCMS Standards
The following table illustrates how R3 CMS and BCMS interp ret specific VDN 
flows for the G1/G3 versions of the DEFINITY switch:
NOTE:
(R3 CMS only):  If a call that covers to a VDN is originally a call to a 
measured (nonvector-controlled) VDN, R3 CMS records a VDN flow in for 
the coverage to the second VDN and a VDN flow out for the first VDN.
Vector Inflows and Outflows
The following section discusses the specific vector flows vis-a-vis R3 CMS.
R3 CMS Standards
Vector flow in pertains to calls that flow into a vector from another vector via a 
route to or a goto vector command. Vector flow out pertains to calls that 
successfully flow out of a vector via a 
route to or a goto vector command. Table F-1. R3 CMS and BCMS Standards for Interpreting VDN 
Flows (in G1/G3)
Flow Type Management System Interpretation
VDN flow in R3 CMS
BCMSCalls that flow into the vector 
from another vector via a 
route-to 
command.
(Not tracked.)
VDN flow out R3 CMS
BCMSCalls that successfully flow out of 
a vector to another VDN or 
external location via a 
route-to 
command.
Calls that are a dvanced to 
another position via a successful 
route-to or messaging split 
command.  This can involve 
adjunct routing, calls forwarded, 
calls route d to a VDN, and calls 
p icked up b y an agent who is not 
in the sp lit for which the call is 
q ueued by the VDN. 
Calls that are answered by an 
attendant (via a 
route-to 
command).