Call Center Reporting PDF

Document Name: Call Center Reporting
Document Category: ACD

Document Number: R.100
Issue: 1.06
Date: October 8, 1999
Author: TGCCR
Security: ECTF Proprietary
PROPRIETARY INFORMATION: The information contained in this document is the

property of ECTF. Except as specifically authorized in writing by ECTF, the holder of this
document shall keep all information contained herein confidential and shall protect same in
whole or in part from disclosure and dissemination to all third parties.
R.100 Copyright Notice ECTF Proprietary
ECTF Call Center Reporting ACD
Copyright Notice
 1997-1999, Enterprise Computer Telephony Forum.
This document is copyrighted and all rights are reserved by the Enterprise Computer
Telephony Forum (ECTF).
Page ii
R.100 Revision History ECTF Proprietary
Revision History
Issue Date Author Description Of Changes
Number
0.01 June 23, 1997 Roger Huffadine
0.02 Roger Huffadine
0.04 September, 1998 Berny MacLeod
0.05 January, 1999 Berny MacLeod
0.06 February 15, 1999 Chuan Chee Minor edits for TGCCR committee vote.
1.00 February 16, 1999 Chuan Chee Minor edits for ECTF straw vote.
1.01 June 28, 1999 Judi Brodil Made spelling consistent with US English.
Corrected some grammar.
1.02 July 1, 1999 Chuan Chee Reformatted document.
1.03 September 2, 1999 Chuan Chee More changes based on Straw Vote
feedback.
1.04 September 23, 1999 Berny MacLeod More changes based on Straw Vote
feedback. Submitted to ECTF for October
1999 meeting.
1.05 September 27, 1999 Chuan Chee Minor editorial changes. Included change
bars for Issue 1.04 and 1.05. Issued to
ECTF as an errata.
1.06 October 8, 1999 Chuan Chee Minor editorial changes. Issue 1.04 and
1.05 change bars removed. New change
bars used.
Page iii
R.100 Table of Contents ECTF Proprietary
Table of Contents
COPYRIGHT NOTICE ....................................................................................................................... II
REVISION HISTORY....................................................................................................................... III
TABLE OF CONTENTS.....................................................................................................................IV
1 INTRODUCTION ......................................................................................................................1-1
1.1 OVERVIEW .......................................................................................................................1-1
1.1.1 Mission Statement ....................................................................................................1-1
1.1.2 Scope ........................................................................................................................1-1
1.1.3 Method .....................................................................................................................1-2
1.2 SUMMARY ........................................................................................................................1-3
1.2.1 Call Center Reporting Terminology.........................................................................1-3
1.2.2 Call Center Models...................................................................................................1-3
1.2.3 Events .......................................................................................................................1-3
1.2.4 Scenarios ..................................................................................................................1-4
1.2.5 State Transition Table ..............................................................................................1-4
1.2.6 Clock Synchronization .............................................................................................1-4
1.2.7 Call Record...............................................................................................................1-4
1.2.8 Threads .....................................................................................................................1-4
1.2.9 Thread Record ..........................................................................................................1-4
1.2.10 Typical ACD Area of Visibility Call Scenarios.......................................................1-4
1.2.11 Counters and Timers for Reporting..........................................................................1-4
1.3 CONFORMANCE ................................................................................................................1-5
1.4 PHASING ..........................................................................................................................1-5
2 CALL CENTER REPORTING TERMINOLOGY .........................................................................2-1
Page iv
2.1 OVERVIEW .......................................................................................................................2-1
2.2 DEFINITIONS AND STATISTICS ..........................................................................................2-2
3 CALL CENTER MODELS.........................................................................................................3-1

3.1 TRADITIONAL CALL CENTER MODEL...............................................................................3-1
3.2 GENERIC ACD MODEL ....................................................................................................3-2
3.3 DEFINITIONS FOR GENERIC ACD COMPONENTS ..............................................................3-3
4 EVENTS...................................................................................................................................4-1
5 SCENARIOS .............................................................................................................................5-1
5.1 OVERVIEW .......................................................................................................................5-1
5.2 SUCCESS MAKE CALL ......................................................................................................5-3
5.2.1 This Scenario is copied from ECMA TR 68 - (3.1 Successful Make Call) .............5-3
5.2.2 Call Scenario - successful make call ........................................................................5-5
5.3 SUCCESSFUL CONSULTATION CALL .................................................................................5-7
5.3.1 This Scenario is copied from ECMA TR 68 - (6.1 Successful Consultation Call)..5-7
5.3.2 Call Scenario - successful consultation call .............................................................5-9
5.4 SUCCESSFUL CONFERENCE CALL...................................................................................5-12
5.4.1 This Scenario is copied from ECMA TR 68 - (9.1 Conference Call Service).......5-12
5.4.2 Call scenario - successful conference call..............................................................5-14
5.5 INCOMING CALL WITH NO AGENTS ................................................................................5-15
5.5.1 This Scenario is copied from ECMA TR 68 - (14.2 Incoming call to ACD with no
available agents).................................................................................................................5-15
5.5.2 Call scenario - incoming call with no available agents..........................................5-18
5.6 MAKE PREDICTIVE CALL ON ESTABLISHED ...................................................................5-21
6 STATE TRANSITION TABLE ...................................................................................................6-1
7 CLOCK SYNCHRONIZATION ...................................................................................................7-1
Page v
8 CALL RECORD .......................................................................................................................8-1

8.1 OVERVIEW .......................................................................................................................8-1
8.2 CALL RECORD (SEGMENTED) ..........................................................................................8-2
8.2.1 Call Segment Header................................................................................................8-2
8.2.2 Call Segment ............................................................................................................8-3
8.3 CALL RECORD (FIXED) ....................................................................................................8-3
8.3.1 Usage Note ...............................................................................................................8-5
9 THREADS ................................................................................................................................9-1
9.1 OVERVIEW .......................................................................................................................9-1
9.2 DESCRIPTION OF THE ATTACHED DATA SCHEMA ..............................................................9-1
10 THREAD RECORD.................................................................................................................10-1
10.1 RECORD STRUCTURE .....................................................................................................10-1
10.2 USAGE RULES.................................................................................................................10-2
11 TYPICAL ACD AREA OF VISIBILITY CALL SCENARIOS .....................................................11-1

11.1 OVERALL .......................................................................................................................11-1
11.2 SCENARIOS ....................................................................................................................11-1
12 COUNTERS FOR REPORTING................................................................................................12-1
13 TIMERS FOR REPORTING .....................................................................................................13-1
Page vi
R.100 Introduction ECTF Proprietary
1 Introduction
1.1 Overview
In January 1997, the Task Group for Call Center Reporting (TGCCR) held its first
meeting within ECTF.
1.1.1 Mission Statement
Simplify the collection and reporting of data within the call center environment through
standardization.
1.1.1.1 Goals
The proliferation of devices that participate in a call has resulted in the fragmentation of
call data such that data on segments of a single call may be stored in several entities
within a Call Center.
Businesses are increasingly driven by statistical data and the inability to correlate data for
a single call from separate entities is a business inhibitor.
This paper addresses a group of techniques that when applied, will consistently permit the
consolidation and correlation of data within the Call Center environment.
The following represent the goals of the R.100 document:
• define a common terminology for elements within the call center environment, having
detail and granularity that uniquely and comprehensively differentiates them
• define minimum data sets that shall be available from Call Center functions
• define a common tracking method from call initiation to conclusion regardless of the
number of segments
• eliminate multiple counting
• define method for clock synchronization to ensure time stamp consistency
• define data structures
1.1.2 Scope
R100 addresses the area of Call Centers that has the most pre-existing specifications, as
this ensures a well-defined and solid basis for the derived terminology.
Page 1-1
The work of the group has focused on the ACD. The ACD has modeling and standards,
which has been used as a foundation to build upon.
In producing this document, considerable effort was expended to ensure that the
modeling would survive when considering current and future call transports and
Computer Telephony implementation.
This model is applicable in environments that implement some or all of the following:
• Intelligent Networks
• Customer Premise Equipment
• Virtual Call Centers
• Networked Call Centers
• Circuit Switched networks
• IP networks
• Computer Telephony Integration

using, for example: ECTF C.001, TAPI, TSAPI, JTAPI, and ECMA CSTA.
• Multimedia transports, systems, and calls
1.1.3 Method
Call scenarios1 and flows2 from ECMA and Versit have been examined and converted
from device-oriented to call-oriented tables. Each event in the scenarios was examined
for timers and counters that should be started/stopped or incremented/decrement at this
stage of the call.
The data associated with each timer and counter has been named and defined.
Higher levels of definition have been derived from the granular data associated with each
event. Examples of these high level definitions include Call Duration and Service Level.
1
Scenarios for Computer Supported Telecommunications Applications (CSTA) Phase II, ECMA Technical Report
TR/68, 1994.
2
versit Computer Telephony Integration (CTI) Encyclopedia Volume 4: Call Flow Scenarios, Revision 1.0, October
1996.
Page 1-2
It is useful to understand the structure of this document in a graphical manner. The

following diagram displays how the application of call scenarios to a transition matrix,
ultimately result in high level definitions, such as Average Call Duration.
High level definitions such as

Structure of R.100 data abstraction Wait and Service Level
Call Scenarios Single type definitions such as

from CSTA Calls Abandoned
and Versit
Threads
comprising of Call Records
Applied to
Call Records
comprising of Call Segments
State Transition
Table Call Segments
Produces data for
Single instances of
state transitions
1.2 Summary
1.2.1 Call Center Reporting Terminology
This section defines the terminology of R.100.
1.2.2 Call Center Models
This section describes the traditional Call Center model and defines the generic model
that R.100 utilizes.
1.2.3 Events
Events are generated to describe the change of state within a call. This section describes
the use of event within R.100.
Page 1-3
1.2.4 Scenarios
This section includes the R.100 call-oriented scenarios derived from the CSTA device-
oriented scenarios.
1.2.5 State Transition Table
This table describes the timers and counters which are generated at each state transition
and is core to the R.100 models.
1.2.6 Clock Synchronization
As Functions (see “Call Center Reporting Terminology”) may reside in different time
zones, or even keep a local clock, a method of synchronizing time is important. R.100
uses UTC.
1.2.7 Call Record
In order to provide the granularity of data required within reporting, a call record
structure has been defined. This section describes the Call Record (Segmented) with Call
Segments and a fixed-length Call Record.
1.2.8 Threads
It is important within Call Center reporting that a call can be tracked from Cradle to
Grave across Functions. The concept of a Thread is introduced.
1.2.9 Thread Record
This section describes the structure of the Thread Record.
1.2.10 Typical ACD Area of Visibility Call Scenarios
R.100 uses the concept of an Area of Visibility rather than just an ACD, IVR etc. It
describes the scope for Call Center reporting.
This section describes typical call scenarios.
1.2.11 Counters and Timers for Reporting
This section shows the calculations for deriving the Counts and Timers from the Call
Record information.
Page 1-4
1.3 Conformance
In order to conform, an application may use some or all of the terms and definitions
described within R.100. Where only some terms are used, all of the component parts
within the term shall also use the definitions as described.
An application that conforms to R.100 shall use the terminology of R.100 only where the
application explicitly complies with the meanings, values and methods contained within
R.100.
Where a company conforms in all respects except in using aliases for words in R.100
(e.g. Held in Queue rather than Delayed) the company shall include a translation table
which explicitly indicates the ECTF acceptable definition and formulas for the user(s).
Where the application deviates from R.100, it shall use a different terminology not
described within R.100. The application documentation shall explicitly indicate those
areas where the application deviates from R.100.
1.4 Phasing
Additional task group work is planned to cover the following phases:
• ACD / Agent Modeling
• IVR
• Multimedia
• Dialers
• Workforce Management
• Messaging
• Accounting and Billing
• Enterprise Data
Page 1-5
R.100 Call Center Reporting Terminology ECTF Proprietary
2 Call Center Reporting Terminology

