ATT DEFINITY Generic 3 Call Vectoring/Expert Agent Instructions Manual

							BCMS/CMS Tracking in a Call Vectoring Environment
Issue  4 September 1995
F-5
Split Inflows, Outflows, and Dequeues
The following sections discuss the various sp lit flow types vis-a-vis R3 CMS, R2 
CMS, and BCMS.
R3 CMS and BCMS Standards
R3 CMS and BCMS are grouped together because both of these systems 
interpret two split flow types identically.  These flows include 
inflow and outflow.  
However, whereas R3 CMS interp rets another sp lit flow type, namely 
d equeue, 
BCMS does not d o so because this system does not have a dequeue tracking 
item.  This means that in a situation where R3 CMS tracks a dequeue, BCMS 
does not because it is unable to do so.
Before we detail how R3 CMS and BCMS interpret split flows, we should discuss 
the term 
p rimary split, since this concept plays a significant role in tracking. 
Primary split is d efined as the first split in a VDN to which a call actually q ueues 
or at which the call is connected to an agent
. Therefore, this split is not 
necessarily
 the first split referenced in the vector.
Another split becomes the primary split if either of the following events occur:
nCall cannot queue to the originally-targ eted split because the split has no 
queue slots available.
nCall leaves the VDN (via a route to VDN command, for example) and is 
queued to another split as a result.
If the call leaves vector processing and does not queue to another split (as a 
result of a 
route-to extension command, for example), there is no new primary 
split. 
						

							Interactions Between Call Vectoring/EAS and 
BCMS/CMS
F-6Issue  4 Septemb er 1995 
With this discussion in mind, let’s take a look at the following table to see how R3 
CMS and BCMS interp ret split flows for the G1/G3 versions of the DEFI NI TY 
switch:
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 track a dequeue when the call outflows, abandons, is 
given busy treatment, or is disconnected.
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
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 command, for 
example), an 
inflow is tracked only in the first split to which the call requeues. Table F-2. R3 CMS and BCMS Standards for Interpreting Split
Flows (in G1/G3)
Flow Management
Type System Interpretation
Inflow R3 CMS
BCMSCalls answered by a split other 
than a primary split.
(Same as for R3 CMS.)
Outflow R3 CMS
BCMSCalls that are d equeued from a 
p rimary split via a 
route-to or 
messaging s plit c ommand, or b y 
b eing answered by an agent in 
another split to which the call is 
also q ueued.
(Same as for R3 CMS.)
Dequeue R3 CMS
BCMSCalls that are d equeued from 
and not answered by any split 
other than the primary split in a 
VD N.
(Not tracked.) 
						

							BCMS/CMS Tracking in a Call Vectoring Environment
Issue  4 September 1995
F-7
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 de queues without 
being answered there. In effect, then, R2 CMS tracks an outflow in the same 
situations where R3 CMS tracks a dequeue.
Examples of Split Flow Tracking
The following sections provide some examples of tracking in R3 CMS, R2 CMS, 
and BCMS.  Each section first presents a scenario of Call Vectoring events. The 
scenario is then followed by a table in which the tracking for the various splits 
involved is recorded.  Following each ‘‘tracking table,’’ an explanation of the 
tracking procedure is provided.
The scenarios presented include the following:
nCall answered by a primary sp lit
nCall answered by a nonprimary split
nCall a bandoned
nCall answered by a primary sp lit after a route to VDN
nCall answered by a nonprimary split after a route to VDN
nCall answered after a route to split
NOTE:
Inflows, outflows, and dequeues are not tracked for splits administered by 
the 
c onverse on split command.  However, if a call is answered both by a 
converse split and (subsequently) by a nonconverse split, an ‘‘answer’’ is 
tracked for each split.  However, a call is really considered ‘‘answered’’ only 
when it is answered by a nonconverse split. Therefore, traffic 
measurements for converse splits should be used only to measure 
converse split traffic and not to calculate the total number of calls.
Call Answered by a Primary Split. The following scenario involves a call 
answered by the primary split.  The scenario is as follows:
1. Call comes into a VDN whose vector queues the call to splits 1, 2 and 3.
2. Call is answered in split 1. 
						

							Interactions Between Call Vectoring/EAS and 
