Arena Contact Center Edition User's Guide PDF

ARENCC-UM001B-EN-P_Titlepg.
qxd
3/10/04
3:41 PM
Page 1
Users Guide
Doc ID ARENCC-UM001C-EN-P
CCE.book Page ii Wednesday, August 4, 2004 4:28 PM
Contacting
Rockwell Software
Copyright Notice
Technical Support Telephone1-440-646-5800

Technical Support Fax1-440-646-5801
World Wide Webwww.rockwellsoftware.com
Copyright 2004 Rockwell Software Inc. All rights reserved. Printed in USA.
This manual and any accompanying Rockwell Software products are copyrighted by Rockwell
Software Inc. Any reproduction and/or distribution without prior written consent from Rockwell
Software is strictly prohibited. Please refer to the license agreement for details.
Commercial runtime models may be legally loaded and run only by employees of organizations
with a commercial Arena license. Models created using a research licenses may not be used for
commercial use. Any other use of a runtime model is illegal and unauthorized.
Commercial Arena software can be obtained by contacting Rockwell Software at 1.412.741.3727
or contacting your local representative (listed under partners at www.ArenaSimulation.com
<http://www.ArenaSimulation.com>).
Trademark Notice
Arena and SIMAN are registered trademarks and the phrase Forward Visibility for Your
Business and the Rockwell Software logo are trademarks of Rockwell Automation, Inc.
Microsoft, Windows, and Visual Basic are registered trademarks of the Microsoft Corporation.
Crystal Reports is a registered trademark of Crystal Decisions.
All other trademarks and registered trademarks are the property of their respective holders and are
hereby acknowledged.
Warranty
This Rockwell Software product is warranted in accord with the product license. The products
performance will be affected by system configuration, the application being performed, operator
control, and other related factors.
This products implementation may vary among users.
This manual is as up-to-date as possible at the time of printing; however, the accompanying
software may have changed since that time. Rockwell Software reserves the right to change any
information contained in this manual or the software at anytime without prior notice.
The instructions in this manual do not claim to cover all the details or variations in the equipment,
procedure, or process described, nor to provide directions for meeting every possible contingency
during installation, operation, or maintenance.
ii
CCETOC.fm Page iii Wednesday, August 4, 2004 4:36 PM
Contents
1 Welcome to Arena Contact Center Edition
What is Arena Contact Center Edition? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation of contact centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arena Contact Center Edition: A custom-designed simulation system
for contact centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reference the users guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use the SMARTs library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Access the Arena Symbol Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get Web support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Get consulting services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Introduction to Simulation
1
1
1
3
4
4
4
4
5
5
5
6
6
6
6
Simulation defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Systems and models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Advantages of simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
The simulation process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Problem definition and project planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Style definition and model formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Experimental design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Input data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Verification and validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Documentation and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 General Concepts
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
19
20
20
21
21
iii
CCETOC.fm Page iv Wednesday, August 4, 2004 4:36 PM
ARENA CONTACT CENTER EDITION USERS GUIDE
Arrival pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trunk Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent Skill Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parent Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Animation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance measures/reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Features
Different stages in the contact life span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact arrival (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Blocked contacts (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Offered contacts (required). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Abandoned contacts (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disconnected contacts (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contacts leaving messages (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handled contacts (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Talk time (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conference (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transfer (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
After-contact work (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact back (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Queue behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Queue construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Queue ranking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Skill-based routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing script construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Begin Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Queue for Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remove from Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
21
21
22
22
22
22
23
23
23
23
23
24
24
24
24
24
24
27
27
28
28
29
29
29
30
30
31
31
32
32
33
33
34
34
35
36
36
36
36
37
CCETOC.fm Page v Wednesday, August 4, 2004 4:36 PM
Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transfer to Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Transfer to Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Branch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
End Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trunk costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Miscellaneous features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pattern entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Individual agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Advanced configuration agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Getting Started
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loading and running an existing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General modeling skills and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Panels and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Module copy and paste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Repeat group duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disable animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Building an Arena Contact Center Edition model . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining the business application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Model construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Running the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 The Contact Data Panel
37
37
37
37
37
37
38
38
38
38
38
38
38
39
39
39
39
39
39
41
41
41
42
42
42
43
43
43
43
43
44
44
44
56
56
59
Configuration module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Schedule module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Pattern module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
CONTENTS
CCETOC.fm Page vi Wednesday, August 4, 2004 4:36 PM
Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Animate module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Report module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 The Script Panel
71
78
86
94
99
Begin Script module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Queue for Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Remove from Queue module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Wait module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Priority module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Message module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Disconnect module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Overflow module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Transfer to Script module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Transfer to Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Conference module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Branch module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Assignment module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
End Script module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Script restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Arena Contact Center Edition script examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
8 Reports
Agents and Trunks report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trunk Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact Times and Counts report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other Contact Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact Count Statistics report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contact Time Statistics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agent Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parent Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trunk Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overflow Count Statistics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
123
124
124
124
125
125
125
126
127
128
129
131
132
134
135
CCETOC.fm Page vii Wednesday, August 4, 2004 4:36 PM
9 Case Studies
Purposes of cases and examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 1Bilingual Contact Center model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . .
The data detail for the Bilingual Contact Center example . . . . . . . . . . . . . . . . .
Example 2Bank model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The data detail for the Bank example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 3Skill-based Routing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The data detail for the Skill-based Routing example . . . . . . . . . . . . . . . . . . . . .
Example 4Premium Service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The data detail for the Premium Service example . . . . . . . . . . . . . . . . . . . . . . .
Example 5Teamwork model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The data detail for the Teamwork example . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example 6Multi-site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The data detail for the Multi-site example . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Outbound/blend examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
137
137
137
137
137
139
144
144
145
147
153
153
154
159
159
159
161
167
168
176
176
177
177
185
185
A Reserved Words
187
B Reports
189
Index
193
vii
CONTENTS
CCETOC.fm Page viii Wednesday, August 4, 2004 4:36 PM
viii
CCE.book Page 1 Wednesday, August 4, 2004 4:28 PM
Welcome to Arena Contact Center Edition

1 Welcome
What is Arena Contact Center Edition?

Arena Contact Center Edition is a simulation system developed by Rockwell Software
Inc. for the performance analysis of contact centers. It is built on Rockwell Softwares
Arena simulation system and has been customized to enable its users to build and run
simulation models of contact center operations quickly and easily and to analyze the
results that these models produce.
Intended audience
Arena Contact Center Edition is designed for contact center managers and analysts and
industrial or systems engineers. It is typically deployed as an enterprise business analysis
and productivity tool.
We assume that you are familiar with the basic concepts and terms used in these types of
systems. You are interested in improving business productivity and are responsible for
evaluating and predicting the impact of proposed strategic and tactical changes to help
improve performance. A familiarity with computers and the Microsoft Windows
operating system is assumed. A familiarity with the concepts and terms used in simulation
is also helpful.
Simulation of contact centers

For contact center managers and analysts, their planning problems are far easier to
describe than to model or to solve.
Ive got my staffing budget for the next fiscal year, but I dont know how many
people I need to make service levels, what shifts to hire for, or what skills to train my
workers on.
Service levels look pretty good right now, but our peak season is coming up. What I
dont know is how badly our service levels and abandonment rates will suffer if our
forecasts turn out to be too low.
Our service levels are in bad shape. We are considering either hiring an outsourcer to
help share the handling load or extending our hours. I wish I knew where to get the
most bang for the buck.
My telecomm guy has a new set of routing scripts to make use of some of our
advanced phone switch capabilities. I wonder how this is going to impact our average
speed of answer and our staff utilization.
Marketing has come up with a new program giving our preferred customers a
special priority when they contact us with questions. What Im worried about is how
this new program will affect the waiting times that the rest of our customers
experience.
Weve been asked to provide telephone service and support for another business unit.
Theyre asking us how much staff we need to hire or cross-train in order to handle this
increased load.
Contact center managers have traditionally attacked these types of problems with several
methods, including gut feel estimates, back-of-the-envelope calculations, elaborate
spreadsheets, and analytical queueing formulas such as Erlang C. Each of these
approaches, however, has significant limitations when applied to contact centers and contact center networks.
Simulation is the only analysis method that can effectively and accurately model a contact
center (or a network of contact centers). Such models can be used to study the performance of the system. The simulation method is based on creating a computerized copy
of the actual contact center system and running this system on the computer for a period
of time representing a day, a week, or a month.
In particular, simulation explicitly models the interaction between contacts (e.g., calls or
email), routes, and agents, as well as the randomness of individual contact arrivals and
handle times.
By using simulation, managers and analysts translate contact center data (forecasts,
contact-routing vectors, contact-handle time distributions, agent schedules, agent skills,
etc.) into actionable information about service levels, customer abandonment, agent
utilization, first-contact resolution, and other important contact center performance
measures. These results are used to support key management decisions that drive contact
center operations and expenditures.
1 Welcome
Agent
AgentPopulation
Population
(#
(#of
ofAgents,
Agents,Skills,
Skills,Priorities,
Priorities,
Shifts,
Shifts,Breaks
Breaks))
1 WELCOME TO ARENA CONTACT CENTER EDITION
Routing
RoutingScripts
Scripts
(By
(ByContact
ContactName)
Name)
Contact
ContactCenter
Center
Simulation
Simulation
Model
Model
Contact
ContactCenter
Center
Performance
Performance
Statistics
Statistics
Call-Volume
Call-VolumeForecasts
Forecasts
(By
(ByContact
ContactName,
Name,Time
TimeSlots)
Slots)
Center
CenterConfiguration
ConfigurationData
Data
(Hours
(Hoursof
ofOperation,
Operation,
Trunk
Line
Capacity,
etc.)
Trunk Line Capacity, etc.)
Arena Contact Center Edition: A custom-designed simulation

system for contact centers
The successful use of simulation in many contact center environments led to the development of Arena Contact Center Edition. It was developed by Rockwell Software in partnership with Onward, a management consulting firm based in Mountain View, California,
specializing in contact center operations.
In conjunction with a team of contact center managers and analysts from many different
types of business environments, Rockwell Software and Onward have designed Arena
Contact Center Edition to:
1. Make it easy for analysts to build accurate and detailed simulation models of contact
centers, ranging from fairly simple to very complex, without extensive simulation or
management science training.
2. Support a process of managing input data into these contact center simulation models
that is as easy and sensible as possible.
3. Have the capacity to deliver real-time statistics, animation, and output statistics that
provide insight into key contact center performance measures.
4. Use standard contact center terminology wherever possible to make the model building and usage process as intuitive as possible for contact center professionals.
Arena Contact Center Edition is a Microsoft Windows operating system-based

simulation system. It is one of a family of application solution templates (ASTs) built on
top of the Arena simulation system, leveraging Arenas development environment to
create a focused and easy-to-use tool for contact center managers and analysts.
Where can I go for help?

Our commitment to your success starts with the suite of learning aids and assistance we
provide for Arena. Whether youre new to simulation or a seasoned veteran putting a new
tool to use, youll quickly feel at home with the Arena Contact Center Edition.
Reference the users guides

The documentation set includes this manual, Arena Contact Center Edition Users Guide,
which cover the product basics; the Arena Users Guide, which covers the standard
product modules and offers an easy, click-by-click tutorial; and the Variables Guide, a
separate reference booklet providing complete descriptions of Arena variables found in
the Arena product templates.
DOCUMENT CONVENTIONS
Throughout the guides, a number of style conventions are used to help identify material.
New terms and concepts may be emphasized by use of italics or bold; file menu paths are
in bold with a (>) separating the entries (e.g., go to Help > Arena Help); text you are
asked to type is shown in Courier Bold (e.g., in this field, type Work Week), and dialog
and window button names are shown in bold (e.g., click OK).
Explore our examples

Arena is accompanied by a number of sample models that illustrate many of the
commonly used approaches for capturing the essence of manufacturing processes.
Examples are provided for both job shop and flow shop environments. For a description
of and list of Arenas examples, go to Help > Arena Help. On the Contents tab, choose
Model Building Basics, and then select Viewing Arena Example Models.
Get help
Online help is always at your fingertips! Arena incorporates the latest in help features,
including Whats This? help that displays a brief description of fields in dialogs, contextsensitive help on menu and toolbar buttons, and a help button on each of Arenas modules.
Just refer to the Arena help table of contents and index for a list of all help topics.
1 WELCOME TO ARENA CONTACT CENTER EDITION
Use the SMARTs library
Access the Arena Symbol Factory

Arena animations can be enhanced using Arena Symbol Factorys extensive library of
symbols. These symbols can be used for entity, resource, transporter or global pictures; or
as graphic symbols within a model window. You can copy these symbols directly to the
Arena model window, add them to your own libraries (.plb files), or add them to any of
the Arena picture library files.
Get phone support

Rockwell Software provides full support for the entire Arena family of products.
Questions concerning installation, how modules work, the use of the model editor, and the
use of the software are handled by technical support.
ARENA TECHNICAL SUPPORT INCLUDES:
(for users on active maintenance) a technical support hotline and e-mail address
staffed by full-time, experienced professionals
help with installation problems or questions related to the softwares requirements
troubleshooting
limited support regarding the interaction of Arena with other programs
support of the Arena Object Model, which is used in Microsoft Visual Basic for
Applications.
If you call the support line (1.440.646.5800), you should be at your computer and be
prepared to give the following information:
the product serial number

the product version number
the operating system you are using
the exact wording of any messages that appeared on your screen
a description of what happened and what you were doing when the problem occurred
a description of how you tried to solve the problem.
1 Welcome
As you craft models of your own manufacturing processes, use our SMARTs library to
explore how to best use Arena. This suite of tutorial models covers topics ranging from
modeling resources to animation techniques. The library is organized into categories to
help you find the right model with ease. When youre wondering how to take the next step
in your model, browse the SMARTs library for a ready-made solution. For a list of categories and their related SMARTS, go to Help > Arena Help. On the Contents tab, first click
Model Building Basics, and then Learning Arena with SMART Files.
Get Web support

In addition to phone support, the Rockwell Automation Customer Support Center offers
extensive online knowledgebases of tech notes and frequently asked questions for support
of non-urgent issues. These databases are updated daily by our support specialists.
To receive regular e-mail messages with links to the latest tech notes, software updates,
and firmware updates for the products that are of interest to you or to submit an online
support request, register through http://support.rockwellautomation.com/.
And be sure to check the Arena User Zone section of our Web site at www.ArenaSimulation.com. The User Zone links to a peer-to-peer forum on Arena topics and has a link to a
download page where you can check for possible software updates (patches). If you cant
find the answer you need, contact your local representative or Arena technical support.
Get training
Do you need training? Rockwell Software offers a standard training course comprised of
lecture and hands-on workshops designed to introduce you to the fundamental concepts of
modeling with Arena.
We also offer customized training courses designed to meet your specific needs. These
courses can be held in our offices or yours, and we can accommodate one person or
twenty. You design the course thats right for you! Simply contact our consulting services
group to discuss how we can help you achieve success in your simulation efforts.
Get consulting services

Rockwell Automation provides expert consulting and turnkey implementation of the
entire Arena product suite. Please contact your local representative for more information.
Contact us
We strive to help all of our customers become successful in their manufacturing improvement efforts. Toward this objective, we invite you to contact your local representative or
Rockwell Software at any time that we may be of service to you.
Support E-mail: Arena-Support@software.rockwell.com
Corporate E-mail: Arena-Info@software.rockwell.com
Support phone: 1.440.646.5800
URL: www.ArenaSimulation.com
URL: www.rockwellsoftware.com
Introduction to Simulation
This chapter contains excerpts from the simulation textbook written by C. Dennis Pegden,
Randall P. Sadowski, and Robert E. Shannon entitled Introduction to Simulation Using
SIMAN, Second Edition (McGraw-Hill, 1995).
Simulation defined
To simulate, according to Websters Collegiate Dictionary, is to feign, to obtain the

essence of, without the reality. According to Schriber [1987], Simulation involves the
modeling of a process or system in such a way that the model mimics the response of the
actual system to events that take place over time. We will define simulation as the
process of designing a model of a real system and conducting experiments with this model
for the purpose of understanding the behavior of the system and/or evaluating various
strategies for the operation of the system. We consider simulation to include both the
construction of the model and the experimental use of the model for studying a problem.
Thus, you can think of simulation modeling as an experimental and applied methodology
that seeks to accomplish the following:
describe the behavior of systems,
construct theories or hypotheses that account for the observed behavior, and
use the model to predict future behavior; i.e., the effects produced by changes in the
system or in its method of operation.
The terms model and system are key components of our definition of simulation. By
model, we mean a representation of a group of objects or ideas in some form other than
that of the entity itself. By system, we mean a group or collection of interrelated elements
that cooperate to accomplish some stated objective. We can simulate systems that already
exist and those that can be brought into existence; i.e., those in the preliminary or planning
stage of development.
Systems and models

The conceptualization and development of models have played a vital part in our
intellectual activity ever since we began to try to understand and manipulate our
environment. People have always used the idea of models to attempt to represent and
Simulation is one of the most powerful analysis tools available to those responsible for the
design, analysis, and operation of complex processes or systems. In an increasingly
competitive world, simulation has become a very powerful tool for the planning, design,
and control of systems. It is viewed today as an indispensable problem-solving
methodology for engineers, designers, and managers.
express ideas and objects. Historically, modeling has taken many forms: from
communicating through wall paintings to writing complex systems of mathematical
equations for the flight of a rocket through outer space. As a matter of fact, the progress
and history of science and engineering are reflected most accurately in the progress of our
ability to develop and use models.
One of the major elements required in attacking any problem is the construction and use
of a model. We use models because we want to learn something about some real system
that we cannot observe or experiment with directlyeither because the system does not
yet exist, or because it is too difficult to manipulate. A carefully conceived model can strip
away the complexity, leaving only that which the analyst finds important. Such a model
can take many forms, but one of the most usefuland certainly the most often usedis
simulation.
Likewise, the concept of systems plays a critical role in our modern view of the world.
The fundamental idea of thinking about the world in terms of systems and trying to take
the systems approach to attacking problems has become so ingrained in contemporary
practice that we tend to take it for granted. The systems approach tries to consider total
system performance rather than simply concentrating on the parts [Weinberg, 1975]; it is
based on our recognition that, even if each element or subsystem is optimized from a
design or operational viewpoint, overall performance of the system may be suboptimal
because of interactions among the parts. The increasing complexity of modern systems
and the need to cope with this complexity underscore the need for engineers and managers
to adopt a systems approach to thinking.
Although complex systems and their environments are objective (i.e., they exist), they are
also subjective (i.e., the particular selection of included (and excluded) elements and their
configuration is dictated by the problem solver). Different analyses of the same objective
process or phenomenon can conceptualize it into very different systems and environments.
For example, a telecommunications engineer may think of a contact center system as a
collection of trunk lines and routing scripts. The contact center director, however, is more
likely to view the system as the combination of phone lines, scripts, contacts, agents, and
schedules. The vice president in charge of contact center operations may see the system as
the collection of all the centers her company runs/along with all outsourcers under
contract. Hence, several different conceptualizations of any particular real-world system
and thereby several different modelscan simultaneously exist.
System elements are the components, parts, and subsystems that perform a function or
process. The relationships among these elements and the manner in which they interact
determine how the overall system behaves and how well it fulfills its overall purpose.
Therefore, the first step in creating any model is to specify its purpose. There is no such
thing as the model of a system: we can model any system in numerous ways, depending
on what we wish to accomplish. Both the elements and the relationships included must be
2 INTRODUCTION TO SIMULATION
chosen to achieve a specific purpose. The model developed should be as simple as the
stated purpose will allow.
Advantages of simulation
Because its basic concept is easy to comprehend, a simulation model is often easier to
justify to management or customers than some of the analytical models. In addition,
simulation might have more credibility because its behavior has been compared to that of
the real system or because it has required fewer simplifying assumptions and thereby has
captured more of the true characteristics of the real system.
Virtually all simulation models are so-called input-output models; that is, they yield the
output of the system for a given input. Simulation models are therefore run rather than
solved. They cannot generate an optimal solution on their own as analytical models can;
they can only serve as tools for the analysis of system behavior under specified conditions. (The exception is a simulation model used to find the optimum values for a set of
control variables under a given set of inputs.)
We have defined simulation as experimentation with a model of the real system. An
experimental problem arises when a need develops for specific system information that
isnt available from known sources. The following list describes some of the benefits
associated with simulation.
In a contact center, the impact of new types of contacts, new agent schedules, modified contact priorities, contact volumes, and other key inputs can be explored without
disrupting ongoing operations.
New routing scripts or transfer logic can be tested before committing resources to
implementation.
Hypotheses about how or why certain phenomena occur can be tested for feasibility.
Time can be controlled: it can be compressed, expanded, etc., allowing us to speed up
or slow down a phenomenon for study.
The types of simulations of interest here are those used to develop an understanding of the
performance of a system over time. We typically use simulation models to help us explain,
understand, or improve a system. To be effective, simulation must concentrate on some
previously defined problem (otherwise, we do not know what elements to include in the
model or what information to generate and collect). We typically use models to predict
and comparethat is, to provide a logical way of forecasting the outcomes that follow
alternative actions or decisions and (we hope) to indicate a preference among them.
Although this use of models is important, it is by no means its only purpose. Model building also provides a systematic, explicit, and efficient way to focus judgment and intuition.
Furthermore, by introducing a precise framework, a simulation model can effectively
communicate system configuration and assist the thought process.
Insight can be gained about which variables are most important to performance and
how these variables interact.
A simulation study can prove invaluable to understanding how the system really
operates as opposed to how everyone thinks it operates.
New situations, about which we have limited knowledge and experience, can be
manipulated in order to prepare for theoretical future events. Simulations great
strength lies in its ability to let us explore what if questions.
The simulation process

The essence or purpose of simulation modeling is to help the ultimate decision maker
solve a problem. Therefore, to learn to be a good simulation modeler, you must merge
good problem-solving techniques with good software engineering practice. The following
steps should be taken in every simulation study.
1. Problem Definition. Defining the goals of the study clearly so that we know the
purpose; i.e., why are we studying this problem and what questions do we hope to
answer? What is the business impact of these answers?
2. Project Planning. Being sure that we have sufficient personnel, management support,
computer hardware, and software resources to do the job with a relevant timetable.
3. System Definition. Determining the boundaries and restrictions to be used in defining
the system (or process) and investigating how the system works.
4. Conceptual Model Formulation. Developing a preliminary model either graphically
(e.g., block diagrams) or in pseudo-code to define the components, descriptive variables, and interactions (logic) that constitute the system.
5. Preliminary Experimental Design. Selecting the measures of effectiveness to be
used, the factors to be varied, and the levels of those factors to be investigated; i.e.,
what data need to be gathered from the model, in what form, and to what extent.
6. Input Data Preparation. Identifying and collecting the input data needed by the
model.
7. Model Translation. Formulating the model in an appropriate simulation language or
software package such as Arena Contact Center Edition.
8. Verification and Validation. Confirming that the model operates the way the analyst
intended (debugging) and that the output of the model is believable and representative
of the output of the real system.
10
9. Final Experimental Design. Designing an experiment that will yield the desired
information and determining how each of the test runs specified in the experimental
design is to be executed.
10. Experimentation. Executing the simulation to generate the desired data and to
perform a sensitivity analysis.
11. Analysis and Interpretation. Drawing inferences from the data generated by the
simulation.
Problem definition and project planning

It should be obvious that before you can solve a problem you must know what the
problem is. (This is sometimes easier said than done.) Experience indicates that beginning
a simulation project properly may well make the difference between success and failure.
Simulation studies are initiated because a decision maker or group of decision makers face
a problem and need a solution. Often the project is initiated by someone who cant
necessarily make the final decision, but who is responsible for making recommendations.
In such a case, the results of the study may have to serve two purposes simultaneously:
helping the sponsor to formulate the recommendations; and justifying, supporting, and
helping to sell those recommendations.
We begin our analysis by collecting enough information and data to provide an adequate
understanding of both the problem and the system to be studied. A typical project begins
with the description of the situation to be modeled in a general and imprecise way, in
terms such as service levels, agent utilization, abandonment rates, or other key system
performance measures. We must view the problem description as a set of symptoms
requiring diagnosis. We begin, therefore, by diagnosing the symptoms; then we define the
problem; and, finally, we formulate a model.
To make that diagnosis, we must become thoroughly familiar with all relevant aspects of
the organizations operations, including influential forces (or factors) outside the
organization and the subjective and objective aspects of the problem. Minimally, we
should perform the following steps.
1. Identify the primary decision maker(s) and the decision-making process relative to the
system being studied.
2. Determine the relevant objectives of each of those responsible for some aspect of the
decision.
3. Identify other participants in the final decision (especially those likely to oppose
changes in the system) and determine their objectives and vested interests.
11
12. Implementation and Documentation. Putting the results to use, recording the
findings, and documenting the model and its use.
4. Determine which aspects of the situation are subject to the control of the decision
maker(s) and the range of control that can be exercised.
5. Identify those aspects of the environment or problem context that can affect the outcome of possible solutions but that are beyond the control of the decision maker(s).
An important aspect of the planning phase involves ensuring that we have considered
certain factors critical to project success:
Clearly defined goals. Do we know the purpose of the studyi.e., why are we doing
it and what do we expect to find?
Sufficient resource allocation. Are we sure that there is sufficient time, personnel,
and computer hardware and software available to do the job?
Management support. Has management made its support for the project known to all
concerned parties?
Project plans and schedules. Are there detailed plans for carrying out the project?
What are the key dates?
Competent project manager and team members. Are we assured of having the
necessary skills and knowledge available for successful completion of the project?
Responsiveness to the clients. Have all potential users of the results been consulted
and regularly apprised of the projects progress?
Adequate communication channels. Are we continually concerned that sufficient
information is available on project objectives, status, changes, user or client needs,
etc., to keep everyone (team members, management, and clients) fully informed as the
project progresses?
The major thrust of the planning and orientation period is the determination of the explicit
goals or purpose of the simulation project. Simulation experiments are conducted for a
wide variety of purposes, including the following:
12
Evaluation: determining how well a proposed system design performs in an absolute

sense when evaluated against specific criteria.
Comparison: comparing several proposed operating policies or procedures or other
input scenarios.
Prediction: estimating the performance of the system under some projected set of
conditions.
Sensitivity analysis: determining which of many factors affect overall system
performance the most.
Optimization: determining exactly which combination of factor levels produces the

best overall system response.
Functional relations: establishing the nature of the relationships among one or more
significant factors and the systems response.
Style definition and model formulation

The essence of the modeling art is abstraction and simplification. We try to identify that
small subset of characteristics or features of the system that is sufficient to serve the
specific objectives of the study. So, after we have specified the goal or purpose for which
the model is to be constructed, we then begin to identify the pertinent components. This
process entails itemizing all system components that contribute to the effectiveness or
ineffectiveness of its operation. After we have specified a complete list, we determine
whether each component should be included in our model; this determination may be
difficult because, at this stage of model development, a components significance to the
overall goal is not always clear. One of the key questions to be answered is whether a
particular component should be considered part of the model or part of the outside
environment, which is represented as inputs to the model.
In general, we have little difficulty deciding on the output variables. If we have done a
good job specifying the goals or purposes of the study, the required output variables
become apparent. The real difficulty arises when we try to determine which input and
status variables produce the effects observed and which can be manipulated to produce the
effects desired.
We also face conflicting objectives. On the one hand, we try to make the model as simple
as possible for ease of understanding, ease of formulation, and computational efficiency.
13
Although not exhaustive, this list identifies the most common simulation goals or
purposes. The explicit purpose of the model has significant implications for the entire
model-building and experimentation process. For example, if a models goal is to evaluate
a proposed (or existing) system in an absolute sense, then the model must be accurate; and
there must be a high degree of correspondence between the model and the real system. On
the other hand, if the goal for a model is the relative comparison of two or more systems
or operating procedures, the model can be valid in a relative sense even though the
absolute magnitude of responses varies widely from that which would be encountered in
the real system. The entire process of designing the model, validating it, designing
experiments, and drawing conclusions from the resulting experimentation must be closely
tied to the specific purpose of the model. No one should build a model without having an
explicit experimental goal in mind. Unfortunately, the analyst does not always understand
the real-world problem well enough at first to ask the right questions. Therefore, the
model should have an easily modified structure so that additional questions arising from
early experimentation can be answered later.
On the other hand, we try to make the model as accurate as possible. Consequently, we
must simplify realitybut only to the point where there is no significant loss of accuracy
of outputs with respect to the studys objectives.
We want to design a model of the real system that neither oversimplifies the system to the
point where the model becomes trivial (or worse, misleading) nor carries so much detail
that it becomes clumsy and prohibitively expensive. The most significant danger lies in
having the models become too detailed and including elements that contribute little or
nothing to understanding the problem. Frequently, the analyst includes too much detail,
rather than too little. The inexperienced tend to try to transfer all the detailed difficulties in
the real situation into the model, hoping that the computer will somehow solve the problem.
This approach is unsatisfactory: it increases programming complexity (and the associated
costs for longer experimental runs), and it dilutes the truly significant aspects and relationships with trivial details. The definition of the model boundary is usually a tradeoff
between accuracy and cost. The greater the degree of detail to be modeled, the more precise and expensive the required input data. Therefore, the model must include only those
aspects of the system relevant to the study objectives.
One should always design the model to answer the relevant questions and not to imitate
the real system precisely. According to Paretos law, in every group or collection of
entities there exist a vital few and a trivial many. In fact, 80% of system behavior can be
explained by the action of 20% of its components. Nothing really significant happens
unless it happens to the significant few. Our problem in designing the simulation model is
to ensure that we correctly identify those few vital components and include them in our
model.
Once we have tentatively decided which components and variables to include in our
model, we must then determine the functional relationships among them. At this point, we
are trying to show the logic of the model; i.e., what happens. Usually we use a flowchart
or pseudo-code to describe the system as a logical flow diagram.
Experimental design
We have defined simulation as being experimentation via a model to gain information
about a real-world process or system. It then follows that we must concern ourselves with
the strategic planning of how to design an experiment (or experiments) that will yield the
desired information for the lowest cost. The next step, therefore, is to design an experiment that will yield the information needed to fulfill the studys goal or purpose.
The design of experiments comes into play at two different stages of a simulation study. It
first comes into play very early in the study, before the model design has been finalized.
As early as possible, we want to select which measures of effectiveness we will use in the
study, which factors we will vary, and how many levels of each of those factors we will
investigate. By having this fairly detailed idea of the experimental plan at this early stage,
we have a better basis for planning the model to generate the desired data efficiently.
14
The design of a computer simulation experiment is essentially a plan for acquiring a

quantity of information by running the simulation model under different sets of input
conditions. Design profoundly affects the effective use of experimental resources for two
reasons:
The design of the experiment largely determines the form of statistical analysis that
can be applied to the results.
The success of the experiment in answering the questions of the experimenter (without excessive expenditure of time and resources) is largely a function of choosing the
right design.
We conduct simulation studies primarily to learn the most about the behavior of the system
for the lowest possible cost. We must carefully plan and design not only the model but also
its use. Thus, experimental designs are economical because they reduce the number of
experimental trials required and provide a structure for the investigators learning process.
Input data
Stochastic systems contain one or more sources of randomness. The analyst must be
concerned about data related to the inputs for the model such as the contact-volume
forecasts, contact-arrival patterns, and contact-handle times. Although data gathering is
usually interpreted to mean gathering numbers, this interpretation addresses only one
aspect of the problem. The analyst must also decide what data is needed, what data is
available, whether the data is pertinent, whether existing data is valid for the required
purpose, and how to gather the data.
The design of a stochastic simulation model always involves choosing whether to
represent a particular aspect of the system as probabilistic or deterministic. If we opt for
probabilistic and if empirical data exist, then we must make yet another decision. Will we
sample directly from the empirical data, or will we try to fit the data to a theoretical
distribution and, if successful, sample from the theoretical distribution? This choice is
fundamentally important for several reasons.
15
Later, after we have developed the model, verified its correctness, and validated its
adequacy, we again need to consider the final strategic and tactical plans for the execution
of the experiment(s). We must update project constraints on time (schedule) and costs to
reflect current conditions, and we must impose these constraints on the design. Even
though we have exercised careful planning and budget control from the beginning of the
study, we must now take a hard, realistic look at what resources remain and how best to
use them. At this point, we adjust the experimental design to account for remaining
resources and for information gained in the process of designing, building, verifying, and
validating the model.
First, using raw empirical data implies that we are only simulating the past; by using data
from one year, we replicate the performance of that year but not necessarily of future
years. When sampling directly from historical data, the only events possible are those that
transpired during the period when the data was gathered. It is one thing to assume that the
basic form of the distribution will remain unchanged with time; it is quite another to
assume that the idiosyncrasies of a particular year will always be repeated.
Second, it is much easier to change certain aspects of the input if theoretical random
variate generation is being used; i.e., there is greater flexibility. For example, if we want to
determine what happens if inputs increase by 10% per week, we need only increase the
mean arrival rate of the theoretical distribution by the required 10%. On the other hand, if
we are sampling directly from the empirical data, it is not clear how we increase the
contact arrival rate by the required amount.
Third, it is highly desirable to test the sensitivity of the system to changes in the
parameters. For example, we may want to know how much the contact arrival rate can
increase before system performance deteriorates to an unacceptable degree. Again,
sensitivity analysis is easier with theoretical distributions than with sampling directly
from empirical data.
The problem is exacerbated when no historical behavioral data exist (either because the
system has not yet been built or because the data cannot be gathered). In these cases, we
must estimate both the distribution and the parameters based on theoretical considerations.
Verification and validation

After the development of the model is functionally complete, we should ask ourselves a
question: Does it work? There are two aspects to this question. First, does it do what the
analyst expects it to do? Second, does it do what the user expects it to do? We find the
answers to these questions through model verification and validation. Verification seeks to
show that the computer program performs as expected and intended, thus providing a correct logical representation of the model. Validation, on the other hand, establishes that
model behavior validly represents that of the real-world system being simulated. Both
processes involve system testing that demonstrates different aspects of model accuracy.
Verification can be viewed as rigorous debugging with one eye on the model and the other
eye on the model requirements. In addition to simply debugging any model development
errors, it also examines whether the code reflects the description found in the conceptual
model. One of the goals of verification is to show that all parts of the model work, both
independently and together, and use the right data at the right time.
The greatest aid to program verification is correct program design, followed by clarity,
style, and ease of understanding. Very often, simulation models are poorly documented,
especially at the model statement level. Verification becomes much easier if the analyst
comments the model liberally. This includes comments wherever Arena Contact Center
16
enables the modeler to enter them, as well as separate documentation of model assumptions, model inputs, and logical relationships.
Validation is the process of raising to an acceptable level the users confidence that any
simulation-derived inference about the system is correct. Validation is concerned with
three basic questions:
Are the model-generated behavioral data characteristic of the real systems behavioral
data?
Does the simulation model user have confidence in the models results?
Consequently, we are concerned with tests that fall into three groups: tests of model
structure, tests of model behavior, and tests of the policy implications of the model.
Because a model is constructed for a specific purpose, its adequacy or validity can only be
evaluated in terms of that purpose. We try to build a model that creates the same problems
and behavioral characteristics as the process or system being studied. Validation occurs
throughout model development, beginning with the start of the study and continuing as
the model builder accumulates confidence that the model behaves plausibly and generates
symptoms or modes of behavior seen in the real system. Validation then expands to
include persons not directly involved in constructing the model.
Validation is a communication process requiring the model builder to communicate the
basis for confidence in a model to a target audience. Unless that confidence can be transferred, the models usefulness will never be realized. Thus, through verification testing,
we develop personal confidence in the model and, through validation measures, transfer
that confidence to others.
We must realize that there are degrees of validation; it is not merely an either-or notion.
Validation is not a binary decision variable indicating whether the model is valid or
invalid. No one or two tests can validate a simulation model. Rather, confidence in the
usefulness of a model must gradually accumulate as the model passes more tests and as
new points of correspondence between model and reality are found. Validation testing
occurs continually in the process of designing, constructing, and using the model.
We should also remember that verification and validation are never really finished. If the
model is to be used for any period of time, the data and the model itself will need periodic
review to ensure validity. Verification and validation are intertwined and proceed
throughout the study. They are not tacked on toward the end of the study; rather, they are
an integral process that starts at the beginning of the study and continues through model
building and model use. It should also be pointed out that involving the ultimate user in
the entire simulation process makes validation much easier.
17
Does the model adequately represent the real-world system?
Documentation and implementation

At this point, we have completed all the steps for the design, development, and running of
the model and for analyzing the results; the final elements in the simulation effort are
implementation and documentation. No simulation project can be considered successfully
completed until its results have been understood, accepted, and used. Although documentation and implementation are obviously very important, many studies fall short in the
reporting and explaining of study results.
Documentation and reporting are closely linked to implementation. Careful and complete
documentation of model development and operation can lengthen the models useful life
and greatly increase the chances that recommendations based on the model will be
accepted. Good documentation facilitates modification and ensures that the model can be
usedeven if the services of the original developers are no longer available. In addition,
careful documentation can help us to learn from previous mistakes; it may even provide a
source of submodels that can be used again in future projects.
Amazingly, modelers often spend a great deal of time trying to find the most elegant and
efficient ways to model a system, and then they throw together a report for the sponsor or
user at the last minute. If the results are not clearly, concisely, and convincingly presented,
they will not be used. If the results are not used, the project is a failure. Presenting results
is as critical a part of the study as any other part, and it merits the same careful planning
and design.
Several issues should be addressed in model and study documentation: appropriate
vocabulary (i.e., suitable for the intended audience and devoid of jargon), concise written
reports, and timely delivery. We must also ensure that all reports (both oral and written)
are pertinent and address the issues that the sponsor or user considers important.
References
McKay, K. N., J. A. Buzacott, and C. J. Strang (1986), Software Engineering Applied to
Discrete Event Simulation, in Proceedings of the 1986 Winter Simulation Conference, Washington, D.C., pp. 485-493.
Schriber, T. J.(1987), The Nature and Role of Simulation in the Design of Manufacturing
Systems, in Simulation in CIM and Artificial Intelligence Techniques, J. Retti and
K. E. Wichmann (eds.), Society for Computer Simulation, pp. 5-18.
Sheppard, S. (1983), Applying Software Engineering to Simulation, Simulation, vol.
10, no. 1, pp. 13-19.
Weinburg, G. M. (1975), An Introduction to General Systems Thinking, John Wiley &
Sons, Inc., New York, NY.
18
CCE.book Page 19 Thursday, March 18, 2004 12:00 PM
General Concepts
This chapter provides a high-level overview of the components of a model built using
Arena Contact Center Edition. In particular, this chapter explains the terminology used
within the software and the type of information that is needed to represent the way in
which contacts arrive and are processed in a contact center system, which is referred to as
the Contact Center Core Process. The major modeling elements are also described in
some detail.
Once you have read this chapter, you will have a better understanding of the process of
creating a model with Arena Contact Center Edition.
Overview
As you build your contact center models, it may be helpful to keep in mind the Contact
Center Core Process, as illustrated below.
Contact
Arrival
Contact
Processing
Contact
Termination
The basic components of this process are:
Contacts
Arrival Patterns
Trunk Groups
Routing Scripts
Schedules
Agents
19
3 General Concepts
The basic process of contact center simulation is to generate a stream of arriving contacts,
assign them to trunk lines, and route them through the center to an agent. To create a simulation model of a contact center or network of contact centers, you will describe the
sequence of events that occur as contacts move through the system, from the arrival of the
contacts at the contact center to successful resolution. You will also need to specify information about the contact center itself (trunk-line capacity, agent skills, agent schedules,
etc.).
The relationships between these components are illustrated below.
Trunk Groups
Individual
Agents
Routing Scripts
Queueing to
Parent
Groups
Contacts
Queueing to
Agent
Groups
Parent Groups
(containing one or
more Agent Groups)
Agent
Skills
Agent Groups
Agent
Schedules
Pattern
In addition, the length of the simulation run (see Planning horizon) and granularity of
data specification and collection (see Timeslots) need to be specified. Animation and
performance measure reporting are also important components of models.
Planning horizon
The planning horizon is defined as the time period that is being examined by a particular
simulation model. The planning horizon is typically one day, one week, or one month.
Timeslots
The planning horizon is broken into specific timeslots for data specification and
collection. These intervals are typically 30 minutes or one hour long.
With Arena Contact Center Edition, the basic unit of time is the minute. With the
exception of the planning horizon, trunk costs, agent costs, and contact service level, all
inputs are in terms of minutes or fractions of minutes.
20
3 GENERAL CONCEPTS
Contact types
Describing the different types of contact is generally the starting point for contact center
modeling and analysis. Each contact name represents a particular customer request for
agent services. It is characterized by the expected talk time, as well as the associated
arrival pattern and the trunk group on which the contacts enter the center.
The following more advanced aspects of contact behavior may also be modeled using
Arena Contact Center Edition:
Abandonment
After-Contact Work
Prioritization
Contact Back
Data sources
Information about contact volumes is typically taken from forecasts while expected talk
time is available either from contact center ACD databases or from a contact centers
contact-tracking system.
Contact patterns describe the arrival of contacts across the planning horizon by specifying
the distribution of contacts across each timeslot. Within the Pattern module, this distribution is specified in terms of expected contact counts for each timeslot.
The arrival times of contacts within the timeslot are randomly generated according to a
Poisson process with the defined rate. Therefore, the actual number of contacts arriving
within the timeslot may differ from the expected number.
EXAMPLE
Suppose that the planning horizon is one day (24 hours), the timeslots are 60 minutes long.
Then, if the arrival pattern specifies that 240 contacts are handled during the 10:00 AM11:00 AM timeslot, the simulation model would assume 240 expected contacts during the
10:00 AM-11:00 AM timeslot. The Poisson arrival rate for the timeslot is 0.25 (60/240) or,
on average, one contact every 15 seconds.
Data sources
Arrival pattern data is available either from contact center ACD databases or from a
contact centers tracking system.
21
3 General Concepts
Arrival pattern
Trunk Groups
Trunk Groups represent groups of phone lines that are dedicated to a particular set of
contact types. A single trunk group can serve multiple contact types and names, but only
one trunk group may serve each contact name. Trunk groups have an associated capacity
(# of lines), cost, and a default routing script and contact priority. Any incoming contact
assumes the default priority and follows the default routing script unless these attributes
are overridden at the contact level.
Note that trunk-line capacity determines the maximum number of contacts that the contact
center can accommodate simultaneously. If a trunk line is not available when a contact
attempts to enter the center, the contact is blocked and does not gain entry. Otherwise, the
contact is attached to a trunk line and remains with that particular line until exiting the
center or until transferring to another trunk line.
Data sources
Fundamental components of the contact center infrastructure, trunk-line organization, and
capacity are typically specified in the phone-switching hardware.
Routing Scripts
Routing Scripts are sequences of actions that control the flow of contacts through the
centers system. This will result in contacts being connected with agents, leaving
messages, being disconnected, or abandoning the center.
From a simulation modeling perspective, scripts allow contact flow logic to be categorized
into six general areas:
1. Time delays (playing announcements, music, doing nothingwaiting)
2. Conditional route branching (caller-entered information, center dynamics)
3. Allocation of contacts into queues (single or simultaneous) or message ports
4. Contact prioritization within queues (ranking)
5. Contact flow between queues (movement of contacts out of and into queues, overflow
from one queue into another)
6. Contact flow between scripts
Data sources
These command sequences are generally referred to as scripts, although each switch
vendor has a different name for their particular variety (i.e., Vector, Telescript, Call
22
3 GENERAL CONCEPTS
Control Table). These scripts specify the actions, activities, and states that each contact
undergoes as it attempts to reach an agent.
The process of creating routing scripts that match the behavior of your ACD switch and
assigning these scripts to specific contact names is described in more detail in Chapter 6.
Agent Skill Sets

Agent Skill Sets are composed of three elements that define how particular contacts are
processed. The agents repertoire of handling skills specifies what contacts the agent is
skilled to handle, the priority (or order) in which the agent will perform available work,
and the agents proficiency in each contact name, expressed as a multiplier of average talk
time for the contact name.
Data sources
Schedules
Schedules dictate when agents are available to handle contacts. Each schedule specifies
on-duty shifts for each day in the planning horizon. In addition to phone time, these
schedules can include lunches, breaks, meetings, or other off-duty time that is spent away
from the phones.
Data sources
Agent schedules can usually be obtained from a human resources or a planning and
analysis group.
Agent Groups
Agents are the primary resource of the contact center. An Agent Group represents a group
of agents within the contact center who have the same skill sets and follow the same
schedule. From a modeling perspective, an agent group is a set of identical agents. In
building a model, the key questions to answer regarding agent groups are:
How many agents are in this group?

What hours do these agents work?
What types of contacts can an agent of this type handle, and in what priority order?
How long does it take for these agents to handle each contact name?
23
3 General Concepts
Estimates of handling proficiency may be obtained from careful study of handle time
statistics collected from the ACD database or tracking system, or based on the expertise of
group managers. For example, a group of experienced agents may have a very high
proficiency level, while a group of newly hired agents may experience significantly
higher handle times.
Data sources
The definition of agent groups may depend on the purpose of the simulation study and
will not necessarily correspond to the group definition within the organization. However,
the agent lists and skill sets maintained by the human resources or planning and analysis
group are a good starting point.
Parent Groups
A Parent Group is a collection of agent groups. Parent groups are used to:
Implement simultaneous queueing

Simplify routing scripts by masking the underlying complexity of agent group definitions (multiple schedules, sites, groups, etc.)
Collect statistics across a set of agent groups
Data sources
Parent group definition typically supports contact routing and may depend on the purpose
of the simulation study. However, if a model is being made of current contact center
operations, insight into parent groupings may be obtained from examination of existing
routing scripts.
Queues
Queues are the mechanism by which contacts and agents interact in the contact center.
Each agent group has a queue associated with it to hold its contacts while they wait to be
handled. Contacts may move from one queue (i.e., one agent group) to another before
being serviced, based upon the routing script that is assigned to that contact name.
Note that while queues are an important concept to understand, the data and logic associated with queues are specified in the Agent and Script modules and related modules
located on the Script panel (i.e., Queue for Agent module, Transfer to Agent module, etc.).
Animation
Simulation animation is intended to provide dynamic graphical insight into contact center
conditions. A variety of plots, graphs, and counters are available to animate specific
contact center elements. These animations are often useful for validation and verification
of the contact center model.
Performance measures/reporting
In addition to a default report covering the entire planning horizon, there are focused
reports that collect and report data by user-defined timeslot. These results quantify the
24
3 GENERAL CONCEPTS
impact of various changes on contact center operations. Contact center reports are available for:
Contact counts
Contact times
Agent utilization
Trunk utilization
Overflow
The output of these reports is discussed in detail in Chapter 7.
3 General Concepts
25
26
Features
This chapter is intended to provide a description of all Arena Contact Center Edition
features. Once you have read this chapter, you will have a better understanding of the
capabilities of the software and the simulation process.
The features described in this chapter are organized as follows:
Different stages in the contact life span

Queue behavior
Routing script construction
Costing
Miscellaneous features
Different stages in the contact life span

This section describes the potential avenues that a contact may travel as it moves through
the contact center, as shown in Figures 4.1 and 4.2. Each stage is described and identified
as either optional or required to the model. Particular attention is given to the module(s)
involved in each stage.
If not blocked,
disconnected, or abandoned, the contact
reaches the front of its queue here.
Contact arrives
in Contact Center
If not blocked, the contact follows its

script and begins to queue for agent
group or parent group
Contact seizes agent,

begins to receive service
here.
4 Features
TIME
If no trunk line is available, the

contact is blocked from entering the
Contact Center.
While queueing, a contact may

become disconnected or leave a
message and hang up.
Depending on its abandonment distribution

and amount of time spent in queue, the
contact may abandon the queue.
Depending on model input, these contacts may be eligible for contact back.
Figure 4.1 The path of a contact before processing begins
27
Contact begins to
receive service from
an agent
Contact completes
service
Contact receives service from primary agent.

Depending upon input data, contact may also
receive service from conference agent.
Contact transferred to
another agent or to a script
(remains in the center)
ACW*
TIME
*ACW: "After Contact Work" is time spent by an agent

on finishing a contact (paperwork, logging, etc.) after the
contact itself has been completed.
Contact departs center (may

contact back based on model
input data)
Figure 4.2 The path of a contact after processing begins
Contact arrival (required)

For each timeslot, contacts of a particular name arrive according to a Poisson process with
an arrival rate based on the expected contact volumes per timeslot, which are defined in
the associated pattern module. Upon arrival at the contact center, a contact is assigned to a
trunk line from the trunk group associated with that contact name.
Arrivals may also be generated by contact returning to the contact center (contact backs)
after being blocked, abandoned, or disconnected, as well as contact backs due to messages
or previously served but unresolved contacts.
RELEVANT MODULES AND RELATED CONCEPTS
Patterns are defined in the Pattern module and associated with a contact name in the
contact module.
Trunk groups are defined in the Configuration module and associated with a contact
name in the Contact module.
Blocked contacts (required)

When there are no available trunk lines in the relevant trunk group to accommodate an
arriving contact, the contact is blocked. Depending on the model, blocked contacts may
attempt to contact back following a specified delay.
28
4 FEATURES
Contact back is defined in the Contact Back section of the Contact module. It is
described further in this section.
Offered contacts (required)

When an arriving contact is able to secure a trunk line, it is considered to be offered to the
contact center for service. The newly offered contact then begins to follow the routing
logic specified in its associated script.
Scripts are defined by connecting a series of modules located on the Script panel and
are associated with trunk groups in the Configuration module. Contacts either inherit
their routing scripts by default through their associated trunk group or specifically
identify a routing script by overriding the trunk default in the Advanced section of the
Contact module.
Abandoned contacts (optional)

Abandonment occurs when the contactor terminates the contact before reaching an agent.
For each contact name, abandonment may be modeled by specifying a distribution for the
amount of time a contactor will wait prior to abandoning the center. For each contact, a
value is generated from this distribution to determine at what time the contactor will
abandon if not yet connected with an agent.
Once a contact abandons the contact center, it may contact back, depending on the model.
Abandonment is defined in the Abandonment section of the Contact module.

Once defined for a contact, abandonment logic is initiated during Contact Arrival and
Transfer to Script stages of the contact life span that are described in this section.
described further in the Contact back section below.
Disconnected contacts (optional)

Contacts may be disconnected (i.e., dispatched from the contact center) by their controlling routing script.
Once a contact has been disconnected, it may contact back, depending on the model.
29
4 Features
Contacts may only be disconnected via the Disconnect module located on the Script
panel.
Contacts leaving messages (optional)

Contacts may be directed to leave a message by their controlling routing script. Immediately following the completion of the recorded message, the contact is dispatched from the
contact center.
Once a contact has left a message, it may contact back, depending on the model.
Contacts may only be directed to leave a message via the Message module located on
the Script panel.
Handled contacts (required)

When a contact is connected to an agent, it is considered to be handled. The agent then
assumes control over the contact from its routing script and proceeds to address its needs.
A list of contact names is defined for each agent group thereby defining which contacts
they are skilled to handle. A model error is generated if a script directs a contact to an
agent who is not skilled for that contact name.
The first agent to whom a contact is connected within the contact center is considered to
be the primary agent. If the primary agent transfers the contact, additional service may be
provided by a secondary agent.
30
Handling skills are defined in the Talk Time section of the Agent module.
Contacts are connected to agents through the queueing process triggered by the Queue
for Agent module located on the Script panel and described in greater detail in the
following section.
Contact transfer is defined via the Transfer to Agent module located on the Script
panel. It is described further in the Contact transfer section below.
4 FEATURES
Talk time (required)

Talk time is the time an agent spends on the line with a contactor. The expected talk time
for a contact name is specified in the main section of the Contact module. This value is
used as the mean of an exponential distribution. In the advanced Contact module dialog,
the basic exponential talk time distribution can be replaced with any general distribution.
Individual talk times for each contact are generated whenever the contact is assigned to an
agent. Within the Agent module, talk time multipliers are specified to account for agent
proficiency. The generated contact time is multiplied by this factor to determine the actual
talk time for the contact.
Expected talk time is specified in the Contact module. The distribution for talk time
can be overridden in the Advanced section of the Contact module.
Adjustments to talk time to reflect agent proficiency are made through multipliers
defined within the Talk Time section of the Agent module.
Conference (optional)
Conferencing describes the situation where an agent can include an additional agent (like
a supervisor) for assistance in contact resolution. Conference is modeled using the
Conference module located on the Script panel. This module is for use within the Queue
for Agent module only. The Queue for Agent module has three Advanced features that
allow external logic to be specified at three different times; After Seizing Agent, After
Talk Time, and Prior to Post Contact Work. The Conference module must be used with the
After Talk Time option. By connecting this module to the special exit point created for the
advanced Queue for Agent option, a contact can be conferenced with another agent after
the primary agents talk time is complete.
Conference is an optional consideration in that a contact will only be conferenced if an

agent is available immediately to be included in the conference.
Multiple-agent conferencing can be modeled by connecting a series of Conference
modules. The original agent is not released until all the conferences are complete.
However, each conference is performed in series. Therefore, the first conference agent is
not a part of the second conference with the next conference agent, and so on.
31
4 Features
A conference is done in addition to talk time. The length of the conference is determined
by sampling from the conference time distribution defined in the Conference module and
adjusting it using the conference time multiplier (to account for agent proficiency) associated with the conferenced agent.
Contacts requiring conference are specified by the contacts script. The contact must
be directed to a Conference module. This module can only be used in the After Talk
Time external logic of a Queue for Agent module.
Specifics of which agent to be included in the conference and the conference time are
detailed in the Conference module from the Script panel.
Transfer (optional)
Transfer describes the situation where the primary agent routes a contact to a transfer
agent who then takes over complete responsibility for the contact. Transfer is modeled by
using the Transfer to Agent module in a contacts script.
The Transfer to Agent module is for use within the Queue for Agent module only. The
Queue for Agent module has three Advanced features that allow external logic to be
specified at three different times: After Seizing Agent, After Talk Time, and Prior to Post
Contact Work. The Transfer to Agent module must be used with the Prior to Post Contact
Work option. By connecting this module to the special exit point created for the advanced
Queue for Agent option, a contact can be directed to another agent after the first agents
tasks are complete.
Multiple-agent transfer can be modeled by connecting a series of Transfer to Agent
modules. The original agent is released before the contact is transferred to the next agent.
Each transfer is performed in series. Therefore, the primary agent does not participate in
the next (transfer) agents activities, and so on.
Transfer takes place immediately following the completion of talk time.
Transfer is an optional consideration in that a contact will only be transferred if the
transfer agent is available immediately to receive the contact (i.e., the contact will not be
re-queued).
Contacts potentially requiring transfer are specified by the contacts script. The
contact must be directed to a Transfer to Agent module. This module can only be used
in the Prior to Post Contact Work external logic of a Queue for Agent module.
Specifics of which agent and the talk time incurred with the transfer agent are detailed
in the Transfer to Agent module from the Script panel.
After-contact work (optional)

To model the time the primary agent must spend completing a contact (wrap-up,
documentation, research, etc.) after they are finished with the contactor, an After Contact
32
4 FEATURES
Time distribution may be specified in the Advanced section of the Contact module. An
individual after-contact time is generated from this distribution for every contact of this
contact name.
The primary agent completes all after-contact work, beginning immediately upon completion of primary service. Primary service includes any activity if specified in the After Talk
Time logic of the Queue for Agent module (e.g., conferences with other agents).
The After Contact Time distribution is defined in the Advanced section of the Contact
module.
Talk time is described earlier in this section.
Contact back (optional)

Contacts can terminate in one of the following ways:
Blocked
Abandoned
Disconnected
Served
Message
In each case, there is a certain probability that the contactor will attempt to return to the
contact center for more service. Therefore, for each case, the probability of contact back
and a distribution on the amount of time the contactor will wait before contacting back
may be specified.
Served contacts are those that leave the contact center immediately following service from
an agent.
4 Features
Contact back is defined in the Contact Back section of the Contact module.
Blocked contacts are described earlier in this section.
Abandoned contacts are described earlier in this section.
Disconnected contacts are described earlier in this section.
Handled contacts are described earlier in this section.
Contacts leaving messages are described earlier in this section.
Queue behavior
The relationship between contacts and queues can be divided primarily into three
categories:
33
Queue construction. What is the relationship between queues and agents?
Queue ranking. What happens to the contact while waiting within the queue?
Agent selection. What happens when the contact gets to the front of the queue?
A discussion of skill-based routing, a powerful routing strategy linking all three categories,
is also included.
Queue construction
Queues are automatically created for each defined agent group. Contacts are placed in an
agent group queue via the Queue for Agent module located in the Script panel. The only
difference, from a functionality standpoint, is whether the associated group is an Agent
Group or a Parent Group.
Direct queueing involves placing a contact in the queue directly associated with an agent
group. These contacts will be served only by members of that specific agent group.
Simultaneous queueing enables a contact to wait for an agent from any number of agent
groups. This is accomplished by queueing the contact to a parent group, effectively queueing it simultaneously to all member agent groups. The contact will then be assigned to an
available agent from any of the member agent groups. This type of simultaneous queueing
is provided by most ACD vendors.
An agent group may be a member of multiple parent groups in addition to having its own
direct queue to serve. Note that this implies that there can be situations in which multiple
contacts waiting in multiple queues are simultaneously requesting service from that agent
group. It is important to remember that each agent group can potentially serve multiple
queues, each being physically separate from the others.
Queue ranking
All queues are ranked based on the priority of the contacts they contain. Different contact
names may have different priorities while waiting for service from agents. This priority
may depend on the contact names themselves (e.g., Purchase customers get priority over
Refund customers) or on the agent group (e.g., Experts give priority to Windows calls
over DOS calls).
Contacts are assigned a default priority (associated with the trunk group defined within
the Configuration module) upon entering the contact center. This default priority may be
overridden (within the Contact module) for each contact name.
When a contact is queued to an agent group, its priority may again be overridden based on
the group definition. Within the Agent module, an override contact priority may be specified for each contact name that the agent group services.
34
4 FEATURES
Agent skill priorities at the parent group level do not apply to contacts queued directly to a
member agent group and vice versa.
Also, the priority of an individual contact may be adjusted by its routing script depending
on contact center conditions (see the Priority module). Each time the priority of a contact
changes, the contact is reordered within its queue.
A contacts priority will revert to its pre-queue priority upon leaving a queue and revert to
its initial priority when contacting back.
Agent selection
Once a contact has reached the front of its queue, the only remaining consideration is
which agent resource to select for service.
All agents within an agent group are identical. Therefore, if the queue belongs to an agent
group, resource selection is quite simplethe contact is assigned to the next available
agent.
If the queue belongs to a parent group, resource selection is considerably more complicated, although it falls nicely into the following two categories:
Multiple-member agent groups have available agents

No agents are available
MULTIPLE AGENTS AVAILABLE
NO AGENTS AVAILABLE
If there are no agents available to service the contact immediately, the contact must wait.
Once an agent becomes available, the contact normally would be assigned immediately to
the agent unless there were multiple waiting contacts simultaneously laying claim to the
agent. Recall that this is a possibility in models where agent groups belong to one or more
parent groups.
In this case, priorities come back into play. Among those contacts in position to select the
newly available agent, the one with the highest priority will be assigned. While that is
straightforward, there is one additional concept that applies in this situation. The current
35
4 Features
When agents are available within multiple-agent groups, the concept of preferences is
applied to determine from which group to select a server. Defining a parent group (see the
Agent module for more details) consists of making a list of member agent groups. A
numerical preference is associated with each member group to dictate the desirability of
the agents within that group relative to other member agent groups. An agent having the
highest available preference will be selected to serve the contact. Ties for highest preference will be broken according to the specified selection rule (see the Queue for Agent
module for more detail).
contact priorities for all candidate contacts may be overridden one final time by the agent
skill priorities associated with the available agent (see Agent module for more details).
Basically, this means that the priorities of the candidate contact names are redefined from
the point of view of the agents skills, enabling the agent to serve the contact he is most
capable of handling. Note that the current contact priority will be preserved for any
contact type for which the agent has no defined agent skill priority.
Skill-based routing
Skill-based routing ensures that each contact is assigned to the best available agent and
that agents focus on serving the contacts for which they are most proficient.
There are three components to skill-based routing:
Simultaneous queueing. Contacts are queued to all Agent Groups (via a Parent
Group) capable of serving their particular contact name.
Preferences. Contacts select the most qualified agent from among all available
agents.
Agent skill priorities. Agents select the type of work they are most proficient in from
among all waiting contacts requesting their service.
Arena Contact Center Edition supports skill-based routing in a very natural and elegant
manner by combining these three features.
Routing script construction

This section describes the features of Arena Contact Center Edition that are available for
representing the contact-routing logic employed by your system.
For the purpose of creating a realistic simulation model, the elemental functions of the
phone switches have been condensed into modules that are pieced together to form
routing scripts within a model. Using these modules as building blocks, extremely
complex contact-routing logic can be incorporated into your contact center simulation.
Each module is briefly described below.
Begin Script
The Begin Script module simply identifies a script by defining the scripts name.
Queue for Agent

A Queue for Agent module simply places the contact within the specified agent group
queue where it is ranked according to its active priority and proceeds to the next action in
36
4 FEATURES
the script. When queueing to a parent group, several Selection Rules are provided to
control which agent is selected from among multiple-member agent groups.
Remove from Queue

A Remove from Queue module simply removes the contact from its current agent group
queue and proceeds to the next module in the script.
Wait
The Wait module is used to represent a wide variety of routing activities involving delays
experienced by the contactor, including playing welcome messages and announcements,
prompting and receiving customer inputs, transfer times, and being placed on hold for an
agent.
Priority
A Priority module will adjust the active priority of a contact. This priority may in turn
affect its processing, including moving it ahead of other contacts in a queue.
Message
When a Message module is encountered in a routing script, a wait time (representing the
time required to record a message) is generated from the specified distribution. The
contact is then delayed for that amount of time, counted as leaving a message, and
dispatched from the contact center.
Disconnect
Overflow
An Overflow module removes the contact from its current queue and counts it as an overflow between the specified source group and destination group. Routing control flow then
continues to the next module in the script, which must be a Queue for Agent action for the
appropriate destination group.
Transfer to Script
The Transfer to Script module simply shifts routing-control flow to the actions defined in
the specified script.
37
4 Features
When a Disconnect module is encountered in a routing script, the contact is immediately

dispatched from the contact center.
Transfer to Agent
The Transfer to Agent module transfers a contact to the specified agent if available. This
module may only be used in a script within the Prior to Post Contact Work logic of the
Queue for Agent module.
Conference
The Conference module conferences a contact with the primary agent and the specified
conference agent if available. This module may only be used in a script within the After
Talk Time logic of the Queue for Agent module.
Branch
A Branch module serves to implement conditional and probabalistic branching logic. If
the associated condition is true, routing-control flow is transferred to the module
connected to the correponding exit. Flow can be controlled by logical conditions
including: Contact Name, Time In Contact Center, Time of Day, Day, Agent Expressions,
Queue Length, and Probabilities.
Assignment
The Assignment module allows the assignment of a contacts picture or attribute, a global
variable, or counter.
End Script
The End Script module identifies the end of a script.
Costing
Arena Contact Center Edition currently tracks variable costs associated with contact
center operations. These costs pertain to the use of particular trunk and agent resources.
The total cost incurred for each resource is summarized in the default report.
Agent costs
A busy and idle hourly cost per agent (hourly wage), as well as a per-use cost, can be
associated with each agent group. The busy, idle, and per-use cost of this group over the
simulation planning horizon is calculated based on the following formulas:
Busy Agent Cost = (Busy Hourly Cost) * (Average Number of Busy Agents in Agent Group) *
(Length of Planning Horizon)
Idle Agent Cost = (Idle Hourly Cost) * (Average Number of Idle Agents in Agent Group) *
(Length of Planning Horizon)
Usage Cost = (Per Use Cost) * ( Number of times an agent was seized)
38
4 FEATURES
Trunk costs
A cost per trunk hour can be associated with each trunk group. The total cost of operating
this trunk group over the simulation planning horizon is calculated based on the total
number of hours each trunk line is in use, analogous to the following formula:
Total Trunk Cost = (Cost/Hour) * (Number of Trunks in Trunk Group) * (Utilization) * (Length
of Planning Horizon)
Miscellaneous features
Pattern entry
Patterns are defined by entering the expected number of contacts for each timeslot. The
Scale Factor field is used to increase or decrease globally the expected number of contacts
per timeslot. The Scale Factor value is multiplied by the value entered for each timeslot.
Agent states
Schedules are composed of individual time periods or shifts. An agent state is associated
with each shift. The main purpose of the agent state is to differentiate between on- and
off-duty states. The off-duty states currently are used only for documentation purposes and
to aid in model validation.
Individual agents
When a parent group is composed entirely of individual agents, contacts may be routed to
the specific agent who has been available for the longest time (see Selection Rules
under Queue for Agent module).
Advanced configuration agents

The following features are available in the Advanced section of the Configuration module:
REPLICATIONS
Each simulation run, or replication, is equivalent to a single execution of an experiment.
Sometimes, to obtain results that are statistically conclusive, it is necessary to conduct
39
4 Features
Most Arena Contact Center models deal with groups of agents where individual agents are
represented only in generic terms. In some situations, it is necessary to extend the level of
detail to include individual agents. This is done by defining agent groups containing
single agents (Number of Agents: 1). This allows each individual to have custom contacthandling skills and follow his own schedule. These individuals are grouped together as
members of a parent group.
multiple replications. The desired number of replications is specified in the Configuration

module.
The companion features to the multiple replication functionality determine whether the
replications are treated independently or as a continuous run. For more details on when
and how to initialize the system and initialize the statistics between each replication, see
Arena online help.
NUMBER OF AGENT GROUPS
This value limits the size of internal data structures for optimized performance. It may
need to be increased in very large simulation models.
40
Chapter5.fm Page 41 Wednesday, August 4, 2004 4:48 PM
Getting Started
Introduction
This chapter will help you get started quickly in the Contact Center template by
explaining how to load and run an existing model and by demonstrating how to build your
own model from scratch. Please see Chapters 3 and 4 for a review of contact center
simulation concepts, as well as Chapters 6 and 7 for a detailed description of each Contact
Center module.
Loading and running an existing example

The Telethon.doe case study model illustrates a simple contact center application.
To load the telethon case, click on File > Open in Arena. A selection box will appear in
the center of the screen. Click on (or Browse for) the file name Telethon.doe and select
Open. The telethon model will be loaded and appear within the model window.
Figure 5.1 The Telethon model
41
5 Getting Started
To run the model, click Run > Go, and a week of telethon activity will then be simulated.
When complete, a dialog will appear asking whether you would like to see the results.
Click Yes to view the Agents and Trunks report. You may also view the Contact Times
and Counts report by clicking on Contact Times and Counts on the report panel located
on the project bar. When finished viewing these reports, use the Close button to close each
report. At this point, to leave Run mode and return to the model, click on Run > End.
For more detail on your options during the simulation run, please consult Arena online
help.
Finally, select File > Close to complete the demonstration. The remainder of this chapter
will show the step-by-step process of building the telethon model.
General modeling skills and concepts

Panels and modules
There are two template panels associated with Arena Contact Center Edition: Contact
Data and Script. The Contact Data panel contains modules that are used to describe the
various aspects of the contact center, such as a contact name or an agent group. The
Contact Data modules are:
Pattern
Contact
Schedule
Agent
Animate
Report
The Script panel contains modules that are used to create a contacts routing script. A
script is a sequence of actions that controls the flow of a contact through the centers
system. The Script modules are:
Begin Script
Queue for Agent
Remove from Queue
Wait
Priority
Message
Disconnect
Overflow
Transfer to Script
Transfer to Agent
Conference
Branch
Assignment
End Script
Names
Certain object names are reserved words within the Contact Center template. Appendix 1
contains the list of Contact Center reserved words. In addition, it is not permissible for
42
5 GETTING STARTED
two different objects to have the same name (i.e., a model with a contact name named
Express cannot also have an Express agent group).
Lists
Once a Contact Center object has been named (or is referenced from another object), it is
placed on an internal list. From then on, the object name may be selected from a dropdown list in the appropriate dialogs. Lists are maintained for the following Contact Center
objects:
Trunk Groups
Contact Names
Patterns
Scripts
Schedules
Agent Groups
Parent Groups
Module copy and paste

Entire modules may be copied and pasted within a model (or even from one open model
to another) by using Ctrl+C and Ctrl+V. After pressing Ctrl+V, click within the model to
place a copy of the module.
Repeat group duplication

Entries within a repeat group can be duplicated by highlighting the entry and pressing
Ctrl+D. This creates an identical repeat group line item, which can then be customized.
Disable animation
The following steps describe how to disable/enable animation for performance purposes.
1. Select Run > Run Control > Batch Run.
2. Under Mode, check Batch Run (No Animation) for greater performance, unless
animation is desired.
Building an Arena Contact Center Edition model
43
5 Getting Sttarted
This section describes in detail a development session for a simple contact center model.
After completing this section, you will be familiar with the basic structure of a contact
center model and will possess the navigational skills necessary to work comfortably in the
Arena environment.
This example is also used to illustrate the module descriptions within Chapters 6 and 7.
Additionally, Chapter 9 contains several complete case studies, which may be used for
further practice with the template.
Defining the business application

The simple contact center model used to demonstrate the Contact Data and Script
template panels deals with the organization of a pledge drive for a local public radio
station. Each weekday morning during an on-air solicitation period, donors will be calling
in to make their pledges to a 12-member volunteer staff manning the companys 24-line
phone bank. From a business perspective, there are a limited number of potential donors,
so the number lost due to busy signals or abandonment must be minimized. Therefore,
from a contact center perspective, the key performance measures are blocked contacts and
average speed of answer.
Once the basic model is in place, it will be used to assess the wait time faced by donors
and analyze the impact of various levels of contact volume on the performance of the
center. This will allow station management to determine whether an investment in
additional phone lines and/or contract telereps would be justified.
Model overview
This simple model consists of:
1 week-long planning horizon, divided into hourly intervals

1 trunk group (with 24 lines)
1 agent group (with 12 volunteer members)
1 schedule (6:00 am-10:00 am, Monday-Friday)
1 contact name (donor)
1 routing script (queue, wait, and take message)
1 pattern (estimated contact volume by hour)
Animation (Agent Number Busy, Callers Waiting, etc.)
Reporting
Model construction
Once the Arena application has been started, a new model window is automatically
opened. If you need to open another new window, select File > New. Select Model
Window from the presented dialog and click OK. If you are not familiar with resizing
model windows or placing and editing modules, please refer to Arena online help.
Select File > Template Panel > Attach. From the resulting dialog, browse for and select
the file called ContactData.tpo and click on the Open button. A panel containing the
Contact Data modules appears. Execute the same steps again, this time selecting the file
called Script.tpo. This will attach the Script panel.
44
5 GETTING STARTED
DEFINING PLANNING HORIZON AND CONTACT CENTER INFRASTRUCTURE

THE CONFIGURATION MODULE
As described in the model overview, the radio telethon will run for one week. The basic
phone system at the radio station will be used to handle incoming donor calls. To
represent these items within the Arena Contact Center environment, a Configuration
module is employed.
To place a Configuration module in the model, click on the Configuration module on the
Contact Data panel, drag and then drop the module in the desired position within the
model window. Double-click on the resulting module to open the module dialog.
When the module opens, you will notice a drop-down list for defining the planning
horizon. Fill out this dialog to match the inputs in Figure 5.2. Below these items you will
see the trunk definitions scroll list with Add, Edit, and Delete buttons to the right. This is
known as a repeat group and enables you to enter multiple items (in this case, trunk group
definitions). To add an item to the repeat group, click on the Add button and fill out the
resulting dialog, as in Figure 5.3. The Delete button is used to remove items from repeat
groups, while an item is edited by highlighting the item within the scroll list and clicking
on the Edit button. Many Contact Data and Script panel modules contain one or more
repeat groups, which are completed in a similar manner.
Figure 5.2 Configuration module main dialog

5 Getting Sttarted
45
This defines a week-long planning horizon and a trunk group with 24 trunk lines on which
the Direct Routing script will be applied to route the contacts through the contact center.
Figure 5.3 Configuration moduletrunk definitions
The features described in the Advanced section of the Configuration module in Chapter 6
are accessed by clicking on the Advanced button, but will not be needed in this simple
example.
Finally, click the OK button to accept the module into the simulation model. Note that the
planning horizon is now documented in the model window.
DEFINING THE CONTACTSTHE CONTACT MODULE
The Contact module is used to define the characteristics of the donor calls that are
responding to the radio telethon. Their expected talk time is defined along with the
associated contact pattern and trunk group. An abandonment model is also specified that
enables callers to abandon the center if not served within a specified amount of time.
Place a Contact module in the model window and open its main dialog. You will notice
fields for defining the basic contact characteristics: contact type, contact name, pattern,
expected talk time, and associated trunk group. All the fields contain default values. These
values can be edited so that more meaningful names can be used. At the bottom of the
dialog, note the buttons containing additional dialogs for modeling Contact Back,
Abandonment, and other Advanced features.
Complete this dialog as illustrated in Figure 5.4. Note that there is a drop-down selection
list associated with the contact name, pattern, and trunk group fields. Use the trunk group
selection list to choose the Phone Bank trunk group that was previously defined in the
46
5 GETTING STARTED
Configuration module. This is a general ease-of-use Arena feature, where named objects
defined in one module may be selected from lists in others.
Figure 5.4 Contact module main dialog
To include donor abandonment in the model, click on the Abandonment button and type
EXPO(2) in the dialog to define an exponential abandonment model where the average
contact abandons after two minutes. Click OK to close the dialog.
DEFINING THE CONTACT ARRIVAL PATTERNTHE PATTERN MODULE
The Pattern module is the mechanism for describing the expected contact volumes for all
timeslots within the planning horizon. In the Telethon model, we expect calls to be
distributed evenly throughout the on-air pledge-solicitation period.
5 Getting Sttarted
47
Place a Pattern module in the model window and double-click to open its main dialog.
Note the correspondence between this dialog and the main dialog of the configuration
module. The Daily Arrival Pattern repeat group disappears in the case of day-long
planning horizons. Complete the main dialog as illustrated in Figure 5.5.
Figure 5.5 Pattern module main dialog
Following this, a pattern must be defined for each day of the week. To do this, click on the
Add button in the main dialog. This opens a data entry screen that partitions a day into the
appropriate timeslots. Enter the day of week and 50 into each of the timeslots between
6:00 AM and 10:00 AM, as shown in Figure 5.6. When finished, click OK. This process
must be repeated for each day of the week. Since no calls are expected on Saturday and
Sunday, their arrival patterns will contain all zeros (the default).
48
5 GETTING STARTED
A quick method of completing the set of arrival patterns is to duplicate entries using
Ctrl+D. First, complete all of the entries for the Monday arrival pattern. Then hit Ctrl+D
simultaneously. Each hit of Ctrl+D will create a duplicate of the highlighted arrival
pattern. Then simply edit the duplicate entry and change the Day of the Week.
Note: You can use Ctrl+D to duplicate the initial daily pattern for all weekdays.
Figure 5.6 Pattern moduleDaily Arrival Pattern
DEFINING THE TELETHON HOURSTHE SCHEDULE MODULE

The volunteer group fielding donor calls at the radio station must have their schedules
defined to correspond with the on-air solicitation period. This is done by placing a
Schedule module and defining on-duty hours of 6:00 AM to 10:00 AM on each weekday.
5 Getting Sttarted
49
Upon opening the Schedule module, you will notice its similarity to the Pattern module.
Complete the dialog, as shown in Figure 5.7.
Figure 5.7 Schedule module main dialog
When this is complete, the individual daily schedules must be defined. This is a slightly
different process from the Pattern module because the dialogs are more involved. Click on
the Add button to the right of the daily schedule repeat group. This opens another level of
repeat groups that facilitates the definition of multiple shifts within a given day. At this
point, select Monday as the day of the week and click on the Add button to the right of
the shift schedule repeat group. Complete the resulting dialog as shown in Figure 5.8 and
click OK to enter the shift.
Since there are no more shifts during the day, click OK to complete the daily schedule for
Monday. Repeat this process to define shifts for the remaining days of the week, including
Saturday and Sunday, even though no agent shifts will be defined on the weekends. Be
careful not to get confused by the extra level of repeat groups; there is a repeat group to
define days within the planning horizon and a repeat group to define all shifts within a
given day.
50
5 GETTING STARTED
Figure 5.8 Schedule moduleShift
DEFINING THE WORKERSTHE AGENT MODULE

In the Telethon model, a group of volunteers will be manning the phone lines at the radio
station. These volunteers will service incoming donor calls. This is a very simple agent
group to represent, requiring the absolute minimum input.
Place an Agent module within the model window and open the main dialog. By default,
the dialog is initially set up to define agent groups (rather than parent groups). Since this is
what we want, complete the dialog to match the one in Figure 5.9. Recall that the schedule
associated with the agent group can be selected from the drop-down list. Note the button
at the bottom of the dialog for defining the agent groups handling skills in terms of talktime capabilities.
5 Getting Sttarted
Figure 5.9 Agent module main dialog
51
Following the basic agent definition, the only remaining task is to define the handling
skills for the volunteers. This is done by clicking on the Talk Time button, which exposes
a dialog containing a repeat group in which a list of contact names and associated
handling characteristics is generated. Since there is only a single contact name in the
Telethon model, we will only need to make one entry. To do this, click on Add to reveal
the dialog shown in Figure 5.10, select Donor from the list of contact names and click
OK to close the dialog and preserve the default talk and conference-time multipliers.
Figure 5.10 Agent moduleTalk Time contact names
This completes the basic agent group definition, so click OK in each of the open dialogs
to accept the module into the simulation model.
DEFINING THE ROUTING LOGICTHE SCRIPT PANEL
Donor calls start the phones ringing at the radio station. If not answered, the calls will roll
over to voice mail after two minutes. The functionality of the phone switching system is
specified by creating a script using a series of modules from the Script panel.
Place a Begin Script module within the model window and open the main dialog. You will
see a field for the script name. Select Direct Routing from the drop-down list as shown in
Figure 5.11 and click OK.
Figure 5.11 Begin Script module main dialog
52
5 GETTING STARTED
Next place a Queue for Agent module in the model window. If a connector was not
automatically added from the Begin Script module to the Queue for Agent module, use
the Connect button located on the standard toolbar to connect the exit point of the Begin
Script module to the entry point of the Queue for Agent module. Refer to Arena help for
more information on connecting modules.
Open the Queue for Agent main dialog. By default, the dialog is initially set up to define
agent groups (rather than parent groups). Since this is what we want, complete the dialog
to match the one shown in Figure 5.12. At the bottom of the dialog, note the button
containing additional dialogs for modeling Advanced features.
Figure 5.12 Queue for Agent module main dialog
Next, place and connect a Wait module after the Queue for Agent module in the model
window. Open the main dialog and enter 2 in the Wait Time field as illustrated in Figure
5.13.
Figure 5.13 Wait module main dialog
Now place and connect a Remove from Queue module after the Wait module in the model
window. This module has no required values to enter.
5 Getting Sttarted
53
Place and connect a Message module after the Remove from Queue module in the model
window. Open the main dialog and enter .5 into the Message Wait Time field as
illustrated in Figure 5.14. Note the check boxes for contact back and contact return
options. Since neither contact back nor contact return were defined in the Donor Call
module, the values specified here are irrelevant.
Figure 5.14 Message module main dialog
To complete the script, place and connect an End Script module after the Message module
in the model window. This module has no required values to enter.
This script will model a call immediately queueing for a volunteer. It will implement a
two-minute wait before activating the recording of a 30-second voice mail message. The
completed script is shown in Figure 5.15.
Figure 5.15 Direct routing script
ADDING REAL-TIME GRAPHICSTHE ANIMATE MODULE

Animation is often useful to provide visual insight into contact center conditions during a
simulation run. In the Telethon model, agent utilization is a valuable indicator of whether
the size of the volunteer staff is adequate to handle all donor callsa critical component
in making the pledge drive a success. Therefore, we will animate the utilization level of
the volunteer group both numerically and with a plot.
54
5 GETTING STARTED
Place an Animate module within the model window and double-click to open its dialog.
Select Agent from among the Data Object options and complete the remaining dialog as
shown in Figure 5.16.
Figure 5.16 Animate module main dialog
COLLECTING STATISTICSTHE REPORT MODULE

The purpose of constructing simulation models is to gain insight into contact center
business processes and drive the planning and improvement of those operations. The
Report module supports detailed data collection of important performance measures
throughout the planning horizon under study. In the Telethon model, managers are
interested in the experience of donors as they wait for agents. In particular, long answer
times may indicate that potential pledges are abandoning the center without being served.
Place a Report module within the model window and complete its dialog as specified in
Figure 5.17.
5 Getting Sttarted
Figure 5.17 Report module main dialog
55
Note that multiple Report modules may be placed to collect as many statistics as
necessary. Varying the timeslot size in separate modules focused on the same statistic will
generate a series of reports detailing that performance measure at various levels of
aggregation (for instance, Donor Call Time averages for each hour, day, and the week as a
whole).
Running the model

The Telethon model is now ready for execution. Before a run, it is a good idea to save the
model. Do so by clicking on the disk icon on the toolbar or by selecting File > Save. After
naming the model (choose a model name other than Telethon.doe so as not to overwrite
the original) and completing the ensuing dialog, the model is ready to run.
Begin the run by selecting Run > Go. Arena will now check the model for any errors and
initiate the run. At this point, the animation tracking the utilization of the volunteer group
should be active, as well as a display of elapsed execution time. When complete, a dialog
will appear asking whether you would like to see the results. Click on Yes to view the
default summary report. The report window may be resized to better view its contents.
When finished viewing the default report, click on File > Exit to return to Arena. At this
point, to leave Run mode and return to the model, click Run > End.
You may also examine the file generated by the Report module that contains statistics on
donor contact times reported in 60-minute intervals.
For more information on the default summary report or the possible output generated
using the Report module, please refer to Chapter 7.
Conclusions
This chapter illustrates the ease of building a simulation model using Arena Contact
Center Edition. The Contact Center environment is designed to require less effort to create
a model in order to allow more attention to be focused on using the simulation to address
and answer key business issues and questions.
While the Telethon model is relatively simple, it does use all seven of the Contact Data
panel modules and six of the Script panel modules. The process of creating a more
complex model is virtually the same, although complex models would generally contain
multiple modules of each type.
With a completed model in hand, you may want to experiment with some of the model
parameters or some advanced options. Try making incremental adjustments to the model
and examining their impact on center performance (as summarized in the output
statistics). Performing these types of what if? analyses are common practice in a
simulation study. Here are some potential changes and enhancements to evaluate:
56
5 GETTING STARTED
Increase the volume of donor calls. What impact does this have on blocking,
abandonment, and agent utilization?
Alter the number of agents and/or trunk lines. What impact does this have on customer
service?
Add animation to show counts of abandoned calls.
Generate a report containing counts of calls generated, blocked, abandoned, and
handled.
Add contact back in the case of abandonment.
Add a new agent group to process lifetime memberships and transfer 10% of the
calls to this group following their service with the regular volunteer group.
Extend the telethons hours of operation (remember that both arrival pattern and agent
schedules must be adjusted).
Add an agent group to handle overflow from the regular volunteers after calls have
been on the line more than one minute. Modify the routing script to overflow calls to
this group.
5 Getting Sttarted
57
58
The Contact Data Panel

This chapter describes each of the seven modules that form the Contact Data template
panel, one of the two template panels contained in the Arena Contact Center Edition.
Chapter 7 describes the modules located in the second template panelthe Script panel.
The following modules are located on the Contact Data panel:
Configuration
Schedule
Pattern
Agent
Contact
Animate
Report
All of the above modules allow the definition of a single object (e.g., Agent Group, Contact, etc.). Multiple modules of the same type are placed to complete the model. Several
modules incorporate the notion of component repeat groups. That is, the module may be
composed of many similar pieces (e.g., Days within a Week for the Pattern and Schedule
modules), and each piece is defined separately. The repeat groups are described in the
prompt text and will be obvious within the template constructs, although their repetitive
nature does not appear in the prompt tables. Similarly, many modules have custom dialogs
that vary depending on the options selected. This conditional input is also not explicitly
highlighted in the prompt tables.
59
6 Contact Data Panel
Configuration module
DESCRIPTION
This modules purpose is to specify the layout of the contact center simulation. The planning horizon and all trunk groups applicable to the contact center are defined within this
module.
PROMPTS
Planning HorizonLength of the planning horizon chosen from the following predefined list of options: Month, Bi-Week, Week, Day. The planning horizon defines the
length of the simulation run.
Trunk DefinitionsThis repeat group defines the contact capacity of the contact center in
terms of trunk lines. Trunk groups will be useful in defining different functions within a
contact center and for networked contact centers that are not at the same physical location.
Trunk GroupText descriptor of the trunk group being defined (e.g., Sales, Dallas
Office, Outsourcer).
Trunk CapacityNumber of trunks in this trunk group.
Inbound ContactsIndicates if this trunk is used for inbound contacts.
Inbound Contact ScriptRouting script for inbound contact associated with this trunk
group, chosen from the list of defined Scripts.
60
Outbound ContactsIndicates if this trunk is used for outbound contact.

Outbound Contact ScriptRouting script for outbound contact associated with this
trunk group, chosen from the list of defined Scripts.
Outbound Contact PriorityInteger used to rank outbound contact associated with
Trunk Group when queued to a priority queue.
Trunk Cost/HourCost of trunk lines in $/hour/trunk line.
AdvancedThe following group of items support several advanced features of the run.
Number of ReplicationsNumber of simulation runs to be performed during this
analysis. Each runs length is determined by the Planning Horizon.
Initialize System Between ReplicationsControls whether each replication is started
with an empty contact center or continues from the endpoint of the previous replication.
Initialize Statistics Between ReplicationsControls whether statistics collection is
reset at the beginning of each replication or accumulates throughout all replications.
61
Inbound Contact PriorityInteger used to rank inbound contact associated with

Trunk Group when queued to a priority queue.
6 THE CONTACT DATA PANEL
Max Number of Agent GroupsUpper bound on the number of Agent Groups to be

included in the simulation model. This value may need to be increased for very large
simulation runs.
Prompt
Valid Entry
Default
Planning Horizon
Day, Week, Bi-Week, Month
Day
Trunk Group
Symbol Name [Trunk Group]
Trunk 1
Trunk Capacity
Integer >= 1
100
Inbound Contacts
Checked, Unchecked
Checked
Inbound Contact Script
Symbol Name [Scripts]
Script 1
Inbound Contact Priority
Expression
Outbound Contacts
Checked, Unchecked
Unchecked
Outbound Contact Script
Script 1
Outbound Contact Priority
Expression
100
Trunk Cost/Hour
Real Number >= 0
0.00
Number of Replications
Integer >= 1
Initialize System
Checked, Unchecked
Checked
Initialize Statistics
Checked, Unchecked
Checked
Max Number of Agent Groups
Integer >= 1
50
Trunk Definitions
Advanced
REMARKS
Only one Configuration module may be defined for each simulation model.
The Planning Horizon value specified in the Configuration module is independent of planning horizon values specified in other modules.
The Planning Horizon defined within the Configuration module determines the length (in
minutes) of the simulation run.
The Priorities and Scripts defined at the Trunk Group level are provided as defaults for the
Contacts incoming on those trunk lines. Overrides of these attributes may be specified in
the Contact module.
62
In very large models, the Maximum Number of Agent Groups may need to be increased
accordingly.
The simulation begins at time 0.0, which in calendar time is Monday at midnight.
EXAMPLE
Prompt
Entry
Planning Horizon
Week
Trunk Definitions
Trunk Group
Phone Bank
Trunk Capacity
24
Inbound Contacts
Checked
Direct Routing
Outbound Contacts
Unchecked
This example sets up a weekly planning horizon. A single trunk group with 24 lines is also
defined.
Schedule module
63
The advanced functionality dealing with replications and system initialization is detailed
in Arena online help.
DESCRIPTION
This module defines schedules to which agents can be assigned. The schedule is based on
the planning horizon and timeslot structure, with an agent-availability state associated
with each timeslot.
The defined list of availability states is:
On-Duty
Lunch
Break
Meeting
Research
PROMPTS
Schedule NameText descriptor of the schedule being defined (e.g., Graveyard).
Planning HorizonLength of the planning horizon chosen from the following predefined list of options: Month, Bi-Week, Week, Day.
Timeslot (in minutes)Length of the intervals composing the schedule: 15, 30, or 60
minutes.
Daily ScheduleThis repeat group is used to define a schedule for each individual day
within the planning horizon. Each day is identified by its week and day of week, if applicable. Within each day, multiple agent shifts may be defined.
64
Day of WeekSelection of the day within the planning horizon for which the agent
shifts apply.
Shift ScheduleThis repeat group is used to define the agent shifts that are in
effect on the particular day. Each shift is specified by an agent availability state
and a starting and ending time.
Agent StateThis field defines the agent availability state for this particular shift.
Alter Capacity byThis field allows you to specify whether the shift schedule being
defined applies to the entire agent group capacity or for a specified number of the
group.
Number of AgentsThis option defines the number of agents for which the shift
schedule applies.
Group Capacity This option defines the absolute capacity of the agent. It must be a
positive integer and cannot be larger than the Agents capacity as defined in the Agent
module.
Schedule Adherence FactorMultiplier used to calculate the actual number of agents
used for a given timeslot.
Shift Begins atThis dialog specifies the time the shift begins (e.g., 8:00 AM).
Shift Ends atThis dialog specifies the time the shift ends (e.g., noon).
Prompt
Valid Entry
Default
Schedule Name
Symbol Name [Schedule]
<Module Name and

instance number>
Planning Horizon
Day
Timeslot
15, 30, 60
30
Week
Week 1, Week 2, Week 3, Week 4
Week 1
Day Of Week
Monday, Tuesday, Wednesday, Thursday,

Friday, Saturday, Sunday
Monday
Agent State
On Duty, Lunch, Break, Meeting,

Research
On Duty
Alter Capacity by
Group Capacity, Number of Agents
Group Capacity
Number of Agents
Integer > 1
65
WeekSelection of the week within the planning horizon for which the agent shifts
apply.
Prompt
Valid Entry
Default
Schedule Adherance
Factor
Integer > 1
Shift Begins at
Time (hour, minute, AM/PM)
12 AM
Shift Ends at
Time (hour, minute, AM/PM)
12 PM
REMARKS
By default, all timeslots are initialized to an off-duty availability state. Therefore, agent
shifts need only be defined for those time intervals that are not off-duty.
There are error checks to prevent infeasible shifts from being entered (e.g., shifts that end
before they begin). All shifts must be entered in chronological order starting with
midnight, going until midnight the following day. For example, if an agent has two
separate shifts (noon to 4 PM, and 5 PM to 9 PM), the shifts must be entered in this order.
Entering the 5 PM to 9 PM shift will raise an error.
Overlapping agent shift intervals are not permitted.
Shifts are defined for each calendar day. Therefore, a shift that overlaps days must be
defined in two separate pieces (e.g., Monday: 8:00 PMmidnight; Tuesday: midnight
6:00 AM).
The planning horizon defined in the Schedule module dictates the number of days for
which schedules must be defined. An entry must be made in the Daily Schedule for each
day within the planning horizon, although no shifts need to be defined for any day (e.g., if
everyone is off-duty on the weekends, no shifts would be defined for Saturday and
Sunday, although Saturday and Sunday must appear in the Daily Schedule list).
Note that schedules are repeated to fill the simulation run length as defined in the Configuration module (e.g., a weekly pattern will be repeated four times to fill a month-long
run). However, schedules defined for longer than the run length will raise an error.
Timeslots, as defined in the Schedule module, determine the start and end points of shift
intervals. It is important to synchronize shift changes with statistics collection in the
Report module to ensure consistency. Agent Utilization will be distorted if groups go onor off-duty in the middle of a reporting interval. Therefore, the intervals defined for statistics should be no larger than the shift timeslots, and coincide with shift changes. For
instance, when shifts change on the hour, statistics can be collected on the hour or halfhour. However, if shifts change on the half-hour, statistics must be collected on the halfhour.
66
The timeslot and planning horizon data specified within the Schedule module are independent of this data in other modules.
EXAMPLE
Prompt
Entry
Schedule Name
Telethon Hours
Planning Horizon
Week
Timeslot
60
Daily Schedule
Day of Week
Monday/Tuesday/Wednesday/Thursday/Friday
Agent State
On-Duty
Shift Begins at
6:00 AM
Shift Ends at
10:00 AM
Day Of Week
Saturday
Day Of Week
Sunday
This example defines the schedule the volunteer agents will follow (coinciding with the
on-air pledge drive) in the Basic Telethon case study.
67
Currently, the agent states associated with each shift have no effect. Contacts are only
taken during shifts with the on-duty state. All other states denote off-duty periods and are
included for clarity.
Pattern module
DESCRIPTION
This module defines contact arrival patterns of particular contact names. The pattern is
based on the planning horizon and timeslot structure. A distribution is constructed from
the expected contact counts entered for each timeslot.
PROMPTS
PatternText descriptor of the contact pattern being defined (e.g., Windows, DOS).
Planning HorizonLength of the planning horizon chosen from the following predefined list of options: Month, Bi-Week, Week, Day.
Timeslot (in minutes)Length of the intervals composing the pattern: 30 or 60 minutes.
Scale FactorMethod of scaling the arrival pattern data up or down. Each timeslot value
will be multiplied by the scale factor to determine the expected total contacts for each
timeslot.
68
Daily Arrival PatternThis repeat group is used to define a pattern for each individual
day within the planning horizon. For each day, the expected total contacts arriving within
each timeslot are specified.
WeekSelection of the week within the planning horizon for which the pattern
applies.
Day Of WeekSelection of the day within the planning horizon for which the pattern
applies.
Daily Contact PatternSpecification of the expected total contacts for each timeslot
for the given day.
69
EXAMPLE
Prompt
Valid Entry
Default
Pattern
Symbol Name [Pattern]
<Module Name and

instance number>
Planning Horizon
Day
Timeslot
30, 60
30
Scale Factor
Real Number
1.0
Week
Week 1, Week 2, Week 3, Week 4
Week 1
Day Of Week
Mon, Tue, Wed, Thu, Fri, Sat, Sun
Mon
Daily Contact Pattern
Real Number >= 0
0.0
Daily Arrival Pattern
REMARKS
An entry must be made in the Daily Arrival Pattern for each day of the planning horizon,
although no patterns need to be defined for any day (e.g., if no contacts are received on the
weekends, no patterns would be defined for Saturday and Sunday, although Saturday and
Sunday must appear in the Daily Arrival Pattern list).
Patterns are repeated (if necessary) to fill the simulation run length as defined in the Configuration module (e.g., a weekly pattern will be repeated four times to fill a month-long
run). In these cases, patterns are adjusted so that the distribution covers the entire run
length (e.g., the expected number of contacts entered in the Contact module will be generated over the simulation run). However, patterns defined for longer than the run length
will raise an error.
The timeslot specified within the Pattern module is independent of timeslot lengths in all
other modules. These timeslots determine at what level patterns are entered and when the
arrival rates for contacts change within the simulation.
70
Prompt
Entry
Pattern
Basic Pattern
Planning Horizon
Week
Day Of Week
Mon/Tue/Wed/Thu/Fri

(6:00 AM - 7:00 AM)
50

(7:00 AM - 8:00 AM)
50

(8:00 AM - 9:00 AM)
50

(9:00 AM - 10:00 AM)
50
EXAMPLE
This example illustrates the donor arrival patterns for the Basic Telethon case study. This
pattern corresponds to calls arriving uniformly over the timeslots in the planning horizon
(50 calls are expected in each of the 20 timeslots).
Agent module
71
DESCRIPTION
This module defines the agents of the contact center. Each Agent Group is composed of
identical agents based on a generic definition. A Skill Set, defined by a set of talk-time
details, is specified for each Agent Group, along with an associated Schedule.
Parent Groups are used to combine multiple Agent Groups to serve a particular function,
as well as provide aggregate statistics. (For example, Agent Groups could be defined for
groups that handle Day, Evening, and Graveyard shifts, with a Parent Group to encapsulate all three.)
PROMPTS
Agent NameText descriptor of the group being defined.
Agent TypeChoice of Agent Group or Parent Group.
If Agent Type = Agent Group:
These items define the generic agents that belong to this Agent Group and the specific
agent operational details. The Agent Group will be defined by the number of agents, their
associated skill set, and the schedule they follow.
Max Number AvailableMaximum number of agents available in the Agent Group.
ScheduleAssociated Agent Schedule, chosen from the list of the defined Agent
Schedules.
Clear Queue when Off DutySpecifies whether a check is made every 15 minutes to
determine if all agent groups comprising the parent group are off-duty and to clear the
parent queue by disconnecting all the contacts in the queue. Note that a parent group
queue may be cleared several times daily depending upon the member agent group
schedules.
Busy Cost/HourCost per hour incurred while a single agent is busy.
Idle Cost/HourCost per hour incurred while a single agent is idle.
Per Use CostCost per contact incurred for a single agent.
72
Talk TimeDialog containing a repeat group that facilitates defining talk time specifics
by contact name.
Contact NameParticular contact name that can be handled by agents with the given
skill set.
Talk Time MultiplierNumerical expression quantifying the skill of the agent with
respect to the specified contact name (e.g., 0.9 implies agents with this skill set handle
this contact 10% faster than average).
Conference Time MultiplierNumerical expression quantifying the skill of the agent
when conferenced on a particular contact name (e.g., 0.9 implies agents with this skill
set resolve this contact 10% faster than average).
Override Contact Priority with Skill PriorityField indicating whether contact priority should be redefined when served by this Agent Group.
Agent Skill PriorityNumber indicating the priority for Contact Name (i.e., 1 for
highest priority, 2 for next, etc.). Lower-valued Contact Names will be assigned before
those with higher values. This value overrides the Contact Priority when a contact is
queued to this Agent Group.
73
If Agent Type = Parent Group:
These items define a Parent Group in terms of its component Agent Groups. Preferences
may be specified to further define the assignment of contacts to the Agent Groups within
the Parent Group.
Clear Queue when Off DutySpecifies whether contacts are disconnected when all agent
groups comprising the parent group go off duty at the end of a day.
MembersThis repeat group facilitates the selection of the various Agent Groups that
compose the given Parent Group.
Agent GroupText descriptor of the Agent Group that belongs to the Parent Group,
chosen from the list of Agent Groups that have been defined.
PreferenceNumber indicating the preference of this Agent Group within Parent
Group (e.g., 1 for primary preference, 2 for secondary preference). Preference defines
an order within Parent Group for assignment of contacts to Agent Group. Lowervalued groups will always be assigned before higher-valued agents when agents of
different Preference are available.
Agent Skill PriorityDialog containing a repeat group that facilitates defining agent skill
priorities by contact name.
Contact NamesThis repeat group facilitates defining agent skill priorities by contact
name.
Contact NameParticular contact name that can be handled by agents with the given
skill set.
74
Prompt
Valid Entry
Default
Agent Name
Symbol Name [Agent]
Agent Group
Agent Type
Agent Group or Parent Group
Agent Group
Max Number Available
Integer >= 1
Schedule
Symbol Name [Schedule]
Schedule 1
Busy Cost
Real Number >= 0
0.00
Idle Cost
Real Number >= 0
0.00
Per Use Cost
Real Number >= 0
0.00
Contact Name
Symbol Name [Contact]
Contact 1
Talk Time Multiplier
Real Number >= 0
Conference Time Multiplier
Real Number >= 0
Override Contact Priority
Checked, Unchecked
Unchecked
Agent Skill Priority
Integer >= 1
Checked, Unchecked
Checked
Agent Group
Symbol Name [Agent Group]
Agent Group 1
Preference
Integer >= 1
Contact Name
Contact 1
Integer >= 1
Agent Group
Talk Time/Contact Names
Parent Group
Clear Queue when Off-Duty
Members

Contact Names
75
Agent Skill PriorityNumber indicating the priority for Contact Name (i.e., 1 for
highest priority, 2 for next, etc.). Lower-valued Contact Names will be assigned before
those with higher values. This value overrides the Contact Priority when a contact is
queued to this Agent Group.
REMARKS
Parent Groups are used for several reasons, including simulation of simultaneous
queueing, grouping common resources to support skill-based routing, and isolating the
script logic from scheduling complexities (e.g., the Windows Group is a single logical
entity to which contacts can be routed, when in reality it is made up of many subgroups,
each containing a different number of agents following a different schedule).
Preferences among Agent Groups determine which agent resource from those available is
selected to service the next contact in queue. Priorities (Agent Skill and Contact) determine the order of contacts within a queue. Both features can be used concurrently.
Talk Time applies to the entire Agent Group.
Agent Skill Priorities are used to rank contacts within the queue directly associated with
the Agent Group. As such, priorities specified at the Agent Group level will not affect the
ordering of the Parent Group queue and vice versa. However, priorities at the Agent
Group level always override priorities set at other levels when resolving contention
among contacts competing for a particular agent resource.
EXAMPLES
EXAMPLE 1BASIC USE
Prompt
Entry
Agent Name
Volunteers
Agent Type
Agent Group
12
Schedule
Telethon Hours
Checked
Busy Cost
0.0
Idle Cost
0.0
Per Use Cost
0.0
Talk Time
Contact Name
Donor
Unchecked
This example defines the volunteers in the Basic Telethon case study as an Agent group of
12 generic agents.
76
Prompt
Entry
Agent Name
Expert
Agent Type
Agent Group
Schedule
First Shift
Checked
Busy Cost
0.0
Idle Cost
0.0
Per Use Cost
0.0
EXAMPLE 2USING BASIC MULTIPLIER TO MODEL SKILL LEVELS
Talk Time
Contact Name
Regular
0.8
0.8
Contact Name
Premium
0.8
0.8
This example illustrates the use of the Talk Time Skill Set to model an expert agent who
handles contacts in 80% of the average time.
77
Contact module
DESCRIPTION
This module defines the contact names handled by the contact center. The Contact module
drives the modeling effort in that most important aspects of the simulation are defined in
relation to contacts. Important contact behavior to be specified within this module
includes: talk time, contact back and abandonment propensity, contact return properties,
as well as several advanced capabilities that expand on these.
PROMPTS
Contact TypeDefines the type of contact (e.g., Call, Email, Fax, Web Hit or Other).
OptionDefines a contact as inbound or outbound.
Contact NameText descriptor of the contact being defined (e.g., Reservations).
PatternAssociated Pattern, chosen from the list of the defined Patterns.
Expected Talk TimeAverage talk time for contacts of Contact Name. This value is used
as the mean of an exponential distribution from which talk time values are generated for
each contact.
Trunk GroupAssociated Trunk Group, chosen from the list of the defined Trunk
Groups.
78
Contact BackDialog that defines contact-back behavior:

Contact Back ReasonsBlocked, Disconnected, Message, Abandoned, Served.
ProbabilityNumerical expression for probability of contact back.
Wait TimeDistribution for the delay (in minutes) before contacting back.
AbandonmentSpecification of Abandonment module to apply to the contact.

Wait Time Until AbandonmentDistribution specifying time until abandonment.
79
AdvancedDialog that allows incorporation of the following advanced modeling features:

Override Trunk PriorityCheck box determines whether or not the priority specified
in the Configuration module will be used for a given contact name.
Override Trunk PriorityExpression used to rank contacts of Contact Name when
queued in a priority queue. If not entered, Priority is inherited from Trunk Group
Priority (see Configuration module).
Override Trunk ScriptCheck box used to indicate whether the Script inherited
from Trunk Group Script (see Configuration module) is to be overridden.
[Override Type]Defines whether the default trunk group script will be overridden
with another script or if the contact will be routed directly to a particular agent queue.
Call Routing ScriptOverriding Script, chosen from the list of defined Routing
Scripts. If not specified, Script is inherited from Trunk Group Script (see the
Configuration module on page 60).
[Agent Type]Defines whether the overriding agent type is a parent group or basic
agent group.
Agent GroupName of the overriding agent group to which contacts of Contact
Name will be sent directly to its associated queue.
Parent GroupName of the overriding parent group to which contacts of Contact
Name will be sent directly to its associated queue.
80
Talk Time DistributionOverrides default talk-time distribution by allowing specification of any general distribution.
After Contact TimeSpecifies the distribution for after-contact delay. This is the
amount of time the primary agent spends in contact wrap-up before becoming ready
for another contact.
Service Level (seconds)Number defining the target amount of time in seconds
(service level) by which this Contact Name should be answered. The percentage of
contacts meeting this target is reported in the simulation output.
Can PreemptIndicates whether a contact of Contact Name can preempt another
contact that is being served by an agent.
Can Be PreemptedIndicates whether a contact of Contact Name currently being
serviced by an agent can be preempted by another contact.
Contact Picture NameDefines the name of the entity symbol used for animating
Contact Name contacts.
Create ContactIndicates if a Contact Name contact is created when another entity
executes the Contact module.
Contact CharacteristicsDialog that allows the assignment of user-defined contact
attributes or user-defined global variables.
AssignmentsSpecified one or more assignments that will be made when a
contact of Contact Name is generated.
[Assignment Type]Type of assignment to be made. This is a choice of either a
user-defined contact attribute or global variable.
Contact Attribute NameName of the user-defined contact attribute that will be
assigned a value when a contact of Contact Name is generated.
Global Variable NameName of the global variable being assigned.
ValueAssignment value of the attribute or variable.
Contact Return check boxDisplays a dialog that defines return contact characteristics.
Contact ReturnDialog that specifies contact return behavior.
PriorityInteger used to rank returned contacts in an agents queue.
[Contact Return Logic Type]Determines whether a returned contact follows a script
or is queued for an agent.
81
Selection RuleRule used to determine which agent is selected from among multiple
member agent groups.
Contact Return ScriptThe script that returned contacts will follow.

[Contact Return Agent Type]Determines whether the returned contact is queued to
an agent group or a parent group.
Contact Return Agent GroupThe name of the agent group that will service the
returned contact.
Contact Return Parent GroupThe name of the parent group of agents that will
service the returned contact.
Selection RuleThe rule to use when there is more than one available agent to handle
the returned contact.
Pre WorkThe amount of time an agent needs prior to returning a contact.
Connection TimeThe amount of time it takes to connect with the returned contactor.
Probability of ConnectionThe probability that an agent will be able to connect with
the returned contactor.
Max Number of AttemptsThe number of attempts an agent will make to connect
with a returned contactor prior to abandoning it.
Time Between AttemptsThe time between subsequent contact return attempts.
Outbound ContactsDialog that specifies outbound contact behavior.
Pre WorkThe amount of time an agent needs prior to making an outbound contact.
Connection TimeThe amount of time it takes to connect the outbound contact.
Probability of ConnectionThe probability that an agent will be able to connect with
the outbound contact.
Max Number of AttemptsThe number of attempts an agent will make to connect
with an outbound contact prior to abandoning it.
Time Between AttemptsThe time between subsequent outbound contact attempts.
82
Prompt
Valid Entry
Default
Contact Name
<module name and

instance number>
Contact Type
Call, Email, Fax, Web Hit or Other

Call
Call
Pattern
Symbol Name [Pattern]
Pattern 1
Expected Talk Time
Real Number > 0
Valid Entry
Default
Trunk Group
Trunk 1
Contact Back Reason:

Blocked, Disconnected,
Message, Abandoned,
Served
Checked, Unchecked
Unchecked
Probability
0 <= Real Number

<= 1.0 or expression
Wait Time
Expression (Distribution)
None
Override Trunk Priority

Check box
Checked, Unchecked
Unchecked
Override Trunk Priority
Integer >= 1
Override Trunk Script
Checked, Unchecked
Unchecked
[Override Type]
Script, Agent
Script
Call Routing Script
Symbol Name [Script]
Script 1
[Agent Type]
Agent Group, Parent Group
Agent Group
Agent Group
Agent Group 1
Parent Group
Symbol Name [Parent Group]
Parent Group 1
Selection Rule
First Available, Longest Available,

Uniform by Availability
Talk Time Distribution
(Uses Expected Talk Time

from main dialog)
After Contact Time

Distribution
0.0
Service Level
Real Number > 0
60
Can Preempt
Checked, Unchecked
Unchecked
Can Be Preempted
Checked, Unchecked
Unchecked
Prompt
Contact Back
Abandonment
Wait Time Until
Abandonment
Advanced
83
Prompt
Valid Entry
Default
Contact Picture Name
Symbol Name [Pictures]
Contact 1 Picture
Create Contact
Checked, Unchecked
Unchecked
[Assignment Type]
Contact Attribute, Global Variable
Contact Attribute
Contact Attribute Name
Symbol Name [Attributes]
Attribute 1
Global Variable Name
Symbol Name [Variables]
Variable 1
Value
Expression
Checked, Unchecked
Unchecked
Priority
Integer>=1
50
[Contact Return Logic

Type]
Script, Agent
Script
Contact Return Script
Script 1
[Contact Return Agent

Type]
Agent Group
Contact Return Script
Script 1
Contact Return Agent

Group
Agent Group 1
Contact Return Parent

Group
Parent Group 1
Selection Rule

Pre Work
Expression (Distributions)
0.0
Connection Time
0.0
Probability of
Connection
0<=Expression<=1
Max Number of
Attempts
Integer>=1
Time Between
Attempts
0.0
Contact Characteristics
Contact Return Check box

Contact Return
84
Valid Entry
Default
Pre Work
0.0
Connection Time
0.0
Probability of
Connection
0<=Expression<=1
Max Number of
Attempts
Integer>=1
Time Between
Attempts
0.0
Prompt
Outbound Contacts
REMARKS
Note that the Talk Time field in the main dialog of the Contact module requires a
numerical input representing the mean of an exponential delay distribution. On the other
hand, any Time field in the Contact Back, Abandonment, or Advanced sections requires a
statistical distribution or constant to be specified for that time value.
In the event of contact back, the priority of the contact will be reset as though it were a
new contact (i.e., the contact is not credited for any priority adjustments that occurred in a
previous visit to the contact center).
A contact return is generated when a contact executes a Message module.
Preemption of and by contacts only occurs in the Queue for Agent module of the Script
panel. Preemption does not occur for outbound, transferred, or conferenced contacts.
Animation of preempted contacts can be made available by placing an animated storage
and naming the storage Agent Group_STO.
Logic modules may be connected to a contact module if the Allow contact creation via
external logic check box is checked. When this happens, a single contact is created and
sent to its assigned routing script. The original entity that triggered the contact creation
continues to the next logic module. For more information on using this feature, see
CSmart21.
85
EXAMPLE
Prompt
Entry
Contact Name
Donor
Pattern
Basic Pattern
Talk Time
10
Trunk Group
Phone Bank
Abandonment
Wait Time Until
Abandonment
EXPO(1)
This example defines the call type Donor contact name for the Basic Telethon case study.
Talk time is sampled from an exponential distribution with a mean of 10. Calls will wait a
random amount of time following an exponential with a mean of 1 prior to abandoning.
Note that no contact back has been indicated, meaning there is no second chance to serve
donors who are blocked or abandoned.
Animate module
DESCRIPTION
The Animate module enables animation of real-time statistics during the simulation run.
PROMPTS
Data ObjectIndicates the type of contact center statistic to be displayed.
86
If Data Object = Contact:

Contact NameSelection of the Contact Name to animate, from a list of all defined
Contact Names.
Contact Statistic TypeSelection of the Contact Statistic Type to animate. Choices
include:
Contact CountRunning total number of contacts in particular stages.
Contact Back CountRunning totals of contact backs by contact-back reason.
Contact TimesAverage time contacts spend in a particular state.
PercentagesPercentages of contacts in various categories.
Contact DataSelection of the particular real-time statistic to animate. Choices depend
on the Contact Statistic Type being animated and are summarized in Table 6.1.
Table 6.1 Summary of Contact Statistic Type
Contact Statistic
Definition
Contact Count
Created
Count of number of original contacts created
Blocked
Count of the number of blocked (denied entry) contacts
Offered
Count of the number of contacts entering the center
Abandoned
Count of the number of contacts that abandon (hang up) before being
connected to an agent
Handled
Count of the number of contacts connected to an agent
Serviced in X minutes
Count of the number of contacts connected to an agent within the

specified service-time cutoff
Leaving Message
Count of the number of contacts leaving messages
Disconnected
Count of the number of contacts disconnected
In System
Count of the number of contacts currently in the contact center
Waiting
Count of the number of contacts currently waiting for service
87
Contact Statistic
Definition
Contact Back Counts

Blocked
Count of the number of contacts contacting back after being blocked

(denied entry)
Abandoned
Count of the number of contacts contacting back after abandoning the

center
Disconnected
Count of the number of contacts contacting back after being

disconnected
Leaving Message
Count of the number of contacts contacting back after leaving messages
Served
Count of the number of contacts contacting back after being served by

an agent
Contact Times
Speed of Answer
Average time between contact-center entry and connection with an

agent
Handle Time
Average time the primary agents spends serving the contact, including
both talk and after-contact time
Time in Contact
Center
Average amount of time the contact spends in the contact center
Percentages
88
Blocking
Percentage of attempted contacts that are blocked
Abandonment
Percentage of offered contacts that abandon the center
Serviced in X minutes
Percentage of served contacts that are handled within the specified

service cutoff
If Data Object = Agent Group or Parent Group:
Agent/ParentSelection of the Agent/Parent Group to animate, from a list of all defined

Agent/Parent Groups.
Object DataSelection of the particular cumulative real-time statistic to animate.
Choices include:
UtilizationThe fraction of on-duty time during which members of the Agent Group
are serving customers.
Number BusyThe average number of agents concurrently serving customers.
Number AvailableThe average number of idle agents.
If Data Object = Trunk Group:
89
TrunkSelection of the Trunk Group to animate, from a list of all defined Trunk Groups.
Object DataSelection of the particular cumulative real-time statistic to animate.
Choices include:
UtilizationThe fraction of time during which trunk lines of the Trunk Group are
busy.
Number in UseThe average number of trunk lines concurrently in use.
Number AvailableThe average number of trunk lines that are idle.
If Data Object = Overflow:
Source GroupSelection of the Agent Group from which overflowed contact counts
should be animated.
Destination GroupSelection of the Agent Group to which overflowed contact counts
should be animated.
90
If Data Object = System Time:
Display AsSelection of the view(s) by which the system time should be animated.
Choices include:
VariableDisplay of the day of the simulation run as a numerical quantity (1-28).
Analog ClockIllustration of the day of simulation run as a clock face.
Digital ClockIllustration of digital 24-hour clock in numeric form.
If Data Object = Other:
Other DataSpecification of an expression to be animated throughout the simulation

run.
91
If Data Object is not System Time:

Display AsSelection of the view(s) by which the chosen statistic should be animated.
Choices include:
VariableDisplay of the statistic as a numerical quantity.
LevelIllustration of the statistic as a graphical quantity.
HistogramIllustration of the statistic as a histogram of values it assumes over time.
PlotDisplay of the statistic as a plot over time.
Prompt
Valid Entry
Default
Data Object
Contact, Agent Group, Parent Group, Trunk

Group, Overflow, System Time or Other
Contact
Contact Name
Contact 1
Contact Statistic Type
Contact Count, Contact-Back, Count,

Contact Times, Percentages
Contact Count
Contact Data
Selection from list of available statistics
Abandoned
Agent Group
Agent Group 1
Agent Data
Utilization
Parent Group
Parent Group 1
Parent Data
Utilization
Trunk Group
Trunk 1
Trunk Data
Utilization
Source Group
Symbol Name [Agent]
Agent Group 1
Destination Group
Symbol Name [Agent]
Agent Group 2
Contact
Agent Group
Parent Group
Trunk Group
Overflow
92
Valid Entry
Default
Selection of the views (multiple choices

allowed) to animate the statistic
All
Other Data
Expression
Required
Display As
Selection of the views (multiple choices

allowed) to animate the statistic
All
Prompt
System Time
Display As
Other
REMARKS
Some display options may not be appropriate for all measures.
To change the characteristics of a given animation display, simply double-click the
animation (e.g., the plot or variable), edit the appropriate fields, and click OK (i.e.,
change colors, borders, labels, etc.).
EXAMPLE
Prompt
Entry
Data Object
Agent Group
Agent Group
Volunteers
Agent Data
Utilization
Display As
Variable
Display As
Plot
This example will display the utilization of the Volunteer group within the Basic Telethon
example. Utilization will be animated as a variable, as well as a plot.
93
Report module
DESCRIPTION
This modules purpose is to specify data collection and report generation for various
contact-center statistics. The statistics type, length of data collection timeslot, and output
file name are defined within this module, and the corresponding report is generated during
the simulation run.
PROMPTS
Report TypeThe type of statistical report and the particular value to be tracked are
chosen from among the following:
Contact TimesSelection of a particular Contact Name for which contact-time
statistics will be collected.
Contact CountsSelection of a particular Contact Name for which counts will be
tallied as contacts enter various stages.
Agent GroupSelection of a particular Agent Group for which utilization statistics
will be collected.
Parent GroupSelection of a particular Parent Group for which utilization statistics
will be collected.
Trunk GroupSelection of a particular Trunk Group for which utilization statistics
will be collected.
OverflowSelection of a particular pair of Source and Destination Agent groups for
which overflow counts will be collected.
94
Agent GroupThis field, visible if Report Type is Agent Group, defines the agent group
for which the report will be written.
Parent GroupThis field, visible if Report Type is Parent Group, defines the parent group
Trunk GroupThis field, visible if Report Type is Trunk Group, defines the trunk group
Source GroupThis field, visible if Report Type is Overflow, defines the source agent or
parent group for which the overflow statistics are to be reported.
Destination GroupThis field, visible if Report Type is Overflow, defines the destination
agent or parent group for which the overflow statistics are to be reported.
Time IntervalNumerical value, in minutes, defining the interval length for which statistics will be collected.
Form of OutputChoice of Data or Text File, which determines whether the output report
is generated in a spreadsheet-based or text format.
Output FileName of the output file to which the report will be written.
OptionsDialog that allows the specification of advanced options.
Exclude empty time slotsControls whether empty timeslots are displayed.
Highlight time slots with a specified conditionDetermines if specified timeslots will
be highlighted.
ConditionThe condition that must be met so that a timeslot will appear highlighted.
The first two fields must be selected from the drop-down list supplied.
Prompt
Valid Entry
Default
Report Type
Contact Times, Contact Counts,

Agent Group, Parent Group, Trunk
Group, Overflow
Contact Times
Contact Name
Contact 1
Contact Counts
Symbol Name [Contact Counts]
Contact 1
Agent Group
Agent Group 1
Parent Group
Parent Group 1
95
Contact NameThis field, visible if Report Type is Contact Times or Contact Counts,
defines the contact type for which the report will be written.
Prompt
Valid Entry
Default
Trunk Group
Trunk 1
Source Group
Agent Group 1
Destination Group
Agent Group 2
Time Interval
Integer >= 1
30
Form of Output
Data or Text File
Data
Output File
Symbol
Default value based on

Report type, name, and
time interval
Exclude empty time slots
Checked, Unchecked
Unchecked
Highlight time slots with a

specified condition
Checked, Unchecked
Unchecked
Condition
Expression
Required
Options
REMARKS
Each Report module facilitates statistics collection for a particular type and value. Therefore, multiple Report modules may be placed to collect all desired statistics.
In the Report module, the timeslot intervals specified for statistics collection may be of
any length. Separate Report modules may be placed to collect statistics at different levels
of aggregation (e.g., hourly, daily, and weekly).
Refer to Contact Center Edition Reports (Chapter 8) for a detailed description of each
field in the report.
Note that while statistic collection can be made for any length, the shorter the time interval, the slower the simulation will run (i.e., dont use time intervals that are unnecessarily
detailed).
In practice, care must be taken to synchronize the timeslots within the Report modules
with the timeslots defined in the Schedule modules. Agent Group statistics collection will
be disrupted if groups go on/off duty in the middle of a reporting timeslot. Therefore,
reporting timeslots should be shorter than agent shifts and coincide with their start and
end. For instance, when shifts change on the hour, statistics can be collected on the hour or
half-hour. However, if shifts change on the half-hour, statistics must be collected on the
half-hour.
96
Figure 6.1 Report outputtext form (Notepad)
The data file form of output, Figure 6.2, saves the same information with commas
between each value. This form is commonly referred to as comma-separated values and
uses the default extension .csv. Many programs like Microsoft Excel make provisions
to read .csv files directly or indirectly. Then you can use the other features of these programs to view, sort (e.g., all Mondays or all 8-9 AM timeslots), graph, and print the data.
Figure 6.2 Report outputdata form (Excel)
97
The text form of output Figure 6.1 can be readily viewed in any text editor (such as Notepad) or a word processor (such as Microsoft Word). Because of the column-oriented
data, it should be viewed in a fixed-size font, such as Courier or Line Printer, rather than a
proportional font, such as Times Roman.
EXAMPLE
Prompt
Entry
Report Type
Contact Times
Contact Name
Donor
Time Interval
60
Form of Output
Data File
Output File
Donor Time 60.csv
In this example, a report is generated of contact times for the contact name Donor.
Statistics are collected every 60 time units. The output is written to the data file Donor
Time 60.csv.
98
The Script Panel

This chapter describes each of the 14 modules that form the Script template panel. These
modules are used to define scripts. A script is used to mimic the actions, activities, and
states that each contact undergoes as it attempts to reach an agent. The following modules
are located in the Script panel:
7 The Script Panel
Begin Script
Queue for Agent
Remove from Queue
Wait
Priority
Message
Disconnect
Overflow
Transfer to Script
Transfer to Agent
Conference
Branch
Assignment
End Script
A script is created by connecting modules from the Script panel to describe this flow. All
scripts must begin with a Begin Script module.
At the end of this chapter is a list of several script restrictions as well as examples of
several Contact Center Edition scripts.
Begin Script module
99
DESCRIPTION
This modules purpose is to identify the script. The option of obtaining a trunk line can
also be specified.
PROMPTS
Script NameIdentifier of script.
Seize Trunk GroupIndicates whether a trunk should be seized.
Trunk NameName of trunk to be seized.
Prompt
Valid Entry
Default
Script Name
Script <module instance

number>
Seize Trunk Group
Checked, Unchecked
Unchecked
Trunk Name
Symbol Name [Trunks]
Trunk 1
REMARKS
The Begin Script module is required as an identifier for all scripts.
The seizing of a trunk group should only be specified for those scripts whose contacts
originate from another script containing a Transfer to Script module with Release Trunk
Group checked. An error will be generated if a contact tries to obtain more than one trunk
group.
EXAMPLE
Prompt
Entry
Script Name
Direct Routing
Seize Trunk
Unchecked
This example represents the first module for the Direct Routing script of the Basic
Telethon case study.
100
7 THE SCRIPT PANEL
Queue for Agent module
The Queue for Agent module places the contact within the specified agent group queue
where it is ranked according to its priority.
The option to access external logic is available with the Queue for Agent module. If one
or more of the check boxes are checked, entry and exit points are made available to the
module. You may connect other blocks of logic to the module via these entry and exit
points. There are restrictions with using external logic: 1) the original contact must return
to the module, 2) the Transfer to Agent module can only be used within the Prior to Post
Contact Work external logic, 3) the Conference module can only be used within the
After Talk Time external logic, and 4) any delays will be included in the handle time
and time in contact center statistics.
(Group Type)This radio button determines whether the contact will queue for an agent
group or a parent group of agents.
Agent GroupName of the agent group.
Parent GroupName of the parent group.
Selection RuleThis field, visible if Group Type is Parent Group, defines the rule used to
determine which agent is selected from among multiple member agent groups.
AdvancedThis dialog supports several options to access external logic.
After seizing agentAllows the contact entity to access external logic after seizing an
agent (before talk time starts).
After talk timeAllows the contact entity to access external logic after talk time.
101
7 The Script Panel
DESCRIPTION
Prior to post contact workAllows the contact entity to access external logic prior to
post-contact work.
Prompt
Valid Entry
Default
Group Type
Agent Group
Agent Group
Agent Group 1
Parent Group
Parent Group 1
Selection Rule

After seizing agent
Checked, Unchecked
Unchecked
After talk time
Checked, Unchecked
Unchecked
Prior to post contact

work
Checked, Unchecked
Unchecked
Advanced
REMARKS
When queueing to a parent group, there are three agent selection rules from which to
choose:
Uniform by Availability. Select an agent randomly from among any groups with the
highest preference having an available agent. Weight the random selection by the
percentage of available agents in each group.
First Available. Select the first available agent with the highest preference.
Longest Available. Select the agent that has been idle for the longest period of time
from among the available agents with the highest preference. This option is available
ONLY when the member Agent Groups are each made up of a single agent.
Additional external logic can be specified at three points in time with a relationship to the
primary agent and the agent talk time:
102
If external logic is specified in After Seizing Agent, any delays incurred will include
the primary agent. This external logic will be immediately followed by the talk time
delay specified in the Contact module.
If external logic is specified in After Talk Time, any delays incurred will include the
primary agent. This is the only place that contact conferencing can be specified. This
external logic will be immediately followed by the releasing of the primary agent.
7 THE SCRIPT PANEL
If external logic is specified in Prior to Post Contact Work, any delays incurred will
not include the primary agent. This is the only place that agent transfer can be specified. While the contact is executing this external logic, the primary agent concurrently
incurs the post-contact work delay if any is specified in the Contact module.
EXAMPLE
Entry
Group Type
Agent Group
Agent Group
Volunteers
In this example, the contact is placed in the Volunteers queue from the Basic Telethon case
study.
Remove from Queue module
DESCRIPTION
This module removes the contact from its current agent group queue and proceeds to the
next module in the script.
PROMPTS
None required.
REMARKS
This module cannot be the last module in a Script. This module typically precedes a
Message or Disconnect module.
103
7 The Script Panel
Prompt
Wait module
DESCRIPTION
The Wait module is used to hold the contact in place for a specified amount of time before
proceeding.
PROMPTS
Wait TimeDistribution of the delay for the contact.
Prompt
Valid Entry
Default
Wait Time
0.0
REMARKS
When a Wait module is encountered in a routing script, a wait time is generated from the
specified distribution. The contact is then delayed for that amount of time before
proceeding to the next module in the script. This action is used to represent abstractly a
wide variety of routing activities involving delays experienced by the contactor, including
playing welcome messages and announcements, prompting and receiving customer
inputs, transfer times, and being placed on hold for an agent.
EXAMPLE
Prompt
Entry
Wait Time
TRIA(1,3,5)
This example defines a triangular distribution that is used to determine the amount of time
the contact will wait before proceeding to the next module in the script.
104
7 THE SCRIPT PANEL
Priority module
7 The Script Panel
DESCRIPTION
The Priority module adjusts the priority of the contact. This may affect its processing,
including moving it ahead of other contacts in a queue.
PROMPTS
(Priority Change)Determines the method by which the priority changes via one of the
following methods:
IncreaseIncreases the importance of the contact by the specified amount. This will
result in the contact being ranked higher in queue and having greater claim on available agent resources.
DecreaseDecreases the importance of the contact by the specified amount. This will
result in the contact being ranked lower in queue and having reduced claim on available agent resources.
NewRedefine the importance of the contact to the specified priority. Queue ranking
and claim to available agent resources will be adjusted accordingly.
Increase Priority byQuantity by which the current value will be increased.
Decrease Priority byQuantity by which the current value will be decreased.
New PriorityNew value assigned to the current priority.
Prompt
Valid Entry
Default
Priority Change
Increase, Decrease, New
Increase
Increase Priority by
Expression
Decrease Priority by
Expression
New Priority
Expression
105
REMARKS
If the contact is already waiting in queue when a Priority action is processed, the contact
will be re-ranked within the queue based on its updated priority. If the contact is not in
queue, its updated priority will be used for ranking when it enters a queue. After priority
adjustment is complete, the routing control flow proceeds to the next module in the script.
When removed from the queue, the active priority of the contact reverts to the priority it
had upon entering the queue.
Note that the smaller the priority value, the higher the contact ranks in importance. Therefore, when the priority is increased in importance, the value of the priority attribute is
decreased numerically.
EXAMPLE
Prompt
Entry
Priority Change
Increase
Increase Priority by
This example increases the priority of the contact by 2.
Message module
DESCRIPTION
This module allows a contact to leave a message, possibly generating a contact return.
PROMPTS
Message Wait TimeAmount of time to leave a message.
Disable Contact BackDisable the option for messaged contacts to contact back (re-enter
the system).
106
7 THE SCRIPT PANEL
Disable Contact ReturnDisable the option to turn a messaged contact into a contact
return.
Prompt
Valid Entry
Default
Message Wait Time
0.0
Disable Contact Back
Checked, Unchecked
Unchecked
Disable Contact Return
Checked, Unchecked
Checked
When a Message module is encountered in a routing script, a wait time (representing the
time required to record a message) is generated from the specified distribution. The
contact is then delayed for that amount of time, counted as leaving a message, and
dispatched from the contact center. If specified in the Contact module corresponding to
the contacts type, a contact back may occur with the probability and in the time specified.
Contact backs generated from messages (specified in the Contact module) may optionally
be disabled by checking the Disable Contact Back field.
A Message module can be used for Inbound scripts only.
EXAMPLE
Prompt
Entry
Message Wait Time
UNIF(1,2)
Unchecked
Disable Contact Return
Checked
This example delays the contact according to a uniform distribution with a minimum of
1 minute and a maximum of 2 minutes. After the delay, which represents the time to leave
a message, the contact is dispatched from the contact center.
107
7 The Script Panel
REMARKS
Disconnect module
DESCRIPTION
The Disconnect module terminates a contact.
PROMPTS
Disable Contact BackDisable the option for messaged contacts to contact back (re-enter
the system).
Prompt
Valid Entry
Default
Checked, Unchecked
Unchecked
REMARKS
When a Disconnect module is encountered in a routing script, the contact is immediately
dispatched from the contact center. This Disconnect module is not permitted if the contact
is in queue. A Remove from Queue module must be executed first.
Any contact back from disconnected contacts (specified in the contacts corresponding
Contact module) may optionally be disabled using this action.
EXAMPLE
Prompt
Entry
Unchecked
This example dispatches the contact from the center. Based on the probability (if any)
specified in the associated Contact module, a contact back may be generated since the
Disable Contact Back option was not selected.
108
7 THE SCRIPT PANEL
Overflow module
7 The Script Panel
DESCRIPTION
The Overflow module removes the contact from its Source queue and sends it to its
Destination queue.
PROMPTS
Source GroupThe queue from which the contact will be removed.
Destination GroupThe queue to which the removed contact will be sent.
Prompt
Valid Entry
Default
Source Group
Agent Group 1
Destination Group
Agent Group 2
REMARKS
An Overflow module removes the contact from its current queue and counts it as an overflow between the specified Source Group and Destination Group. Routing control flow
then continues to the next module in the script. Eventually a Queue for Agent module for
the appropriate Destination Group must occur to complete the overflow sequence.
EXAMPLE
Prompt
Entry
Source Group
Primary Agents
Destination Group
Secondary Agents
This example removes the contact from the Primary Agents queue and sends it to the
queue of the Secondary Agents.
109
Transfer to Script module
DESCRIPTION
This module shifts the routing control to another script.
PROMPTS
Script NameName of the routing script to which the contact will be transferred.
Release Trunk GroupOption to indicate that the current trunk group should be released.
Prompt
Valid Entry
Default
Script Name
Script 1
Release Trunk Group
Checked, Unchecked
Unchecked
REMARKS
The Transfer to Script module is used to simplify routing scripts by separating common
elements and functions so they may be executed as subroutines by multiple scripts. It may
also be useful in matching the design of the actual routing scripts in the phone switching
system.
If Release Trunk Group is selected, the destination Begin Script module must specify a
trunk group to seize. An error will be generated if this is not defined.
EXAMPLE
Prompt
Entry
Script Name
Advanced
Release Trunk Group
Unchecked
This example would cause a contacts routing control flow to be transferred to the
Advanced script for continued processing.
110
7 THE SCRIPT PANEL
Transfer to Agent module
7 The Script Panel
DESCRIPTION
The Transfer to Agent module directs a contact from one agent group to another. This
module is for use within the Queue for Agent module only.
PROMPTS
(Group Type)Determines whether the contact will queue for an agent group or a parent
group of agents.
Agent GroupThe name of the agent group.
Parent GroupThe name of the parent group.
Selection RuleDetermines which agent is selected from among multiple available agent
groups.
Transfer Talk TimeDelay time incurred by the contact with the transfer agent.
Prompt
Valid Entry
Default
(Group Type)
Agent Group
Agent Group
Agent Group 1
Parent Group
Parent Group 1
Selection Rule

Transfer Talk Time
0.0
111
REMARKS
The Transfer to Agent module is for use within the Queue for Agent module only. The
Queue for Agent module has three Advanced features that allow external logic to be
specified at three different times: After Seizing Agent, After Talk Time, and Prior to Post
Contact Work. The Transfer to Agent module must be used with the Prior to Post Contact
Work option. By connecting this module to the special exit point created for the advanced
Queue for Agent option, a contact can be directed to another agent after the first agents
tasks are complete.
If the requested transfer agent is not available, the transfer will not be completed.
Multiple-agent transfer can be modeled by connecting a series of Transfer to Agent
modules together. The original agent is released before the contact is transferred to the
next agent. Each transfer is performed in series. Therefore, the primary agent does not
participate in the next (transfer) agents activities, and so on.
EXAMPLE
Prompt
Entry
(Group Type)
Agent Group
Agent Group
Manager
Transfer Talk Time
UNIF(3,5)
This example transfers a contact from the current agent group to the Manager Agent
Group (if available). The talk time incurred by the manager is represented by a uniform
distribution with a minimum of 3 and a maximum of 5 minutes.
Conference module
112
7 THE SCRIPT PANEL
DESCRIPTION
The Conference module is used to model agent conferencing. This module is for use
within the Queue for Agent module only.
PROMPTS
(Group Type)Determines whether the contact will conference with a member of an
agent group or a parent group of agents.
Agent GroupThe name of the agent group.
Selection RuleDetermines which agent is selected from among multiple member agent
groups.
Conference Talk TimeDelay time incurred by the contact with the conference agent and
the primary agent.
Prompt
Valid Entry
Default
(Group Type)
Agent Group
Agent Group
Agent Group 1
Parent Group
Parent Group 1
Selection Rule

Conference Talk Time
0.0
REMARKS
The Conference module is for use within the Queue for Agent module only. The Queue for
Agent module has three Advanced features that allow external logic to be specified at three
different times: After Seizing Agent, After Talk Time, and Prior to Post Contact Work. The
Conference module must be used with the After Talk Time option. By connecting this
module to the special exit point created for the advanced Queue for Agent option, a contact
can be conferenced with another agent after the first agents talk time is complete.
If the required conference agent is not available, the conference will not take place.
Multiple-agent conferencing can be modeled by connecting a series of Conference
modules. The original agent is not released until all the conferences are complete.
However, each conference is performed in series. Therefore, the first conference agent is
not a part of the second conference with the next conference agent, and so on.
113
7 The Script Panel
Parent GroupThe name of the parent group.
EXAMPLE
Prompt
Entry
(Group Type)
Agent Group
Agent Group
Manager
UNIF(7,10)
This example conferences a contact with a member of the Manager Agent group (if available). The primary agent and the conference agent incur a conference talk time anywhere
between 7 and 10 minutes.
Branch module
DESCRIPTION
This module allows for decision-making processes in a script. It includes options to make
decisions based on one or more conditions (e.g., if a contacts priority is greater than five
or based on one or more probabilities (e.g., 75%).
114
7 THE SCRIPT PANEL
PROMPTS
Branch OptionsSpecifies the one or more branch conditions/probabilities that will be
evaluated when a contact executes the module.
(Branch Type)Type of condition (If), probabilistic branch (With), or Else condition.
ConditionCondition to be evaluated. This field is visible when Branch Type is If.
There are 11 conditions that can be evaluated.
Condition is Agent Availability
Condition is Contact Attribute Value

Contact Attribute NameName of contact attribute to be evaluated.
(Operator)Mathematical operator used in the condition.
(Contact Attribute Value)Value to which the Contact Attribute Name will be
compared.
Condition is Contact Priority
(Contact Priority)Value to which the contacts current priority value will be
compared.
Condition is Contact Name Is
Contact NameName of contact type to which the contacts type will be
compared. If the contacts type is the same as Contact Type, the condition is
TRUE.
Condition is Day Is
DayDay of week to which the current simulation day will be compared. If the
current day of the week is the same as Day, the condition is evaluated as TRUE.
Condition is General Expression
SIMAN ExpressionAny valid SIMAN expression.
Condition is Queue Length
Agent QueueName of the Agent or Parent Group whose queue length will be
evaluated against (Agent Queue Length).
115
7 The Script Panel
Agent GroupName of the Agent or Parent Group whose availability is evaluated. If at least one member of the parent or agent group is available, this condition
is evaluated as TRUE.
(Agent Queue Length)Value to which the queue length of the specified Agent
Queue will be compared.
Condition is Time in Call Center
(Time in Call Center)Time (in minutes) to which that the contacts current total
time spent in the center will be compared.
Condition is Global Variable Value
Global Variable NameName of the global variable whose value will be evaluated against (Global Variable Value).
(Global Variable Value)Value to which the global variable will be compared.
Condition is Time of Day
(Time of Day)Specifies the point in time to which the current simulation time
will be compared (AM, PM, noon, or midnight).
(Hour)Specifies the hour to which the current simulation time will be compared.
(Minute)Specifies the minute in time to which the current simulation time will
be compared.
Condition is Agent Expressions
(Agent Expression)Specifies the type of agent statistic that will be used for the
condition.
Agent GroupName of the Agent or Parent Group for whom the (Agent Expression) is referring.
(Agent Expression Value)Value to which the agent statistic expression will be
compared.
Branching ProbabilityProbability of selecting branch. Used only when Branch Type
is set to With.
116
Valid Entry
Default
Branch Type
If, With, Else
If
Condition
Agent Availability, Contact Attribute

Contact Name is
Value, Contact Priority, Contact Name is,
Day is, General Expression, Queue Length,
Time in Call Center, Global Variable Value,
Time of Day, Agent Expressions
Agent Group
Agent Group 1
Symbol Name [Contact Attribute]
Attribute 1
(Contact Attribute Value) Expression
(Contact Priority)
Expression
Contact Name
Contact 1
Day
Monday, Tuesday, Wednesday, Thursday,

Friday, Saturday, Sunday
Monday
SIMAN Expression
Expression
Required
Agent Queue
Agent Group 1
(Agent Queue Length)
Expression
(Time in Call Center)
Expression
Symbol Name [Variable]
Variable 1
(Global Variable Value)
Expression
(Time of Day)
AM, PM,
AM
(Hour)
Integer (0-12)
(Minute)
Integer (0 - 59)
(Agent Expression)
Average Wait Time, Average Handle

Time, Expected Wait Time
Average Wait Time
Midnight, Noon
(Agent Expression Value) Expression
(Operator)
==
<, <=, <>, ==, >, >=
7 The Script Panel
Prompt
7 THE SCRIPT PANEL
REMARKS
The Branch module is used to simplify routing scripts by separating common elements
and functions so they may be executed as subroutines by multiple scripts. It may also be
useful in matching the design of the actual routing scripts in the phone switching system.
The last Branch specified should be an Else.
117
EXAMPLE
Prompt
Entry
Branch Type
If
Condition
Queue Length
Agent Queue
IRA specialists
(Operators)
<=
(Agent Queue Length)
Branch Type
Else
In this example, if the queue is relatively short, the contact will be directed out the first
exit point (possibly continuing to wait for a specialist). However, if the queue is long, the
contact will be directed out the second exit point (possibly overflowing to a general group
in the hope of quicker service).
Assignment module
DESCRIPTION
This module allows the assignment of contact attributes, Arena Contact Center global
variables, contact pictures, or user-defined counters.
PROMPTS
(Assignment Type)Type of assignment to be made.
Contact Attribute NameName of the contact attribute to be assigned.
Global Variable NameName of Contact Center global variable to be assigned.
ValueThe value to be assigned to the attribute or variable.
Contact Picture NameName of the contacts picture used for animation.
118
7 THE SCRIPT PANEL
Counter NameName of the counter to be incremented.

IncrementValue by which the counter is incremented.
Valid Entry
Default
(Assignment Type)
Contact Attribute, Contact Picture,

Global Variable, Counter
Contact Attribute
Symbol Name [Contact Attribute]
Attribute 1
Symbol Name [Contact Center Global

Variable]
Variable 1
Value
Expression
Symbol Name [Picture]
Picture 1
Counter Name
Symbol Name [Counter]
Counter 1
Increment
Integer
7 The Script Panel
Prompt
REMARKS
User-defined counters appear in the Category Overview, Category by Replication, and
User-Specified reports.
EXAMPLE
Prompt
Entry
(Assignment Type)
Contact Picture
Transferred Picture
This example reassigns the contacts picture to Transferred Picture.
End Script module
119
DESCRIPTION
This modules purpose is to identify the end of the script.
PROMPTS
No values are required.
REMARKS
All straight-flow scripts must end with either an End Script or Transfer to Script module.
Scripts that loop contacts until they are answered do not need an End Script module.
Script restrictions
The following actions are not permitted as the last action in a script:
Remove from Queue

Overflow
The following actions are not permitted until the contact is in queue:
Remove from Queue

Overflow
The following actions are not permitted if the contact is in queue:
Queue for Agent

Message
Disconnect
Each Overflow action must be followed eventually by a Queue for Agent action specifying
the appropriate overflow destination group.
Arena Contact Center Edition script examples

EXAMPLE 1BASIC QUEUEING
The most basic routing script consists of a single Queue for Agent module. This type of
script places the contact in the specified queue, where it will remain until it is served or
abandons the center.
1. Begin Script
2. Queue for Agent
3. End Script
120
7 THE SCRIPT PANEL
EXAMPLE 2QUEUEING WITH MESSAGE OPTION

A common script in contact centers that takes messages during periods of high demand
will queue for an agent, but will take a message if the contact has not been served within a
certain period of time.
Begin Script
Queue for Agent: Volunteers
Wait: 2
Remove from Queue
Message: 0.5
End Script
EXAMPLE 3BASIC OVERFLOW

The overflow of contacts from one group or location to another is an increasingly
common routing script feature. The most basic case of overflow is illustrated in the
following script where a contact is queued to a specialist group, where it waits for a period
of time, and is then overflowed to all potential servers if not yet served.
1.
2.
3.
4.
5.
6.
Begin Script
Queue for Agent: IRA specialists
Wait: 2
Overflow: IRA Specialists to General Customer Service
Queue for Agent: General Customer Service (Selection rule: uniform by availability)
End Script
Note that the Queue for Agent module must be placed following the Overflow module.
Also, in this example, the IRA specialists where the contact is initially queued is an agent
group, while the overflow group (general customer service) is a parent group containing
the IRA specialists group as a member. This is a common model structure in overflow
cases. In this way, the contact will be served as soon as possible by a general agent, but
may still chance upon a specialist.
121
7 The Script Panel
1.
2.
3.
4.
5.
6.
122
Reports
Arena Contact Center Edition produces the following eight reports:
Agents and Trunks

Contact Times and Counts
Contact Count Statistics
Contact Time Statistics
Agent Group Utilization
Parent Group Utilization
Trunk Group Utilization
Overflow Count Statistics
This chapter describes each type of report.

The Agents and Trunks and the Contact Times and Counts are produced by default
with each simulation run. These reports are generated using Business Objects Crystal
Reports. The output statistics are stored in an Access database where Crystal Reports
retrieves the data to generate these two reports.
Table 8.1 Timeslot column descriptions
Column Heading
Description
Timeslot
The number of the timeslot within the planning horizon for which the
statistics were collected
Week
The number of the week within the planning horizon on which the statistics
were collected
Day
The number of the day of the week on which the statistics were collected
Daily Timeslot
The number of the timeslot within the day on which the statistics were
collected
Each report also contains a report header listing the name of the simulation model, the title
of the particular run, and the date and time the run was performed.
123
8 Reports
Other reports are custom generated by the user, using the Report module. In each report, a
timeslot is defined and the appropriate statistics are then collected and reported for each
timeslot in the planning horizon. Therefore, each of the custom reports contains a set of
columns indicating the number of the timeslot within the planning horizon, as well as the
corresponding week and day of the timeslot. The number of the timeslot within the day is
also provided. This common section is described as follows:
Agents and Trunks report

This report is broken down by replication. The values calculated and displayed are for
individual replications. Each replication is broken into two sections: Trunk Summary and
Agent Summary.
Trunk Summary
The Trunk Summary is broken into two groups: Usage and Cost. Listed below are the
statistics reported for each group. Each group displays a value for each trunk defined in
the system.
USAGE
AvailableThis section reports the average number of available trunk lines for the specified planning horizon. Available is a time-persistent statistic. The value is weighted to
take into consideration the value as a function of time.
In UseThis section reports the average number of busy trunk lines for the specified
planning horizon. In Use is a time-persistent statistic. The value is weighted to take into
consideration the value as a function of time.
UtilizationThis section reports each trunk lines utilization for the specified planning.
Utilization is a time-persistent statistic. The average is weighted to take into consideration
the value as a function of time.
COST
Busy CostThis section reports the busy cost for all trunk lines. The busy cost for each
trunk line is the product of the average number of busy lines, the simulation run length,
and the trunks busy cost rate.
Agent Summary
The Agent Summary is broken into three groups: Usage, Cost, and Inbound and
Outbound Utilization. Listed below are the statistics reported for each group. Each group
displays a value for each parent and agent group defined in the system.
USAGE
AvailableThe average number of agents available over the simulation run length.
BusyThe utilization over the simulation run length. This may include times when an
agent group may not be scheduled in the system.
Est on DutyThis section reports the total time for each entity type. Total time for an
entity is calculated based on the time the entity enters the system until when statistics are
generated.
124
8 REPORTS
UtilizationThis section reports the total time for each entity. Total time for an entity is
calculated based on the time the entity enters the system until when statistics are generated.
COST
Busy CostThe product of the average number of busy agents, the simulation run length,
and the agent busy cost specified in the Agent module.
Idle CostThe product of the average number of idle agents, the simulation run length,
and the agent idle cost specified in the Agent module.
Per Use CostThe cost incurred for using an agent. Usage cost is calculated based on the
agent per-use cost and the number of times the agent is seized or allocated to an entity.
INBOUND AND OUTBOUND UTILIZATION
Inbound UtilThis section reports each trunks busy cost. Busy cost is the cost accrued
by a trunk while it is in a non-value-added activity.
Outbound UtilThis section reports each trunks busy cost. Busy cost is the cost accrued
by a trunk while it is in a non-value-added activity.
Example
See Appendix B for a sample Summary Report.
Contact Times and Counts report

This report is broken down by replication. The values calculated and displayed are for
individual replications. Each replication is broken into three sections: Contact Times,
Contact Counts, and Other Contact Data.
Contact Times
Contact Times is broken into five groups: External Logic, Handle Time, Message to
Return, Speed of Answer, and Time in Contact Center. Listed below are the descriptions of
each statistic. Each group displays the average, half-width, maximum, and minimum
values for each replication for each contact defined in the system.
125
8 Reports
Note that the report produced corresponds very closely with the information contained in
the custom reports described below. The major difference is that all measures in the
default report are based on observations taken throughout the entire planning horizon,
while the custom reports focus on individual timeslots within the planning horizon. The
contact times section of the default report also includes standard distributional measures:
average, standard deviation, minimum, maximum, and number of observations.
Handle TimeThe amount of time a contact spends from when the agent is available until
the contact is complete.
Message to Return TimeThe time from when a contact leaves a message to when an
agent returns the contact.
Speed of Answer TimeThe time a contact spends waiting for an available agent.
Time in Contact CenterThe time span from when a contact enters the center until the
contact is completed.
Contact Counts
Contact Counts is broken into three groups: Counts, Outcomes, and Contact Backs. Listed
below are the statistics reported for each group. Each group displays a value for each
contact type defined in the system.
COUNTS
BlockedThe total number of contacts blocked as of the end of the replication.
CreatedThe total number of contacts that arrived at the contact center as of the end of
the replication. This number includes contact backs generated from blocked, abandoned,
disconnected, served, and messages.
In SystemThe total number of contacts that were left in the system as of the end of the
replication.
OfferedThe total number of contacts offered as of the end of the simulation.
WaitingThe total number of contacts that were left waiting for an agent as of the end of
the replication.
OUTCOMES
AbandonedThe total number of contacts abandoned as of the end of the replication.
DisconnectedThe total number of contacts disconnected as of the end of the replication.
HandledThe total number of contacts handled as of the end of the replication.
In TargetThe total number of contacts answered within the specified service-level time
as of the end of the replication.
MessageThe total number of messages generated as of the end of the replication.
CONTACT BACKS
AbandonedThe total number of contact backs generated due to abandoned contacts for
the duration of the simulation.
126
8 REPORTS
BlockedThe total number of contact backs generated due to blocked contacts for the
duration of the simulation.
DisconnectedThe total number of contact backs generated due to disconnected contacts
for the duration of the simulation.
MessageThe total number of contact backs generated due to messages for the duration
of the simulation.
ServedThe total number of contact backs generated due to served contacts for the
duration of the simulation.
Other Contact Data

Contact Counts is broken into four groups: Service Level, Abandoned Percent, Blocking
Percent, and Contact Return Counts. Listed below are the statistics reported for each
group. Each group displays a value for each contact type defined in the system.
SERVICE LEVEL
PercentThe number of contacts answered within the specified service level divided by
the number of contacts that enter the system.
Abandoned PercentThe number of contacts abandoned divided by the number of calls

that enter the system.
Blocking PercentThe number of contacts blocked divided by the number of contacts
generated.
CONTACT RETURN COUNTS
AbandonedThe total number of contact returns generated due to abandoned contacts.
OutstandingThe total number of messages for which no action was taken (a contact
return). Note that this counter is incremented even when Disable Contact Return is
checked in the Message module or when Contact Return is not checked in the Contact
module.
ReturnedThe total number of return contacts made due to messages generated.
127
8 Reports
Target LevelThe number of seconds, specified in the Contact module, for a contacts
service level.
Contact Count Statistics report

Contact Count Statistics for [Contact Type] by [N] Minute Time Period
This report records, for each timeslot, the number of contacts entering various stages
within the contact lifespan. Each report covers a particular Contact Name.
Note that contact counts are updated as soon as the corresponding event occurs. This
implies that counts pertaining to a single contact may be spread across timeslots. For
example, a contact may be created in one timeslot, but handled in another.
Table 8.2 Contact Count Statistics report column description
128
Column Heading
Description
Contacts Waiting
The number of contacts waiting for an agent, as of the end of the

specified timeslot
Contacts In System
The number of contacts in the contact center, as of the end of the

specified timeslot
Contacts Created
The number of contacts created according to the contact pattern that

attempts to enter the system
Contact Backs
The number of previously created contacts that are attempting to return

to the contact center
Contacts Blocked
The number of contacts that were denied access to the contact center due
to lack of available trunk lines
Contacts Offered
The number of contacts that were assigned a trunk line and successfully
enter the contact center
Contacts Abandoned
The number of offered contacts that abandon the contact center prior to
being connected to an agent
Disconnected Contacts
The number of offered contacts that are disconnected by the phone

system
Messages Left
The number of offered contacts resulting in a message
Contacts Handled
The number of offered contacts that are connected to an agent
8 REPORTS
EXAMPLE
Contact Count Statistics for Account Balance by 60-Minute Time Period
Contact Time Statistics report

Contact Time Statistics for [Contact Type] by [N] Minute Time Period
This report records, for each timeslot, the amount of time handled contacts spend in
various states. Each report covers a particular Contact Name.
Note that observations are incorporated into the average statistics as soon as the
corresponding state is completed. This implies that some observations for a given contact
may be split across timeslots, and thus, each measure within a timeslot may be based on a
different number of contacts. For example, 50 contacts may be answered in a given
timeslot, but 70 complete their talk time with some overlapping from the previous
timeslot or extending into the next timeslot.
129
8 Reports
Note that during the contact centers hours of operation, all arriving contacts attain trunk
lines and enter the contact center. In fact, all contacts are ultimately handled, since no
contacts are listed as abandoned, leaving messages, or being disconnected. Observe that,
as discussed above, the service of some contacts overlap timeslots. This can be seen by
the number of contacts in the system at the end of each timeslot, as well as the occasional
discrepancy between number of offered contacts and number of handled contacts in the
same timeslot.
Table 8.3 Contact Time Statistics report column descriptions
Column Headings
Description
Time in Center
The average time each handled contact spends in the contact center
Service Level
The percentage of handled contacts that were handled within the specified service interval
Answer Time
The average time each handled contact waits before being connected to
an agent
Talk Time
The average time each handled contact spends with an agent
After Contact Time
The average time the primary agent spends completing after-contact

work
Handle Time
The average time the primary agent spends serving a contact (in terms of
talk time and after-contact time)
Additional Service
The average positive difference between the time the Time contact
leaves the contact center and the time its after-contact work is completed
EXAMPLE
Contact Time Statistics for Account Balance by 60-Minute Time Period
130
8 REPORTS
Note that during the contact centers hours of operation, the service level for contacts
within 1 minute is 100%. Further, the average speed of answer is zero. This indicates that
there was always an available agent to meet every incoming contactan extremely overstaffed contact center. This suggests that acceptable service levels could be maintained by
reducing the number of agents on-duty, perhaps by staffing them at other times to extend
the hours the center is open for business.
Agent Group Utilization report

Agent Statistics for [Agent Group] by [N] Minute Time Period
This report details the utilization of Agent Group resources for each timeslot within the
planning horizon. Each report covers one particular Agent Group.
Table 8.4 Agent Group Utilization report column descriptions
Description
Agents Busy
The average number of agents busy throughout the timeslot
Agents On Duty
The number of agents on duty throughout the timeslot
Agent Utilization
The average utilization of agents throughout the timeslot
8 Reports
Column Heading
131
EXAMPLE
Agent Statistics for Savings Specialists by 60-Minute Time Period
Note that in this example, the contact center is open only during (i.e., Schedules and
Patterns are only defined for) normal business hours. The agent total in the Savings
Specialist group is 10, as given by the number of on-duty agents. Average Savings
Specialist utilization ranges between 5.34% to 12.04%.
Parent Group Utilization report

Agent Statistics for [Parent Group] by [N] Minute Time Period
This report details the utilization of Parent Group resources for each timeslot within the
planning horizon. Parent Group statistics are based on the aggregate statistics of each
member Agent Group. Each report covers one particular Parent Group.
132
8 REPORTS
Table 8.5 Parent Group Utilization report column descriptions
Column Heading
Description
Agents Busy
The average number of agents busy throughout the timeslot
Agents On Duty
The number of agents on duty throughout the timeslot
Agent Utilization
The average utilization of agents throughout the timeslot
EXAMPLE
Agent Statistics for Savings Servers by 60-Minute Time Period
8 Reports
Patterns are only defined for) normal business hours. Also, recall that in addition to the
Savings Specialist group, the Checking Specialists and New Account Specialists are
members of the Savings Servers. The combined agent total in the three groups is 30, as
given by the number of on-duty agents. Average Savings Server utilization ranges
between 1.3% to 3.3%.
133
Trunk Group Utilization report

Trunk Statistics for [Trunk Group] by [N] Minute Time Period
This report details the utilization of Trunk Group resources for each timeslot within the
planning horizon. Each report covers one particular Trunk Group.
Table 8.6 Trunk Group Utilization report column descriptions
Column Heading
Description
Trunks In Use
The average number of trunk lines in use throughout the timeslot
Total Trunks
The number of trunk lines within the trunk group
Trunk Utilization
The average utilization of trunk lines throughout the timeslot
EXAMPLE
Trunk Statistics for Central Trunks by 60-Minute Time Period
134
8 REPORTS
Patterns are only defined for) normal business hours. Thus, the central trunk group is
utilized only during this time period. Average trunk utilization ranges between 0.94% to
9.09%.
Overflow Count Statistics report
This report details, by timeslot, the total number of contacts that overflow from one
specific agent group to another. Each report covers a particular source and destination pair
of agent groups.
Table 8.7 Overflow Count Statistics report column description
Column Heading
Description
Number of Contacts
The number of contacts overflowed from the Source Group to the

Destination Group
8 Reports
EXAMPLE
Overflow Statistics Between U.S. Center and Europe Center by 60-Minute Time Period
135
This report indicates that during primary U.S. hours (8:00 AM - 4:00 PM, EST) contacts are
overflowed between the U.S. center and its secondary center in Europe. This overflow is
initially heavy, but declines throughout the day. This may suggest increased staffing
during the U.S. morning shift, depending on the cost of trunk lines and the load placed on
the center in Europe.
136
Case Studies
Purposes of cases and examples
The purpose of the case studies and example models is to illustrate the Contact Center
Edition modeling and analysis process. Many of the product features are highlighted in
these sample models. These examples also provide a starting point for new Contact Center
Edition users.
As with any modeling tool, the best way to become familiar with Arena Contact Center
Edition is to examine the example models, run these models, and observe the differences
in output when the model inputs are altered (e.g., contact volume is increased, agents/
trunks are added, agent schedules are changed, etc.). Utilizing the products animation
features to watch your models run can also be very informative.
Example 1Bilingual Contact Center model

Overview and business objective
The business objective is to model a contact center that serves an English and Spanish
population with three types of agents: English-speaking, Spanish-speaking, and Bilingual.
The utilization of the various groups can then be assessed under different demand forecasts to ascertain staffing levels and to quantify the added value of hiring bilingual agents.
The focus of this example is on the definition of the agent and parent groups, which
support sharing of contact-center agent resources across functions and simultaneous
queueing to those resources. In addition, this example also illustrates Arena Contact
Center Editions contact abandonment and contact-back capability.
AGENT AND PARENT GROUPS

Arena Contact Center Edition makes it very easy to model basic groups comprised of one
Type of agent (agent groups) and larger groups of agents that are comprised of more than
one type of agent group (parent groups).
In the Bilingual Call Center example, there are three types of agent groups: Englishspeaking, Spanish-speaking, and Bilingual. In addition, there will be two parent groups:
the English Servers (comprised of English-speaking and Bilingual agents) and the Spanish
Servers (comprised of Spanish-speaking and Bilingual agents).
With this parent group structure, English calls will then be queued to the English Group
and Spanish calls can be queued to the Spanish Group. This means that all English calls
137
9 Case Studies
Key modeling techniques illustrated in this example
will be simultaneously queued to both English-speaking and Bilingual agents, and all
Spanish calls will be simultaneously queued to both Spanish-speaking and Bilingual
agents.
EnglishEnglishSpeaking
Speaking
(Agent
(Agent
Group)
Group)
Bilingual
Bilingual
(Agent
(Agent
Group)
Group)
English
English
Group
Group
(Parent
(Parent
Group)
Group)
English Calls Queue Here
SpanishSpanishSpeaking
Speaking
(Agent
(Agent
Group)
Group)
Spanish
Spanish
Group
Group
(Parent
(Parent
Group)
Group)
Spanish Calls Queue Here
Figure 9.1 Conceptual illustration of contact center agent groups and parent groups
CONTACT ABANDONMENT AND CONTACT BACK

Most contact centers experience some level of contact abandonment. Arena Contact
Center Edition makes it easy for you to model this behavior and to include a certain
proportion of these customers as contact backs to the contact center.
In the Bilingual Contact Center example, both English calls and Spanish calls will hang
up (abandon) if the time that they spend waiting for an agent exceeds a certain amount of
time. The amount of time that a particular call is willing to wait is a random value, based
on an exponential distribution with mean value of 2 minutes.
Of the calls that abandon the contact center, 75% will contact back after waiting for some
amount of time. The amount of time that a particular abandoned call will wait before
contacting back is 20 minutes in this example model.
The flow of a contact abandonment and contact back is illustrated in Figure 9.2.
138
Call arrives
in contact center
If no agent
by this time, call
abandons here.
Time to abandon:
random value
based on expo(2)
distribution
9 CASE STUDIES
Contact back
arrives in contact
center here.
75% of calls abandoned-produce a contact back after

20 minutes
From here, a contact back is

treated like any other contact
TIME
25% of calls abandoned-do not produce a contact back
Figure 9.2 Conceptual illustration of contact center call abandonment and contact back
The data detail for the Bilingual Contact Center example

MODEL FILE
The Bilingual Center example model can be found in bilingual.doe.
CONFIGURATION MODULE
The following table illustrates the setup of a weekly planning horizon for the Bilingual
Center case study. A single trunk group with 100 lines is also defined.
Table 9.1 Configuration moduleBilingual Center
Entry
Planning Horizon
Week
9 Case Studies
Prompt
Trunk Definitions
Trunk Group
Central Trunks
Trunk Capacity
100
Inbound Contacts
Checked
English Script
139
SCHEDULE MODULE
The following table lists the data inputs for defining the schedule the agents will follow in
the Bilingual Contact Center example.
Table 9.2 Schedule moduleBilingual Center
Prompt
Entry
Schedule Name
Business Hours
Planning Horizon
Week
Timeslot
60
Day of Week
Shift Schedule
Agent State
On-Duty
Shift Begins At
8:00 AM
Shift Ends At
5:00 PM
Day of Week
Saturday
Day of Week
Sunday
PATTERN MODULE
The Bilingual Center uses a single weekly arrival pattern for both English and Spanish
calls. Note that, in this case, the same pattern holds for each weekday in the planning
horizon with no calls arriving over the weekend.
Table 9.3 Pattern moduleBilingual Center
Prompt
Entry
Pattern
Weekly Pattern
Planning Horizon
Week
Timeslot
60
140
Day of Week
8:00 AM9:00 AM
100
9:00 AM10:00 AM
50
10:00 AM11:00 AM
50
Prompt
Entry
11:00 AMNoon
50
Noon1:00 PM
50
1:00 PM2:00 PM
50
2:00 PM3:00 PM
50
3:00 PM4:00 PM
50
4:00 PM5:00 PM
50
Day of Week
Saturday
Day of Week
Sunday
9 CASE STUDIES
AGENT MODULE
The following example defines the basic agent groups in the Bilingual Center case
(English Only, Spanish Only, Bilingual) as well as the parent agent groups built from
those groups (English Servers, Spanish Servers). The Bilingual basic agent group is
included in both parent groups. Note that each group is skilled for only those calls for
which Talk Time specifics are listed. In particular, the Bilingual group is skilled for calls
in both languages.
Note: The definitions for these agent groups and parent groups are shown together in the table
below. However, in Arena Contact Center Edition, each agent group and each parent group is
required to have its data entered into its own module.
Table 9.4 Agent modulesBilingual Center
Entry
Agent Name
English Only
Agent Type
Agent Group
20
Schedule
Business Hours
Clear Queue when Off Duty
Checked
9 Case Studies
Prompt
Talk Time
Contact Name
English
Agent Name
Spanish Only
141
Prompt
Entry
Agent Type
Agent
20
Schedule
Business Hours
Checked
Talk Time
Contact Name
Spanish
Agent Name
Bilingual
Agent Type
Agent
10
Schedule
Business Hours
Checked
Talk Time
Contact Name
English
Contact Name
Spanish
Agent Name
English Servers
Agent Type
Parent
Members
142
Agent Group
English Only
Preference
Agent Group
Bilingual
Preference
Agent Name
Spanish Servers
Agent Type
Parent
Prompt
9 CASE STUDIES
Entry
Members
Agent Group
Spanish Only
Preference
Agent Group
Bilingual
Preference
SCRIPTS
The following example illustrates the contact control flow in the Bilingual Center case
study. Each call is queued to the appropriate language group according to the contact
name. Note that, through use of parent groups, calls are simultaneously queued to both
member agent groups.
Note: The definitions for both scripts are shown together in the table below. In the template, each
script would be in its own grouping with each of the modules connected in series.
Table 9.5 Script modulesBilingual Center
Module
Prompt
Entry
Begin Script
Script Name
English Script
Queue for Agent
Group Type
Parent Group
Parent Group
English Servers
Selection Rule
Begin Script
Script Name
Spanish Script
Queue for Agent
Group Type
Parent Group
Parent Group
Spanish Servers
Selection Rule
9 Case Studies
End Script
End Script
CONTACT MODULE
The following example defines the English and Spanish call types for the Bilingual Center
case study. The two types differ only in terms of associated routing scripts. Talk time is
sampled from a uniform distribution. An abandonment model is indicated, with calls
143
waiting a random amount of time following an exponential distribution with a mean of

2 minutes prior to abandoning. Seventy-five percent of calls will contact back after
abandoning, but not if they are blocked. Finally, the default script provided from the trunk
is overridden to employ a specific script for each contact name.
Table 9.6 Contact modulesBilingual Center
Prompt
Entry
Contact Name
English/Spanish
Pattern
Weekly Pattern
Trunk Group
Central Trunks
Contact Back
Contact Back Reason
Abandoned
Probability
0.75
Wait Time
20
Abandonment
Wait Time Until Abandonment
EXPO(2)
Advanced
Checked
(Override Type)
Script
Routing Script
English Script/Spanish Script
Talk Time Distribution
UNIF(3,7)/UNIF(4,6)
Example 2Bank model

In this case study, the business objective is to model a customer service center for a bank
where each agent can handle any type of contact, but is able to handle contacts within
their specialty more efficiently than others. Account Balance, Savings, and Checking
contacts are processed by this contact center, and specialty groups have been created for
everything but common account balance inquiries.
The impact of different contact loads on the utilization of the agent groups is of interest, as
well as the handle time of each contact name type. In particular, the goal is to maximize
144
9 CASE STUDIES
customer service by routing contacts to the agents who handle them most effectively
while ensuring that the account balance inquiries are shared fairly across all groups.
From a modeling perspective, the focus of this example is on definition of agent and
parent groups to support sharing of agent resources, simultaneous queueing, and the
implementation of preferences among agents. Also, agent proficiency levels for particular
contacts are modeled through different handle times by contact.

OVERRIDE TRUNK SCRIPT
In Arena Contact Center Edition, each trunk group is assigned a specific routing script,
which is then used as the default script for all contacts in that trunk group.
However, each contact name can be assigned its own individual script, which then overrides the script assigned to its trunk group.
In the Bank example, the Balance Script is assigned to the Central Trunks trunk
group, but each contact name in this trunk group is assigned its own individual routing
script.
AGENT GROUPS, PARENT GROUPS, AND AGENT PREFERENCES
Arena Contact Center Edition makes it very easy to model basic groups comprised of one
type of agent (agent groups) and larger groups of agents that are comprised of more than
one type of agent group (parent groups).
In the Banking example, there are two types of agent groups (Savings and Checking) and
three contact names (Savings, Checking, and Account Balances).
In Arena Contact Center Edition, this concept is modeled by creating Parent Groups and
Preferences within those parent groups. For example, the Savings Parent Group includes
Savings agents with a Preference value of 1 and Checking agents with a Preference value
of 5, while the Checking Parent Group includes Checking agents with a Preference value
of 1 and Savings agents with a Preference value of 5.
In Arena Contact Center Edition, Agent Preference values enable a contact to choose
between different agents when agents of more than one type are available to provide
service.
145
9 Case Studies
In this model, every agent is capable of handling every type of contact, and thus there is a
parent group for each individual contact name. However, because agents are better suited
to handle the contacts that they specialize in (that is, agents from the Savings group handle
Savings contacts more quickly than other agents), the policy of the contact center is that
agents will have a preference for these contacts.
For example, suppose that a Savings contact is queued to the Savings Parent Group and
that there are both Savings and Checking agents idle when it arrives. The contact will be
served by the Savings agent because the Savings agent has a lower Preference value in the
Savings Parent Group.
Similarly, suppose that a Checking contact is queued to the Checking Parent Group and
that there are both Savings and Checking agents idle when it arrives. The contact will be
served by the Checking agent because the Checking agent has a lower Preference value in
the Checking Parent Group.
This concept is illustrated in Figure 9.3 below. Note that the Preference values are
assigned when agent groups are assigned to a Parent Group.
Savings
Savings
(Agent
(Agent
Group)
Group)
Checking
Checking
(Agent
(Agent
Group)
Group)
Preference
1
Preference
5
Savings
Savings
Servers
Servers
(Parent
(Parent
Group)
Group)
Savings calls queue here. If Savings Agent group
member available, choose that agent (lower
preference).
Figure 9.3 Conceptual description of Agent Groups, Parent Groups, and Agent Preferences
AGENT PROFICIENCY LEVELS

In many contact centers, it is common to see some agent groups handling certain types of
contacts faster than other agent groups. Arena Contact Center Edition makes it very easy
for you to model different proficiency levels through the use of Talk Time Multipliers.
In the Banking example, agents who specialize in a particular contact name handle contacts of that type more quickly than other agents. For example, agents from the Savings
agent group handle Savings contacts with a talk time multiplier of 0.75, compared to
Checking agents, who have a talk time multiplier of 1.00 for Savings contacts.
Note that the talk time multiplier is multiplied by the base talk time associated with a contact to determine how much time an agent spends processing a particular type of contact.
146
9 CASE STUDIES
The data detail for the Bank example

MODEL FILE
The Bank model can be found in bank.doe.
The Bank case study is based on a weekly planning horizon and a center with a single
trunk group of 15 lines.
Table 9.7 Configuration module-Bank model
Prompt
Entry
Planning Horizon
Week
Trunk Definitions
Trunk Group
Central Trunks
Trunk Capacity
15
Inbound Contacts
Checked
Balance Script
Outbound Contacts
Unchecked
Trunk Cost/Hour
SCHEDULE MODULE
9 Case Studies
Agents in the Bank model work normal business hours.

Table 9.8 Agent Schedule moduleBank model
Prompt
Entry
Schedule Name
Business Hours
Planning Horizon
Week
Timeslot
60
Day Of Week
Shift Schedule
Agent State
On-Duty
Shift Begins at
8:00 AM
147
Prompt
Entry
Shift Ends at
5:00 PM
Day Of Week
Saturday
Day Of Week
Sunday
PATTERN MODULE
Each contact name within the Bank model follows its own unique arrival pattern.
Table 9.9 Pattern moduleBank model
Prompt
Entry
Pattern
Savings Pattern (Checking Pattern, Account Balance Pattern)
Planning Horizon
Week
Timeslot
60
148
Day Of Week
8:00 AM9:00 AM
4 (40,100)
9:00 AM10:00 AM
2 (20,50)
10:00 AM11:00 AM
2 (20,50)
11:00 AMNoon
2 (20,50)
Noon1:00 PM
2 (20,50)
1:00 PM2:00 PM
2 (20,50)
2:00 PM3:00 PM
2 (20,50)
3:00 PM4:00 PM
2 (20,50)
4:00 PM5:00 PM
2 (20,50)
Day Of Week
Saturday
Day Of Week
Sunday
9 CASE STUDIES
AGENT MODULE
The important observation to make about the Agent Group definitions is that agent
proficiency is incorporated by varying the talk time multipliers for each contact name. In
particular, specialist agents handle contacts within their specialty in 75% of the time
required by their counterparts.
The Savings Specialist agent group is defined in the table below. The other basic group is
defined similarly, with the only difference being that the talk time multiplier of 0.75 is
shifted to the appropriate specialty contact. Each group requires its own module.
Table 9.10 Agent modules (Agent Groups)Bank model
Prompt
Entry
Agent Name
Savings Specialists
Agent Type
Agent
Schedule
Business Hours
Checked
Busy Cost/Hour
12
Idle Cost/Hour
12
Per Use Cost
0.0
Talk Time
Savings
0.75
Call Type
Checking
Contact Name
Account Balance
Agent Name
Checking Specialists
Agent Type
Agent
Schedule
Business Hours
Checked
Busy Cost/Hour
7.5
9 Case Studies
Contact Name
149
Prompt
Entry
Idle Cost/Hour
7.5
Per Use Cost
0.0
Talk Time
Contact Name
Checking
0.75
Contact Name
Savings
Contact Name
Account Balance
The objective of the Bank model is to route contacts to agent specialists whenever they
are available. This is accomplished by using preferences in the Parent Group definitions.
Based on the definitions below, notice that a call queued to a particular parent group is, in
effect, simultaneously queued to all potential servers, but will select a server from the
preferred agent group if possible. Since all agents are equally qualified to handle balance
inquiries, there are no associated preferences for a particular agent group.
The Savings Server agent group is defined in Table 9.11. The other two groups are defined
similarly, with the only difference being that the high preference is shifted to the appropriate specialty contact. Finally, all agent groups are skilled to handle account balance contacts and a parent group is set up to distribute those contacts without preference among the
specialty group. Each group requires its own module.
Table 9.11 Agent module (Parent Groups)Bank model
Prompt
Entry
Agent Name
Savings Servers
Agent Type
Parent
Checked
Members
150
Agent Group
Savings Specialists
Preference
Agent Group
Preference
Prompt
Entry
Agent Name
Checking Servers
Agent Type
Parent
Checked
9 CASE STUDIES
Members
Agent Group
Preference
Agent Group
Savings Specialists
Preference
Agent Name
Balance Servers
Agent Type
Parent
Checked
Members
Agent Group
Savings Specialists
Preference
Agent Group
Preference
SCRIPTS
Table 9.12 Script modulesBank model
Module
Prompt
Entry
Begin Script
Script Name
Savings Script
Queue for Agent
Group Type
Parent Group
Parent Group
Savings Servers
Selection Rule
Script Name
Checking Script
End Script
Begin Script
151
9 Case Studies
Since a parent group has been defined for each contact name that encapsulates all valid
servers, the routing scripts are straightforward in the Bank model.
Module
Prompt
Entry
Queue for Agent
Group Type
Parent Group
Parent Group
Checking Servers
Selection Rule
Begin Script
Script Name
Balance Script
Queue for Agent
Group Type
Parent Group
Parent Group
Balance Servers
Selection Rule
End Script
End Script
CONTACT MODULE
The definitions for contact names in the bank model are all basically parallel. There are
minor differences in expected handle time. Each call is associated with its own custom
routing script.
Table 9.13 Contact moduleBank model
Prompt
Entry
Contact Name
Savings (Checking, Account Balance)
Pattern
Savings Pattern (Checking Pattern, Account Balance Pattern)
Expected Talk Time
5 (Savings,Checking) or 1 (Account Balance)
Trunk Group
Central Trunks
Advanced
152
Checked
(Override Type)
Script
Routing Script
Savings Script (Checking Script, Balance Script)
9 CASE STUDIES
Example 3Skill-based Routing model

OVERVIEW AND BUSINESS OBJECTIVE
The business objective is to model a contact center that serves three different contact
names, which we refer to only as A, B, and C.
The focus of this example is on the definition of the agent and parent groups, simultaneous queueing, and agent skill priorities.

AGENT GROUPS, PARENT GROUPS, AND AGENT-SKILL PRIORITIES
In this example, there are two agent groups: AB agents (who serve calls of Type A with
priority 1 and calls of Type B with priority 2) and BC agents (who serve calls of Type B
with priority 1 and calls of Type C with priority 2). In addition, there is one parent group
called B servers that is comprised of AB agents and BC agents.
Calls of Type A are queued to the AB Agent Group.
Calls of Type B are queued to the B servers Parent Group.
Calls of Type C are queued to the BC Agent Group.
Note: Contact Priorities are used to determine which contact an agent will choose when there are
contacts of several different types waiting to be served by its agent group.
153
9 Case Studies
In this example, suppose that there are calls of Type A, calls of Type B, and calls of Type
C all waiting for service. When an AB agent becomes available, it will choose a Type A
call, because Type As have the lowest priority value for AB agents. Similarly, when a BC
agent becomes available, it will choose a Type B call, because Type Bs have the lowest
priority value for BC agents.
The agent skill priority concept is illustrated in Figure 9.4 below.

BC
BC Agents
Agents
(Agent
(Agent
Group)
Group)
AB
AB Agents
Agents
(Agent
(Agent
Group)
Group)
Priority 1
Priority 2
BB Servers
Servers
(Parent
(Parent
Group)
Group)
Priority 1
Calls
Calls of
of
Type
Type BB
Queue
Queue for
for
BB Servers
Servers
Parent
Parent Group
Group
(AB
(AB and
and BC
BC
Agents)
Agents)
Calls
Calls of
of Type
Type
A
A
Queue
Queue for
for AB
AB
Agents
Agents
Priority 2
Calls
Calls of
of Type
Type
C
C
Queue
Queue for
for BC
BC
Agents
Agents
Figure 9.4 Conceptual illustration of contact center agent skill priority concept
The data detail for the Skill-based Routing example

MODEL FILE
The Skill-based Routing model can be found in Skill.doe.
The Skill-based Routing case study is based on a weekly planning horizon and a center
with a single trunk group of 100 lines.
Table 9.14 Configuration moduleSkill-based Routing model
Prompt
Entry
Planning Horizon
Week
Trunk Definitions
Trunk Group
Central Trunks
Trunk Capacity
100
Inbound Contacts
154
Checked
Skill A Script
9 CASE STUDIES
SCHEDULE MODULE
All agents in the Skill-based Routing model are on-duty during normal business hours.
Table 9.15 Agent Schedule moduleSkill-based Routing model
Prompt
Entry
Schedule Name
Business Hours
Planning Horizon
Week
Timeslot
60
Day Of Week
Shift Schedule
Agent State
On-Duty
Shift Begins at
8:00 AM
Shift Ends at
5:00 PM
Day Of Week
Saturday
Day Of Week
Sunday
PATTERN MODULE
All contact names within the Skill-based Routing model follow the same arrival pattern.
Table 9.16 Pattern moduleSkill-based Routing model
Entry
Pattern
Weekly Pattern
Planning Horizon
Week
Timeslot
60
9 Case Studies
Prompt

Day of Week
8:00 AM9:00 AM
40
9:00 AM10:00 AM
20
10:00 AM11:00 AM
20
11:00 AMNoon
20
Noon1:00 PM
20
155
Prompt
Entry
1:00 PM2:00 PM
20
2:00 PM3:00 PM
20
3:00 PM4:00 PM
20
4:00 PM5:00 PM
20
Day Of Week
Saturday
Day Of Week
Sunday
AGENT MODULE
The key component of Agent Group definitions in the Skill-based Routing example is the
inclusion of Agent Skill Priorities. These priorities express the agents preference for what
contact name to serve when faced with multiple options. In this model, both agent groups
are multi-skilled, handling Call B and either Call A or Call C. The AB skilled agents have
a primary focus on Call A, and therefore assign it top priority. Similarly, the BC skilled
agents have a primary focus on Call B. Thus, when faced with a choice between Call A
and Call B, AB agents will select Call A. Given a similar choice between Call B and Call
C, BC agents will service Call B.
Table 9.17 Agent modulesSkill-based Routing model
Prompt
Entry
Agent Name
AB Agents
Agent Type
Agent
Schedule
Business Hours
Checked
Talk Time
Contact Name
Call A
Override Contact Priority with

Skill Priority
Checked
156
Prompt
Entry
Contact Name
Call B
Checked with Skill Priority
9 CASE STUDIES
Agent Name
BC Agents
Agent Type
Agent
Schedule
Business Hours
Checked
Talk Time
Contact Name
Call B
Override Call Priority with

Skill Priority
Checked
1
Call Type
Call C
Override Call Priority with

Skill Priority
Checked
9 Case Studies
Agent Name
B Servers
Agent Type
Parent Group
Checked
Members
Agent Group
AB Agents
Preference
157
Prompt
Entry
Agent Group
BC Agents
Preference
SCRIPTS
Since there is only one agent group skilled to handle Call A or Call C, these contacts are
queued directly to the appropriate agent group. Since all agents are capable of serving Call
B, a parent group has been defined to provide simultaneous queueing. Note that all agents
in each agent group face two queues: their own agent group queue and the parent group
queue. It is this setup that enables the skill-based contact selection described in the Agent
module discussion.
Table 9.18 Script modulesSkill-based Routing model
Module
Prompt
Entry
Begin Script
Script Name
Skill A Script
Queue for Agent
Group Type
Agent Group
Agent Group
AB Agents
Begin Script
Script Name
Skill B Script
Queue for Agent
Group Type
Parent Group
Parent Group
B Servers
Selection Rule
Begin Script
Script Name
Skill C Script
Queue for Agent
Group Type
Agent Group
Agent Group
BC Agents
End Script
End Script
End Script
158
9 CASE STUDIES
CONTACT MODULE
There is nothing fancy about the definition of the three contact names, except the association of custom routing scripts for each.
Table 9.19 Contact modulesSkill-based Routing model
Prompt
Entry
Contact Name
Call A (Call B, Call C)
Pattern
Weekly Pattern
Expected Talk Time
Trunk Group
Central Trunks
Advanced
Checked
(Override Type)
Script
Routing Script
Skill A Script (Skill B Script, Skill C Script)
Example 4Premium Service model

This case study illustrates several important modeling concepts, including multiple-trunk
groups, global contact priorities, multiple-agent schedules, and multiple patterns.

MULTIPLE-TRUNK GROUPS AND GLOBAL CALL PRIORITIES
Arena Contact Center Edition allows you to create multiple trunk groups and to assign
different contacts to different trunk groups. In this example, all Regular contacts are
assigned to the Regular Trunks trunk group, and all Premium contacts are assigned to
the Premium Trunks trunk group.
159
9 Case Studies
The business objective is to model a contact center that serves two contacts (Premium and
Regular), with one contact (Premium) getting priority over the other one. After building
this type of simulation model, one can assess the impact of increasing the percentage or
length of premium contacts on service levels for both premium and regular contacts. One
can also easily analyze the service-level impact of increasing the number of agents dedicated to premium contacts.
Each trunk group can then be assigned its own capacity, its own default contact priority,
and its own default routing script. All contact names assigned to a given trunk group
default to this contact priority and this routing script unless assigned their own priority
and/or routing script.
When building a contact center model, the following rules will help you keep track of
contact priority assignments:
Every Trunk Group has a default Contact Priority.

If a Contact Name is assigned a Contact Priority, this assignment overrides the Trunk
Group default.
If an Agent Skill Priority is assigned for a particular Contact Name, this assignment
overrides both the Trunk Group and Contact assignment.
In this example, all contacts assigned to the Regular Trunks group have Priority value 2,
and all contacts assigned to the Premium Trunks group have Priority value 1. Therefore,
because of their lower priority value, all contacts in the Premium Trunks group will have
priority for agents over all contacts in the Regular Trunks group. No other priority assignments are made in this model.
MULTIPLE PATTERNS
In an Arena Contact Center model, you can use many different patterns to represent the
way in which different types of contacts arrive to your contact center system. Any patterns
are, in turn, assigned to one or more contact names.
MULTIPLE-AGENT SCHEDULES
In a contact center model, you can create and use many different agent schedules. Any
agent schedule is, in turn, assigned to and used by one or more agent groups.
These assignments are illustrated in Figure 9.5.
160
Trunk
Trunk Groups
Groups
Individual
Individual
Agents
Agents
Routing
Routing Scripts
Scripts
Queueing to
Parent
Groups
Queueing to
Agent
Groups
Parent
Parent Groups
Groups
(Containing
(Containing One
One or
or
More
More Agent
Agent Groups)
Groups)
Calls
Calls
9 CASE STUDIES
Agent
Agent
Skills
Skills
Agent
Agent Groups
Groups
Agent
Agent
Schedules
Schedules
Pattern
Pattern
Figure 9.5 The relationship between key contact center modeling components
The data detail for the Premium Service example

MODEL FILE
The Premium Service model can be found in premium.doe.
The Premium Service model will simulate one day of contact-center activity. Two trunk
groups are defined in order to provide premium contactors with dedicated service. Note
that there is a custom routing script and contact priority associated with each trunk group.
The priorities specify a global precedence for premium contacts over regular contacts.
Table 9.20 Configuration modulePremium Service model
Prompt
Entry
Planning Horizon
Day
Trunk Definitions
Trunk Group
Regular Trunks
Trunk Capacity
100
161
9 Case Studies
Prompt
Entry
Inbound Contacts
Checked
Regular Script
Inbound Call Priority
Trunk Group
Premium Trunks
Trunk Capacity
20
Inbound Contacts
Checked
Premium Script
SCHEDULE MODULE
In addition to a standard business hour schedule, a 24-hour schedule has been defined to
provide premium contacts with round-the-clock service.
Table 9.21 Agent Schedule modulesPremium Service model
Prompt
Entry
Schedule Name
Business Hours
Planning Horizon
Day
Timeslot
60
Shift Schedule
Agent State
On-Duty
Shift Begins at
8:00 AM
Shift Ends at
5:00 PM
Schedule Name
24 Hours
Planning Horizon
Day
Timeslot
60
Shift Schedule
162
Agent State
On-Duty
Shift Begins at
Midnight
Shift Ends at
Midnight
9 CASE STUDIES
PATTERN MODULE
A separate pattern is defined for each contact name. This corresponds to the business
application: regular contacts are restricted to service during the regular business day,
while premium contacts have 24-hour access to agents.
Table 9.22 Pattern modulesPremium Service model
Prompt
Entry
Pattern
Regular Pattern
Planning Horizon
Day
Timeslot
60

160
9:00 AM10:00 AM
80
10:00 AM11:00 AM
80
11:00 AMNoon
80
Noon1:00 PM
80
1:00 PM2:00 PM
80
2:00 PM3:00 PM
80
3:00 PM4:00 PM
80
4:00 PM5:00 PM
80
Pattern
Premium Pattern
Planning Horizon
Day
Timeslot
60
9 Case Studies
8:00 AM9:00 AM

Midnight1:00 AM
1:00 AM2:00 AM
2:00 AM3:00 AM
3:00 AM4:00 AM
4:00 AM5:00 AM
5:00 AM6:00 AM
6:00 AM7:00 AM
163
Prompt
Entry
7:00 AM8:00 AM
8:00 AM9:00 AM
160
9:00 AM10:00 AM
72
10:00 AM11:00 AM
64
11:00 AMNoon
64
Noon1:00 PM
64
1:00 PM2:00 PM
64
2:00 PM3:00 PM
64
3:00 PM4:00 PM
64
4:00 PM5:00 PM
64
5:00 PM6:00 PM
6:00 PM7:00 PM
7:00 PM8:00 PM
8:00 PM9:00 PM
9:00 PM10:00 PM
10:00 PM11:00 PM
11:00 PMMidnight
AGENT MODULE
Agent Group definitions are relatively straightforward in the Premium Service model. As
in the Bilingual Center, agent groups are defined based on the contact name they will
serve: Regular, Premium, or Utility (both). Parent groups are defined for each contact
name to facilitate simultaneous queueing to all capable servers. Note that due to the
establishment (see Configuration) of a global priority of premium contacts over regular
contacts, an available utility agent will serve any waiting premium contact before a
regular contact.
Table 9.23 Agent modulesPremium Service model
164
Prompt
Entry
Agent Name
Regular Agents
Agent Type
Agent Group
Prompt
Entry
10
Schedule
Business Hours
Checked
9 CASE STUDIES
Talk Time
Contact Name
Regular Call
Agent Name
Premium Agents
Agent Type
Agent Group
Schedule
24 Hours
Checked
Talk Time
Contact Name
Premium Call
1
Utility Agents
Agent Type
Agent Group
Schedule
Business Hours
Checked
9 Case Studies
Agent Name
Talk Time
Contact Name
Regular Call
Contact Name
Premium Call
Agent Name
Regular Servers
Agent Type
Parent Group
Checked
165
Prompt
Entry
Members
Agent Group
Regular Agents
Preference
Agent Group
Utility Agents
Preference
Agent Name
Premium Servers
Agent Type
Parent Group
Checked
Members
Agent Group
Premium Agents
Preference
Agent Group
Utility Agents
Preference
SCRIPTS
The routing scripts in the Premium Service model are straightforward.
Table 9.24 Script modulesPremium Service model
Module
Prompt
Entry
Begin Script
Script Name
Regular Script
Queue for Agent
Group Type
Parent Group
Parent Group
Regular Servers
Selection Rule
Begin Script
Script Name
Premium Script
Queue for Agent
Group Type
Parent Group
Parent Group
Premium Servers
Selection Rule
End Script
End Script
166
9 CASE STUDIES
CONTACT MODULE
The contact-type definitions in the Premium Service model are very basic.
Table 9.25 Contact modulesPremium Service model
Prompt
Entry
Contact Type
Call
Contact Name
Regular Call
Pattern
Regular Pattern
Expected Talk Time
10
Trunk Group
Regular Trunks
Contact Type
Call
Contact Name
Premium
Pattern
Premium Pattern
Expected Talk Time
10
Trunk Group
Premium Trunks
Example 5Teamwork model

OVERVIEW AND BUSINESS OBJECTIVE
The logic flow for this example is illustrated in Figure 9.6.
167
9 Case Studies
This is a more advanced, more complex model than the other examples in this chapter.
The business objective is to model a contact center that processes a large number of
contacts that simultaneously require more than one agent to handle (conferencing)
and/or require contacts to be transferred from one agent group to another. This type of
model enables managers to understand where increased staff may be needed to achieve
service-level targets, to identify agent groups with high- and low-utilization levels, and to
evaluate the impact of different contact-routing rules.
Trunk
Trunk Groups
Groups
Individual
Individual
Agents
Agents
Routing
Routing Scripts
Scripts
Queueing to
Parent
Groups
Calls
Calls
Queueing to
Agent
Groups
Parent
Parent Groups
Groups
(Containing
(Containing One
One or
or
More
More Agent
Agent Groups)
Groups)
Agent
Agent
Skills
Skills
Agent
Agent Groups
Groups
Agent
Agent
Schedules
Schedules
Pattern
Pattern
Figure 9.6 Logic flow for the Teamwork model
KEY MODELING TECHNIQUES ILLUSTRATED IN THIS EXAMPLE

There are a number of different modeling techniques illustrated in this model, including:
Queueing to Agent Groups

Advanced Talk-Time Distributions
Talk Time Multipliers (for Agent Proficiency)
Transfer to Routing Scripts
Conferencing and Conference-Time Multipliers
After-Contact Time
These concepts are described in more detail in the Data Detail section below.
The data detail for the Teamwork example

MODEL FILE
The Teamwork model can be found in teamwork.doe.
The Teamwork model is based on a daily planning horizon and a center with a central
168
9 CASE STUDIES
Table 9.26 Configuration moduleTeamwork model
Prompt
Entry
Planning Horizon
Week
Trunk Definitions
Trunk Group
Central Trunks
Trunk Capacity
25
Inbound Contacts
Checked
Direct Routing
SCHEDULE MODULE
All agent groups in the Teamwork model work normal business hours.
Table 9.27 Agent Schedule moduleTeamwork model
Prompt
Entry
Schedule Name
Business Hours
Planning Horizon
Day
Timeslot
60
Shift Schedule
On-Duty
Shift Begins at
8:00 AM
Shift Ends at
5:00 PM
9 Case Studies
Agent State
PATTERN MODULE
All customer requests within the Teamwork model follow a basic arrival pattern.
Table 9.28 Pattern moduleTeamwork model
Prompt
Entry
Pattern
Daily Pattern
Planning Horizon
Day
Timeslot
60
169
Prompt
Entry

8:00 AM9:00 AM
200
9:00 AM10:00 AM
100
10:00 AM11:00 AM
100
11:00 AMNoon
100
Noon1:00 PM
100
1:00 PM2:00 PM
100
2:00 PM3:00 PM
100
3:00 PM4:00 PM
100
4:00 PM5:00 PM
100
AGENT MODULE
The Agent Group definitions identify all the key players in the Teamwork model and how
they work together.
All contacts arrive at a central receptionist. The receptionist will ascertain the nature of
the customer request (represented by the talk time specified in the contact module) and
potentially conference in a member of the accounting department before transferring the
contact to either technical support or a manager. The receptionist will then update the
customers folder (after-contact time) before taking a new contact. Note that the transfer
to manager is implemented via the Transfer to Script module. This allows the contact to
queue for a manager, whereas the use of a Transfer to Agent module will only transfer the
contact if an agent is immediately available to accept the transfer.
Also note that the transfer to technical support uses a Transfer to Script module. Using the
Transfer to Script allows the contact to be directed to another Queue for Agent module,
which must be used if contact conferencing is needed. A technical support agent will
address the contactors technical questions (represented by the talk time specified in the
contact module, multiplied by the technical support agents talk time multiplier specified
in the agent module) and potentially conference in a member of the development team.
Since the contact was transferred to a script instead of an agent, if the contactor
disconnects if a technical support agent is not immediately available, this must be
modeled explicitly within the script.
Based on the talk- and conference-time multipliers used to model the nature of the dialog
at different servers, and the time distributions specified in the Contact module, the amount
of time the contact spends in various states is:
170
9 CASE STUDIES
Reception (talk time from Contact module): TRIA(0.5, 1, 5)

Conference with accounting (reception agent conference time multiplier * conference
with accounting talk time): 2*UNIF(0, 1)
Technical support (technical support agent talk time multiplier * talk time from
Contact module): 10*TRIA(0.5, 1, 5)
Conference with development (technical support agent conference time multiplier *
conference with development talk time): 5*UNIF(0,1)
Manager (manager agent talk time multiplier * talk time from Contact module):
3*TRIA(0.5, 1, 5)
Reception (after-contact time): EXPO(1)
Note that not all stages occur on every contact, and recall that conference and transfer
times are in addition to talk time. For example, the conference with accounting occurs
after the talk time with the receptionist. Also, the after-call work performed by the
receptionist begins immediately upon transfer of the call from reception, NOT after the
call leaves the center.
Table 9.29 Agent modulesTeamwork model
Entry
Agent Name
Reception
Agent Type
Agent Group
Schedule
Business Hours
Checked
9 Case Studies
Prompt
Talk Time
Contact Name
Customer Request
Conference-Time Multiplier
Agent Name
Accounting
Agent Type
Agent Group
Schedule
Business Hours
Checked
171
Prompt
Entry
Talk Time
Contact Name
Customer Request
Agent Name
Technical Support
Agent Type
Agent Group
Schedule
Business Hours
Checked
Talk Time
Contact Name
Customer Request
10
Conference-Time Multiplier
Agent Name
Development
Agent Type
Agent Group
Schedule
Business Hours
Checked
Talk Time
Contact Name
Customer Request
Agent Name
Managers
Agent Type
Agent Group
Schedule
Business Hours
Checked
Talk Time
172
Contact Name
Customer Request
9 CASE STUDIES
SCRIPTS
The Teamwork model employs three separate scripts to direct incoming contacts through
the system. The first script, Direct Routing, directs incoming contacts to a receptionist.
After the talk time, there is a 20 percent chance that the contact will be conferenced with
Accounting, if available. Prior to the post-contact work, the contact is directed to either
the Manager script or the Tech script.
The Manager script is a basic script that directs incoming contacts to the manager.
The Tech script directs the incoming contacts to Technical Support. In the main section of
the logic, the contact is disconnected if it is not immediately answered. If the contact is
handled by Technical Support, there is a 20 percent change that the contact will be conferenced with Development, if available.
The individual module data for all three scripts are listed below. Refer to Figures 9.79.9
below to see how the modules are connected.
Table 9.30 Script modulesTeamwork Model
Module
Prompt
Entry
Begin Script
Script Name
Direct Routing
Queue for Agent
Group Type
Agent Group
Agent Group
Receptionist
Branch Type
With
Branching Probability
Branch Type
Else
Agent Type
Agent Group
Agent Group
Accounting
UNIF(0,1)
Branch Type
With
Branch Type
Else
Transfer to Script
Script Name
Manager Script
Transfer to Script
Script Name
Tech Script
After Talk Time Logic

Branch
9 Case Studies
Conference
Prior to Post Contact

Work Logic
Branch
173
Module
Prompt
Entry
Begin Script
Script Name
Manager Script
Queue for Agent
Group Type
Agent Group
Agent Group
Managers
Begin Script
Script Name
Tech Script
Queue for Agent
Group Type
Agent Group
Agent Group
Technical Support
Branch Type
With
Branch Type
Else
Agent Type
Agent Group
Agent Group
Development
UNIF(0,1)
End Script
End Script
After Talk Time Logic

Branch
Conference
Remove from Queue

Disconnect
End Script
Figure 9.7 Manager ScriptTeamwork model
174
9 CASE STUDIES
Figure 9.8 Direct-Routing ScriptTeamwork model
9 Case Studies
Figure 9.9 Tech ScriptTeamwork model
CONTACT MODULE
The contacts in the Teamwork model cover a wide range of customer requests and, as a
result, advanced distributions are used to model talk time and after-contact work.
The talk-time distribution specified in the Advanced section of the Contact module
replaces the traditional exponential distribution used in the Main section. In this case, a
triangular distribution is used having a mean of 1 minute and minimum and maximum of
30 seconds and 5 minutes, respectively.
175
An exponential distribution with a mean of 1 minute is used to model the after-contact

paperwork that must be completed by the receptionist following each contact.
Table 9.31 Contact moduleTeamwork model
Prompt
Entry
Contact Name
Customer Request
Pattern
Daily Pattern
Talk Time
(See Advanced section)
Trunk Group
Central Trunks
Advanced
Talk-Time Distribution
TRIA(0.5, 1, 5)
After-Contact Time
Distribution
EXPO(1)
Example 6Multi-site model

The business objective is to model the worldwide operations of an organization providing
24 x 7 support. Of particular interest is overflow between contact center locations and the
impact staffing decisions one location may have on others.
The three contact centers in the model are located in the U.S., Europe, and Japan. Each
center works an 8-hour shift as the primary service provider followed by an 8-hour shift
handling overflow, according to the following schedule (all times in Eastern Standard
Time):
176
Primary Service
Overflow Service
Midnight to 8:00 AM
Europe
Japan
8:00 AM to 4:00 PM
U.S.
Europe
4:00 PM to Midnight
Japan
U.S.
9 CASE STUDIES

MULTIPLE SITES
This is a high-level model of operations, with each center represented by a single agent
group. Multiple-schedule models are used to define the hours of operation of each contact
center.
Notice the transparency of multi-site modelingno reference is ever made to the physical
location of an agent group; therefore, whether they are in the same building or positioned
around the globe is immaterial. For the purpose of constructing a model, only the group
definitions, schedules, and routing script logic need to reflect the multi-site configuration,
and this is often indistinguishable from that applying to groups within the same building.
MULTIPLE PATTERNS
Separate contact names have been defined to represent service requests originating from
each service zone. To further reflect the worldwide nature of this example, an individual
pattern has been associated with each contact name to tie the arrivals to the local business
hours.
COMPLEX SCRIPT
The strategy in this organization is to route all contacts to the primary center regardless of
their origin. Then, if the contact is not handled within a short period of time, it is sent to
the overflow center. A single script was used to route the contact to the appropriate center
as identified by the time of day at which the contact arrives. Selecting the correct overflow
site also depends on the time of day. Since overflow is of particular management interest,
the Overflow action is used to track activity between centers. This, combined with the
determination of the appropriate centers to which contacts are routed using the Branch
module, results in a fairly complicated script.
9 Case Studies
The data detail for the Multi-site example

MODEL FILE
The Multi-site model can be found in global.doe.
The Multi-site model is based on a daily planning horizon and a center with a central
177
Table 9.32 Configuration moduleMulti-site model
Prompt
Entry
Planning Horizon
Week
Trunk Definitions
Trunk Group
Central Trunks
Trunk Capacity
100
Inbound Contacts
Checked
Global Script
SCHEDULE MODULE
Agents in each of the three international centers staff two consecutive 8-hour shifts: a
primary shift where all contacts are routed to them and a secondary shift where all
overflow is routed to them. These shifts are staggered so that there are always two centers
on dutya primary center and a secondary center to handle overflow. All times are in
Eastern Standard Time.
Table 9.33 Schedule modulesMulti-site model
Prompt
Entry
Schedule Name
U.S. On-Duty
Planning Horizon
Day
Timeslot
60
Shift Schedule
178
Agent State
On-Duty
Shift Begins at
8:00 AM
Shift Ends at
Midnight
Schedule Name
Europe On-Duty
Planning Horizon
Day
Timeslot
60
Prompt
9 CASE STUDIES
Entry
Shift Schedule
Agent State
On-Duty
Shift Begins at
Midnight
Shift Ends at
4:00 PM
Schedule Name
Japan On-Duty
Planning Horizon
Day
Timeslot
60
Shift Schedule
Agent State
On-Duty
Shift Begins at
Midnight
Shift Ends at
8:00 AM
Agent State
On-Duty
Shift Begins at
4:00 PM
Shift Ends at
Midnight
PATTERN MODULE
In the Multi-site model, contacts originate from each of the three international zones. All
contacts follow the same basic pattern, each pattern just begins at different times depending on the zone of origination.
Table 9.34 Pattern modulesMulti-site model
Prompt
Entry
Pattern
U.S. Daily Pattern
Planning Horizon
Day
Timeslot
60

8:00 AM9:00 AM
600
9:00 AM10:00 AM
150
179
9 Case Studies
Note that these patterns could be extended to run over 24 hours in each zone, since the
worldwide operations run around the clock.
Prompt
Entry
10:00 AM11:00 AM
150
11:00 AMNoon
150
Noon1:00 PM
150
1:00 PM2:00 PM
150
2:00 PM3:00 PM
150
3:00 PM4:00 PM
150
4:00 PM5:00 PM
300
5:00 PM6:00 PM
150
6:00 PM7:00 PM
150
7:00 PM8:00 PM
150
8:00 PM9:00 PM
150
9:00 PM10:00 PM
150
10:00 PM11:00 PM
150
11:00 PMMidnight
150
Pattern
Europe Daily Pattern
Planning Horizon
Day
Timeslot
60
180
Midnight1:00 AM
600
1:00 AM2:00 AM
150
2:00 AM3:00 AM
150
3:00 AM4:00 AM
150
4:00 AM5:00 AM
150
5:00 AM6:00 AM
150
6:00 AM7:00 AM
150
7:00 AM8:00 AM
150
8:00 AM9:00 AM
300
9:00 AM10:00 AM
150
Prompt
9 CASE STUDIES
Entry
10:00 AM11:00 AM
150
11:00 AMNoon
150
Noon1:00 PM
150
1:00 PM2:00 PM
150
2:00 PM3:00 PM
150
3:00 PM4:00 PM
150
Pattern
Japan Daily Pattern
Planning Horizon
Day
Timeslot
60

300
1:00 AM2:00 AM
150
2:00 AM3:00 AM
150
3:00 AM4:00 AM
150
4:00 AM5:00 AM
150
5:00 AM6:00 AM
150
6:00 AM7:00 AM
150
7:00 AM8:00 AM
150
4:00 PM5:00 PM
600
5:00 PM6:00 PM
150
6:00 PM7:00 PM
150
7:00 PM8:00 PM
150
8:00 PM9:00 PM
150
9:00 PM10:00 PM
150
10:00 PM11:00 PM
150
11:00 PMMidnight
150
9 Case Studies
Midnight1:00 AM
181
AGENT MODULE
The U.S. Center agent group is defined in Table 9.35. The other two basic groups are
defined similarly, with only the associated schedule being different. Note that each group
is skilled for all contact names in order to support the global overflow of contacts between
centers. Each group requires its own module.
Table 9.35 Agent modulesMulti-site model
Prompt
Entry
Agent Name
U.S. Center (Europe Center, Japan Center)
Agent Type
Agent
10 (10,5)
Schedule
U.S. On-Duty (Europe On-Duty, Japan On-Duty)
Talk Time
Contact Name
U.S. Call
Contact Name
Europe Call
Contact Name
Japan Call
SCRIPTS
The following script illustrates the contact control flow in the Multi-site model case study.
The basic idea is that incoming contacts will be queued to the primary center. Then, if not
served within two minutes, they are overflowed to the secondary center. Primary and
secondary centers are determined based on time of day.
This logic is implemented through extensive use of the Branch module, which enables
conditional branching. The Overflow action is also featured.
Finally, note that a Queue for Agent action is necessary to complete each Overflow action.
Refer to Figure 9.10 to see how modules are connected.
182
9 CASE STUDIES
Table 9.36 Global Script Multi-site model
Prompt
Entry
Begin Script
Script Name
Global Script
Branch
(Branch Type)
If
Condition
Time of Day>=11:58PM
(Branch Type)
If
Condition
Time of Day<=7:58AM
(Branch Type)
If
Condition
Time of Day<=3:58PM
(Branch Type)
Else
Group Type
Agent Group
Agent Group
Europe Center
Group Type
Agent Group
Agent Group
U.S. Center
Group Type
Agent Group
Agent Group
Japan Center
Wait
Wait Time
Branch
(Branch Type)
If
Condition
Time of Day<=8:00AM
(Branch Type)
If
Condition
Time of Day<=4:00PM
(Branch Type)
Else
Source Group
Europe Center
Destination Group
Japan Center
Source Group
U.S. Center
Destination Group
Europe Center
Source Group
Japan Center
Destination Group
U.S. Center
Queue for Agent
Queue for Agent
Queue for Agent
Overflow
Overflow
Overflow
9 Case Studies
Module
183
Module
Prompt
Entry
Queue for Agent
Group Type
Agent Group
Agent Group
Japan Center
Group Type
Agent Group
Agent Group
Europe Center
Group Type
Agent Group
Agent Group
U.S. Center
Queue for Agent
Queue for Agent
End Script
Figure 9.10 Global ScriptMulti-site model
CONTACT MODULE
The definitions for contact names in the Multi-site model are all basically parallel, with
the only difference being associated patterns.
Table 9.37 Contact moduleMulti-site model
184
Prompt
Entry
Contact Name
U.S. Call (Europe Call, Japan Call)
Pattern
U.S. Daily Pattern (Europe Daily Pattern, Japan Daily Pattern)
Expected Talk Time
10
Trunk Group
Central Trunks
9 CASE STUDIES
Other examples
Outbound/blend examples
Any of the preceding examples could easily be imagined to be a pure Outbound contact
center. Instead of contacts coming in and being served by available agents, available
agents are making contacts to outside customers.
A Blended contact center (processing Inbound and Outbound contacts) could be modeled
through careful use of contact priorities and patterns. Outbound contact names would be
assigned a lower priority, and therefore always would be waiting for an available agent to
dial them when no Inbound contacts are waiting.
9 Case Studies
185
186
Reserved Words
The following list contains words reserved for internal use within Arena Contact Center
Edition:
Call Type
First Script
Abandoned
Cap
Flowtime
Adherence Factor
Cap Change
Flowtime1
After Call Time
Child
Friday
Agent Availability
ChildIndex
General Expression
Agent Group
Conference
Goto
All
Conference Time
Inbound
AllAgents
Contact Type
Increase
AllParents
Copy Atb
Ind
AllStates
CR
Infinite
AM
Day
InitPr
Announcement
Day is
InitTr
AnyParents
Day Number
InOut
Astate
DayofWeek
BeenSeized
Decrease
Begin Script
Disconnect
Label_A
Blocked
Disconnected
LabelIt
Both
Downtm
Longest Available
Break S
DummySetEmail
Lunch S
Call Id
End Script
Meeting S
Call Id Var
EndRotation
Message
Call Priority
Fax
Midnight
Call Times
First Available
Monday
A Reserved Words
Abandon Wait Time
187
188
New
Queue for Agent
Terminated
Next Action
Queue Length
Thursday
No Condition
queuetime
Time in Call Center
Noon
Probabilistic Branch
Time of Day
None
Remove from Queue
Time Remaining to Wait
NxtBlk
RepDays
Time Spent Waiting
Off Duty S
Research S
TimeofDay
On Duty S
Saturday
Total Calls
Other
sbr
Transfer
Overflow
sbr type
Transfer to Script
Parent
Script
Trunk Group
ParentIndex
Search Q
Tuesday
Parent Group
Set Type
Pattern
Service Level
uptm
PM
StartRotation
Wait_A
PQPr
Station Type
Web Hit
Pr
Sunday
Wednesday
Pre Work
Talk Time
WeekNumber
Priority
Temp
Yes
Qblock
Temp Atb
Reports
B Reports
Agent and Trunks
9:40:25AM
Tuesday, December 04, 2001
Bank
Replications: 1
Replication 1
Planning Horizon: Week
Trunk Summary
Usage
Central Trunks
Available
14.36
In Use
0.64
Cost
Utilization
4.28
Busy Cost
971.69
Central Trunks
Agent Group Summary

Usage
Balance Servers
Checking Servers
Checking
Specialists
Savings Servers
Savings Specialists
Cost
Checking
Specialists
Savings Specialists
Available
4.64
4.64
2.66
Busy
2.37
2.37
1.34
Est On Duty
7.00
7.00
4.00
Utilization
33.90
33.90
33.60
4.64
1.97
2.37
1.03
7.00
3.00
33.90
34.31
Busy Cost
453.64
Idle Cost
899.15
Per Use Cost

0.00
555.75
1,064.78
0.00
Inbound and Outbound Utilization
Inbound Util
0.00
33.90
33.60
0.00
34.31
Balance Servers
Checking Servers
Savings Servers
Savings Specialists
Agent Utilization per Contact Type

Balance Servers
Checking Servers
Checking
Specialists
Savings Servers
Savings Specialists
Outbound Util
0.00
0.00
0.00
0.00
0.00
Call
0.00
33.90
33.60
Email
0.00
0.00
0.00
Fax
0.00
0.00
0.00
Other
0.00
0.00
0.00
Web Hit
0.00
0.00
0.00
0.00
34.31
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
189
9:40:25AM
Agent and Trunks
Agent Utilization per Contact Name

Checking Specialists Account Balance
Checking Specialists Checking
Checking Specialists Savings
Savings Specialists Account Balance
Savings Specialists Checking
Savings Specialists Savings
190
Util per Type

2.54
30.74
0.32
27.13
2.68
4.50
Bank
Replications: 1
Replication 1
Planning Horizon: Week
Contact Times (in minutes)

Handle Time
Average
Half Width
Minimum
Maximum
Observations
Account Balance
0.9976
0.044472520
0.0007
8.6036
2,478
Checking
3.7583
0.257047910
0.0007
23.2454
941
Savings
3.9151
(Insufficient)
0.0440
14.0986
102
Average
Half Width
Minimum
Maximum
Observations
Speed of Answer
Account Balance
0.02202659
(Correlated) 0.00000000 2.48080051
2,478
Checking
0.01388095
0.015766858 0.00000000 1.54797763
941
Savings
0.02383484
(Insufficient) 0.00000000 1.38975639
Time in Contact Center
Average
Half Width
Minimum
Account Balance
1.0196
0.050476101
Checking
3.7721
0.263991449
Savings
3.9390
(Insufficient)
102
Maximum
Observations
0.0007
8.6036
2,478
0.0007
23.2454
941
0.0440
14.6101
102
Contact Counts
Contacts
Account Balance
Checking
Savings
Blocked
0.00
0.00
0.00
Created
2,478.00
941.00
102.00
In System
0.00
0.00
0.00
Offered
2,478.00
941.00
102.00
Waiting
0.00
0.00
0.00
Abandoned Disconnected
0.00
0.00
0.00
0.00
0.00
0.00
Handled
2,478.00
941.00
102.00
In Target
2,435.00
940.00
101.00
Message
0.00
0.00
0.00
Blocked Disconnected
0.00
0.00
0.00
0.00
0.00
0.00
Message
0.00
0.00
0.00
Served
0.00
0.00
0.00
Outcomes
Account Balance
Checking
Savings
Contact Backs
Account Balance
Checking
Savings
Abandoned
0.00
0.00
0.00
191
B Reports
10:13:11AM
B REPORTS
10:13:11AM
Other Contact Data

Service Level
Account Balance
Checking
Savings
Percent
98.26
99.89
99.02
Target
30.00
90.00
60.00
Abandoned Percent
Account Balance
Checking
Savings
Percent
0.00
0.00
0.00
Blocking Percent
Account Balance
Checking
Savings
Percent
0.00
0.00
0.00
Contact Return Counts

Account Balance
Checking
Savings
192
Abandoned
0.00
0.00
0.00
Outstanding
0.00
0.00
0.00
Returned
0.00
0.00
0.00
Index
C
abandonment 29, 47, 138

accessing external logic 101, 102
After Talk Time logic 38
after-contact work 32
agent costs 38
Agent Group Utilization report 131
agent groups 23, 51
Agent module 30, 51, 72
agent selection 34, 35, 145
agent skill priorities 36, 76, 154
agent skill sets 23, 72
agent states 39
Agent Summary 124
Cost 125
Inbound Utilization 125
Outbound Utilization 125
Usage 124
Agents and Trunks report 124
Animate module 54, 86
animation 24
counters 24
enabling/disabling 43
graphs 24
plots 24
Arena Contact Center Edition 1
Arena examples 4
Arena Symbol Factory 5
arrival patterns 21
Assignment module 38, 118
attributes of contact 118
case studies 137

Bank model 144
Bilingual Contact Center model 137
Multi-site model 176
Premium Service model 159
Skill-based Routing model 153
Teamwork model 167
collecting statistics 55
conditional dialog input 59
Conference module 31, 38, 112
conferencing 31, 167
Configuration module 28, 29, 45, 60
consulting services 6
contact arrival 28
contact back 28, 33, 138
contact behavior 21
abandonment 21
After-Contact Work 21
Contact Back 21
Prioritization 21
contact centers
blended 185
outbound 185
Contact Count Statistics report 128
Contact Counts
Contact Backs 126
Counts 126
Outcomes 126
Contact Data panel 59
Agent module 72
Animate module 86
Configuration module 60
Contact module 78
Pattern module 68
Report module 94
Schedule module 64
contact information 6
contact life span stages 27
abandonment 29
after-contact work 32
B
Bank model 144
Begin Script module 36, 52, 99
Bilingual Contact Center model 137
blended contact center 185
blocked contacts 28
Branch module 38, 114
Buzacott, J. A. 18
Index
193
arrival 28
blocked 28
conference 31
contact back 33
disconnected 29
handled 30
leave a message 30
offered 29
talk time 31
transfer 32
Contact module 28, 29, 30, 31, 33, 46, 78
contact termination 108
Contact Time Statistics report 129
Contact Times and Counts report 125
Contact Counts 126
Contact Times 125
Other Contact Data 127
contact types 21
contact-routing logic 36
contacts leaving messages 30
costing of contact center operations 38
agents 38
trunk group 39
counters 118
Crystal Reports 123
customer service center 144
Customer Support Center
Rockwell Automation 6
D
data input 15
decision-making in a script 114
direct queueing 34
Disconnect module 37, 108
disconnected contacts 29
documentation of your model 18
duplicate (Ctrl+D) 48
E
End Script module 38, 54, 119
experimental model design 14
G
global contact priorities
global variables 118
194
159
H
handle time 144
handled contacts 30, 129
I
identifier 100
implementing your model design
individual agents 39
18
L
lists of object names 43
logic
accessing external blocks
101
M
McKay, K. N 18
Message module 37, 54, 106
models 7
building a sample contact center structure
43
defining the objectives 13
documenting and implementing 18
experimental design 14
input data 15
level of detail 14
pitfalls in the plan design 13
verification and validation 16
modules
Agent 30, 71
Animate 86
Assignment 38, 118
Begin Script 36, 100
Branch 38, 114
Conference 31, 38, 113
Configuration 28, 29, 60
Contact 28, 29, 30, 31, 33, 78
copy and paste 43
Disconnect 37, 108
End Script 38, 120
Message 37, 106
Overflow 37, 109
Pattern 28, 68
Priority 37, 105
Queue for Agent 30, 31, 34, 36, 101
Remove from Queue 37, 103

Report 94
Schedule 63
Transfer to Agent 30, 32, 38, 111
Transfer to Script 37, 110
Wait 37, 104
multiple agents 35
multiple-agent schedules 159
multiple-trunk groups 159
Multi-site model 176
35
O
offered contact 29
online help 4
Other Contact Data
Contact Return Counts 127
Service Level 127
outbound contact centers 185
output statistics 123
Overflow Count Statistics report 135
Overflow module 37, 109
P
Parent Group Utilization report 132
parent groups 24
pattern entry 39
Pattern module 21, 28, 47, 68
patterns 70
for multiple agents 159
Pegden, C. D. 7
planning horizon 20, 64, 68, 123
preferences 35, 36, 145
Premium Service model 159
primary agent 30
priorities
global 159
Priority module 37
project definition 11
project planning 12
Q
queue behavior 33
queue construction 34
Queue for Agent module
101
queue ranking 34
queueing 24, 102, 145
direct 34
rank based on priority
simultaneous 34
30, 31, 34, 36, 53,
34
R
Remove from Queue module 37, 54, 103
repeat group 45, 59
duplication 43
replication 39
Report module 55, 94, 123
reports 189
Agent Group Utilization 131
Agents and Trunks 124
as performance measures 24
Contact Count Statistics 128
Contact Time Statistics 129
Contact Times and Counts 125
Overflow Count Statistics 135
Parent Group Utilization 132
Trunk Group Utilization 134
reserved words 42, 187
resource proficiency level 149
resource proficiency levels 146
resource sharing 145
Rockwell Automation Customer Support 6
routing scripts 22, 145
construction 36
S
Sadowski, R. P. 7
Schedule module 49, 64
schedules 23
schedules for multiple agents
Schriber, T. J. 18
script examples 120
Script panel 30, 34, 52, 99
Assignment 118
159
195
Index
no agents available
INDEX
Begin Script 100

Branch 114
Conference 113
Disconnect 108
End Script 120
Message 106
Overflow 109
Priority 105
Queue for Agent 101
Remove from Queue 103
Transfer to Agent 111
Transfer to Script 110
Wait 104
script restrictions 120
sensitivity analysis 16
served contacts 33
Shannon, R. E. 7
Sheppard, S. 18
shifts 66
simulation
advantages of 9
definition of 7
the process 10
simulation process overview 19
simultaneous queueing 34, 36
skill-based routing 34, 36, 76
agent skill priorities 36
preferences 36
simultaneous queueing 36
Skill-based Routing model 153
SMARTs library 5
statistics collection 96
Strang, C. J. 18
systems 8
196
T
talk time 31, 52
talk time multipliers 146, 149
Teamwork model 167
technical support 5
timeslots 20, 47, 64, 68, 123
training courses 6
transfer agent 32
Transfer to Agent module 30, 32, 38, 111
Transfer to Script module 37, 110
Trunk Group Utilization report 134
trunk groups 22
costs 39
Trunk Summary 124
Cost 124
Usage 124
U
utilization 125
of Agent Group resources
of Parent Group resources
of Trunk Group resources
V
validation 16
verification 16
W
Wait module 37, 53, 104
Web support 6
Weinburg, G. M. 18
worldwide operations 176
131, 144
132
134

Arena Contact Center Edition User's Guide PDF

Caricato da

Informazioni sul documento

Descrizione originale:

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

Arena Contact Center Edition User's Guide PDF

Caricato da

Copyright:

Formati disponibili

ARENCC-UM001B-EN-P_Titlepg.

CCE.book Page ii Wednesday, August 4, 2004 4:28 PM

Technical Support Telephone1-440-646-5800

CCETOC.fm Page iii Wednesday, August 4, 2004 4:36 PM

What is Arena Contact Center Edition? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CCETOC.fm Page iv Wednesday, August 4, 2004 4:36 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

CCETOC.fm Page v Wednesday, August 4, 2004 4:36 PM

6 The Contact Data Panel

CCETOC.fm Page vi Wednesday, August 4, 2004 4:36 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

7 The Script Panel

Begin Script module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

CCETOC.fm Page vii Wednesday, August 4, 2004 4:36 PM

CCETOC.fm Page viii Wednesday, August 4, 2004 4:36 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

CCE.book Page 1 Wednesday, August 4, 2004 4:28 PM

Welcome to Arena Contact Center Edition

What is Arena Contact Center Edition?

Simulation of contact centers

CCE.book Page 2 Wednesday, August 4, 2004 4:28 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

CCE.book Page 3 Wednesday, August 4, 2004 4:28 PM

1 WELCOME TO ARENA CONTACT CENTER EDITION

Arena Contact Center Edition: A custom-designed simulation

CCE.book Page 4 Wednesday, August 4, 2004 4:28 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

Arena Contact Center Edition is a Microsoft Windows operating system-based

Where can I go for help?

Reference the users guides

Explore our examples

CCE.book Page 5 Wednesday, August 4, 2004 4:28 PM

1 WELCOME TO ARENA CONTACT CENTER EDITION

Use the SMARTs library

Access the Arena Symbol Factory

Get phone support

the product serial number

CCE.book Page 6 Wednesday, August 4, 2004 4:28 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

Get Web support

Get consulting services

CCE.book Page 7 Wednesday, August 4, 2004 4:28 PM

To simulate, according to Websters Collegiate Dictionary, is to feign, to obtain the

describe the behavior of systems,

Systems and models

CCE.book Page 8 Wednesday, August 4, 2004 4:28 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

CCE.book Page 9 Wednesday, August 4, 2004 4:28 PM

CCE.book Page 10 Wednesday, August 4, 2004 4:28 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

The simulation process

CCE.book Page 11 Wednesday, August 4, 2004 4:28 PM

Problem definition and project planning

CCE.book Page 12 Wednesday, August 4, 2004 4:28 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

Evaluation: determining how well a proposed system design performs in an absolute

CCE.book Page 13 Wednesday, August 4, 2004 4:28 PM

Optimization: determining exactly which combination of factor levels produces the

Style definition and model formulation

CCE.book Page 14 Wednesday, August 4, 2004 4:28 PM

ARENA CONTACT CENTER EDITION USERS GUIDE

CCE.book Page 15 Wednesday, August 4, 2004 4:28 PM