2.1 Overview
The scope of this section covers definitions and statistics for the ACD only.
The following convention has been used:
Bold Text denotes an item that is defined within the glossary. If the item is referred to within
a description, you will find the item defined in its own right within the glossary.
@MP Shorthand expression used within this document to denote that the value is
calculated at the Monitoring Point.
Where a calculation appears, or is described, it should be taken as read, that the result shall be
calculated within the Reporting Period.
Where an activity spans the boundary of a Reporting Interval, the data shall be collected at the
end of the activity but will appear in the report, in the Reporting Interval in which the activity
started.
Page 2-1
2.2 Definitions and Statistics
A
Abandoned The caller Disconnects while in any of the following base call states:
Received/Delivered, Delayed, or Distributed.
Callers who Disconnect from the Connected state are counted as

Completed calls.
Callers who Disconnect from the Suspended state are counted as

Disconnected Suspended calls.
Abandoned Calls The number of calls Abandoned.
tcAbandoned @MP
Abandoned Calls This is the number of calls which were Abandoned by callers during
After or after receiving an Announcement (Non-Interactive or
Announcement Interactive).
Abandoned Calls This is the number of calls which were Abandoned by callers prior
Before to receiving an Announcement (Non-Interactive or Interactive).
Announcement
Abandoned This is the Wait Duration of all Abandoned calls.

Duration
ttAbandoned @MP
Abandoned During This is the number of calls that were terminated by callers, where the
Suspended Calls calls were answered by an Agent, but currently in a Suspended call
state.
Abandoned During Calls that were terminated by callers while in the Distributed call
Distributed state.
Abandoned During Calls that were terminated by callers while in the Delayed call state.
Delayed
Abandoned This is the total number of calls that were Abandoned while in the
During Delayed Delayed state.
Calls
tcAbandonedDuringDelayed @MP
Page 2-2
Abandoned This is the total duration of calls that were Abandoned while in the
During Delayed Delayed state. A call may enter multiple Delayed states (via the
Duration Diverted state); in this case, the total duration only consists of
durations within the Delayed states (does not include durations within
the Distributed or Diverted states).
ttAbandonedDuringDelayed @MP
Abandoned This is the total number of calls that were Abandoned while in the
During Distributed state.
Distributed Calls
tcAbandonedDuringDistributed @MP
Abandoned This is the total duration of calls that were Abandoned while in the
During Distributed state. A call may enter multiple Distributed states (via
Distributed the Diverted state); in this case, the total duration only consists of
Duration durations within the Distributed states (does not include durations
within the Delayed or Diverted states).
ttAbandonedDuringDistributed @MP
ACD Automatic Call Distributor.
ACD Call A call becomes an ACD Call the moment it enters an ACD Entry
Point and remains an ACD Call until the call completes.
ACD Entry Point The point at which the ACD or assumes control of the call routing.
The generic term for Application, Vector, ACD Group, etc.
Where CTI is employed, the CTI Application passes the call to an

ACD Entry Point.
ACD Exit Point Denotes an application, which makes outgoing calls on behalf of
agents (Predictive and Preview Dialers).
Agent A person or device whose primary function is to process calls.
For additional information refer to ECMA TR/72 on Agent and User.
Page 2-3
Agent (ACD) Denotes an Agent that is logged onto the ACD
Agent (NonACD) Denotes an Agent that is logged onto the ACD and using the
NonACD function of the Agent set.
Agent ID The information entered by an Agent, which puts them into the
Logged On state.
Alerting A call state in which an attempt is made to connect a call to a device

eg Ringing. For additional information refer to ECMA TR/72 on
Alerting, Alerting Call and Alerting Connection state.
Announcement Multimedia messages (Recorded Announcers, music, information,

Non-Interactive and radio) that are provided to callers. Callers cannot interact with
Announcement these types of messages.
Usage Note
Case 1. The Agent cannot make or receive any new calls while this
activity is happening. Within reporting, this time will be attributed to
the agent as Connected Time.Case 2. If the caller cannot go back to
the agent, like in Directory Service, then the call will be treated as
though it has been transferred to the device. The Agent will become
Available and the Connected Timer will stop.
Announcement Multimedia messages (Recorded Announcers, music, information,

Interactive and radio) that are provided to callers. Callers can interact with these
Announcement types of messages.
See the Usage Note in Announce Non Interactive Announcement.
ANI Automatic Number Identification.
API Application Programming Interface.
Area of Visibility The scope for call center reporting. Any calls crossing the boundary
are considered external to the area of visibility, either incoming or
outgoing. Any calls originating and terminating within the area of
visibility are considered as internal. For reporting purposes this may
consist of a single customer premise ACD, multiple ACD nodes at
different locations and/or ACD within the Network. This definition
also includes any other ACD functions related to call routing
including IVR and skill based routing, etc. The area of visibility may
consist of one or more Application Domains as defined by ECMA
TR/72.
Page 2-4
Automatic Call Distributes incoming calls to agents in some logical pattern based
Distributor upon predetermined instructions.
Automatic A service provided by the network that provides the billing directory
Number number associated with a calling device. The number provided by
Identification ANI will not always be the same as the number of the calling device.
Outside of North America, this service is called Calling Line Identity
(CLI).
Average <type> ttConnected<type><direction> + ttSuspended<type><direction>

<direction> tcConnected<type><direction>
Handled Duration
Average This is the average duration of calls that were Abandoned while in
Abandoned the Delayed state.
During Delayed
Duration Total Abandoned During Delayed Duration
Total Abandoned During Delayed Calls
Average Delayed This is the average Delayed duration of Received calls.

Duration
Total Delayed Duration
Total Delayed Calls
Average This is the average Delayed duration of Connected calls that entered
Connected the Delayed state.
Delayed Call
Delayed Duration Total Delayed Connected Delayed Duration
Total Connected Delayed Calls
Average This is the average Distributed duration of Distributed calls.

Distributed
Duration Distributed Duration
Distributed Calls
Average This is the average duration a call was Distributed before callers
Abandoned Abandoned.
During
Distributed Total Abandoned During Distributed Duration
Duration Total Abandoned During Distributed Calls
Average This is the average Distribution duration of Connected calls.

Connected Call
Distributed Connected Call Distributed Duration
Duration Connected Calls
Page 2-5
Average Wait This is the average Wait Duration of Received calls. This only
Duration applies to incoming and internal calls.
Wait Duration
Received Calls
Average This is the average Wait Duration of all calls that Abandoned.
Abandoned Call
Wait Duration Abandoned Duration
Abandoned Calls
Average This is the average Wait Duration of all calls that Connected.
Connected Call
Wait Duration Connected Call Wait Duration
Connected Calls
Page 2-6
B
Business Data A pointer to Corporate data associated with this Thread Record. The
content of the Business Data is not defined within this document.
Page 2-7
C
Call A switching function communications relationship (generally)
between two or more devices. During some circumstances, including
set-up and release, there may be only one device. A thing that happens
between two or more parties. Commonly referred to as a hangover.
Call Record A record containing data fields about a single Call. There are two
types of Call Records for reporting purposes; Segmented and Fixed.
Note: This is not synonymous with ECMA TR/72 Call Detail Record
Call Record - Fixed call record. This record has fields calculated from the
Fixed segmented call record. This record exists (i.e., accessible by other
applications) once the call finishes (i.e., terminates at the Null call
state).
Call Record - Segmented call record. This record has fields populated from CSTA
Segmented events. This record exists when a call starts. It consists of a header
record and one or more call segments. Each call segment record is
created at the termination of each call state.
Call ID A Call ID is a numeric reference associated with a call. The ID relates

to the single call record segment within a Call Record or Thread
Record. For additional information, refer to ECMA TR/72 on Call
Identifier.
Call Related Information collected from the caller- may be more than one piece of
Information information;e.g., account #, language preference, etc. Typically this
information is used for routing and CTI purposes. Refer to ECMA
TR/72.
TGCCR recognizes there are limitations with this information as an

incorrect entry (by the caller) may be corrected by the Agent directly
into the Business Data Application. In this case the uncorrected entry
will be stored within the historical Call Record.
Call State A description of the status of a call. During the lifetime of a call, it
can have many call states, but only one at a time. The status of a call
is independent of the status of any devices involved in this call.
Call States are of two types:
Base call states represent the state of the call at a given point: null,
pending, originated, received, delayed, diverted, distributed,
Page 2-8
connected, suspended, transferred, conferenced. These are used to

generate durations for reporting
The movement between two base call states generates Transitional

call states which provide counts for reporting: idle, originated,
received, delayed, diverted, distributed, suspended, transferred,
conferenced, initiated, aborted, abandoned, disconnected suspended,
completed, connected.
Calling Line See ANI.

Identity
(Identification?)
CLI
Completed Calls Calls which have been connected and then finished (a finished call is
classed as a call where one party has disconnected at this Monitoring
Point).
For example: A call for a particular DN is answered by an agent and

then transferred to another agent. Completed Call Count is
incremented once for the DN and once for each agent.
tcCompleted @MP
Conduit A call transport device providing connectivity with one or more end
points. The industry refers to these as trunks, timeslots, frames, and
channels.
Conduit ID A numeric reference associated with a Conduit.
Conference Call A call consisting of three or more connected devices.
Connected A call is accepted at the terminating device.
Note: ECMA connection state refers to devices. Definitions are call

related.
Connected Call A call which has entered the Connected state.
Connected Calls The number of calls that entered the Connected state.
tcConnected @MP
Connected Call This is the Wait Duration of all Connected calls.

Wait Duration
ttWaitConnected @MP
Page 2-9
Connected This is the total number of Connected Delayed Calls.

Delayed Calls
tcConnectedDelayed @MP
Connected This is the total Delayed duration of Connected Delayed Calls.

Delayed Call
Delayed Duration ttDelayedConnectedDelayed @MP
Connected Call This is the total Distribution duration of Connected calls. This
Distributed provides a statistic for the Agent Area of Visibility. A call may enter
Duration multiple Distributed states (via the Diverted state); in this case, the
total duration only consists of durations within the Distributed states
(does not include durations within the Delayed or Diverted states).
ttDistributedConnected @MP
Connected Calls The number of all calls that were Connected prior to the Wait
Before Wait Threshold.
Threshold
tcConnectedBeforeWaitThreshold
Connected A Connected Call that entered the Delayed state.

Delayed Call
Connected Not A Connected Call that did not enter the Delayed state.
Delayed Call
Connected Point In some systems, calls are brought to the Agent and in others, the
Agent is brought to the call. The Connected Point represents that
meeting point A logical set of agents with a common identifier. The
identifier represents this set of agents and may be a group number or
a particular skill set. The Connected Point may exist with zero agents.
CTI Computer Telephony Integration.
CTI is generally an Application that ties various call center and