BCMS/CMS
F-8Issue  4 Septemb er 1995 
Here’s the tracking table for this scenario:
Comments:
nR3 CMS:  Dequeue is tracked in split 2 as well as in split 3 because the 
call is answered by the primary split (split 1) and is thus d e queued from 
splits 2 and 3 without being answered in these sp lits.
nBCMS:  No d e queue tracking item is available.
nR2 CMS:  Outflow is tracked in the same situations where R3 CMS tracks a 
dequeue.  Accordingly, outflow is trac ked in sp lits 2 and 3 because the 
call is dequeued from these splits without being answered in either one of 
the splits.
Call Answered by a Non-Primary Split. The following scenario involves a call 
answered by a nonprimary split.  The scenario is as follows:
1. Call comes into a VDN whose vector queues the call to splits 1, 2 and 3.
2. Call is answered in split 2.
Here’s the tracking table for this scenario:
Table F-3. Tracking for Call Answered by Primary Split
Split Tracking
123
R3 CMS answer dequeue dequeue
BCMS answer
R2 CMS answer outflow outflow
Table F-4. Tracking for Call Answered by Non-Primary Split
Split Tracking
123
R3 CMS outflow inflow
answerdequeue
BCMS outflow inflow
answer
R2 CMS outflow answer outflow 
						

							BCMS/CMS Tracking in a Call Vectoring Environment
Issue  4 September 1995
F-9
Comments:
nR3 CMS: Outflow is tracked in split 1 because the call is answered by an 
agent in another split to which the call is queued (that is, split 2). Although 
the call is obviously removed from split 1 after it is answered in split 2, 
dequeue is not tracked in split 1 because split 1 is the p rimary sp lit. Inflow 
is tracked in split 2 because the call is answered in this sp lit and the split 
is not the primary split.  
Dequeue is tracked in split 3 because the call is 
removed from the split without being answered there.  When the call is 
removed from split 3, 
outflow is not tracked in split 3 because this sp lit is 
not the primary split.
nBCMS:  Follows the same scheme as R3 CMS except for the dequeue 
tracking.
nR2 CMS:  Outflow is tracked in splits 1 and 3 because the call is 
dequeued from these splits without b eing answered there.
Call Abandoned. The following scenario involves a call a bandoned b y the caller.  
The scenario is as follows:
1. Call comes into a VDN whose vector queues the call to splits 1, 2 and 3.
2. Call is abandoned.
Here’s the tracking table for this scenario:
Comments:
nR3 CMS:  Abandon is tracked in split 1 because this split is the primary 
split.  
Dequeue is tracked in splits 2 and 3 because the call is dequeued 
from these splits without being answered in either split.
nBCMS:  Abandon is tracked in split 1 because this sp lit is the p rimary sp lit.  
Tracking is not recorded in splits 2 and 3 because no dequeue tracking 
item is available.
nR2 CMS:  Abandon is tracked in split 1 because this split is the primary 
split. 
Outflow is tracked in splits 2 and 3 because the call is d equeued 
from these splits without being answered in either one of the splits.
Table F-5. Tracking for Abandoned Calls
Split Tracking
123
R3 CMS abandon dequeue dequeue
BCMS abandon
R2 CMS abandon outflow outflow 
						

							Interactions Between Call Vectoring/EAS and 
BCMS/CMS
F-10Issue  4 September 1995 
Call Answered by a Primary Split after a Route To VDN. The following 
scenario involves a call answered by the primary sp lit after a 
route-to VDN 
command is executed. The scenario is as follows:
1. Call comes into a VDN whose vector queues the call to splits 1, 2 and 3.
2. Vector executes a 
route-to VDN step.
3. Call is then queued to sp lits 4, 5 and 6.
4. Call is answered in split 4.
Here’s the tracking table for this scenario:
Comments:
Split 1 is the 
original primary split, because this is the first split to which the call 
actually queues. However, split 4 b ecomes the 
new primary split because:
nCall leaves the original VDN upon execution of the route-to VDN step.
nSplit 4 is the first sp lit to which the call queues upon execution of this step.
nR3 CMS:  Outflow is tracked in split 1 because this sp lit is the original 
primary split, and the call is dequeued from this sp lit via a 
route-to VDN 
step.  
Dequeue is tracked in splits 2, 3, 5, and 6 because the call is 
dequeued from each of these splits without being answered in any one of 
them.
nBCMS:  Follows the same scheme as R3 CMS except for the dequeue 
tracking.
nR2 CMS:  Outflow is tracked in splits 1, 2, 3, 5 and 6 because the call is 
dequeued from these splits without b eing answered in any one of them. 
Inflow is tracked in split 4 because split 4 is the first split to which the call 
requeues after the 
route to command is executed.
Call Answered by the Non-Primary Split after a Route To VDN. The following 
scenario involves a call answered by the nonprimary split after a 
route to VDN 
command is executed. The scenario is as follows: Table F-6. Tracking for Call Answered by Primary Split after 
Route to VDN
Split Tracking
123456
R3 CMS outflow dequeue dequeue answer d equeue d equeue
BCMS outflow answer
R2 CMS outflow outflow outflow inflow
answeroutflow outflow 
						

							BCMS/CMS Tracking in a Call Vectoring Environment