business functions together. CTI may also provide a source of routing
(see Source and Destination Routing).
Cradle to Grave This is a concept that allows users to track a thread and all its
Reporting associated calls. Reporting starts at the first Area of Visibility
(inception of the thread).
A thread may not be completed at the time of the report request. The
report indicates that the thread is still active.
Page 2-10
D
Delayed Delay Logic is applied to the call.
Delay Logic There are two types of delays, Discretionary and Availability.
Discretionary delay is that which has been deliberately introduced

into the call. This is often a pre-recorded announcement which may
be programmed as follows: “All calls to this call center are being
monitored for quality purposes”.
Availability delay is usually caused because agents are not

immediately available to answer the call and the call waits.
See Routing Logic.
Delayed Call A call that entered the Delayed call state.
Delayed Calls The number of all calls that entered the Delayed call state.
tcDelayed @MP
Delayed Duration This is the Delayed duration of all Delayed calls.
ttDelayed @MP
Disconnected This is the total number of calls that were Disconnected while in the
Suspended Calls Suspended state.
tcDisconnectedSuspended @MP
Device A physical (e.g., buttons, lines, trunks, stations) or logical (e.g.,

groups of physical devices, pilot numbers, ACD groups) entity that is
used to access telecommunications services.
Device ID Within Call Center reporting this is a numeric reference associated

with a single Device.
Directionality All calls have directionality. It is one of incoming, outgoing, internal

to the Area of Visibility.
Directory Number Is an example of an Identity.
Disconnected An action that causes the termination of the call.
Page 2-11
Distributed call A call is presented to the terminating device.

state
Distributed Call A call that entered the Distributed call state.
Distributed Calls The number of all calls that entered the Distributed call state.
tcDistributed @MP
Distributed This is the Distributed duration of all Distributed calls.

Duration
ttDistributed @MP
Diverted A call has been redirected and is no longer present at the device.
Usage Note: Time Diverted is always 0 seconds.
DN Directory Number.
DNIS Dialed Number Identification Service. A service that provides

information about the number that was dialed.
DNIS ID The number that was dialed via DNIS.
Page 2-12
E
Event A transition between two CSTA call states. CSTA compliant
systems use messages to indicate an event has taken place.
Exceptions User definable areas for reporting which are outside the acceptable
range.
Page 2-13
F
FTE Agents Full Time Equivalent Agents. Equivalent number of agents
working full time during a reporting period. Agents may only be
Logged On for part of the reporting period. The Logged On time is
equivalent to a partial agent working during the reporting period.
Total Logged On Time of Agents @ MP within the Reporting Period

Reporting Period
For example:
Within a 30-minute reporting period 4 Agents log on; one for 15

minutes, 2 for 24 minutes and one is logged on for the whole
reporting period.
1 x 15 = 15 = 0.5 Agent )
1 x 24 = 24 = 0.8 Agent )
1 x 24 = 24 = 0.8 Agent ) so, 85 = 2.8 FTE (and not 4)
1 x 30 = 30 = 1.0 Agent ) 30
85
Function A single call processing entity within a call center. These are call
center hardware and software applications. E.g. ACD, IVR, CTI
Applications and Predictive Dialers. This Function ID consists of
application and hardware IDs that will provide the tracking of calls
via the Thread Record, across the different “functions”.
Page 2-14
Page 2-15
Page 2-16
I
ID Identifier (Identification)
Identification A number that can be associated with an object within the call
Center. The association for the number does not have to be unique
within the call Center, for example Agent 007, Trunk 007, The
number shall be unique within the class of objects (i.e. two Agent
007 cannot exist concurrently - unless they are a double agent).
Not to be confused with Identity.
Identity A unique entity that can be the source or destination of a call. For
example; DN, IP address, URL, Portable Number, Personal
Number. Not to be confused with Identification or ID.
Idle A call state in which there is no relation between the call and a
device i.e. the call does not exist.
Incoming Call A call originating outside and entering the Area of Visibility.
Internal Call A call that originates and terminates within the Area of Visibility.
Initiated A call state in which there is a single device associated with the
call, the device goes off hook.
ISDN Integrated Services Digital Network.
Interactive Voice A call center function which allows interaction between it and the
Response caller usually via DTMF tones. Tones are initiated by the caller to
select menu items for input of say, bank account number, or a
choice of routing within the call center to agents with a particular
skill. An IVR may be set up as Agent.
Synonymous with VRU (Voice Response Unit) and ARU (Audio

Response Unit).
IVR See Interactive Voice Response.
Page 2-17
Page 2-18
Page 2-19
Page 2-20
M
Monitoring Point A call can involve one or more physical or logical entities within a
Call Center. Statistics can be measured at each of these entities. For
the purposes of reporting, these are called Monitoring Points.
Usage Note:
Statistics at any monitoring point are not generally the same as the
equivalent statistics at any other monitoring point; for example,
Completed Calls at the ACD Entry Point and Completed Calls at
the Agent Group.
Multimedia In the context of this document multimedia means

a) as defined in the PC world
b) as having single or multiple media content (voice or video
etc)
Page 2-21
N
No Delay ACD calls routed directly to an Agent position without
encountering Delay Logic.
NonACD A call made or received by an Agent who is logged on to the ACD,

but does not use any of the ACD Routing Logic.
Page 2-22
O
Originated A call state which indicates that input activity is complete.
Outgoing Call A call originating within and leaving the Area of Visibility.
Overflowed In Received Calls that originated at another ACD Entry Point and
have subsequently been Diverted to this ACD Entry Point for
service.
Calls will be pegged as Received calls at the originating ACD

Entry Point within the Area of Visibility.
Overflowed Out Received Calls for this ACD Entry Point which were Diverted to
another ACD Entry Point for service.
Page 2-23
P
Pending A Call State where the Agent is entering a Directory Number.
Personal Greeting A device which provides passive messages, music or both to callers
once they have been routed to an Agent. Time in Personal Greeting
shall be considered as part of the Connected state.
Predictive Call A Call made on behalf of an Agent by the Predictive Dialer.
Predictive Dialer The predictive dialer uses an algorithm to predict which agents will
be free to take calls made on their behalf. The predictive dialer also
decides whether to place calls to the agent. This predictive dialer
may be part of the same or a separate Area of Visibility.
Preview Call Usually an application which presents the Agent with a prospect’s
account information and/or phone number that appear on the screen
before the call is made. The Agent typically reviews the account
information and if the agent wants to make the call, hits a key and
the computer dials the number.
Progressive Call Slightly more automated than preview dialing. Once an agent
becomes available/free, a call is launched on their behalf but the
customer data is not displayed until after the number is dialed,
giving the agent less time to review the screen and even less time
between calls.
Page 2-24
Page 2-25
R
Received A call is being presented providing the opportunity to accept,
deflect, reject or issue other services.
Received Calls The number of all calls that entered the Received call state.
Reporting Period The time span to which the data in the report applies e.g. 0900-
1400, Monday-Friday, Jan-Aug or Jan to Aug for Mondays only.
Reporting Interval The time interval e.g. 0900-0930, 0900-0917 to which this
row/column of data applies.
Routing Logic That part of an ACD that makes routing decisions that optimize the
call progress through the ACD based on pre-determined rules.
These rules may range from simple overflow parameters to
complex neural networks. Routing Logic comprises of two parts:
Delay Logic
There are two types of delay, Discretionary and Availability.
Discretionary delay is that which has been deliberately introduced
into the call. This is often a pre-recorded announcement which may
be programmed as follows: “all calls to this call center may be
monitored for quality purposes”.
Availability delay is usually caused because agents are not
immediately available to answer the call and the call waits.
Distribution
That part of the routing logic that delivers the call to the agent.
Page 2-26
S
Service Level Service Level is a Call Center measure of performance. TGCCR
recognizes that many variations of Service Level calculation are in
common usage.
TGCCR discussed this at great length and have derived the following
formula for a Universal Service Level calculation.
(Connected Calls Before Wait Threshold + Abandoned Calls Before X Threshold) x 100%
(Connected Calls + Abandoned Calls - Abandoned Calls Before Y Threshold)
The Thresholds are User defined within a Call Center Reporting

Application. The actual values may be recommended by regulatory bodies
depending on the industry sector of the Call Center. Setting the Thresholds
to different values provides the four main industry recognized variants, of
the Service Level calculation.
Variant 1
Connected Calls Before Wait Threshold x 100%

Connected Calls + Abandoned Calls
Set the Thresholds as follows:

Connected Before Wait Threshold to Value
Abandoned Calls Before X Threshold to Zero
Abandoned Calls Before Y Threshold to Zero
Variant 2
(Connected Calls Before Wait Threshold + Abandoned Calls Before X Threshold) x 100%
Connected Calls + Abandoned Calls

Abandoned Calls Before X Threshold to Value
Variant 3
Connected Calls Before Wait Threshold

(Connected Calls + Abandoned Calls - Abandoned Calls Before Y Threshold)

Page 2-27
Abandoned Calls Before Y Threshold to Value
Variant 4
Connected Calls Before Wait Threshold

Connected Calls

Abandoned Calls Before Y Threshold to Maximum
Examples of Variants
The different variants of the calculation currently exist within the industry
and give different resulting Service Level %. Different industries define
what is acceptable to their sector.
If a call center had the following traffic:
#Connected + #Abandoned 1000 #Abandoned 300

#Connected 700 #Abandoned Before X Threshold 200
#Connected Before Wait Threshold 500 #Abandoned Before Y Threshold 100
Results:
Variant 1
Connected Calls Before Wait Threshold x 100% 500x100% 50%
Connected Calls + Abandoned Calls 1000
Using the Universal Service Level % calculation

(Connected Calls Before Wait Threshold + Abandoned Calls Before X Threshold) x 100% (500+0) x100% 50%
(Connected Calls + Abandoned Calls - Abandoned Calls Before Y Threshold) (1000-0)

Variant 2
(Connected Calls Before Wait Threshold + Abandoned Calls Before X Threshold) x 100% (500+200) x100% 70%
Page 2-28
Connected Calls + Abandoned Calls 1000
Using the Universal Service Level % calculation:

(Connected Calls Before Wait Threshold + Abandoned Calls Before X Threshold) x 100% (500+200)x100% 70%
Abandoned Calls Before X Threshold to Value
Variant 3
Connected Calls Before Wait Threshold x100% 500x100% 55%

Abandoned Calls Before Y Threshold to Value
Variant 4
Connected Calls Before Wait Threshold x100% 500x100% 71%
Connected Calls 700


Abandoned Calls Before Y Threshold to Maximum
Page 2-29
Source and Routing which usually takes place related to the ANI or DNIS.
Destination Routing
CTI Applications allow for much more complex routing (some
vendors refer to this as Post Dialed Routing) based on information
collected from the caller after they have entered the Network.
Routing may be based on ANI or DNIS however; more information

may be required from the Caller before the routing decision can be
made. This information may be Account Number or other digit
collection.
Where CTI routing is considered as a separate Area of Visibility to

the ACD a call is passed from the CTI Routing Logic to an ACD.
At the point of transfer from the CTI Routing into the ACD one
call terminates and a new call starts. The two calls are considered
separate but may be tracked via the Thread ID.
Where the CTI Routing is part of the Area of Visibility then the
routing is considered as Routing Logic (Delay Logic).
State See Call State.
Supervisor A person or device engaged in Supervisory activities. Agents are

normally monitored by a Supervisor (person) using a Device
(Supervisor Set) which has special properties.
Suspended call state A call state in which the device is inactively participating in a call.
This call state includes logical participation in a call while physical
participation is suspended.
Suspended Call A call that entered the Suspended call state.
Page 2-30
T
Thread A Thread has a Record that contains a globally unique identifier,
which is passed between any ECTF compliant Functions. Thread
Records allow reporting on all calls in a logical sequence. A Thread
ID will be generated at the first ECTF compliant Function and
propagated to any other ECTF compliant Function. As soon as a call
is passed to a non-ECTF compliant Function or via a non-ECTF
compliant Conduit the Thread Record is completed and a new Thread
generated at the next ECTF compliant Function.
Thread Records allow for Cradle to Grave reporting across ECTF

compliant Functions.
Threshold A user defined parameter. This is used within Call Center

Applications to determine levels of performance.
Threshold values are defined in seconds.
Total <type> This is the total Delayed duration of Received calls.

<direction>
Delayed Duration ttDelayed<type><direction>
Total <type>
<direction>
Handled Duration ttConnected<type><direction> + ttSuspended<type><direction>
Total <type> ttInitiated<type><direction> + ttOriginated<type><direction> +

<direction> Call ttReceived<type><direction>+ ttDelayed<type><direction> +
Duration ttDiverted<type><direction> + ttDistributed<type><direction> +
ttConnected<type><direction> + ttSuspended<type><direction> +
ttTransferred<type><direction> + ttConferenced<type><direction>
Transferred A call state in which a call is redirected from one place to another for
service. A transfer call may be redirected to another Agent, an ACD
Entry Point or outside of the Area of Visibility.
Transferred In The number of calls that have Transferred as the initial state.
Calls
tcTransferredIn @MP
Page 2-31
Transferred Out The number of calls that entered the Transferred state and were
Calls redirected by an Agent.
tcTransferredOut @MP
Trunk A particular instance of a Conduit, typically visible at the boundary

of the Area of Visibility.
Page 2-32
U
Usage % This is the percentage of time within a reporting interval that the
conduit(s) were being used.
(Total Wait Time + Total Connected Time + Total Suspended Time) x100%
Reporting Interval
Page 2-33
V
Virtual Delay Logic A method used for overflowing calls from a source point to another
destination within the ACD Area of Visibility.
Page 2-34
W
Wait A concept which describes a caller’s perspective of waiting for
connection to an agent within the call center. This only applies to
incoming and internal calls.
Wait is measured from Received until the Connected call state. In

order to measure Wait prior to Received (before the ACD Entry
Point) either expand the Area of Visibility to include those areas
requiring measurement or establish another area of visibility and
measure the wait via the Thread Record.
Wait Duration The total duration from Received state to Connected or Abandoned
state. This only applies to incoming and internal calls. A call could be
Delayed and Distributed more than once if it was Diverted.
Wait Duration This is the total Wait Duration of Received calls. This only applies
(timer) to incoming and internal calls.
ttWait @MP
Wait To This is the total Wait Duration of calls that Abandoned.

Abandoned
Duration ttWaitToAbandoned @MP
Wait To This is the total Wait Duration of calls that Connected.

Connected
Duration ttWaitToConnected @MP
Wait Threshold This is the amount of time that a Call Center has decided it is
acceptable for callers to wait prior to connection.
This Threshold is normally set within a Call Center Application (e.g.

MIS) and is normally used within the Service Level calculation.
Page 2-35
R.100 Call Center Models ECTF Proprietary
3 Call Center Models

3.1 Traditional Call Center Model
LAN
Fax Voice
Server Mail
Email
Gateway
HOST
Switch
Telephone
Network IVR
Predictive
Dialer
Terminal
Devices
File Server
Database
Page 3-1
3.2 Generic ACD Model
In the call center industry, many vendors use similar or different terminology for the same ACD features or functions. Also,
many vendors use the same terminology for different ACD features or functions. R.100 has defined a set of generic
terminology so that a common dialog can be achieved. To aid the transition, the following table shows how different vendors’
terminology map to the R.100 generic terminology.
R.100
Relationships Generic
one to many Term Aspect Ericsson Ericsson Lucent Nortel Nortel Nortel Rockwell GPT Siemens
many to one MD110 ACP 1000 Definity Meridian DMS 100 Symposium Spectrum Realitis BCS
Internal PSTN Private Net Source
Trunk Trunk Primary & Trunk Main

Conduit Routes Route Sup'y DNs Route Trunk
[note1] Group
Source & incoming incoming Srce&Dest
Destination digit digit based
routing conv conv routing
ACD entry Service Trunk Vector CDN ACD ACD RCG &
point Application Group Groups Directory ACD-DN Group CDN Application Queue Calendar
Number [note 2] routing
Routing Call Routing Overflow CCR Enhanced
Logic Control Table Pattern Vector ACD overflow / Application Telescript Overflows ART
Table Supergroup
Messaging Application
Queueing Delay Logic Script
Personal Qs
Information
collection Distribution Presented Presented
Connected Agent Agent Agent Agent ACD Agent Agent Agent

Point Group Group Group Group ACD DN Group Skillset Group Group Group
[note 2]
Agents Agent Agent Agent Agent Agent Agent Agent Agent Agent Agent
Monitor Split / Sub Supervisor/ Supervisor

Team Team Supervisors Group Skill Supervisor Group Skillset I-Group Group Team
[note 3]
[note 1] Trunks do not exist in CO ACD.

[note 2] The relationship between 'Call Queue' ACD Groups and 'Agent Group' ACD Groups in the DMS 100 is special.
[note 3] Supervisors can also be grouped into a 'special' Agent Group.
Page 3-2
3.3 Definitions for Generic ACD Components
Term Proposed Definition
Source The mechanism by which a calling party became associated with the ACD.
Conduit (Conduit Group) A call transport device providing connectivity with one or more end points. The industry refers to these
as trunks, timeslots, frames, and channels.
Source & Destination Routing based on either the Identity of the Calling Party [source based] or based on the number that
Routing was dialed [destination based]
ACD entry point An identified point in the equipment where a Public or Private [dialed] number translates and is
associated with the ACD. This is usually a form of Directory Number [DN] or the address of an
application.
Routing Logic That part of an ACD that makes routing decisions that optimize the call progress through an ACD
based on pre-determined rules. These rules may range from simple overflow parameters to complex
neural networks.
Delay Logic There are two types of delay:
• discretionary
• availability
discretionary delay is a delay that has been deliberately introduced into the call. This is often an
announcement which may say “all calls to this call center are monitored for quality control purposes”.
availability delay is usually caused because agents are not immediately available to answer the call
and the call waits.
Page 3-3
Distribution That part of the Routing Logic that delivers a call to an Agent.
Where ‘personal greeting’ is used, to save constant repetition of greetings by Agents, it shall be
counted as part of the Established Time.
Agent Group A collection of agents that share a common group identifier, as known by the ACD system.
Agent A person or device whose primary function is to process calls.
Team A secondary form of Agent Group where an additional common Identifier is shared by Agents that are
not necessarily in the same Agent Group
Page 3-4
R.100 Events ECTF Proprietary
4 Events
An event is a special kind of service in which no response is required by the requester.

Either the computing or switching domain may send events. They are sent to indicate the
completion of a service performed in multi-step mode, to report an external occurrence
(e.g., an incoming call, a phone going off-hook), or to report a change of status of a
domain or device.
The available call control models do not give a definitive indication of the directionality
of a call. Although t it is considered normal to have a-priori knowledge that permits an
application to indicate “Incoming” or “Outgoing” calls, the lack of definitive signaling
that form lower level protocols such as, SPIs and APIs, restrict some of the modeling
used in this document.
Separate definitions have been supplied for “incoming” and “outgoing” where a-priori
knowledge exists.
A listing of the events modeled in ECTF calls is contained in ECTF Call Control Model
C.0013.
3
ECTF Call Control Model C.001, June 1997.
Page 4-1
R.100 Scenarios ECTF Proprietary
5 Scenarios
5.1 Overview
The scenarios developed by ECMA are device-oriented. To arrive at data associated with
calls the following table is used.
Local Connection State Other Connection State CSTA Simple Call state
Alerting Connected Received

Alerting Held Received-On Hold
Connected Alerting Delivered
Connected Connected Established
Connected Failed Failed
Connected Held Established-On Hold
Connected Null Originated
Connected Queued Queued
Held Alerting Delivered-Held
Held Connected Established-Held
Held Failed Failed-Held
Held Queued Queued-Held
Initiated Null Pending
Null Null Null
This section uses the originating work of Call Scenarios from CSTA Phase II. These are
device-oriented and will not fit into the R.100 model for Call Records. R.100 develops
the CSTA Call Scenarios into call-oriented scenarios. To clarify the transition from one
model to another, R.100 has included columns for each device even though only one Call
Record will be generated. On occasion, the Call Scenario appears to have the same
counters and timers for a call where there is an originating and terminating device. For
example, Make Call creates a single call record although there are two devices involved
and two booleanReceived, one in the originating device column and the another one in
the Terminating device column. Within the Call Record, there will only be one instance
of booleanReceived and a higher level of counters and timers will determine direction.
A call record is generated within an ECTF compliant Function (typically known as MIS).
In the case of more than one ECTF Function being involved in the call, there shall only
Page 5-1
be one call record generated. The question is, “at which Function will the Call Record be
generated?” In practice, it is expected that the call record will be generated within an
ECTF compliant MIS Function within an Area of Visibility. This does not preclude call
records being generated at a terminating Function MIS. Where both Functions are ECTF
compliant, the Thread ID will provide the method for being able to carry out cradle to
grave tracking of both ends of the call.
To simplify the model, virtual states were added (e.g. diverted). These are always of zero
duration but have counters associated with them incremented. Timers for the state prior to
this state are not stopped until the next state (after the virtual state) is encountered. See
section 6, “State Transition Table”.
Page 5-2
5.2 Success Make Call
5.2.1 This Scenario is copied from ECMA TR 68 - (3.1 Successful Make Call)
This scenario initiates a call from device D1 to device D2. In this scenario both devices are free and valid, device D1 is permitted to
make the call and the call reaches establishment.
BEFORE AFTER
D1 D2 D1 c C1 c D2
Activity MONITORED DEVICE D1 MONITORED DEVICE D2 MONITORED DEVICE D3 Comments
A MakeCall to a valid MakeCallRequest

device is invoked on • callingDevice D1
behalf of device D1. • calledDirectoryNumber D2
• deviceProfile ()
• accountCode
• authCode ()
• correlatorData ()
()
• extensions
()
Acknowledgement. MakeCallResult
• initiatedCall D1C1
• extensions ()
Indication that service has ServiceInitiatedEvent The generation of this event

been initiated from this • initiatedConnection D1C1 is switch-specific.
device. • localConnectionInfo Initiated
• cause makeCall
Page 5-3
Device D1 lifts handset OriginatedEvent

ready for call. • originatedConnection D1C1
• callingDevice D1/NR
• calledDevice D2
• originatingDevice ()
• localConnectionInfo Connected
• cause newCall
Device D2 begins to ring DeliveredEvent DeliveredEvent