Issue  4 September 1995
F-11
1. Call comes into a VDN whose vector queues the call to splits 1, 2 and 3.
2. Vector executes a 
route-to VDN step.
3. Call is then queued to splits 4, 5 and 6.
4. Call is answered in split 5.
Here’s the tracking table for this scenario:
Comments:
nR3 CMS:  Outflow is tracked in split 1 because this sp lit is the original 
primary split, and the call is dequeued from this sp lit via a 
route-to VDN 
step.  
Dequeue is tracked in splits 2, 3, and 6 because the call is 
dequeued from each of these splits without being answered in any one of 
them.  
Outflow is tracked in split 4 because this split becomes the new 
primary split after the 
route-to VDN step is executed, and the call is 
subsequently dequeued from this sp lit by being answered in another split 
(sp lit 5) to which the call is also queued.  Finally, 
inflow is tracked in split 5 
because the call is answered in this sp lit, and the split is not the primary 
split.
nBCMS:  Follows the same scheme as R3 CMS except for the dequeue 
tracking.
nR2 CMS:  Outflow is tracked in splits 1, 2, 3, 4, and 6 because the call is 
dequeued from these splits without b eing answered in any one of them.  
Inflow is tracked in split 4 because this split is the first one to which the call 
is requeued after the 
route to command is executed.
Call Answered after a Route To Split. The following scenario involves a call 
answered after it is routed to a split via a 
route-to d i gits or messaging split 
command.  The scenario is as follows:
1. Call comes into a VDN whose vector queues the call to splits 1, 2 and 3.
2. Vector executes a 
route-to d igits (or messaging split) step. Table F-7. Tracking for Call Answered  by Non-Primary Split 
after Route to VDN
Split Tracking
123456
R3 CMS outflow dequeue dequeue outflow inflow
answerd equeue
BCMS outflow outflow inflow
answer
R2 CMS outflow outflow outflow inflow
outflowanswer outflow 
						

							Interactions Between Call Vectoring/EAS and 
BCMS/CMS
F-12Issue  4 September 1995 
3. Call is queued to split 4.
Here’s the tracking table for this scenario:
Comments:
nR3 CMS:  Outflow is tracked in split 1 because this sp lit is the original 
primary split, the call is dequeued from this split via a 
route-to digits (or 
messaging split) step, and the call is answered in split 4, which becomes 
the 
new primary split.  Dequeue is tracked in splits 2 and 3 because the 
call is dequeued from each of these splits without being answered in any 
one of them.
nBCMS:  Follows the same scheme as R3 CMS except for the dequeue 
tracking.
nR2 CMS:  Outflow is tracked in splits 1, 2, and 3 because the call is 
dequeued from these sp lits without b eing answered in any of them.  
Inflow 
is tracked in split 4 because this split is the first one to which the call is 
requeued after the 
route-to digits (or messaging sp lit) command is 
executed.
Evaluating Split Performance
By using the information presented to this point, along with the information from 
various reports (as discussed in the next section), the sp lit supervisor can 
answer one or more questions concerning split performance and then make 
adjustments, if necessary. Here are some of the questions the supervisor can 
answer:
1. How many ACD calls offered to my split were ‘‘mine’’ (that is, were offered 
to this split as the primary split)?
NOTE:
Split ‘‘ACD  calls’’ include Direct Agent Calls for BCMS and for R2 
CMS, but not for R3 CMS, which tracks Direct Ag ent Calls 
separately.
Table F-8. Tracking for Call Answered after Route to Split
Split Tracking
1234
R3 CMS outflow d equeue dequeue answer
BCMS outflow answer
R2 CMS outflow outflow outflow inflow
answer 
						

							BCMS/CMS Tracking in a Call Vectoring Environment