and D1 listens to ringing • connection D2C1 • connection D2C1
tone. • alertingDevice D2 • alertingDevice D2/NR
• callingDevice D1 • callingDevice D1
• calledDevice D2 • calledDevice D2
• lastRedirectionDevice NR • lastRedirectionDevice NR
• originatingConnection () • originatingConnection ()
• localConnectionInfo Connected • localConnectionInfo Alerting

• correlatorData () • correlatorData ()
• cause newCall • cause newCall
Device D2 answers the EstablishedEvent EstablishedEvent Device D2 manually

call. • establishedConnection D2C1 • establishedConnection D2C1 answers the call by lifting
• answeringDevice D2 • answeringDevice D2/NR handset.
• localConnectionInfo Connected • localConnectionInfo Connected

Page 5-4
5.2.2 Call Scenario - successful make call
The Make Call Scenario has been converted from a ‘device’ oriented scenario to a ‘call’ oriented scenario to derive data
elements
A call C1 is made on behalf of device
D1 to D2 - no errors are encountered
Typically this would be a call made

from an outbound Agent - using pre-
view dialing.
Activity D1-D2, C1 - Call Timers and Counters Data Element Names Data Element Names
States for C1 for C1 for C1
Originating Terminating
Make Call is issued on behalf of D1
Service request is acknowledged
Indication that a Service has been Pending Initiated Timer (start)

Initiated from this device D1
make call
Initiated Counter booleanInitiated

(increment)
durationIdle
Idle Timer (stop)
Call_ID
Device D1 goes ‘off-hook’ ready for Originated Originated Timer (start)

the Call - typically on many systems
the ‘off-hook’ will be activated new call
automatically.
Originated Counter booleanOriginated
(increment)
durationInitiated
Initiated Timer (stop)
Page 5-5
Activity D1-D2, C1 - Call Timers and Counters Data Element Names Data Element Names
States for C1 for C1 for C1
Device D2 begins to ring and Device Received/Delivered/ Originated Timer (stop) durationOriginated
D1 listens to ringing tone
new call
Alerting Timer (start)
Alerting Counter booleanReceived booleanReceived

(increment)
Virtual state (found Distributed Distributed Counter booleanDistributed
(increment)
Device D2 answers the Call Established Alerting Timer (stop) durationReceived durationReceived
new call
Connected Timer (start)
Connected Counter booleanConnected booleanConnected

(increment)
Page 5-6
5.3 Successful Consultation Call
5.3.1 This Scenario is copied from ECMA TR 68 - (6.1 Successful Consultation Call)
A call between device D1 and device D2 is already connected. Device D1 decides to invoke a consultation call to another
device, D3. This call is successful.
BEFORE AFTER
D1 c C1 c D2 D1 h C1 c D2
c C2 c D3
Consultation Call service ConsultationCallRequest

to device D3 is invoked on • existingCall D1C1
behalf of device D1. • consultedDevice D3
• consultedDeviceProfile ()
• accountCode ()
• authCode ()
• extensions ()
ConsultationCallResult
Acknowledgement. • initiatedCall D1C2
• extensions ()
Page 5-7
Connection placed on HeldEvent HeldEvent In some implementations the

hold. • heldConnection D1C1 • heldConnection D1C1 cause consultation may not
• holdingDevice D1/NR • holdingDevice D1 be supported.
• localConnectionInfo Hold • localConnectionInfo Connected
• cause consultation • cause consultation
Application notified of ServiceInitiatedEvent The generation of this event

initiating call. • initiatedConnection D1C2 is switch-specific.
• localConnectionInfo Initiated
• cause newCall
The Consultation Call is OriginatedEvent At this point a consultation

launched. • originatedConnection D1C2 call may follow any of the
• callingDevice D1/NR MakeCall scenarios
• calledDevice D3 produced in this Technical
• originatingDevice D2 Report.
• cause newCall
Device D3 begins to alert. DeliveredEvent DeliveredEvent

• connection D3C2 • connection D3C2
• alertingDevice D3 • alertingDevice D3/NR

New call established. EstablishedEvent EstablishedEvent Assuming that the called

• establishedConnection D3C2 • establishedConnection D3C2 device actually answers the
• answeringDevice D3 • answeringDevice D3/NR call.

Page 5-8
5.3.2 Call Scenario - successful consultation call
A call between device D1 and device NOTE - The

D2 is already connected. Device D1 connection between
decides to invoke a consultation call D2 and C1 is not
to another device, D3. The call is addressed in this
successful. scenario.
Activity D1-D2, C1 - Call Timers and Counters Data Element Names D1-D3, C2 - Call Timers and Counters Data Element Names
States for C1 for C1 States for C2 for C2
Call already established between D1 Established Connected Timer

and D2 (continues)
booleanConnected 1
Consultation Call service to device D3

was invoked on behalf of device D1
Established
Acknowledgment Established
Connection (C1) placed on hold Established-Held Connection Timer durationConnected

(stop)
Hold Timer (start)
Hold Counter booleanSuspended

(increment)
Application notified of initiating call Established-Held Pending Initiated Timer (start)

(D1 to D3)

(increment)
Page 5-9
Call_ID
The Consultation Call is launched Established-Held Originated Initated Timer (stop) durationInitiated
Originated Counter booleanOriginated

(increment)
Device D3 begins to alert Established-Held Received/Delivered Originated Timer (stop) durationOriginated
Alerting Timer (start)
Activity D1-D2, C1 - Call Timers and Counters Data Element Names D1-D3, C2 - Call Timers and Counters Data Element Names
States for C1 for C1 States for C2 for C2
Alerting Counter booleanReceived

(increment)
New Call Established Established-Held Established Alerting Timer (stop) durationReceived
Connected Timer
(start)
Connected Counter booleanConnected

(increment)
Consultation Call Disconnected Established-Held Null Connection Timer duration Connected

(stop)
Null Timer (start)
Null Counter booleanCompleted

(increment)
Original Call re-connected Established Hold Timer (stop) durationSuspended
Connected Timer
(start)
Original Call disconnects Null Connected Timer durationConnected

(stop)
Page 5-10
Null Timer (start)
Null Counter booleanCompleted

(increment)
1 - Calls Connected incremented prior

to this scenario.
Page 5-11
5.4 Successful Conference Call
5.4.1 This Scenario is copied from ECMA TR 68 - (9.1 Conference Call Service)
Device D1 has two calls, one active call and the other call on hold. This service provides the ability to conference the three
devices into a single call.
BEFORE AFTER
D1 h C1 c D2 D1 c D2
c C2 c D3 c C3 c D3
Conference Call service is ConferenceCallRequest

invoked on behalf of • heldCall D1C1
device D1. • activeCall D1C2
• extensions ()
Acknowledgement. ConferenceCallResult
• conferenceCall D1C3
• newConnection D2C3
D2
• deviceID D2C1
• oldConnection D3C3
D3
D3C2
• newConnection
()
• deviceID
• oldConnection
• extensions
Page 5-12
Conference established. ConferencedEvent ConferencedEvent ConferencedEvent The added party is the device
• primaryOldCall D1C1 • primaryOldCall D2C1 • primaryOldCall D3C2 representing the person who
• secondaryOldCall D1C2 • secondaryOldCall () • secondaryOldCall () has just joined the call from
• confController D1/NR • confController D1 • confController D1 the perspective of the
• addedParty D3 • addedParty D3 • addedParty D3/NR participants.
• newConnection D1C3 • newConnection D1C3 • newConnection D1C3
D1 D1 D1
• deviceID D2C3 • deviceID D2C3 • deviceID D2C3
• newConnection D2 • newConnection D2 • newConnection D2
D2C1 D2C1 D2C1
D3C3 D3C3 D3C3
• deviceID D3 • deviceID D3 • deviceID D3
• oldConnection D3C2 • oldConnection D3C2 • oldConnection D3C2
Connected Connected Connected
• newConnection () • newConnection () • newConnection ()
newCall newCall newCall
• deviceID • deviceID • deviceID
• oldConnection • oldConnection • oldConnection
• localConnectionInfo • localConnectionInfo • localConnectionInfo
• correlatorData • correlatorData • correlatorData
• cause • cause • cause
Page 5-13
5.4.2 Call scenario - successful conference call
Device D1 has two calls,

one active call and the
other call on hold. This
service provides the
ability to conference the
three devices into a
single call
Activity D1-D2, C1 - Timers and Data Element D1-D3, C2 - Call Timers and Data Element D1-D2-D3, Timers and Data Element
Call States Counters for Names for C1 States Counters for C2 Names for C2 C3 - Call Counters for Names for C3
C1 States C3
Call C1 held at D1 and Established- Established

Call C2 established Held
between D1 and D3
Virtual state Conferenced Conferenced booleanConference Conferenced Conferenced booleanConferenc Conferenced Conference booleanConferenced
Counter d Counter increment ed counter
increment increment
Conference Established Null Hold Timer durationSuspended Null Connected Timer durationConnected Established Connected Call ID
stops (Stops) Counter
increment
booleanCompleted booleanCompleted booleanConnected

Completed counter
increment Connected
Timer starts
Page 5-14
5.5 Incoming Call with no Agents
5.5.1 This Scenario is copied from ECMA TR 68 - (14.2 Incoming call to ACD with no available agents)
Incoming call to an ACD distribution mechanism (device D2) where the call awaits distribution to a free agent. While queuing,
the trunk (device D1) may be connected with a recorded announcement (events not shown). The recording may repeat itself or
change to a different one, several times while the call is queuing at the ACD distribution mechanism. When an agent becomes
free (device D3) the call is delivered to that device.
BEFORE AFTER
D3 D3 c C1
D2 D1 D4 D2 D1 D4
CSTA Domain
CSTA Domain
Device D1 goes "off- ServiceInitiatedEvent

hook". • initiatedConnection D1C1
• localConnectionInfo Initiated
• cause newCall
Page 5-15
Device D1 completes OriginatedEvent

dialling. • originatedConnection D1C1
• callingDevice D4/NK
• calledDevice D2
• originatingDevice D1/NR
• cause newCall
The call begins to alert at DeliveredEvent DeliveredEvent Information about D4 may

the queue. • connection D2C1 • connection D2C1 exist in some types of trunks
• alertingDevice D2 • alertingDevice D2/NR like ISDN or T1 with support
• callingDevice D4 • callingDevice D4 of ANI.
• originatingConnection D1C1 • originatingConnection D1C1
• localConnectionInfo
• localConnectionInfo Connected • correlatorData Alerting
• correlatorData () • cause ()
• cause entering entering
Distribution Distribution
Call is queued in Q1 QueuedEvent QueuedEvent Q1 may identify an ACD

represented by device D2. • queuedConnection D2C1 • queuedConnection D2C1 group or the ACD queuing
Q1 Q1 mechanism. A call may
• queue • queue reside within multiple
• callingDevice D4 • callingDevice D4 queues.
NR NR
• lastRedirectionDevice • lastRedirectionDevice
() ()
• numberedQueued • numberedQueued
() ()
• callsInFront • callsInFront
• localConnectionInfo Connected • localConnectionInfo Queued
• correlatorData • correlatorData
• cause () • cause ()
noAvailable noAvailable
Agents Agents
Page 5-16
The queued call gets DivertedEvent An annoucement can be

diverted to device D3. D3 • connection D2C1 provided prior to this event
represents an agent which • divertingDevice D2/NR for which events may be
is now free. • newDestination D3 generated.
• localConnectionInfo Null
• cause Distributed
Device D3 is alerted. DeliveredEvent DeliveredEvent

• connection D3C1 • connection D3C1
• alertingDevice D3 • alertingDevice D3/NR
• lastRedirectionDevice D2 • lastRedirectionDevice D2
• originatingConnection D1C1 D1C1
• originatingConnection
• cause Distributed • cause Distributed
Device D3 answers the EstablishedEvent EstablishedEvent

call. • establishedConnection D3C1 • establishedConnection D3C1
• answeringDevice D3 • answeringDevice D3/NR
• lastRedirectionDevice D2 • lastRedirectionDevice D2
• originatingConnection • originatingConnection D1C1
D1C1
• cause Distributed • cause Distributed
Page 5-17
5.5.2 Call scenario - incoming call with no available agents
Note: Where CSTA refers to ACD as a device, within TGCCR this is referred to as a Function (in this scenario D2 is the ACD
Entry Point and D1 is the Conduit).
Incoming call from D4 at

D1 waits at a Call Queue
and is then distributed to
D3 as C1
Activity D1-D2, C1 - D2, C1 - Call D1-D3, C1 - Call Timers and Data Element
Call States States States Counters Names
CSTA Device D1 goes idle timer stops durationIdle

'off hook'
Received
Conduit Receives Received counter
Incoming Call increments booleanReceived
Received timer Call_ID
starts
CSTA Device D1 ANI

completes dialling
DNIS
Page 5-18
Call begins to alert at the Delivered Received

ACD Entry Point entering
distribution entering
distribution
Call is Delayed in Q1 Delayed no Delayed Received Timer durationReceived

represented by CSTA available agents stops
device D2 no available
agents
Delayed counter
The call is delayed at the increments booleanDelayed
ACD Entry Point
Delay timer
starts
The call is diverted to

CSTA device D3.
D3 represents an agent
which is now free
The call is distributed to a

free agent
Page 5-19
Device D3 is alerted Delivered Distributed Delay timer stops durationDelayed
[delivered event] Distributed

counter
increments
booleanDistributed
Distributed Timer
starts
Device D3 answers the Established Established Distributed Timer durationDistributed

call stops
[established event]
Connected booleanConnected
counter
increment
Connected Timer
starts
Page 5-20
5.6 Make Predictive Call on Established
There is no CSTA call scenario for Make Predictive Call on Established.
A Make_Predictive_Call is made on The data associated

behalf of an Agent Group D1 that has with the terminating
Agents Ready. The Allocation State is device (D2) may not
set to allocate an Agent D3 once the be visible in all
Call is Established to the Called implementations
Device D2 and no errors are
encountered
Activity C1 - Call States Timers and Counters Data Element Names Data Element Names
for C1 for C1 for C1
Make Predictive Call Service is

requested for an Agent Group D1 by
an application in the Computing
Domain.
Service request is acknowledged
Indication that a Service has been Pending Idle Timer (stop) durationIdle
Initiated for this device
make call

(increment)
Initiated Timer (start) Call_ID Called Device ID
Page 5-21
Device D2 begins to ring Delivered Initiated Timer (stop) durationInitiated
new call
Received timer (start)
Received Counter booleanReceived booleanReceived

(increments)
Virtual State Distributed Distributed counter

(increments)
booleanDistributed booleanDistributed
Device D2 answers the call Established D1,C1,D2 Received Timer durationReceived durationReceived
(stops)
booleanConnected
Connected counter
increments
Connected timer starts

The Call gets Diverted to an Agent Diverted counter booleanDiverted
increments
Virtual state
Distributed to the Agent and the Connected timer stops durationConnected

connection cleared at D1 - C1
Distributed Timer booleanDistributed
starts
Agent answers the Call Establishedl Distributed Timer stops durationDistributed
Connected counter booleanConnected booleanConnected

increments
Connected Timer
starts
Page 5-22
R.100 State Transition Table ECTF Proprietary
6 State Transition Table
TO Pending Originated Received/ Delivered Delayed Diverted Distributed Established Established-On Hold Null
Transferred
FROM
Null booleanInitiated durationIdle

durationIdle booleanReceived Note 4
booleanTransferred
Pending durationInitiated durationInitiated durationInitiated
booleanOriginated booleanReceived booleanAborted
Originated durationOriginated durationOriginated

booleanReceived booleanAborted
Received/ durationReceived durationReceived durationReceived

Delivered booleanDelayed booleanDistributed booleanAbandoned
Delayed durationDelayed durationDelayed

booleanDistributed booleanAbandoned
durationDelayed
booleanDiverted
durationDiverted durationDiverted
booleanReceived booleanDelayed durationDiverted
Diverted booleanDistributed
Distributed durationDistributed durationDistributed duration Distributed
durationDistributed booleanConnected booleanAbandoned booleanTransferred
booleanDiverted
Established durationConnected durationConnected durationConnected
booleanSuspended booleanCom pleted booleanTransferred
see NOTE 1 See NOTES 2 & 3
Established-On durationSuspended durationSuspended
Hold booleanConnected booleanFrustrated durationSuspended
booleanTransferred
durationTransferred durationTransferred durationTransferred

Transferred booleanDistributed booleanConnected booleanCom pleted
durationConferenced durationConferenced durationConferenced

Conferenced booleanDistributed booleanConnected booleanCom pleted
This table contains definitions of values that can be derived from existing CTI protocols and APIs without any
a-priori knowledge. Using CSTA, TSAPI, TAPI, JTAPI it is not possible to distinguish the difference between Incom ing and O utgoing Calls
NO TE 1 where 'personal greeting' is used it shall be accounted as part of the Established state
NO TE 2 M ay need this for re-direction of a call that was initially established to a rem ote site but then turned back.
NO TE 3 Where a predictive dialler is used the call is diverted to the agent once the m ake call is established
NO TE 4 All durations are accounted for in Call 1 and Call 2 at the devices and therefore the Null to Transfer does not require a duration
Page 6-1
R.100 Clock synchronization ECTF Proprietary
7 Clock synchronization
Where data is time stamped by several functions within a Call Center environment, it is
important that the same reference source be used to ensure synchronization.
Since Call Center environments may span the Globe, it is important that one universal time
reference be adopted.
The universal time reference for systems conforming to this document is UTC4 [Universal Co-
ordinated Time].
A reliable method of synchronizing clocks universally to within 1ms is GPS satellites5.
The acceptable error tolerance for a time stamp in UTC, for this document, is 5ms. However, If
in the event that the time stamp is delayed, (for example, due to process context switching) then
the error tolerance may be more than 5ms.
4
Langley, R. “Time, Clocks and GPS,” GPS World Magazine, Advanstar Communications Nov./Dec. 1991, pp. 38-
42.
5
Lewandowski, W., and C. Thomas, “GPS Time Transfer,” Proc of IEEE, Vol. 79, No.7, July 1991.
Page 7-1
R.100 Call Record ECTF Proprietary
8 Call Record
8.1 Overview
R.100 describes two types of call records.
Call Record (Segmented) offers the greatest flexibility and granularity of data for
reporting, it allows tracking of concurrent call data; e.g., Conferenced. But depending on
the design of the application, it may require large storage space. It is event driven and
specifically designed to address those applications that require real time data. R.100
Terminology is designed for use in real time applications as well as reporting. The record
is built as the call progresses. Data is available up to and including the current call
segment.
Call Record (Fixed) is designed for simpler applications that do not require the granularity of
data, are not designed to store large volumes of data and/or do not require the extraction of
concurrent call data. The record becomes available at the termination of the call.
Page 8-1
8.2 Call Record (Segmented)
The segmented call record (recCallSegmented) is in the form of two related tables. The
first table contains header information relating to the overall nature of the call. The
second contains the segmented information; each segment being a new record in the
second table. The two tables are linked via the idCall. The idCallSegment allows tracking
of the segments within a call. This design allows for concurrent calls (transfer
/conference) and incomplete calls to be detected.
8.2.1 Call Segment Header
Field Descriptions Notes
Version Number The compliance version number
idThread Header information
idCall
Call Related Data One or more pieces of information may be collected from the
caller such as Account Number and Language preference.
This information is typically used for both CTI and Routing
applications.
Direction Incoming/Outgoing/Internal/Not Known

All Predictive Dialed calls are considered Outgoing.
Call Type ACD, NonACD and PBX.
ACD Entry Point The point at which the ACD assumes control of the call
routing. The generic name for Application, Vector, ACD
Group, etc.
Agent Group The identifier representing a collection of agents. An Agent

Group may exist with zero agents. Agent Group is used for
routing.
Agent ID An identifier explicitly associated with a single agent.
Call Code e.g. Line of Business, Peg Code
Source e.g. Internal, PSTN, Private Network, VPN, IP
Page 8-2
utcStart UTC
utcStop UTC ……….. end of record
8.2.2 Call Segment
idCall Header information
idCallSegment
idDevice Calling device id
idDevice Called device id
utcStart start time of transition (enters this state)
utcStop stop time of transition (leaves this state)
boolean X indication of transit to state
duration X identification of duration associated with calling device
duration value duration between start/stop times
8.3 Call Record (Fixed)
The fixed call record (recCallFixed) has the following fields:
idThread Header Information
Page 8-3
idCall
Call Related Data One or more pieces of information may be collected from
the caller such as Account # and Language preference. This
information is typically used for both CTI and Routing
applications.
Direction Incoming/Outgoing/Internal/Not Known
All Predictive Dialed calls are considered OUTGOING.
ACD Entry Point The point at which the ACD assumes control of the call
routing. The generic name for Application, Vector, ACD
Group, etc.
Call Type ACD, NonACD, PBX
Transfer Type 0=no xfer, 1= xfer in, 2= xfer out
Agent Group The identifier representing a collection of agents. An Agent

Group may exist with zero agents. Agent Groups are used
for routing.
Agent ID An identifier explicitly associated with a single agent.

Call Code e.g. Line of Business, Peg Code
Source e.g. Internal, PSTN, Private Network, VPN, IP
utcStart UTC
utcStop UTC- Field 0(zero) until call is stopped. I.e. returned to
NULL
Current/Final* State Shows current state until call is finished. I.e. Shows the state
prior to NULL
countInitiated The accumulated counters for each of the boolean

countOriginated counts contained within the segmented call record.
countReceived
countDelayed E.g. A call has been Suspended 3 times during a single
countDiverted call. The record indicates countSuspended = 3. The
countDistributed segmented call record will have a segment for each
countConnected Suspended instance.
countSuspended
Page 8-4
countTransferred
countConferenced
timeIdle Accumulated totals for each type of call activity.

timeInitiated
timeOriginated The individual durations which are contained within the
timeReceived segmented call record.
timeDelayed
timeDiverted E.g.. A call has been Suspended 3 times; for 10 secs,
timeDistributed once for 35 secs and once for 25 secs the record will
timeConnected show timeSuspended = 70 secs.
timeSuspended
timeTransferred
timeConferenced
8.3.1 Usage Note
Within a Reporting Period (e.g. 0900-1400) there will be anomalies when reporting based
upon calls in progress.
If a call has started in the previous Reporting Interval (e.g. 0900-0930, 0900-0917) and
has not completed at the time of reporting the call will appear as received within the
previous Reporting Interval, and the reports shall not display a call completed.
Once the call has completed, the call will appear in the Reporting Interval where it
originated as Received and Completed.
This relates to the skew in the data derived from completed call records. There are two
basic break points that are important to the call center these are firstly, when the call is
connected or abandoned, and secondly when the call is completed. The first of these
includes the amount of time in delay the second is about connection times.
The following tables show examples of how the data can be skewed once figures are put
in.
a) Report call activity in the archive period where the call has been received regardless of
when it was connected or abandoned.
Page 8-5
Time Received Connected Abandoned Connected Completed GOS