Issue  4 September 1995
F-13
2. How many ACD calls d i d ‘‘my’’ split answer that were ‘‘mine?’’ (An d, by 
implication, how many did I answer that were not ‘‘mine?’’)
3. How many of ‘‘my’’ ACD calls d id ‘‘my’’ split not answer?
4. How many ACD calls that I didn’t answer weren’t ‘‘mine?’’
The following sections present the answers to these q uestions from the 
perspective of R3 CMS, BCMS, and R2 CMS.
R3 CMS Standard. The following answers reflect the use of R3 CMS:
1. The number of calls offered to ‘‘my’’ (primary) sp lit that were ‘‘mine’’ can 
be d etermined via examination of the CMS Split Summary Report.  The 
algorithm is as follows: CALLSOFFERRED - INFLOWCALLS - 
DEQ UEUE CALLS (that is, the total number of calls offered 
minus the 
number of calls not ‘‘mine’’ that I answered 
minus the number of calls not 
‘‘mine’’ that I didn’t answer.)
2. The number of calls that my split answered that were ‘‘mine’’ can be 
determined via examination of the CMS Split Summary Report. The 
algorithm is as follows:  ACDCALLS - INFLOWCALLS (that is, the total 
number of calls I answered 
minus the numb er of calls not ‘‘mine’’ that I 
answered.)
3. The numb er of ‘‘my’’ c alls that ‘‘my’’ split didn’t answer can b e determined 
via examination of the CMS VDN Re port.  The algorithm is as follows:  
ABNCALLS +  BUSYCALLS +  DISCCALLS +  OUTFLOWCALLS (that is, the 
number of abandoned calls 
p lus the number of busy calls plus the number 
of disconnected calls 
p lus the numb er of calls outflowed from ‘‘my’’ split 
tagged as a primary split).
4. The number of calls not ‘‘mine’’ that ‘‘my’’ split didn’t answer is 
DEQ UEUE CALLS, which is indicated in the CMS Split Summary Report.
BCMS Standard. The following answers reflect the use of BCMS:
1. The number of calls offered to ‘‘my’’ split that were ‘‘mine’’ can be 
determined via examination of the BCMS Split Report.  The algorithm is as 
follows:  ACDCALLS +  ABNCALLS +  OUTF LOW CA LLS  - INF LOW CA LLS  
(that is, the total number of calls answered 
plus the total number of calls 
abandoned from ‘‘my’’ sp lit ta gg e d as a primary split 
p lus the number of 
calls that outflowed ‘‘my’’ split tag g ed as a p rimary split 
minus the number 
of calls answered that were not directed to ‘‘my’’ split tagged as a primary 
split).
2. The number of calls that ‘‘my’’ split answered that were ‘‘mine’’ can be 
determined via examination of the BCMS Split Report. The algorithm is as 
follows:  ACDCALLS - INFLOWCALLS (that is, the total number of calls I 
answered 
minus the number of calls not ‘‘mine’’ that I answered).
The other two questions cannot be answered because BCMS does not have a 
dequeue tracking item. 
						

							Interactions Between Call Vectoring/EAS and 
BCMS/CMS
F-14Issue  4 September 1995 
R2 CMS Standard. Customers using R2 CMS c onnected to G1/G3 with vectoring 
enabled cannot 
necessarily answer any of the q uestions. If multiple-s plit queuing 
is involved, the OUTFLOWCALLS track contains both ‘‘my’’ calls and other sp lits’ 
calls that outflowed.   As a result, the answers to questions 1, 3 and 4 cannot be 
calculated. Also, question 2 cannot be answered because there is no track for 
the numb er of calls coming from elsewhere that ‘‘my’’ sp lit actually answered.
Using BCMS/CMS Reports to Evaluate
Call Vectoring Activity
There exists a number of CMS and BCMS reports that allow the customer to 
evaluate various facets of Call Vectoring activity. Some of these facets include 
the call flows present within Call Vectoring as well as the speeds at which calls 
are answered.  The sections that follow identify and discuss the CMS and BCMS 
reports that indicate this activity.
CMS Reports
CMS has real-time and historical reports.  Most CMS historical reports are 
available in four versions:  intra-hour, d aily, weekday, and monthly.  The following 
list identifies and describes several CMS reports that summarize Call Vectoring 
activity. For further details on these and other relate d reports, refer to the 
3B Call 
Management System Administration
 585-215-511.
NOTE:
The reports described in this section are generated in R3 CMS.  
Corresponding R2  CMS reports may not provide information that reflects 
capabilities that are new to the DEFINITY Switch (for example, 
internal/external call tracking).
nSplit Summary Report summarizes the call activity for an entire split.  
Among other information, the report provides the total number of flow ins 
(inflows), flow outs (outflows), dequeues, and abandoned calls.
The report also indicates the 
average speed of answer (interval ASA) for 
calls.  This refers to the sum of the queue time and ring time for a call 
within the answering split 
only. Finally, the report indicates the dequeued 
average q ueue time
, which is the average time a call waits until it is 
answered by another split to which the call is also queued.
nVDN Report summarizes VDN activity for specific vectors.  Among other 
information, the report provides the numb er of VDN Flow Ins/Outs, calls 
forced busy, and calls forced disconnect.  
VDN Flow In p ertains to calls 
that flow into a vector from another vector via a 
route to command.  VDN 
Flow Out
 pertains to calls that successfully flow out of vector to another 
VDN or external location via a 
route to command.