within target
0900-0930 120 95 25 65 75 54%
0930-1000 0 0 0 0 20 0%
Total 120 95 25 65 95 54%
b) Report call activity in the archive period when the call was connected or abandoned
regardless of when it was received.

within target
0900-0930 120 80 25 60 75 57%
0930-1000 0 15 0 5 20 33%
Total 120 95 25 65 95 54%
c) Report call activity in the archive period when the call was completed regardless of when it
was received, answered or abandoned

within target
0900-0930 100 75 25 60 75 60%
0930-1000 20 20 0 5 20 25%
Total 120 95 25 65 95 54%
Page 8-6
R.100 Threads ECTF Proprietary
9 Threads
9.1 Overview
Within any call center transaction there may be more than one call record. Typically this
would happen when an IVR greets a caller and then transfers the call to an ACD. To
ensure that the objective of “cradle to grave” call tracking can be implemented a record
that identifies each call within a transaction is required.
This record is known as a Thread and is described in Section 10 Thread Record.
9.2 Description of the attached data Schema
The following data schema shows the application options for data storage and retrieval
techniques to produce call scenario variations.
Schema by Thread and Call IDs

Call
Thread utcStart
idThread utcStop
idEquipment Calling idDevice
idCall Called idDevice Device Group
idCall Last Redirection idDevice idDevice
idEquipment idThread idDevice
idDevice
idCall idDevice
Offered
idDevice
Duration idDevice
idDevice
Queued Call Segments idCall
Duration idCall
idCall
Connected
idCall
Duration
Call
Page 9-1
R.100 Thread Record ECTF Proprietary
10 Thread Record
10.1 Record Structure
idThread The idThread must be globally unique.
DNIS Dialed Number Identification Service (Incoming)

or Campaign
or Source Extn DN Campaign (Outgoing)
Extension DN (Internal)
CLI()/ANI Calling Line Identity/ Automatic Number Identification

(Incoming)
or Called Number
Called Number (Outgoing)
or Called Extn DN
Extension DN (Internal)
Business Data Indicates that corporate data is associated with this

Thread Record. The corporate data may reside within a
separate business database.
Function Pointer This sets the context for this part of the Thread Record.
The first occurrence within this Thread Record will only
type[Forward],[Backward] or be Local.
Local
IdFunction
utcTimeStamp The time at which this triplet (record) was generated.
idCall The record is built sequentially and may contain many
idCall Call_ids for the idFunction.
idCall The same idFunction may appear more than once within
the same Thread Record.
Page 10-1
Function Pointer This pointer indicates the context of the following

idCalls.
type[Forward], [Backward]
or Local
idFunction
utcTimeStamp
idCall
idCall
10.2 Usage rules
The concept of idThread enables the tracking of calls in a call center environment, across
multiple functions, and across multiple stages of a call, within the same function6. Once
in place, true cradle to grave tracking of calls can take place. This will enable Call
Centers to consolidate relevant pieces of data to provide more accurate reporting (in line
with the requirements of ECTF TGCCR).
The first function within the call sequence attaches the idThread and then passes this to
the next in sequence. The next in sequence may be another device (e.g. transfer of call to
another agent) in the same function or another separate function, identified by
FunctionID (e.g. ACD to IVR).
Any function within the call sequence that receives an idThread shall preserve it and:
a) Attach it to all events that it reports.
b) Propagate it to any other subsequent equipment that participates in the call.
R100 does not mandate how a supplier shall propagate the idThread.
The usage shall allow the identification of the following data within Call Center
Reporting:
• all calls for a particular device (Device ID and Call ID).
6
The term Call Center Function addresses the development of Call Center systems which may integrate software
functions (IVR etc) and have historically resided on separate pieces of equipment. The use of Function allows for
both types of call center setup.
Page 10-2
• call record (Call ID) for individual calls including Thread ID.
• a consolidated record (Thread ID, Function ID) of the life of the call including all
idCall within it.
In scenarios like conferenced calls all of the participants share the same idCall [ECMA
TR68, CSTA Section 9]. This has the effect that several Threads will share the same
idCall. R100 does not mandate how an application developer should treat these Threads.
Page 10-3
R.100 Typical ACD Area of Visibility Call Scenarios ECTF Proprietary
11 Typical ACD Area of Visibility Call Scenarios

11.1 Overall
11.2 Scenarios
Underlined text denotes far end state transitions.
Distributed - a virtual state. This state is always connected to Received in the following scenario.
1. A Successful Outgoing Preview ACD/Progressive ACD/NonACD Call

Pending -> Originated -> Received / Distributed -> Established
2. Failed Outgoing Preview ACD/Progressive ACD/NonACD Call

Pending -> Originated -> Received / Distributed -> Null
Usage Note: If ECTF compliant conduit then the call will be abandoned otherwise will be aborted.
3. A Successful Outgoing Predictive(ACD) Call

Pending -> Originated -> Received / Distributed -> Established -> Diverted [-> Delayed] -> Distributed -> Established
Usage Note: In cases where there are no Agents available the call may be sent to Delay Logic prior to being Distributed.
4. Failed Outgoing ACD Call

Pending -> Originated -> Received / Distributed [-> Established] -> Null
5. A Successful Incoming ACD Call (includes CTI Routing within the Area of Visibility)
Received -> Delayed -> Distributed -> Established
6. A Successful Incoming ACD Call with CTI Routing (separate Areas of Visibility)
Call 1: Received -> Delayed -> Distributed -> Transferred -> Null
Call 2: Received -> Delayed -> Distributed -> Established
Page 11-1
R.100 Typical ACD Area of Visibility Call Scenarios ECTF Proprietary
7. A Successful Incoming NonACD Call

Received -> Distributed -> Established
8. Failed (Busy/Treatment) Incoming NonACD Call (Busy denotes divert to Busy Service)
Received -> Distributed -> Diverted -> Distributed -> Established
9. Failed (No Answer/No Treatment) Incoming NonACD Call

Received -> Distributed -> Null
10. A Successful Consultation Transfer of an Incoming/Outgoing Call

Call 1: Established -> Suspended -> Transferred -> Null
Call 2: Pending -> Originated -> Received -> Distributed -> Established -> Transferred->Null
Call 3: Transferred -> Established
11. A Successful Blind Transfer of an Incoming/Outgoing Call

Call 1: Established -> Suspended -> Transferred -> Null
Call 2: Pending -> Originated -> Received -> Distributed -> Transferred -> Null
Call 3: Transferred -> Distributed -> Established
12. A Successful Conference Call

Call 1: Established -> Suspended-> Conferenced -> Null
Call 2: Pending -> Originated -> Received -> Distributed -> Established -> Conferenced->Null
Call 3: Conferenced -> Established
Page 11-2
R.100 Counters for Reporting ECTF Proprietary
12 Counters for Reporting

The following counters are calculated using field(s) from all fixed call records that occur within the desired reporting period
(periodRpt). To be more specific, the call record’s utcStart must satisfy the following criteria:
periodRpt.utcStart <= recCallFixed.utcStart < periodRpt.utcStop
Most counters exist for each of the following call types:

<type> = “ACD” (for Call Type = ACD)
<type> = “NonACD” (for Call Type = NonACD)
<type> = “PBX” (for Call Type = PBX)
<type> = “ALL” (for all call types)
Within the scope of this definition the Directions are defined as follows:
<direction> = “IN” Calls that are Incoming to the Area of Visibility
<direction> = “OUT” Calls that are Outgoing from the Area of Visibility
<direction> = “INTERNAL” Calls that originate and terminate within the Area of Visibility
<direction> = “Not Known” Calls where the direction is unknown
<direction> = “All” Valid for all Directions
Total Count (tc) Direction Within a Reporting Period
tcReceived<type> ALL (if Call Type = <type> then countReceived)
tcDelayed<type> IN (if Call Type = <type> then countDelayed)
OUT not possible
INTERNAL (if Call Type = <type> then countDelayed)
Page 12-1
Not Known (if Call Type = <type> then countDelayed)
tcAbandonedDuringDelayed<type> IN (if Call Type = <type> and FinalState = Delayed then

countAbandoned)
OUT not possible
INTERNAL (if Call Type = <type> and FinalState = Delayed then

countAbandoned)
Not Known ? (if Call Type = <type> and FinalState = Delayed then
countAbandoned)
tcConnectedBeforeWaitThreshold<type> ALL (if Call Type = <type> and (countConnected minus Minimum
(countDiverted,1)) >0 and ttWait<type>
<thresholdWaitConnected<direction><@MP> then
(countConnected minus Minimum (countDiverted,1)))
(Note1: thresholdWaitConnected<direction><@MP> is User

Defined. See Glossary
Note2: For the use of a Predictive Dialer, it is assumed that the Call
Type = ACD and countDiverted >=1.
For Call Type = NonACD or PBX, it is assumed that a Predictive

Dialer is not involved and countDiverted = 0)
tcAbandonedBeforeWaitThreshold<type> IN (if Call Type = <type> and countConnected >0 and

ttWait<type><thresholdWaitAbandoned<direction><@MP> then
countConnected)
Page 12-2
(Note: thresholdWaitAbandoned<direction><@MP> is User

Defined. See Glossary.)
OUT (if Call Type = <type> and countConnected >0 and

ttWait<type><thresholdWaitAborted<direction><@MP> then
countConnected)
(Note: thresholdWaitAborted<direction><@MP> is User Defined.

See Glossary.)
INTERNAL (if Call Type = <type> and countConnected >0 and

countConnected)

Not Known (if Call Type = <type> and countConnected >0 and
countConnected)

tcDelayedToConnected<type> IN (if Call Type = <type> and countDelayed >0 then

countConnected)
OUT not possible
INTERNAL (if Call Type = <type> and countDelayed >0 then

countConnected)
Page 12-3
Not Known (if Call Type = <type> and countDelayed >0 then
countConnected)
tcDiverted<type> ALL (if Call Type = <type> then countDiverted)
tcDistributed<type> ALL (if Call Type = <type> then countDistributed)
tcAbandonedDuringDistributed<type> IN (if Call Type = <type> and FinalState = Distributed then

countAbandoned)
OUT Not Possible
INTERNAL (if Call Type = <type> and FinalState = Distributed then

countAbandoned)
Not Known ? (if Call Type = <type> and FinalState = Distributed then
countAbandoned)
tcConnected<type> IN (if Call Type = <type> then countConnected)
OUT (if Call Type = <type> then (countConnected minus

Minimum(countDiverted,1)))
(Note: For the use of a Predictive Dialer, it is assumed that the Call
Type = ACD and countDiverted >=1.
For Call Type = NonACD or PBX, it is assumed that a Predictive

Dialer is not involved and countDiverted = 0.)
INTERNAL (if Call Type = <type> then countConnected)
Page 12-4
Not Known (if Call Type = <type> then countConnected)
(see Direction note in Call Records)
tcDisconnectedDuringSuspended<type> ALL (if Call Type = <type> then countFrustrated)
tcSuspended<type> ALL (if Call Type = <type> then countSuspended)
tcInitiated<type> IN not possible
OUT (if Call Type = <type> then countInitiated)
INTERNAL (if Call Type = <type> then countInitiated)
Not Known (if Call Type = <type> then countInitiated)
tcOriginated<type> IN not possible
OUT (if Call Type = <type> then countOriginated)
INTERNAL (if Call Type = <type> then countOriginated)
Not Known (if Call Type = <type> then countOriginated)
tcAborted<type> IN not possible
OUT (if Call Type = <type> and utcStop>0 and countReceived=0 then
countInitiated)
Page 12-5
INTERNAL (if Call Type = <type> and utcStop>0 and countReceived=0 then
countInitiated)
Not Known (if Call Type = <type> and utcStop>0 and countReceived=0 then
countInitiated)
tcAbandoned<type> IN (if Call Type = <type> and utcStop >0 and countConnected = 0
then 1)
Shouldn’t this be “not possible” OUT (if Call Type = <type> and utcStop >0 and countConnected = 0
then 1)
INTERNAL (if Call Type = <type> and utcStop >0 and countConnected = 0
then 1)
Not Known (if Call Type = <type> and utcStop >0 and countConnected = 0
then 1)
tcCompleted ALL (if Call Type = <type> and utcStop >0 and countConnected > 0
then 1)
Transfer Type ALL if countTransferred = 0 then Transfer Type=0
if countTransferred >0 and countReceived = 0 then Transfer Type=1
if countTransferred >0 and countReceived > 0 and countSuspended

> 0 then Transfer Type=1
tcTransferredIN<type> ALL (if Call Type = <type> and Transfer Type = 1 then 1)
Page 12-6
tcTransferredOUT<type> ALL (if Call Type = <type> and Transfer Type = 2 then 1)
tcConferenced Not ( (if Call Type = <type> then countConferenced) ) / 3

applicable
Notes:
Aborted = utcStop >0

countInitiated = 1 and countReceived = 0
Abandoned = utcStop >0

countConnected = 0
Completed = utcStop >0

countConnected > 0
Page 12-7
R.100 Timers for Reporting ECTF Proprietary
13 Timers for Reporting

The following timers are calculated using field(s) from all call records (fixed) that occur within the desired reporting period
(periodRpt). To be more specific, the call record’s utcStart must satisfy the following criteria:
periodRpt.utcStart <= recCallFixed.utcStart < periodRpt.utcStop
Most of the timers exist for each of the following call types:
<type> = “ACD” (for Call Type = ACD)
<type> = “NonACD” (for Call Type = NonACD)
<type> = “PBX” (for Call Type = PBX)
<type> = “All” (for all call types)
Within the scope of this definition the Directions are defined as follows:
<direction> = “IN” Calls that are Incoming to the Area of Visibility
<direction> = “OUT” Calls that are Outgoing from the Area of Visibility
<direction> = “INTERNAL” Calls that originate and terminate within the Area of Visibility
<direction> = “Not Known” Calls where the direction is unknown
<direction> = “All” Valid for all Directions
Total Time (tt) Direction Within a Reporting Period
ttIdle<type> ALL (if Call Type = <type> then timeIdle)
ttInitiated<type> IN Not Possible
OUT (if Call Type = <type> then timeInitiated)
Page 13-1
INTERNAL (if Call Type = <type> then timeInitiated)
Not Known (if Call Type = <type> then timeInitiated)
ttOriginated<type> IN Not Possible
OUT (if Call Type = <type> then timeOriginated)
INTERNAL (if Call Type = <type> then timeOriginated)
Not Known (if Call Type = <type> then timeOriginated)
ttReceived<type> ALL (if Call Type = <type> then timeReceived)
ttDelayed<type> IN (if Call Type = <type> then timeDelayed)
OUT Not Possible
INTERNAL (if Call Type = <type> then timeDelayed)
Not Known (if Call Type = <type> then timeDelayed)
ttAbandonedDuringDelayed<type> IN (if Call Type = <type> and FinalState = Delayed then timeDelayed)
OUT Not Possible
INTERNAL (if Call Type = <type> and FinalState = Delayed then timeDelayed)
Not Known ? (if Call Type = <type> and FinalState = Delayed then timeDelayed)
Page 13-2
ttDelayedConnectedDelayed<type> IN (if Call Type = <type> and countDelayed >0 and countConnected >0
then timeDelayed)
OUT Not Possible
INTERNAL (if Call Type = <type> and countDelayed >0 and countConnected >0
then timeDelayed)
Not Known ? (if Call Type = <type> and countDelayed >0 and countConnected
>0 then timeDelayed)
ttDiverted<type> ALL (if Call Type = <type> then timeDiverted) (Note: Always 0)
ttDistributed<type> ALL (if Call Type = <type> then timeDistributed)
ttAbandonedDuringDistributed<type> IN (if Call Type = <type> and FinalState = Distributed then

timeDistributed)
OUT Not Possible
INTERNAL (if Call Type = <type> and FinalState = Distributed then

timeDistributed)
Not Known ? (if Call Type = <type> and FinalState = Distributed then
timeDistributed)
ttDistributedConnected<type> ALL (if Call Type = <type> and countConnected >0 then timeDistributed)
(Note: If countConnected >0 then countDistributed >0)
ttConnected<type> IN (if Call Type = <type> then timeConnected)
Page 13-3
OUT (if Call Type = <type> then (timeConnected minus timeDiverted))

(Note: timeDiverted always 0)
INTERNAL (if Call Type = <type> then timeConnected)
Not Known (if Call Type = <type> then timeConnected)
(see Direction note in Call Records)
ttSuspended<type> ALL (if Call Type = <type> then timeSuspended)
ttWait<type> IN ttReceived + ttDelayed + ttDistributed + ttDiverted
OUT ttPending + ttOriginated + ttReceived + ttDelayed + ttDistributed +

ttDiverted
INTERNAL ttPending + ttOriginated + ttReceived + ttDelayed + ttDistributed +

ttDiverted
Not Known ttPending + ttOriginated + ttReceived + ttDelayed + ttDistributed +

ttDiverted
ttAbandoned<type> IN (if Call Type = <type> and countAbandoned >0 then timeReceived +
timeDelayed + timeDistributed + timeDiverted) (Note: timeDiverted
always 0)
OUT Not Possible
INTERNAL (if Call Type = <type> and countAbandoned >0 then timeReceived +
always 0)
Page 13-4
Not Known ? (if Call Type = <type> and countAbandoned >0 then timeReceived
+ timeDelayed + timeDistributed + timeDiverted) (Note: timeDiverted
always 0)
ttWaitConnected<type> IN (if Call Type = <type> and countConnected >0 then timeReceived +
always 0)
OUT Not possible
INTERNAL (if Call Type = <type> and countConnected >0 then timeReceived +
always 0)
Not Known ? (if Call Type = <type> and countConnected >0 then timeReceived +
always 0)
ttTransferred ALL (if Call Type = <type> then timeTransferred) (Note: Always 0)
ttConferenced ALL (if Call Type = <type> then timeConferenced) (Note: Always 0)
Page 13-5

Call Center Reporting PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Call Center Reporting PDF

Caricato da

Copyright:

Formati disponibili

Document Name: Call Center Reporting

Document Category: ACD

Date: October 8, 1999

Security: ECTF Proprietary

PROPRIETARY INFORMATION: The information contained in this document is the

0.01 June 23, 1997 Roger Huffadine

0.02 Roger Huffadine

0.04 September, 1998 Berny MacLeod

0.05 January, 1999 Berny MacLeod

1.02 July 1, 1999 Chuan Chee Reformatted document.

REVISION HISTORY....................................................................................................................... III

1.1.1 Mission Statement ....................................................................................................1-1

1.1.2 Scope ........................................................................................................................1-1

1.1.3 Method .....................................................................................................................1-2

1.2 SUMMARY ........................................................................................................................1-3

1.2.1 Call Center Reporting Terminology.........................................................................1-3

1.2.2 Call Center Models...................................................................................................1-3

1.2.3 Events .......................................................................................................................1-3

1.2.4 Scenarios ..................................................................................................................1-4

1.2.5 State Transition Table ..............................................................................................1-4

1.2.6 Clock Synchronization .............................................................................................1-4

1.2.7 Call Record...............................................................................................................1-4

1.2.8 Threads .....................................................................................................................1-4

1.2.9 Thread Record ..........................................................................................................1-4

1.2.10 Typical ACD Area of Visibility Call Scenarios.......................................................1-4

1.2.11 Counters and Timers for Reporting..........................................................................1-4

1.3 CONFORMANCE ................................................................................................................1-5

1.4 PHASING ..........................................................................................................................1-5

2 CALL CENTER REPORTING TERMINOLOGY .........................................................................2-1

2.1 OVERVIEW .......................................................................................................................2-1

2.2 DEFINITIONS AND STATISTICS ..........................................................................................2-2

3 CALL CENTER MODELS.........................................................................................................3-1

3.2 GENERIC ACD MODEL ....................................................................................................3-2

3.3 DEFINITIONS FOR GENERIC ACD COMPONENTS ..............................................................3-3

5.2 SUCCESS MAKE CALL ......................................................................................................5-3

5.2.2 Call Scenario - successful make call ........................................................................5-5

5.3 SUCCESSFUL CONSULTATION CALL .................................................................................5-7

5.3.2 Call Scenario - successful consultation call .............................................................5-9

5.4 SUCCESSFUL CONFERENCE CALL...................................................................................5-12

5.4.2 Call scenario - successful conference call..............................................................5-14

5.5 INCOMING CALL WITH NO AGENTS ................................................................................5-15

5.5.2 Call scenario - incoming call with no available agents..........................................5-18

5.6 MAKE PREDICTIVE CALL ON ESTABLISHED ...................................................................5-21

6 STATE TRANSITION TABLE ...................................................................................................6-1

7 CLOCK SYNCHRONIZATION ...................................................................................................7-1

8 CALL RECORD .......................................................................................................................8-1

8.2 CALL RECORD (SEGMENTED) ..........................................................................................8-2

8.2.1 Call Segment Header................................................................................................8-2

8.2.2 Call Segment ............................................................................................................8-3

8.3 CALL RECORD (FIXED) ....................................................................................................8-3

8.3.1 Usage Note ...............................................................................................................8-5

9.2 DESCRIPTION OF THE ATTACHED DATA SCHEMA ..............................................................9-1

10.2 USAGE RULES.................................................................................................................10-2

11 TYPICAL ACD AREA OF VISIBILITY CALL SCENARIOS .....................................................11-1

11.2 SCENARIOS ....................................................................................................................11-1

12 COUNTERS FOR REPORTING................................................................................................12-1

13 TIMERS FOR REPORTING .....................................................................................................13-1

1.1.1 Mission Statement

The following represent the goals of the R.100 document:

• eliminate multiple counting

• define method for clock synchronization to ensure time stamp consistency

• define data structures

• Customer Premise Equipment