Contact Center Template User's Guide PDF

®
Arena Contact Center
USER’S GUIDE
PUBLICATION ARENCC-UM001H-EN-P–January 2012
Supersedes Publication ARENCC-UM001G-EN-P
PN-111657
Contact Rockwell Automation Customer Support Telephone — 1-440-646-3434
Online Support— http://www.rockwellautomation.com/support
Copyright Notice © 2012 Rockwell Automation, Inc. All rights reserved. Printed in USA.
This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation, Inc. Any
reproduction and/or distribution without prior written consent from Rockwell Automation, Inc. is strictly prohibited.
Please see the license agreement for details.
Trademark Notices Arena, Rockwell Automation, and SIMAN are registered trademarks of Rockwell Automation, Inc.
Other Trademarks ActiveX, Microsoft, Microsoft Access, SQL Server, Visual Basic, Visual C++, Visual SourceSafe, Windows, Windows
ME, Windows NT, Windows 2000, Windows Server 2003, and Windows XP are either registered trademarks or
trademarks of Microsoft Corporation in the United States and/or other countries.
Adobe, Acrobat, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the
United States and/or other countries.
ControlNet is a registered trademark of ControlNet International.
DeviceNet is a trademark of the Open DeviceNet Vendor Association, Inc. (ODVA)
Ethernet is a registered trademark of Digital Equipment Corporation, Intel, and Xerox Corporation
OLE for Process Control (OPC) is a registered trademark of the OPC Foundation.
Oracle, SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation.
All other trademarks are the property of their respective holders and are hereby acknowledged.
Warranty This product is warranted in accordance with the product license. The product’s performance may be affected by system
configuration, the application being performed, operator control, maintenance, and other related factors. Rockwell
Automation is not responsible for these intervening factors. The instructions in this document do not cover all the
details or variations in the equipment, procedure, or process described, nor do they provide directions for meeting every
possible contingency during installation, operation, or maintenance. This product’s implementation may vary among
users.
This document is current as of the time of release of the product; however, the accompanying software may have
changed since the release. Rockwell Automation, Inc. reserves the right to change any information contained in this
document or the software at anytime without prior notice. It is your responsibility to obtain the most current information
available from Rockwell when installing or using this product.
Version: 14.00.00
Modified: January 18, 2012 11:02:10 AM
i
ii
Contents
1 • Welcome to Arena Contact Center Template 1

What is the Arena Contact Center template? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Simulation of contact centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
The Arena Contact Center template: A custom-designed simulation system
for contact centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Refer to the user’s guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Use the Smarts library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Get Web support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Refer to the Arena Web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Get consulting services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2 • Introduction to Simulation 9
Simulation defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Systems and models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Advantages of simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
The simulation process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Problem definition and project planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Style definition and model formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Experimental design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Input data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Verification and validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Documentation and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 • General Concepts 23
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Planning horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Contact types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
iii
ARENA CONTACT CENTER TEMPLATE USER’S GUIDE
Arrival pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Trunk Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Routing Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Agent Skill Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Agent Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Parent Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Animation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Performance measures/reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 • Features 31
Different stages in the contact life span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Contact arrival (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Blocked contacts (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Offered contacts (required). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Abandoned contacts (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Disconnected contacts (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Contacts leaving messages (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Handled contacts (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Talk time (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Conference (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Transfer (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
After-contact work (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Contact back (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Queue behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Queue construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Queue ranking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Agent selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Skill-based routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Routing script construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Begin Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Queue for Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Remove from Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
iv
CONTENTS
Wait. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Transfer to Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Transfer to Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Conference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Branch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
End Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Agent costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Trunk costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Miscellaneous features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Pattern entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Agent states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Individual agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Advanced configuration agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5 • Getting Started 47
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Loading and running an existing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
General modeling skills and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Panels and modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Module copy and paste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Repeat group duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Disable animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Building an Arena Contact Center template model . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Defining the business application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Model construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Running the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 • The Contact Data Panel 65

Configuration module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Schedule module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Pattern module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
v
Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Contact module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Animate module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Report module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7 • The Script Panel 107

Begin Script module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Queue for Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Remove from Queue module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Wait module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Priority module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Message module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Disconnect module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Overflow module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Transfer to Script module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Transfer to Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Conference module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Branch module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Assignment module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
End Script module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Script restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Arena Contact Center template script examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
8 • Reports 133
Agents and Trunks report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Trunk Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Agent Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Contact Times and Counts report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Contact Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Contact Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Other Contact Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Contact Count Statistics report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Contact Time Statistics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Agent Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Parent Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Trunk Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Overflow Count Statistics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
vi
CONTENTS
9 • Case Studies 147

Purposes of cases and examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Example 1—Bilingual Contact Center model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 147
The data detail for the Bilingual Contact Center example . . . . . . . . . . . . . . . . . 149
Example 2—Bank model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
The data detail for the Bank example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Example 3—Skill-based Routing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
The data detail for the Skill-based Routing example . . . . . . . . . . . . . . . . . . . . . 165
Example 4—Premium Service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
The data detail for the Premium Service example . . . . . . . . . . . . . . . . . . . . . . . 172
Example 5—Teamwork model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
The data detail for the Teamwork example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Example 6—Multi-site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
The data detail for the Multi-site example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Other examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Outbound/blend examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
A • Reserved Words 199
B • Reports 201
Index 205
vii
1 Welcome to Arena Contact Center
Template
What is the Arena Contact Center template?
The Arena® Contact Center template is a simulation system developed by Rockwell
Automation, Inc., for the performance analysis of contact centers. It is built on
Rockwell Automation’s Arena simulation system and has been customized to allow
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
The Arena Contact Center template is designed for contact center managers and
analysts and for industrial or systems engineers. It is typically deployed as an
enterprise business analysis and productivity tool.
You are interested in improving business productivity and are responsible for
evaluating and predicting the impact of proposed strategic and tactical changes. A
familiarity with the basic concepts and terms used in these types of system is assumed
as is a familiarity with computers and the Microsoft® Windows® operating system. A
familiarity with the concepts and terms used in simulation is also helpful.
Simulation of contact centers

The planning problems of contact center managers and analysts are far easier to
describe than to model or to solve:
 “I’ve got my staffing budget for the next fiscal year, but I don’t 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 don’t know is how badly our service levels and abandonment rates will
suffer if our forecasts turn out to be too low.”
1
 “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 I’m worried about is
how this new program will affect the waiting times that the rest of our customers
experience.”
 “We’ve been asked to provide telephone service and support for another business
unit. They’re asking us how much staff we need to hire or cross-train in order to
handle this increased load.”
Contact center managers have traditionally approached such problems using various
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 can effectively and accurately model a contact center (or a network of
contact centers). Such a model 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 for a period of time representing a day,
a week, or a month.
In particular, simulation explicitly models the interaction between contacts (for
example, calls or e-mail), routes, and agents, as well as the randomness of individual
contact arrivals and handle times.
By using simulation, managers and analysts can translate contact center data (such as
forecasts, contact-routing vectors, contact-handle time distributions, agent schedules,
or agent skills) 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.
2
1 • WELCOME TO ARENA CONTACT CENTER TEMPLATE
The Arena Contact Center template: A

custom-designed simulation system for
contact centers
The successful use of simulation in many contact center environments led to the
development of the Arena Contact Center template. It was developed by Rockwell
Automation in partnership with Onward, a management consulting firm based in
Mountain View, California, who specialize in contact center operations.
In conjunction with a team of contact center managers and analysts from many
different business environments, Rockwell Automation and Onward designed the
Arena Contact Center template to:
 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.
 Support a process of managing input data for these contact center simulation
models that is as easy and sensible as possible.
 Have the capacity to deliver real-time statistics, animation, and output statistics
that provide insight into key contact center performance measures.
3
 Use standard contact center terminology wherever possible to make the model
building and usage process as intuitive as possible for contact center
professionals.
The Arena Contact Center template 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 Arena’s 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 you’re new to simulation or a seasoned veteran using
a new tool, you’ll quickly feel at home with the Arena Contact Center template.
Refer to the user’s guides

The documentation set includes this manual, Arena Contact Center Template User’s
Guide, which cover the product basics; the Arena User’s Guide, which covers the
general 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 text;
file menu paths are in bold with a (>) separating the entries (for example, go to Help
> Arena Help); text you are asked to type is shown in Courier Bold (for example, in
this field, type Work Week), and dialog box and window button names are shown in
bold (for example, click OK).
Explore our examples

Arena provides a number of sample models that illustrate many of the commonly
used approaches for capturing the essence of a variety of processes for both job shop
and flow shop environments. For a list of Arena’s examples, go to Help > Arena
Help. On the Contents tab, choose Model Building Basics, and then select Viewing
Arena Example Models.
4
Get help
Online help is always at your fingertips! Arena incorporates the latest in help
features, including What’s This? help that displays a brief description of fields in
dialog boxes, context-sensitive help on menu and toolbar buttons, and a help button
on each of Arena’s modules. See the Arena Help table of contents and index for a list
of all help topics.
Use the Smarts library

As you craft models of your own system’s 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 you’re 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 phone support

Rockwell Automation provides full support for the entire Arena family of products.
Questions concerning installation, how to use the software, how modules work, and
the use of the model editor 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 software’s requirements
 troubleshooting
 limited support regarding the interaction of Arena with other programs
 support for the Arena Object Model, which is used in Microsoft Visual Basic for
Applications.
If you call the support line (1.440.646.3434, option 3 & 7), 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.
5
International technical support is provided by the global representatives. For contact

information on the representative nearest you, visit the Global Partners page on
www.ArenaSimulation.com.
Get Web support

In addition to phone support, the Rockwell Automation Customer Support Center
offers extensive online knowledgebases of technical notes and frequently asked
questions for support of non-urgent issues. These databases are updated daily by our
support specialists. Go to http://www.rockwellautomation.com/support/ to sign up for
online support.
Once you have signed up for online support you can elect to receive regular e-mail
messages with links to the latest technical notes, software updates, and firmware
updates for the products that interest you. You can also submit online support
requests.
If you can’t find the answer you need, contact your local representative or Arena
technical support.
Refer to the Arena Web site

The Arena Web site provides a collection of brief “how-to” videos and FAQ topics
that may be of assistance to you. This material and more is available through the
Tools and Resources tab of www.ArenaSimulation.com.
Get training
Do you need training? Rockwell Automation offers a standard training course
consisting of lectures 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 that’s 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.
6
Contact us
We strive to help all of our customers become successful in their manufacturing
improvement efforts. To help us achieve this objective, we invite you to contact your
local representative or Rockwell Automation at any time that we may be of service to
you. Be sure to connect with us on Facebook and join the Arena User’s Group on
LinkedIn.
Support E-mail: Arena-Support@ra.rockwell.com

Support Phone: 1.440.646.3434 (options 3 & 7)
General E-mail: Arena-Info@ra.rockwell.com
U. S. Sales Phone: 1.724.741.4000
URL: www.ArenaSimulation.com
URL: www.rockwellautomation.com
7
2 Introduction to Simulation
This chapter contains excerpts from the simulation textbook entitled Introduction to
Simulation Using SIMAN, Second Edition (McGraw-Hill, 1995) written by C. Dennis
Pegden, Randall P. Sadowski, and Robert E. Shannon.
Simulation defined
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.
To simulate, according to Webster’s 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,or evaluating
various strategies for the operation of the system, or both. 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:
 describe the behavior of systems,
 construct theories or hypotheses that account for the observed behavior, and
 use the model to predict future behavior; that is, 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; that is, those
in the preliminary or planning stage of development.
9
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
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 directly—either 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 useful—and
certainly the most often used—is simulation.
The concept of systems also 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 contempo-
rary practice that we tend to take it for granted. The systems approach tries to con-
sider total system performance rather than simply concentrating on the parts
[Weinberg, 1975]; it is based on our recognition that, even if each element or subsys-
tem 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 (that is, they exist),
they are also subjective (that is, 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
10
2 • INTRODUCTION TO SIMULATION
conceptualizations of any particular real-world system—and thereby several different

models—can exist simultaneously.
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 chosen to achieve a specific purpose. The model
developed should be as simple as the stated purpose will allow.
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 compare—that 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.
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
11
that isn’t 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, and so on, allowing us to
speed up or slow down a phenomenon for study.
 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. Simulation’s 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; that is, 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.
12
4. Conceptual Model Formulation. Developing a preliminary model either

graphically (for example, 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;
that is, 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 the Arena Contact Center template.
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.
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.
12. Implementation and Documentation. Putting the results to use, recording the
findings, and documenting the model and its use.
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 suc-
cess 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 can’t 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.
13
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 organization’s 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.
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 study—that is, 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?
14
 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 project’s progress?
 Adequate communication channels. Are we continually concerned that
sufficient information is available on project objectives, status, changes, user or
client needs, and so on, 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:
 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 system’s response.
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 model’s 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
15
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.
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 compo-
nents. 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 compo-
nent’s 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. On the other hand, we try to make the model as accurate as possible.
Consequently, we must simplify reality—but only to the point where there is no
significant loss of accuracy of outputs with respect to the study’s 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
16
aspects and relationships with trivial details. The definition of the model boundary is
usually a trade-off 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 Pareto’s 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; that is, 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 study’s 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.
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
17
experimental design to account for remaining resources and for information gained in
the process of designing, building, verifying, and validating the model.
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
investigator’s learning process.
Input data
Stochastic (random) 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.
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
18
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; that is, 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
19
easier if the analyst comments the model liberally. This includes comments wherever
Arena Contact Center allows 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 user’s confidence that
any simulation-derived inference about the system is correct. Validation is concerned
with three basic questions:
 Does the model adequately represent the real-world system?
 Are the model-generated behavioral data characteristic of the real system’s
behavioral data?
 Does the simulation model user have confidence in the model’s 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 model’s 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
20
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.
Documentation and implementation

At this point, we have completed all the steps for the design, development, and run-
ning of the model and for analyzing the results; the final elements in the simulation
effort are implementation and documentation. No simulation project can be consid-
ered 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
model’s 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 used—even 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 (that is, 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.
21
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.
22
3 General Concepts
This chapter provides a high-level overview of the components of a model built using
the Arena Contact Center template. In particular, this chapter explains the
terminology used within the software and the type of information that is needed to
represent the Contact Center Core Process, that is, the way in which contacts arrive
and are processed in a contact center system. The major modeling elements are also
described in some detail.
Once you have read this chapter, we hope you will have a better understanding of the
process of creating a model with the Arena Contact Center template.
Overview
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, and so on).
As you build your contact center models, it may be helpful to keep in mind the
Contact Center Core Process, as illustrated below.
The basic components of this process are:

 Contacts
 Arrival Patterns
 Trunk Groups
 Routing Scripts
 Schedules
 Agents
23
The relationships between these components are illustrated below.
In addition, the length of the simulation runnd granularity of data specification and
collection (see “Planning horizon” and “Timeslot”s) 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.
24
3 • GENERAL CONCEPTS
With the Contact Center template, 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.
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
the Contact Center template:
 Abandonment
 After-Contact Work
 Prioritization
 Contact Back
Data sources
Information about contact volumes is typically taken from forecasts. Expected talk
time is available either from contact center ACD databases or from a contact center’s
contact-tracking system.
Arrival pattern
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. If the arrival pattern specifies that 240 contacts are handled during the
10:00 AM-11:00 AM timeslot, the simulation model would assume 240 expected
25
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 center’s tracking system.
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
each contact name can only be served by one trunk group.. 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.
Trunk-line capacity determines the maximum number of contacts that the contact
center can accommodate at any one time. 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 it exits the center or until it transfers 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
center’s system. They 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 nothing—waiting)
2. Conditional route branching (caller-entered information, center dynamics)
3. Allocation of contacts into queues (single or simultaneous) or message ports
26
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 action sequences are generally referred to as “scripts,” although each switch
vendor has a different name for their particular variety (that is, Vector, Telescript, Call
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 agent’s repertoire of handling skills specifies what contacts the
agent is sufficiently skilled to handle, the priority (or order) in which the agent will
perform available work, and the agent’s proficiency in each contact name, expressed
as a multiplier of average talk time for the contact name.
Data sources
Estimates of handling proficiency may be obtained by a careful study of handle time
statistics collected from the ACD database or tracking system, or may be 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.
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
spent away from the phones.
27
Data sources
Agent schedules can usually be obtained from a human resources department 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?
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, and so on)
 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 being made is of current contact
center operations, insight into parent groupings may be obtained from examination of
existing routing scripts.
28
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 (that is, one agent group) to
another before being serviced, based upon the routing script that is assigned to that
contact name.
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 (such as Queue for Agent module or Transfer to Agent
module).
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 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.
29
4 Features
This chapter is intended to provide a description of all Arena Contact Center template
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.
Figure 4.1 The path of a contact before processing begins
31
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, as 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 bya 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.
32
4 • FEATURES

 Contact back is defined in the Contact Back section of the Contact module. It is
described in greater detail later in this chapter.
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 the Contact
Arrival and Transfer to Script stages of the contact life span that are described in
this section.
described in greater detail later in this chapter.
33
Disconnected contacts (optional)

Contacts may be disconnected (that is, dispatched from the contact center) by their
controlling routing script.
Once a contact has been disconnected, it may contact back, depending on the model.
 Contacts may only be disconnected via the Disconnect module located on the
Script panel.
described further in the “Contact back” section below.
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.
described further in the “Contact back” section below.
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.
34
4 • FEATURES

 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.
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 box, 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 agent’s talk time is complete.
35
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.
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.
 Contacts requiring conference are specified by the contact’s 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 contact’s 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 agent’s 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) agent’s 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 (that is, the contact will
not be re-queued).
36
4 • FEATURES

 Contacts potentially requiring transfer are specified by the contact’s 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 transfer to 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, and so on) after they are finished with the contactor, an
After Contact 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 specified in the
After Talk Time logic of the Queue for Agent module (for example, 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.
37
Served contacts are those that leave the contact center immediately following service
from an agent.
 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:
 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 in this section.
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 the associated group can be an Agent Group or a Parent Group.
Direct queueing places 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 allows 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. This implies that there can be situations in which multiple
contacts waiting in multiple queues are simultaneously requesting service from that
38
4 • FEATURES
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 (for example, Purchase
customers get priority over Refund customers) or on the agent group (for example,
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.
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 contact’s 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 simple—the 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 intoone of the following two categories:
 Multiple-member agent groups have available agents
 No agents are available
39
MULTIPLE AGENTS AVAILABLE

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 its 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).
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. 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 contact with the highest priority will be assigned.
While that is straightforward, there is one additional concept that applies in this
situation. The current contact priorities for all candidate contacts may be overridden
one final time by the agent skill priorities associated with the available agent (see the
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 agent’s skills,
allowing the agent to serve the contact he is most capable of handling. 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 (through 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.
40
4 • FEATURES
The Arena Contact Center template 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 the Arena Contact Center template for
representing the contact-routing logic employed by your system.
For the purpose of creating a realistic simulation model, the basic 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 identifies a script by defining the script’s name.
Queue for Agent

A Queue for Agent module 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
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 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.
41
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
ADisconnect module encountered in a routing script causes the contact to be
dispatched from the contact center immediately.
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 shifts routing-control flow to the actions defined in the
specified script.
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 probabilistic branching logic.
If the associated condition is true, routing-control flow is transferred to the module
connected to the corresponding 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.
42
4 • FEATURES
Assignment
The Assignment module allows the assignment of a contact’s picture or attribute, a
global variable, or counter.
End Script
The End Script module identifies the end of a script.
Costing
The Arena Contact Center template 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 as in 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)
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)
43
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 are used only for documentation
purposes and to aid in model validation.
Individual agents
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 contact-handling skills and follow his own schedule. These
individuals are grouped together as members of a parent group.
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 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
44
4 • FEATURES
when and how to initialize the system and initialize the statistics between each
replication, see Arena’s 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.
45
5 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, and 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 File > Open in Arena. A selection box will appear in
the center of the screen. Click (or Browse for) the file name Telethon.doe and select
Open. The telethon model will be loaded and open in the model window.
Figure 5.1 The Telethon model
To run the model, click Run > Go, and a week of telethon activity will be simulated.
When the simulation is complete, a dialog box will appear asking whether you would
like to see the results. Click Yes to view the Agents and Trunks report. You can 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
47
reports, use the Close button to close each report. At this point, to leave Run mode
and return to the model, click Run > End.
For more detail on your options during the simulation run, please consult Arena’s
online help.
Finally, select File > Close to complete the demonstration. The rest 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 the Contact Center template: Contact
Data and Script. The Contact Data panel contains modules 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 used to create a contact’s routing script. A script is
a sequence of actions that controls the flow of a contact through the center’s 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
48
5 • GETTING STARTED
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 two different objects to have the same name (that is, 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 can be selected from a
drop-down list in the appropriate dialog boxes. 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 can 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
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.
49
Building an Arena Contact Center template

model
This section describes in detail a development session for a simple contact center
model. After completing this section, you should be familiar with the basic structure
of a contact center model and should possess the navigational skills necessary to
work comfortably in the Arena environment.
This example is also used to illustrate the module descriptions in Chapters 6 and 7.
Additionally, Chapter 9 contains several complete case studies, which can 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 simulates 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
company’s 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 to 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 or contract telereps, or both, would be
justified.
Model overview
This 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, and so on)
 Reporting
50
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 box and click OK. If you are not familiar with
resizing model windows or placing and editing modules, please see the Arena online
Help.
Select File > Template Panel > Attach. From the resulting dialog box, browse for
and select the file called ContactData.tpo and click the Open button. A panel
containing the Contact Data modules appears. Repeat the same steps again, this time
selecting the file called Script.tpo. This will attach the Script panel.
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 used.
To place a Configuration module in the model, click the Configuration module on the
Contact Data panel, drag and then drop the module in the desired position within the
model window. Double-click the resulting module to open the module dialog box.
When the module opens, you will notice a drop-down list for defining the planning
horizon. Fill out this dialog box to match the inputs in Figure 5.2. Below these items
you will see the trunk definition’s scroll list with Add, Edit, and Delete buttons to the
right. This is known as a repeat group and allows you to enter multiple items (in this
case, trunk group definitions). To add an item to the repeat group, click the Add
button and fill out the resulting dialog box, as in Figure 5.3. The Delete button is used
to remove items from repeat groups. An item is edited by highlighting the item in the
scroll list and clicking the Edit button. Many Contact Data and Script panel modules
contain one or more repeat groups, which are completed the same way.
51
Figure 5.2 Configuration module main dialog box
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 module—trunk 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 OK to accept the module into the simulation model. The planning
horizon is now documented in the model window.
52
DEFINING THE CONTACTS—THE 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 allows 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 box. 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. There
are buttons at the bottom of the dialog box that open additional dialog boxes for
modeling Contact Back, Abandonment, and other Advanced features.
Complete this dialog box as illustrated in Figure 5.4. 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 Configuration module. This is a general ease-of-use Arena feature,
where named objects defined in one module can be selected from lists in others.
Figure 5.4 Contact module main dialog box
To include donor abandonment in the model, click the Abandonment button and
type EXPO(2) in the dialog box to define an exponential abandonment model where
the average contact abandons after two minutes. Click OK to close the dialog box.
53
DEFINING THE CONTACT ARRIVAL PATTERN—THE 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.
Place a Pattern module in the model window and double-click to open its main dialog
box. Note the correspondence between this dialog box and the main dialog box of the
configuration module. The Daily Arrival Pattern repeat group disappears in the case
of day-long planning horizons. Complete the main dialog box as illustrated in Figure
5.5.
Figure 5.5 Pattern module main dialog box
Following this, a pattern must be defined for each day of the week. To do this, click
the Add button in the main dialog box. 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).
54
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 module—Daily Arrival Pattern
DEFINING THE TELETHON HOURS—THE 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.
55
Once the Schedule module is placed and opened, you will notice its similarity to the
Pattern module. Complete the dialog box, as shown in Figure 5.7.
Figure 5.7 Schedule module main dialog box
When this is complete, the individual daily schedules must be defined. This is a
slightly different process from the Pattern module because the dialog boxes are more
involved. Click 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. Now select Monday as the day of the week and click the Add
button to the right of the shift schedule repeat group. Complete the resulting dialog
box 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.
56
Figure 5.8 Schedule module—Shift
DEFINING THE WORKERS—THE 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 box. By
default, the dialog box is initially set up to define agent groups (rather than parent
groups). Since this is what we want, complete the dialog box to match the one in
Figure 5.9. Remember that the schedule associated with the agent group can be
selected from the drop-down list. You will see a button at the bottom of the dialog
box for defining the agent group’s handling skills in terms of talk-time capabilities.
Figure 5.9 Agent module main dialog box
57
The only remaining task is to define the handling skills for the volunteers. Click the
Talk Time button to open a dialog box 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. Click Add to open the dialog box shown in Figure 5.10, select Donor from the
list of contact names and click OK to close the dialog box and save the default talk
and conference-time multipliers.
Figure 5.10 Agent module—Talk Time contact names
This completes the basic agent group definition, so click OK in each of the open
dialog boxs to accept the module into the simulation model.
DEFINING THE ROUTING LOGIC—THE 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. You specify how the phone switching
system works 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 box.
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 box
58
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. See the online
Help for more information on connecting modules.
Open the Queue for Agent main dialog box. By default, the dialog box is initially set
up to define agent groups (rather than parent groups). Since this is what we want,
complete the dialog box to match the one shown in Figure 5.12. The Advanced button
contains additional dialog boxes for modeling Advanced features.
Figure 5.12 Queue for Agent module main dialog box
Next, place and connect a Wait module after the Queue for Agent module in the
model window. Open the main dialog box and enter 2 in the Wait Time field as
illustrated in Figure 5.13.
Figure 5.13 Wait module main dialog box
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.
59
Place and connect a Message module after the Remove from Queue module in the
model window. Open the main dialog box 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 box
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 GRAPHICS—THE 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
calls—a 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.
60
Place an Animate module within the model window and double-click to open its
dialog box. Select Agent from among the Data Object options and complete the
remaining dialog box as shown in Figure 5.16.
Figure 5.16 Animate module main dialog box
COLLECTING STATISTICS—THE 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 box as
specified in Figure 5.17.
61
Figure 5.17 Report module main dialog box
Multiple Report modules can 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. Click 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 box, 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 box will appear asking whether you would like to see the results. Click Yes to
view the default summary report. The report window can be resized to better view its
contents. When finished viewing the default report, click File > Exit to return to Arena.
To leave Run mode and return to the model, click Run > End.
You can 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, see Chapter 7.
62
Conclusions
This chapter illustrates the ease of building a simulation model using the Arena
Contact Center template. Making it earier to create a model allows 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:
 Increase the volume of donor calls. What impact does this have on blocking,
abandonment, and agent utilization?
 Change 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 telethon’s 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.
63
6 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
template. Chapter 7 describes the modules located in the second template panel—the
Script panel.
The following modules are located on the Contact Data panel:
 Configuration
 Schedule
 Pattern
 Agent
 Contact
 Animate
 Report
Each of the above modules allow the definition of a single object (for example, Agent
Group or Contact). Multiple modules of the same type make up the model. Several
modules incorporate the notion of component repeat groups. That is, the module may
be composed of many similar pieces (for example, Days within a Week for the
Pattern and Schedule modules), but each piece is defined separately. The repeat
groups are described in the prompt text and will be obvious within the template
constructs, although it is not obvious from the prompt tables that they are repeat
groups. Similarly, many modules have custom dialog boxes that vary depending on
the options selected. This conditional input is also not obvious in the prompt tables.
65
Configuration module
DESCRIPTION
This module’s 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
here.
PROMPTS
Planning Horizon—Length of the planning horizon chosen from the following pre-
defined list of options: Month, Bi-Week, Week, Day. The planning horizon defines
the length of the simulation run.
Trunk Definitions—This 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 Group—Text descriptor of the trunk group being defined (for example,
Sales, Dallas Office, Outsourcer).
Trunk Capacity—Number of trunks in this trunk group.
Inbound Contacts—Indicates if this trunk is used for inbound contacts.
66
6 • THE CONTACT DATA PANEL
Inbound Contact Script—Routing script for inbound contact associated with this
trunk group, chosen from the list of defined Scripts.
Inbound Contact Priority—Integer used to rank inbound contact associated with
Trunk Group when queued to a priority queue.
Outbound Contacts—Indicates if this trunk is used for outbound contact.
Outbound Contact Script—Routing script for outbound contact associated with
this trunk group, chosen from the list of defined Scripts.
Outbound Contact Priority—Integer used to rank outbound contact associated
with Trunk Group when queued to a priority queue.
Trunk Cost/Hour—Cost of trunk lines in $/hour/trunk line.
Advanced—The following items support several advanced features of the run.

Number of Replications—Number of simulation runs to be performed during this
analysis. Each run’s length is determined by the Planning Horizon.
Initialize System Between Replications—Controls whether each replication is
started with an empty contact center or continues from the endpoint of the
previous replication.
Initialize Statistics Between Replications—Controls whether statistics collection
is reset at the beginning of each replication or accumulates throughout all
replications.
67
Max Number of Agent Groups—Upper 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 Definitions
Trunk Group Symbol Name [Trunk Group] Trunk 1
Trunk Capacity Integer >= 1 100
Inbound Contacts Checked, Cleared Checked
Inbound Contact Script Symbol Name [Scripts] Script 1
Inbound Contact Priority Expression 5
Outbound Contacts Checked, Cleared Cleared
Outbound Contact Script Symbol Name [Scripts] Script 1
Outbound Contact Priority Expression 100
Trunk Cost/Hour Real Number >= 0 0.00
Advanced
Number of Replications Integer >= 1 1
Initialize System Checked, Cleared Checked
Initialize Statistics Checked, Cleared Checked
Max Number of Agent Groups Integer >= 1 50
REMARKS
Only one Configuration module can 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.
68
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 can be
specified in the Contact module.
The advanced functionality dealing with replications and system initialization is
detailed in Arena online help.
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
This example sets up a weekly planning horizon. A single trunk group with 24 lines is
also defined.
Prompt Entry
Planning Horizon Week
Trunk Definitions
Trunk Group Phone Bank
Trunk Capacity 24
Inbound Contacts Checked
Inbound Contact Priority 1
Inbound Contact Script Direct Routing
Outbound Contacts Cleared
69
Schedule module
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 Name—Text descriptor of the schedule being defined (for example,
Graveyard).
defined list of options: Month, Bi-Week, Week, Day.
Timeslot (in minutes)—Length of the intervals composing the schedule: 15, 30, or
60 minutes.
70
Daily Schedule—This 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 can be defined.
Week—Selection of the week within the planning horizon for which the agent
shifts apply.
Day of Week—Selection of the day within the planning horizon for which the
agent shifts apply.
Shift Schedule—This 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 State—This field defines the agent availability state for this particular shift.
Alter Capacity by—This 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 Agents—This 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 Agent’s capacity as defined in
the Agent module.
71
Schedule Adherence Factor—Multiplier used to calculate the actual number of

agents used for a given timeslot.
Shift Begins at—This dialog box specifies the time the shift begins (for example,
8:00 AM).
Shift Ends at—This dialog box specifies the time the shift ends (for example,
noon).

Schedule Name Symbol Name [Schedule] <Module Name and
instance number>
Timeslot 15, 30, 60 30
Week Week 1, Week 2, Week 3, Week 4 Week 1
Day Of Week Monday, Tuesday, Wednesday, Monday
Thursday, Friday, Saturday, Sunday
Agent State On Duty, Lunch, Break, Meeting, On Duty
Research
Alter Capacity by Group Capacity, Number of Agents Group Capacity
Number of Agents Integer > 1 0
Schedule Adherence Integer > 1 0
Factor
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 (for example,
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 first shift will raise an error.
72
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 (for example, Monday: 8:00 PM; 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 (for example, 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).
Schedules are repeated to fill the simulation run length as defined in the
Configuration module (for example, 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 on- or off-duty in the middle of a reporting interval. Therefore, the intervals defined
for statistics should be no larger than the shift timeslots, and should coincide with shift
changes. 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.
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.
The timeslot and planning horizon data specified within the Schedule module are
independent of this data in other modules.
EXAMPLE
This example defines the schedule the volunteer agents will follow (coinciding with
the on-air pledge drive) in the Basic Telethon case study.
Prompt Entry
Schedule Name Telethon Hours
73
Prompt Entry
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
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.
74
PROMPTS
Pattern—Text descriptor of the contact pattern being defined (for example,
Windows, DOS).
defined list of options: Month, Bi-Week, Week, Day.
Timeslot (in minutes)—Length of the intervals composing the pattern: 30 or 60
minutes.
Scale Factor—Method 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.
Daily Arrival Pattern—This 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.
Week—Selection of the week within the planning horizon for which the pattern
applies.
75
Day Of Week—Selection of the day within the planning horizon for which the
pattern applies.
Daily Contact Pattern—Specification of the expected total contacts for each
timeslot for the given day.
EXAMPLE

Pattern Symbol Name [Pattern] <Module Name and
instance number>
Timeslot 30, 60 30
Scale Factor Real Number 1.0
Daily Arrival Pattern
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
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 (for example, 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 (for example, 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 (for example, 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.
76
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).
Prompt Entry
Pattern Basic Pattern
Day Of Week Mon/Tue/Wed/Thu/Fri
Daily Arrival Pattern 50
(6:00 AM - 7:00 AM)
(7:00 AM - 8:00 AM)
(8:00 AM - 9:00 AM)
(9:00 AM - 10:00 AM)
Agent module
77
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 to provide aggregate statistics. (For example, Agent Groups could
be defined for groups that handle Day, Evening, and Graveyard shifts, with a Parent
Group to include all three.)
PROMPTS
Agent Name—Text descriptor of the group being defined.
Agent Type—Choice 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 Available—Maximum number of agents available in the Agent Group.
Schedule—Associated Agent Schedule, chosen from the list of the defined Agent
Schedules.
Clear Queue when Off Duty—Specifies 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. Aparent group queue can
be cleared several times daily depending upon the member agent group schedules.
Busy Cost/Hour—Cost per hour incurred while a single agent is busy.
Idle Cost/Hour—Cost per hour incurred while a single agent is idle.
Per Use Cost—Cost per contact incurred for a single agent.
78
Talk Time Specifics—Dialog box containing a repeat group that defines talk time
specifics for each contact name.
Contact Name—Particular contact name that can be handled by agents with the
given skill set.
Talk Time Multiplier—Numerical expression quantifying the skill of the agent
with respect to the specified contact name (for example, 0.9 implies agents with
this skill set handle this contact in 90% of the average time).
Conference Time Multiplier—Numerical expression quantifying the skill of the
agent when conferenced on a particular contact name (for example, 0.9 implies
agents with this skill set resolve this contact in 90% of the average time).
Override Contact Priority with Skill Priority—Indicates whether contact priority
should be redefined when served by this Agent Group.
Agent Skill Priority—Number indicating the priority for Contact Name (that is,
1 for highest priority, 2 for next, and so on). 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.
79
If Agent Type = Parent Group:
These items define a Parent Group in terms of its component Agent Groups.
Preferences can be specified to further define the assignment of contacts to the Agent
Groups within the Parent Group.
Clear Queue when Off Duty—Specifies whether contacts are disconnected when all
agent groups comprising the parent group go off duty at the end of a day.
Members—This repeat group specifies the various Agent Groups that compose the
given Parent Group.
Agent Group—Text descriptor of the Agent Group that belongs to the Parent
Group, chosen from the list of Agent Groups that have been defined.
Preference—Number indicating the preference of this Agent Group within Parent
Group (for example, 1 for primary preference, 2 for secondary preference).
Preference defines an order within Parent Group for assignment of contacts to
Agent Group. Lower-valued groups will always be assigned before higher-valued
agents when agents of different Preference are available.
Agent Skill Priority—Dialog box containing a repeat group that specifies agent skill
priorities by contact name.
Contact Names—This repeat group specifies agent skill priorities by contact name.
Contact Name—Particular contact name that can be handled by agents with the
given skill set.
80
Agent Skill Priority—Number indicating the priority for Contact Name (that is,
1 for highest priority, 2 for next, and so on). 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.

Agent Name Symbol Name [Agent] Agent Group
Agent Type Agent Group or Parent Group Agent Group
Agent Group
Max Number Available Integer >= 1 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
Talk Time/Contact Names
Contact Name Symbol Name [Contact] Contact 1
Talk Time Multiplier Real Number >= 0 1
Conference Time Multiplier Real Number >= 0 1
Override Contact Priority Checked, Cleared Cleared
Agent Skill Priority Integer >= 1 5
Parent Group
Clear Queue when Off-Duty Checked, Cleared Checked
Members
Agent Group Symbol Name [Agent Group] Agent Group 1
Preference Integer >= 1 5
Agent Skill Priority
Contact Names
Agent Skill Priority Integer >= 1 5
81
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 (for example, the Windows Group is a
single logical entity to which contacts can be routed, but 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 1—BASIC USE
This example defines the volunteers in the Basic Telethon case study as an Agent
group of 12 generic agents.
Prompt Entry
Agent Name Volunteers
Agent Type Agent Group
Max Number Available 12
Schedule Telethon Hours
Clear Queue when Off-Duty Checked
Busy Cost 0.0
Idle Cost 0.0
Per Use Cost 0.0
Talk Time
Contact Name Donor
82
Prompt Entry
Talk Time Multiplier 1
Conference Time Multiplier 1
Override Contact Priority Cleared
EXAMPLE 2—USING BASIC MULTIPLIER TO MODEL SKILL LEVELS
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.
Prompt Entry
Agent Name Expert
Schedule First Shift
Busy Cost 0.0
Idle Cost 0.0
Per Use Cost 0.0
Talk Time
Contact Name Regular
Talk Time Multiplier 0.8
Conference Time Multiplier 0.8
Contact Name Premium
Conference Time Multiplier 0.8
83
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 Type—Defines the type of contact (for example, Call, Email, Fax, Web Hit or
Other).
Option—Defines a contact as inbound or outbound.
Contact Name—Text descriptor of the contact being defined (for example,
Reservations).
Pattern—Associated Pattern, chosen from the list of the defined Patterns.
Expected Talk Time—Average 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 Group—Associated Trunk Group, chosen from the list of the defined Trunk
Groups.
84
Contact Back—Dialog box that defines contact-back behavior:

Contact Back Reasons—Blocked, Disconnected, Message, Abandoned, Served.
Probability—Numerical expression for probability of contact back.
Wait Time—Distribution for the delay (in minutes) before contacting back.
Abandonment—Specification of Abandonment module to apply to the contact.

Wait Time Until Abandonment—Distribution specifying time until abandonment.
85
Advanced—Dialog box that allows incorporation of the following advanced modeling

features:
Override Trunk Priority—Check box determines whether or not the priority
specified in the Configuration module will be used for a given contact name.
Override Trunk Priority—Expression 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 Script—Check box used to indicate whether the Script
“inherited” from Trunk Group Script (see the “Configuration module” on
page 66) 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 Script—Overriding 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 66).
[Agent Type]—Defines whether the overriding agent type is a parent group or
basic agent group.
86
Agent Group—Name of the overriding agent group to which contacts of Contact

Name will be sent directly to its associated queue.
Parent Group—Name of the overriding parent group to which contacts of
Contact Name will be sent directly to its associated queue.
Selection Rule—Rule used to determine which agent is selected from among
multiple member agent groups.
Talk Time Distribution—Overrides default talk-time distribution by allowing
specification of any general distribution.
After Contact Time—Specifies 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 Preempt—Indicates whether a contact of Contact Name can preempt another
contact that is being served by an agent.
Can Be Preempted—Indicates whether a contact of Contact Name currently being
serviced by an agent can be preempted by another contact.
Contact Picture Name—Defines the name of the entity symbol used for animating
Contact Name contacts.
Create Contact—Indicates if a Contact Name contact is created when another
entity executes the Contact module.
Contact Characteristics—Dialog box that allows the assignment of user-defined
contact attributes or user-defined global variables.
Assignments—Specified 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 a global variable.
Contact Attribute Name—Name of the user-defined contact attribute that will
be assigned a value when a contact of Contact Name is generated.
Global Variable Name—Name of the global variable being assigned.
Value—Assignment value of the attribute or variable.
87
Contact Return check box—Displays a dialog box that defines return contact
characteristics.
Contact Return—Dialog box that specifies contact return behavior.
Priority—Integer used to rank returned contacts in an agent’s queue.
[Contact Return Logic Type]—Determines whether a returned contact follows a
script or is queued for an agent.
Contact Return Script—The 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 Group—The name of the agent group that will service the
returned contact.
Contact Return Parent Group—The name of the parent group of agents that will
service the returned contact.
Selection Rule—The rule to use when there is more than one available agent to
handle the returned contact.
Pre Work—The amount of time an agent needs prior to returning a contact.
Connection Time—The amount of time it takes to connect with the returned
contactor.
Probability of Connection—The probability that an agent will be able to connect
with the returned contactor.
Max Number of Attempts—The number of attempts an agent will make to connect
with a returned contactor prior to abandoning it.
Time Between Attempts—The time between subsequent contact return attempts.
Outbound Contacts—Dialog box that specifies outbound contact behavior.
Pre Work—The amount of time an agent needs prior to making an outbound
contact.
Connection Time—The amount of time it takes to connect the outbound contact.
Probability of Connection—The probability that an agent will be able to connect
with the outbound contact.
Max Number of Attempts—The number of attempts an agent will make to connect
with an outbound contact prior to abandoning it.
88
Time Between Attempts—The time between subsequent outbound contact

attempts

Contact Name Symbol Name [Contact] <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 1
Contact Back
Contact Back Reason: Checked, Cleared Cleared
Blocked, Disconnected,
Message, Abandoned,
Served
Probability 0 <= Real Number 1
<= 1.0 or expression
Wait Time Expression (Distribution) 1
Abandonment
Wait Time Until Expression (Distribution) None
Abandonment
Advanced
Override Trunk Priority Checked, Cleared Cleared
Check box
Override Trunk Priority Integer >= 1 5
Override Trunk Script Checked, Cleared Cleared
[Override Type] Script, Agent Script
Call Routing Script Symbol Name [Script] Script 1
[Agent Type] Agent Group, Parent Group Agent Group
89

Parent Group Symbol Name [Parent Group] Parent Group 1
Selection Rule First Available, Longest Available, Uniform by Availability
Uniform by Availability
Talk Time Distribution Expression (Distribution) (Uses Expected Talk
Time from main dialog
box)
After Contact Time Expression (Distribution) 0.0
Distribution
Service Level Real Number > 0 60
Can Preempt Checked, Cleared Cleared
Can Be Preempted Checked, Cleared Cleared
Contact Picture Name Symbol Name [Pictures] Contact 1 Picture
Create Contact Checked, Cleared Cleared
Contact Characteristics
[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 1
Contact Return Check box Checked, Cleared Cleared
Contact Return
Priority Integer>=1 50
[Contact Return Logic Script, Agent Script
Type]
Contact Return Script Symbol Name [Script] Script 1
[Contact Return Agent Agent Group, Parent Group Agent Group
Type]
Contact Return Script Symbol Name [Script] Script 1
90

Contact Return Agent Symbol Name [Agent Group] Agent Group 1
Group
Contact Return Parent Symbol Name [Parent Group] Parent Group 1
Group
Pre Work Expression (Distributions) 0.0
Connection Time Expression (Distributions) 0.0
Probability of 0<=Expression<=1 1
Connection
Max Number of Integer>=1 1
Attempts
Time Between Expression (Distributions) 0.0
Attempts
Outbound Contacts
Pre Work Expression (Distributions) 0.0
Connection Time Expression (Distributions) 0.0
Probability of 0<=Expression<=1 1
Connection
Max Number of Integer>=1 1
Attempts
Time Between Expression (Distributions) 0.0
Attempts
REMARKS
The Talk Time field in the main dialog box 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.
91
In the event of contact back, the priority of the contact will be reset as though it were
a new contact (that is, 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 can 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 Contact Queue for Agent External Logic.doe.
EXAMPLE
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. No contact back has been indicated, meaning there is no second chance
to serve donors who are blocked or abandoned.
Prompt Entry
Contact Name Donor
Pattern Basic Pattern
Talk Time 10
Trunk Group Phone Bank
Abandonment
Wait Time Until EXPO(1)
Abandonment
92
Animate module
DESCRIPTION
The Animate module allows animation of real-time statistics during the simulation
run.
PROMPTS
Data Object—Indicates the type of contact center statistic to be displayed.
If Data Object = Contact:
Contact Name—Selection of the Contact Name to animate, from a list of all defined
Contact Names.
Contact Statistic Type—Selection of the Contact Statistic Type to animate. Choices
are:
Contact Count—Running total number of contacts in particular stages.
Contact Back Count—Running totals of contact backs by contact-back reason.
Contact Times—Average time contacts spend in a particular state.
Percentages—Percentages of contacts in various categories.
Contact Data—Selection of the particular real-time statistic to animate. Choices
depend on the Contact Statistic Type being animated and are summarized in
Table 6.1.
93
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
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
94
Contact Statistic Definition

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 Average amount of time the contact spends in the contact center
Center
Percentages
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/Parent—Selection of the Agent/Parent Group to animate, from a list of all

defined Agent/Parent Groups.
Object Data—Selection of the particular cumulative real-time statistic to animate.
Choices are:
95
Utilization—The fraction of on-duty time during which members of the Agent

Group are serving customers.
Number Busy—The average number of agents concurrently serving customers.
Number Available—The average number of idle agents.
If Data Object = Trunk Group:
Trunk—Selection of the Trunk Group to animate, from a list of all defined Trunk
Groups.
Object Data—Selection of the particular cumulative real-time statistic to animate.
Choices are:
Utilization—The fraction of time during which trunk lines of the Trunk Group are
busy.
Number in Use—The average number of trunk lines concurrently in use.
Number Available—The average number of trunk lines that are idle.
96
If Data Object = Overflow:
Source Group—Selection of the Agent Group from which overflowed contact counts
should be animated.
Destination Group—Selection of the Agent Group to which overflowed contact
counts should be animated.
If Data Object = System Time:
Display As—Selection of the view(s) by which the system time should be animated.
Choices are:
Variable—Display of the day of the simulation run as a numerical quantity (1-28).
97
Analog Clock—Illustration of the day of simulation run as a clock face.

Digital Clock—Illustration of digital 24-hour clock in numeric form.
If Data Object = Other:
Other Data—Specification of an expression to be animated throughout the

simulation run.
If Data Object is not System Time:
Display As—Selection of the view(s) by which the chosen statistic should be
animated. Choices are:
Variable—Display of the statistic as a numerical quantity.
Level—Illustration of the statistic as a graphical quantity.
Histogram—Illustration of the statistic as a histogram of values it assumes over
time.
Plot—Display of the statistic as a plot over time.
98

Data Object Contact, Agent Group, Parent Group, Contact
Trunk Group, Overflow, System Time or
Other
Contact
Contact Statistic Type Contact Count, Contact-Back, Count, Contact Count
Contact Times, Percentages
Contact Data Selection from list of available statistics Abandoned
Agent Group
Agent Data Selection from list of available statistics Utilization
Parent Group
Parent Data Selection from list of available statistics Utilization
Trunk Group
Trunk Data Selection from list of available statistics Utilization
Overflow
Source Group Symbol Name [Agent] Agent Group 1
Destination Group Symbol Name [Agent] Agent Group 2
System Time
Display As Selection of the views (multiple choices All
allowed) to animate the statistic
Other
Other Data Expression Required
Display As Selection of the views (multiple choices All
allowed) to animate the statistic
99
REMARKS
Some display options may not be appropriate for all measures.
To change the characteristics of a given animation display, double-click the animation
(for example, the plot or variable), edit the appropriate fields, and click OK (such as
change colors, borders or labels).
EXAMPLE
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.
Prompt Entry
Data Object Agent Group
Agent Group Volunteers
Agent Data Utilization
Display As Variable
Display As Plot
Report module
100
DESCRIPTION
This module’s 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 in this module, and the corresponding report is generated
during the simulation run.
PROMPTS
Report Type—The type of statistical report and the particular value to be tracked are
chosen from among the following:
Contact Times—Selection of a particular Contact Name for which contact-time
statistics will be collected.
Contact Counts—Selection of a particular Contact Name for which counts will be
tallied as contacts enter various stages.
Agent Group—Selection of a particular Agent Group for which utilization
Parent Group—Selection of a particular Parent Group for which utilization
Trunk Group—Selection of a particular Trunk Group for which utilization
Overflow—Selection of a particular pair of Source and Destination Agent groups
for which overflow counts will be collected.
Contact Name—This field, visible if Report Type is Contact Times or Contact
Counts, defines the contact type for which the report will be written.
Agent Group—This field, visible if Report Type is Agent Group, defines the agent
group for which the report will be written.
Parent Group—This field, visible if Report Type is Parent Group, defines the parent
Trunk Group—This field, visible if Report Type is Trunk Group, defines the trunk
Source Group—This field, visible if Report Type is Overflow, defines the source
agent or parent group for which the overflow statistics are to be reported.
Destination Group—This field, visible if Report Type is Overflow, defines the
destination agent or parent group for which the overflow statistics are to be reported.
101
Time Interval—Numerical value, in minutes, defining the interval length for which
Form of Output—Choice of Data or Text File, which determines whether the output
report is generated in a spreadsheet-based or text format.
Output File—Name of the output file to which the report will be written.
Options—Dialog box that allows the specification of advanced options.
Exclude empty time slots—Controls whether empty timeslots are displayed.
Highlight time slots with a specified condition—Determines if specified timeslots
will be highlighted.
Condition—The 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.

Report Type Contact Times, Contact Counts, Contact Times
Agent Group, Parent Group, Trunk
Group, Overflow
Contact Counts Symbol Name [Contact Counts] Contact 1
Source Group Symbol Name [Agent Group] Agent Group 1
Destination Group Symbol Name [Agent 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
102

Options
Exclude empty time slots Checked, Cleared Cleared
Highlight time slots with Checked, Cleared Cleared
a specified condition
Condition Expression Required
REMARKS
Each Report module collects statistics for a particular type and value. Therefore,
multiple Report modules can be placed to collect all desired statistics.
In the Report module, the timeslot intervals specified for statistics collection can be
of any length. Separate Report modules can be placed to collect statistics at different
levels of aggregation (for example, hourly, daily, and weekly).
See “Contact Center Template Reports” (Chapter 8) for a detailed description of each
field in the report.
While statistic collection can be made for any length of time, the shorter the time
interval, the slower the simulation will run (that is, don’t 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.
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.
103
Figure 6.1 Report output—text 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 can read
.csv files directly or indirectly. Then you can use the other features of these programs
to view, sort (for example, all Mondays or all 8-9 AM timeslots), graph, and print the
data.
Figure 6.2 Report output—data form (Microsoft Excel)
104
EXAMPLE
In this example, a report of contact times for the contact name Donor is generated.
Statistics are collected every 60 time units. The output is written to the data file
Donor Time 60.csv.
Prompt Entry
Report Type Contact Times
Contact Name Donor
Time Interval 60
Form of Output Data File
Output File Donor Time 60.csv
105
7 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:
 Begin Script
 Queue for Agent
 Wait
 Priority
 Message
 Disconnect
 Overflow
 Transfer to Script
 Transfer to Agent
 Conference
 Branch
 Assignment
 End Script
All scripts must begin with a Begin Script module. A list of several script restrictions,
as well as examples of several Contact Center template scripts,is included at the end
of the chapter.
Begin Script module
107
DESCRIPTION
This module’s purpose is to identify the script. The option of obtaining a trunk line
can also be specified.
PROMPTS
Script Name—Identifier of script.
Seize Trunk Group—Indicates whether a trunk should be seized.
Trunk Name—Name of trunk to be seized.

Script Name Symbol Name [Scripts] Script <module
instance number>
Seize Trunk Group Checked, Cleared Cleared
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
This example represents the first module for the Direct Routing script of the Basic
Telethon case study.
Prompt Entry
Script Name Direct Routing
Seize Trunk Cleared
108
7 • THE SCRIPT PANEL
Queue for Agent module
DESCRIPTION
The Queue for Agent module places the contact in 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 can connect other blocks of logic to the module using 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
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 Group—Name of the agent group.
Parent Group—Name of the parent group.
Selection Rule—This field, visible if Group Type is Parent Group, defines the rule
used to determine which agent is selected from among multiple member agent
groups.
109
Advanced—This dialog box shows several options to access external logic.

After seizing agent—Allows the contact entity to access external logic after
seizing an agent (before talk time starts).
After talk time—Allows the contact entity to access external logic after talk time.
Prior to post contact work—Allows the contact entity to access external logic
prior to post-contact work.

Group Type Agent Group, Parent Group Agent Group
Advanced
After seizing agent Checked, Cleared Cleared
After talk time Checked, Cleared Cleared
Prior to post contact Checked, Cleared Cleared
work
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.
110
Additional external logic can be specified at three points in time with a relationship to
the primary agent and the agent talk time:
 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.
 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
In this example, the contact is placed in the Volunteers queue from the Basic Telethon
case study.
Prompt Entry
Group Type Agent Group
Agent Group Volunteers
Remove from Queue module
111
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.
Wait module
DESCRIPTION
The Wait module is used to hold the contact in place for a specified amount of time
before proceeding.
PROMPTS
Wait Time—Distribution of the delay for the contact.

Wait Time Expression (Distributions) 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 a wide
variety of delays experienced by the contactor, including playing welcome messages
112
and announcements, prompting and receiving customer inputs, transfer times, and
being placed on hold for an agent.
EXAMPLE
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.
Prompt Entry
Wait Time TRIA(1,3,5)
Priority module
DESCRIPTION
The Priority module changes the priority of the contact. This may affect its
processing, including moving it ahead of other contacts in a queue.
PROMPTS
(Priority Change)—Determines by which method the priority changes:
Increase—Increases 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.
Decrease—Decreases 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.
New—Redefine the importance of the contact to the specified priority. Queue
ranking and claim to available agent resources will be adjusted accordingly.
Increase Priority by—Quantity by which the current value will be increased.
113
Decrease Priority by—Quantity by which the current value will be decreased.

New Priority—New value assigned to the current priority.

Priority Change Increase, Decrease, New Increase
Increase Priority by Expression 1
Decrease Priority by Expression 1
New Priority Expression 1
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.
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
This example increases the priority of the contact by 2.
Prompt Entry
Priority Change Increase
Increase Priority by 2
114
Message module
DESCRIPTION
This module allows a contact to leave a message, possibly generating a contact
return.
PROMPTS
Message Wait Time—Amount of time to leave a message.
Disable Contact Back—Disable the option for messaged contacts to contact back
(re-enter the system).
Disable Contact Return—Disable the option to turn a messaged contact into a contact
return.

Message Wait Time Expression (Distribution) 0.0
Disable Contact Back Checked, Cleared Cleared
Disable Contact Return Checked, Cleared Checked
REMARKS
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 contact’s type, a contact back may occur with the probability
and in the time specified. Contact backs generated from messages (specified in the
115
Contact module) may optionally be disabled by checking the Disable Contact Back
field.
A Message module can be used for Inbound scripts only.
EXAMPLE
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.
Prompt Entry
Message Wait Time UNIF(1,2)
Disable Contact Back Cleared
Disable Contact Return Checked
Disconnect module
DESCRIPTION
The Disconnect module terminates a contact.
PROMPTS
Disable Contact Back—Disable the option for messaged contacts to contact back
(re-enter the system).

Disable Contact Back Checked, Cleared Cleared
116
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 contact’s
corresponding Contact module) may optionally be disabled using this action.
EXAMPLE
This example dispatches the contact from the center. Based on the probability (if any)
specified in the associated Contact module, a contact back can be generated since the
Disable Contact Back option was not checked.
Prompt Entry
Disable Contact Back Cleared
Overflow module
DESCRIPTION
The Overflow module removes the contact from its Source queue and sends it to its
Destination queue.
117
PROMPTS
Source Group—The queue from which the contact will be removed.
Destination Group—The queue to which the removed contact will be sent.

Source Group Symbol Name [Agent Group] Agent Group 1
Destination Group Symbol Name [Agent 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
This example removes the contact from the Primary Agents’ queue and sends it to the
Secondary Agents’ queue.
Prompt Entry
Source Group Primary Agents
Destination Group Secondary Agents
Transfer to Script module
118
DESCRIPTION
This module shifts the routing control to another script.
PROMPTS
Script Name—Name of the routing script to which the contact will be transferred.
Release Trunk Group—Option to indicate that the current trunk group should be
released.

Script Name Symbol Name [Script] Script 1
Release Trunk Group Checked, Cleared Cleared
REMARKS
The Transfer to Script module is used to simplify routing scripts by separating
common elements and functions so they can be executed as subroutines by multiple
scripts. It can 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
This example would cause a contact’s routing control flow to be transferred to the
Advanced script for continued processing.
Prompt Entry
Script Name Advanced
Release Trunk Group Cleared
119
Transfer to Agent module
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 Group—The name of the agent group.
Parent Group—The name of the parent group.
Selection Rule—Determines which agent is selected from among multiple available
agent groups.
Transfer Talk Time—Delay time incurred by the contact with the transfer agent.

(Group Type) Agent Group, Parent Group Agent Group
Transfer Talk Time Expression (Distributions) 0.0
120
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 agent’s 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. 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) agent’s activities, and so on.
EXAMPLE
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.
Prompt Entry
(Group Type) Agent Group
Agent Group Manager
Transfer Talk Time UNIF(3,5)
121
Conference module
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 Group—The name of the agent group.
Parent Group—The name of the parent group.
Selection Rule—Determines which agent is selected from among multiple member
agent groups.
Conference Talk Time—Delay time incurred by the contact with the conference agent
and the primary agent.

(Group Type) Agent Group, Parent Group Agent Group
Conference Talk Time Expression (Distributions) 0.0
122
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 agent’s 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.
EXAMPLE
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.
Prompt Entry
(Group Type) Agent Group
Agent Group Manager
Conference Talk Time UNIF(7,10)
123
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 (for example, if a contact’s priority
is greater than five or based on one or more probabilities (for example, 75%).
PROMPTS
Branch Options—Specifies the one or more branch conditions or probabilities that
will be evaluated when a contact executes the module.
(Branch Type)—Type of condition (If), probabilistic branch (With), or Else
condition.
Condition—Condition to be evaluated. This field is visible when Branch Type is
If. There are 11 conditions that can be evaluated.
Condition is Agent Availability
Agent Group—Name 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.
124
Condition is Contact Attribute Value

Contact Attribute Name—Name 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 contact’s current priority value will be
compared.
Condition is Contact Name Is
Contact Name—Name of contact type to which the contact’s type will be
compared. If the contact’s type is the same as Contact Type, the condition is
TRUE.
Condition is Day Is
Day—Day 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 Expression—Any valid SIMAN expression.
Condition is Queue Length
Agent Queue—Name of the Agent or Parent Group whose queue length will
be evaluated against (Agent Queue Length).
(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 contact’s current
total time spent in the center will be compared.
125
Condition is Global Variable Value

Global Variable Name—Name 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 Group—Name 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 Probability—Probability of selecting branch. Used only when Branch
Type is set to With.
126

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
Contact Attribute Name Symbol Name [Contact Attribute] Attribute 1
(Contact Attribute Expression 1
Value)
(Contact Priority) Expression 1
Day Monday, Tuesday, Wednesday, Monday
Thursday, Friday, Saturday, Sunday
SIMAN Expression Expression Required
Agent Queue Symbol Name [Agent Group] Agent Group 1
(Agent Queue Length) Expression 1
(Time in Call Center) Expression 1
Global Variable Name Symbol Name [Variable] Variable 1
(Global Variable Value) Expression 1
(Time of Day) AM, PM, Midnight, Noon AM
(Hour) Integer (0-12) 1

(Minute) Integer (0 - 59) 0
(Agent Expression) Average Wait Time, Average Handle Average Wait Time
Time, Expected Wait Time
(Agent Expression Expression 1
Value)
(Operator) <, <=, <>, ==, >, >= ==
127
REMARKS
The Branch module is used to simplify routing scripts by separating common
elements and functions so they can be executed as subroutines by multiple scripts. It
can 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.
EXAMPLE
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).
Prompt Entry
Branch Type If
Condition Queue Length
Agent Queue IRA specialists
(Operators) <=
(Agent Queue Length) 3
Branch Type Else
Assignment module
DESCRIPTION
This module allows the assignment of contact attributes, Arena Contact Center global
variables, contact pictures, or user-defined counters.
128
PROMPTS
(Assignment Type)—Type of assignment to be made.
Contact Attribute Name—Name of the contact attribute to be assigned.
Global Variable Name—Name of Contact Center global variable to be assigned.
Value—The value to be assigned to the attribute or variable.
Contact Picture Name—Name of the contact’s picture used for animation.
Counter Name—Name of the counter to be incremented.
Increment—Value by which the counter is incremented.

(Assignment Type) Contact Attribute, Contact Picture, Contact Attribute
Global Variable, Counter
Contact Attribute Name Symbol Name [Contact Attribute] Attribute 1
Global Variable Name Symbol Name [Contact Center Global Variable 1
Variable]
Value Expression 1
Contact Picture Name Symbol Name [Picture] Picture 1
Counter Name Symbol Name [Counter] Counter 1
Increment Integer 1
REMARKS
User-defined counters appear in the Category Overview, Category by Replication,
and User-Specified reports.
EXAMPLE
This example reassigns the contact’s picture to “Transferred Picture.”
Prompt Entry
(Assignment Type) Contact Picture
Contact Picture Name Transferred Picture
129
End Script module
DESCRIPTION
This module’s 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:
 Overflow
The following actions are not permitted until the contact is in 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.
130
Arena Contact Center template script

examples
EXAMPLE 1—BASIC 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
EXAMPLE 2—QUEUEING 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.
1. Begin Script
2. Queue for Agent: Volunteers
3. Wait: 2
4. Remove from Queue
5. Message: 0.5
6. End Script
EXAMPLE 3—BASIC 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. Begin Script
2. Queue for Agent: IRA specialists
3. Wait: 2
4. Overflow: IRA Specialists to General Customer Service
5. Queue for Agent: General Customer Service (Selection rule: uniform by
availability)
6. End Script
131
The Queue for Agent module must be placed following the Overflow module. Also, in
this example, the IRA specialists group 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.
132
8 Reports
The Arena Contact Center template produces the following eight reports:
 Agents and Trunks  Agent Group Utilization

 Contact Times and Counts  Parent Group Utilization
 Contact Count Statistics  Trunk Group Utilization
 Contact Time Statistics  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 SAP® Crystal
Reports®. The output statistics are stored in an Access database where Crystal
Reports retrieves the data to generate these two 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, he corresponding week and day of the timeslot, and the number of
the timeslot within the day. This common section is described as follows:
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.
133
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
Available—This 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 Use—This 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.
Utilization—This section reports each trunk line’s 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 Cost—This 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 trunk’s 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
Available—The average number of agents available over the simulation run length.
Busy—The utilization over the simulation run length. This can include times when an
agent group cannot be scheduled in the system.
134
8 • REPORTS
Est on Duty—This 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 the time the
statistics are generated.
Utilization—This 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 Cost—The product of the average number of busy agents, the simulation run
length, and the agent busy cost specified in the Agent module.
Idle Cost—The product of the average number of idle agents, the simulation run
length, and the agent idle cost specified in the Agent module.
Per Use Cost—The 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 Util—This section reports each trunk’s busy cost. Busy cost is the cost
accrued by a trunk while it is in a non-value-added activity.
Outbound Util—This section reports each trunk’s busy cost. Busy cost is the cost
accrued by a trunk while it is in a non-value-added activity.
The report produced corresponds very closely to 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.
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.
135
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.
Handle Time—The amount of time a contact spends from when the agent is available
until the contact is complete.
Message to Return Time—The time from when a contact leaves a message to when an
agent returns the contact.
Speed of Answer Time—The time a contact spends waiting for an available agent.
Time in Contact Center—The 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
Blocked—The total number of contacts blocked as of the end of the replication.
Created—The 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 System—The total number of contacts that were left in the system as of the end of
the replication.
Offered—The total number of contacts offered as of the end of the simulation.
Waiting—The total number of contacts that were left waiting for an agent as of the
end of the replication.
OUTCOMES
Abandoned—The total number of contacts abandoned as of the end of the replication.
Disconnected—The total number of contacts disconnected as of the end of the
replication.
Handled—The total number of contacts handled as of the end of the replication.
In Target—The total number of contacts answered within the specified service-level
time as of the end of the replication.
136
8 • REPORTS
Message—The total number of messages generated as of the end of the replication.
CONTACT BACKS
Abandoned—The total number of contact backs generated due to abandoned contacts
for the duration of the simulation.
Blocked—The total number of contact backs generated due to blocked contacts for
the duration of the simulation.
Disconnected—The total number of contact backs generated due to disconnected
contacts for the duration of the simulation.
Message—The total number of contact backs generated due to messages for the
duration of the simulation.
Served—The 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
Percent—The number of contacts answered within the specified service level divided
by the number of contacts that enter the system.
Target Level—The number of seconds, specified in the Contact module, for a
contact’s service level.
Abandoned Percent—The number of contacts abandoned divided by the number of
calls that enter the system.
Blocking Percent—The number of contacts blocked divided by the number of
contacts generated.
CONTACT RETURN COUNTS
Abandoned—The total number of contact returns generated due to abandoned
contacts.
Outstanding—The total number of messages for which no action was taken (a contact
return). 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.
Returned—The total number of return contacts made due to messages generated.
137
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.
Contact counts are updated as soon as the corresponding event occurs. This implies
that counts pertaining to a single contact can be spread across timeslots. For example,
a contact can be created in one timeslot, but handled in another.
Table 8.2 Contact Count Statistics report column 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
138
8 • REPORTS
EXAMPLE
Contact Count Statistics for Account Balance by 60-Minute Time Period
During the contact center’s 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. 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 the number of offered contacts and the number of
handled contacts in the same timeslot.
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.
Observations are incorporated into the average statistics as soon as the corresponding
state is completed. This implies that some observations for a given contact can be
split across timeslots, and thus, each measure within a timeslot can be based on a
different number of contacts. For example, 50 contacts can 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.
139
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
140
8 • REPORTS
During the contact center’s 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 contact—an 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
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
141
EXAMPLE
Agent Statistics for Savings Specialists by 60-Minute Time Period
In this example, the contact center is open only during (that is, 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.
142
8 • REPORTS
Table 8.5 Parent Group Utilization report column descriptions

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
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% and 3.3%.
143
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
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
144
8 • REPORTS
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
Number of Contacts The number of contacts overflowed from the Source Group to
the Destination Group
EXAMPLE
Overflow Statistics Between U.S. Center and Europe Center by 60-Minute Time Period
145
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 can 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.
146
9 Case Studies
Purposes of cases and examples
The purpose of the case studies and example models is to illustrate the Contact Center
template 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 template users.
As with any modeling tool, the best way to become familiar with the Arena Contact
Center template is to examine the example models, run these models, and observe the
differences in output when the model inputs are altered (for example, contact volume
is increased, agents/ trunks are added or agent schedules are changed). Utilizing the
product’s animation features to “watch” your models run can also be very
informative.
Example 1—Bilingual 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 the Arena
Contact Center template’s contact abandonment and contact-back capability.
Key modeling techniques illustrated in this example

AGENT AND PARENT GROUPS
The Arena Contact Center template 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).
147
In the Bilingual Call Center example, there are three types of agent groups: English-
speaking, 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 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.
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. The Arena
Contact Center template 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.
148
9 • CASE STUDIES
The flow of a contact abandonment and contact back is illustrated in Figure 9.2.
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 Bilingual Center case study is based on a weekly planning horizon and a center
with a single trunk group of 100 lines.
Table 9.1 Configuration module—Bilingual Center
Prompt Entry
Trunk Definitions
Trunk Group Central Trunks
Trunk Capacity 100
Inbound Contact Script English Script
149
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 module—Bilingual Center
Prompt Entry
Schedule Name Business Hours
Timeslot 60
Day of Week Monday/Tuesday/Wednesday/Thursday/Friday
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. 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 module—Bilingual Center
Prompt Entry
Pattern Weekly Pattern
Timeslot 60
8:00 AM–9:00 AM 100
150
9 • CASE STUDIES
Prompt Entry
9:00 AM–10:00 AM 50
10:00 AM–11:00 AM 50
11:00 AM–Noon 50
Noon–1:00 PM 50
1:00 PM–2:00 PM 50
2:00 PM–3:00 PM 50
3:00 PM–4:00 PM 50
4:00 PM–5:00 PM 50
Day of Week Saturday
Day of Week Sunday
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. 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 The Arena Contact Center template, each agent group
and each parent group is required to have its data entered into its own module.
Table 9.4 Agent modules—Bilingual Center

Prompt Entry
Agent Name English Only
Schedule Business Hours
Clear Queue when Off Duty Checked
151
Prompt Entry
Talk Time
Contact Name English
Agent Name Spanish Only
Agent Type Agent
Talk Time
Contact Name Spanish
Agent Name Bilingual
Agent Type Agent
Talk Time
Contact Name English
Contact Name Spanish
Agent Name English Servers
Agent Type Parent
Members
Agent Group English Only
Preference 5
Agent Group Bilingual
152
9 • CASE STUDIES
Prompt Entry
Preference 5
Agent Name Spanish Servers
Agent Type Parent
Members
Agent Group Spanish Only
Preference 5
Agent Group Bilingual
Preference 5
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. 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 modules—Bilingual Center

Module Prompt Entry
Begin Script Script Name English Script
Queue for Agent Group Type Parent Group
Parent Group English Servers
Selection Rule Uniform by Availability
End Script
Begin Script Script Name Spanish Script
153
Module Prompt Entry

Parent Group Spanish Servers
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 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 modules—Bilingual Center
Prompt Entry
Contact Name English/Spanish
Contact Back
Contact Back Reason Abandoned
Probability 0.75
Wait Time 20
Abandonment
Wait Time Until Abandonment EXPO(2)
Advanced
Override Trunk Script Checked
(Override Type) Script
Routing Script English Script/Spanish Script
Talk Time Distribution UNIF(3,7)/UNIF(4,6)
154
9 • CASE STUDIES
Example 2—Bank 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 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 the Arena Contact Center template, 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
The Arena Contact Center template 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).
155
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.
In the Arena Contact Center template, 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 the Arena Contact Center template, Agent Preference values allow a contact to
choose between different agents when agents of more than one type are available to
provide service.
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. The Preference values are assigned
when agent groups are assigned to a Parent Group.
156
9 • CASE STUDIES
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. The Arena Contact Center template
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.
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.
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.
157
Table 9.7 Configuration module-—Bank model

Prompt Entry
Trunk Definitions
Trunk Capacity 15
Inbound Contact Script Balance Script
Outbound Contacts Cleared
Trunk Cost/Hour 9
SCHEDULE MODULE
Agents in the Bank model work normal business hours.

Table 9.8 Agent Schedule module—Bank model
Prompt Entry
Timeslot 60
Day Of Week Monday/Tuesday/Wednesday/Thursday/Friday
Shift Schedule
Agent State On-Duty
Shift Ends at 5:00 PM
Day Of Week Sunday
158
9 • CASE STUDIES
PATTERN MODULE
Each contact name within the Bank model follows its own unique arrival pattern.
Table 9.9 Pattern module—Bank model
Prompt Entry
Pattern Savings Pattern (Checking Pattern, Account Balance
Pattern)
Timeslot 60
8:00 AM–9:00 AM 4 (40,100)
9:00 AM–10:00 AM 2 (20,50)
10:00 AM–11:00 AM 2 (20,50)
11:00 AM–Noon 2 (20,50)
Noon–1:00 PM 2 (20,50)
1:00 PM–2:00 PM 2 (20,50)
2:00 PM–3:00 PM 2 (20,50)
3:00 PM–4:00 PM 2 (20,50)
4:00 PM–5:00 PM 2 (20,50)
Day Of Week Sunday
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
159
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
Busy Cost/Hour 12
Idle Cost/Hour 12
Per Use Cost 0.0
Talk Time
Contact Name Savings
Call Type Checking
Contact Name Account Balance
Agent Name Checking Specialists
Agent Type Agent
Busy Cost/Hour 7.5
Idle Cost/Hour 7.5
Per Use Cost 0.0
160
9 • CASE STUDIES
Prompt Entry
Talk Time
Contact Name Checking
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, 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
Members
Agent Group Savings Specialists
Preference 1
Agent Group Checking Specialists
Preference 5
161
Prompt Entry
Agent Name Checking Servers
Agent Type Parent
Members
Preference 1
Preference 5
Agent Name Balance Servers
Agent Type Parent
Members
Preference 5
Preference 5
SCRIPTS
Since a parent group that includes all valid servers has been defined for each contact
name, the routing scripts are straightforward in the Bank model.
Table 9.12 Script modules—Bank model
Module Prompt Entry
Begin Script Script Name Savings Script
Parent Group Savings Servers
End Script
162
9 • CASE STUDIES
Module Prompt Entry

Begin Script Script Name Checking Script
Parent Group Checking Servers
End Script
Begin Script Script Name Balance Script
Parent Group Balance Servers
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 module—Bank 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)
Advanced
Routing Script Savings Script (Checking Script, Balance Script)
163
Example 3—Skill-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 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.
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 A’s have the lowest priority value for AB agents. Simi-
larly, when a BC agent becomes available, it will choose a Type B call, because Type
B’s have the lowest priority value for BC agents.
164
9 • CASE STUDIES
The agent skill priority concept is illustrated in Figure 9.4 below.
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 module—Skill-based Routing model
Prompt Entry
Trunk Definitions
Trunk Capacity 100
Inbound Contact Script Skill A Script
165
SCHEDULE MODULE
All agents in the Skill-based Routing model are on-duty during normal business
hours.
Table 9.15 Agent Schedule module—Skill-based Routing model
Prompt Entry
Timeslot 60
Shift Schedule
Agent State On-Duty
Day Of Week Sunday
PATTERN MODULE
All contact names within the Skill-based Routing model follow the same arrival
pattern.
Table 9.16 Pattern module—Skill-based Routing model
Prompt Entry
Timeslot 60
8:00 AM–9:00 AM 40
9:00 AM–10:00 AM 20
166
9 • CASE STUDIES
Prompt Entry
10:00 AM–11:00 AM 20
11:00 AM–Noon 20
Noon–1:00 PM 20
1:00 PM–2:00 PM 20
2:00 PM–3:00 PM 20
3:00 PM–4:00 PM 20
4:00 PM–5:00 PM 20
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 agent’s 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 modules—Skill-based Routing model
Prompt Entry
Agent Name AB Agents
Agent Type Agent
Talk Time
Contact Name Call A
167
Prompt Entry
Override Contact Priority Checked
with Skill Priority
Agent Skill Priority 1
Contact Name Call B
Override Contact Priority Checked with Skill Priority
Agent Name BC Agents
Agent Type Agent
Talk Time
Contact Name Call B
Override Call Priority with Checked
Skill Priority
Call Type Call C
Override Call Priority with Checked
Skill Priority
168
9 • CASE STUDIES
Prompt Entry
Agent Name B Servers
Agent Type Parent Group
Members
Agent Group AB Agents
Preference 5
Agent Group BC Agents
Preference 5
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.
All agents in each agent group face two queues: their own agent group queue and the
parent group queue. It is this setup that allows the skill-based contact selection
described in the Agent module discussion.
Table 9.18 Script modules—Skill-based Routing model
Module Prompt Entry
Begin Script Script Name Skill A Script
Queue for Agent Group Type Agent Group
Agent Group AB Agents
End Script
Begin Script Script Name Skill B Script
Parent Group B Servers
End Script
169
Module Prompt Entry

Begin Script Script Name Skill C Script
Agent Group BC Agents
End Script
CONTACT MODULE
There is nothing complex about the definition of the three contact names, except the
association of custom routing scripts for each.
Table 9.19 Contact modules—Skill-based Routing model
Prompt Entry
Contact Name Call A (Call B, Call C)
Expected Talk Time 5
Advanced
Routing Script Skill A Script (Skill B Script, Skill C Script)
Example 4—Premium Service model

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, you can assess the impact of increasing the
percentage or length of premium contacts on service levels for both premium and
regular contacts. You can also analyze the service-level impact of increasing the
number of agents dedicated to premium contacts.
170
9 • CASE STUDIES
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
The Arena Contact Center template 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.
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.
171
These assignments are illustrated in Figure 9.5.
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. 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.
172
9 • CASE STUDIES
Table 9.20 Configuration module—Premium Service model

Prompt Entry
Planning Horizon Day
Trunk Definitions
Trunk Group Regular Trunks
Trunk Capacity 100
Inbound Contact Script Regular Script
Inbound Call Priority 2
Trunk Group Premium Trunks
Trunk Capacity 20
Inbound Contact Script 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 modules—Premium Service model
Prompt Entry
Timeslot 60
Shift Schedule
Agent State On-Duty
173
Prompt Entry
Schedule Name 24 Hours
Timeslot 60
Shift Schedule
Agent State On-Duty
Shift Begins at Midnight
Shift Ends at Midnight
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 modules—Premium Service model
Prompt Entry
Pattern Regular Pattern
Timeslot 60
8:00 AM–9:00 AM 160
9:00 AM–10:00 AM 80
10:00 AM–11:00 AM 80
11:00 AM–Noon 80
Noon–1:00 PM 80
1:00 PM–2:00 PM 80
2:00 PM–3:00 PM 80
3:00 PM–4:00 PM 80
174
9 • CASE STUDIES
Prompt Entry
4:00 PM–5:00 PM 80
Pattern Premium Pattern
Timeslot 60
Midnight–1:00 AM 8
1:00 AM–2:00 AM 8
2:00 AM–3:00 AM 8
3:00 AM–4:00 AM 8
4:00 AM–5:00 AM 8
5:00 AM–6:00 AM 8
6:00 AM–7:00 AM 8
7:00 AM–8:00 AM 8
8:00 AM–9:00 AM 160
9:00 AM–10:00 AM 72
10:00 AM–11:00 AM 64
11:00 AM–Noon 64
Noon–1:00 PM 64
1:00 PM–2:00 PM 64
2:00 PM–3:00 PM 64
3:00 PM–4:00 PM 64
4:00 PM–5:00 PM 64
5:00 PM–6:00 PM 8
6:00 PM–7:00 PM 8
7:00 PM–8:00 PM 8
8:00 PM–9:00 PM 8
175
Prompt Entry
9:00 PM–10:00 PM 8
10:00 PM–11:00 PM 8
11:00 PM 8
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. 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 modules—Premium Service model
Prompt Entry
Agent Name Regular Agents
Talk Time
Contact Name Regular Call
Agent Name Premium Agents
Schedule 24 Hours
176
9 • CASE STUDIES
Prompt Entry
Talk Time
Contact Name Premium Call
Agent Name Utility Agents
Talk Time
Contact Name Premium Call
Agent Name Regular Servers
Members
Agent Group Regular Agents
Preference 5
Agent Group Utility Agents
Preference 5
Agent Name Premium Servers
177
Prompt Entry
Members
Agent Group Premium Agents
Preference 5
Agent Group Utility Agents
Preference 5
SCRIPTS
The routing scripts in the Premium Service model are straightforward.
Table 9.24 Script modules—Premium Service model
Module Prompt Entry
Begin Script Script Name Regular Script
Parent Group Regular Servers
End Script
Begin Script Script Name Premium Script
Parent Group Premium Servers
End Script
178
9 • CASE STUDIES
CONTACT MODULE
The contact-type definitions in the Premium Service model are very basic.
Table 9.25 Contact modules—Premium Service model
Prompt Entry
Contact Type Call
Pattern Regular Pattern
Trunk Group Regular Trunks
Contact Type Call
Contact Name Premium
Pattern Premium Pattern
Trunk Group Premium Trunks
Example 5—Teamwork model

OVERVIEW AND BUSINESS OBJECTIVE
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 who simultaneously require more than one agent to handle
(“conferencing”) or require contacts to be transferred from one agent group to
another, or both. This type of model allows 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.
The logic flow for this example is illustrated in Figure 9.6.
179
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.
180
9 • CASE STUDIES
The Teamwork model is based on a daily planning horizon and a center with a central
Table 9.26 Configuration module—Teamwork model
Prompt Entry
Trunk Definitions
Trunk Capacity 25
Inbound Contact Script Direct Routing
SCHEDULE MODULE
All agent groups in the Teamwork model work normal business hours.
Table 9.27 Agent Schedule module—Teamwork model
Prompt Entry
Timeslot 60
Shift Schedule
Agent State On-Duty
181
PATTERN MODULE
All customer requests within the Teamwork model follow a basic arrival pattern.
Table 9.28 Pattern module—Teamwork model
Prompt Entry
Pattern Daily Pattern
Timeslot 60
8:00 AM–9:00 AM 200
9:00 AM–10:00 AM 100
10:00 AM–11:00 AM 100
11:00 AM–Noon 100
Noon–1:00 PM 100
1:00 PM–2:00 PM 100
2:00 PM–3:00 PM 100
3:00 PM–4:00 PM 100
4:00 PM–5: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 customer’s folder (after-contact time) before taking a new contact.
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.
182
9 • CASE STUDIES
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 contactor’s technical questions (represented by the talk
time specified in the contact module, multiplied by the technical support agent’s 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 when 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 box at different servers, and the time distributions specified in the Contact
module, the amount of time the contact spends in various states is:
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)
Not all stages occur on every contact, and 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 modules—Teamwork model
Prompt Entry
Agent Name Reception
183
Prompt Entry
Talk Time
Contact Name Customer Request
Conference-Time 2
Multiplier
Agent Name Accounting
Talk Time
Agent Name Technical Support
Talk Time
Conference-Time 5
Multiplier
Agent Name Development
184
9 • CASE STUDIES
Prompt Entry
Talk Time
Agent Name Managers
Talk Time
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 chance that the
contact will be conferenced with Development, if available.
The individual module data for all three scripts are listed below. See Figures 9.7–9.9
below to see how the modules are connected.
185
Table 9.30 Script modules—Teamwork Model

Module Prompt Entry
Begin Script Script Name Direct Routing
Agent Group Receptionist
After Talk Time Logic
Branch Branch Type With
Branching Probability 8
Branch Type Else
Conference Agent Type Agent Group
Agent Group Accounting
Prior to Post Contact
Work Logic
Branch Type Else
Transfer to Script Script Name Manager Script
Transfer to Script Script Name Tech Script
End Script
Begin Script Script Name Manager Script
Agent Group Managers
End Script
Begin Script Script Name Tech Script
Agent Group Technical Support
186
9 • CASE STUDIES
Module Prompt Entry

After Talk Time Logic
Branch Type Else
Conference Agent Type Agent Group
Agent Group Development
Remove from Queue
Disconnect
End Script
Figure 9.7 Manager Script—Teamwork model
187
Figure 9.8 Direct-Routing Script—Teamwork model
Figure 9.9 Tech Script—Teamwork 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.
188
9 • CASE STUDIES
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 module—Teamwork model
Prompt Entry
Pattern Daily Pattern
Talk Time (See Advanced section)
Advanced
Talk-Time Distribution TRIA(0.5, 1, 5)
After-Contact Time EXPO(1)
Distribution
Example 6—Multi-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):
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.
189

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 modeling—no 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 is 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.
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
190
9 • CASE STUDIES
Table 9.32 Configuration module—Multi-site model

Prompt Entry
Trunk Definitions
Trunk Capacity 100
Inbound Contact Script 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 duty—a primary center and a secondary center to handle overflow. All
times are in Eastern Standard Time.
Table 9.33 Schedule modules—Multi-site model
Prompt Entry
Schedule Name U.S. On-Duty
Timeslot 60
Shift Schedule
Agent State On-Duty
Schedule Name Europe On-Duty
Timeslot 60
191
Prompt Entry
Shift Schedule
Agent State On-Duty
Schedule Name Japan On-Duty
Timeslot 60
Shift Schedule
Agent State On-Duty
Shift Ends at 8:00 AM
Agent State On-Duty
Shift Begins at 4:00 PM
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.
These patterns could be extended to run over 24 hours in each zone, since the
worldwide operations run around the clock.
Table 9.34 Pattern modules—Multi-site model
Prompt Entry
Pattern U.S. Daily Pattern
Timeslot 60
192
9 • CASE STUDIES
Prompt Entry
8:00 AM–9:00 AM 600
9:00 AM–10:00 AM 150
10:00 AM–11:00 AM 150
11:00 AM–Noon 150
Noon–1:00 PM 150
1:00 PM–2:00 PM 150
2:00 PM–3:00 PM 150
3:00 PM–4:00 PM 150
4:00 PM–5:00 PM 300
5:00 PM–6:00 PM 150
6:00 PM–7:00 PM 150
7:00 PM–8:00 PM 150
8:00 PM–9:00 PM 150
9:00 PM–10:00 PM 150
10:00 PM–11:00 PM 150
11:00 PM 150
Pattern Europe Daily Pattern
Timeslot 60
1:00 AM–2:00 AM 150
2:00 AM–3:00 AM 150
3:00 AM–4:00 AM 150
4:00 AM–5:00 AM 150
193
Prompt Entry
5:00 AM–6:00 AM 150
6:00 AM–7:00 AM 150
7:00 AM–8:00 AM 150
8:00 AM–9:00 AM 300
9:00 AM–10:00 AM 150
10:00 AM–11:00 AM 150
11:00 AM–Noon 150
Noon–1:00 PM 150
1:00 PM–2:00 PM 150
2:00 PM–3:00 PM 150
3:00 PM–4:00 PM 150
Pattern Japan Daily Pattern
Timeslot 60
1:00 AM–2:00 AM 150
2:00 AM–3:00 AM 150
3:00 AM–4:00 AM 150
4:00 AM–5:00 AM 150
5:00 AM–6:00 AM 150
6:00 AM–7:00 AM 150
7:00 AM–8:00 AM 150
4:00 PM–5:00 PM 600
5:00 PM–6:00 PM 150
6:00 PM–7:00 PM 150
194
9 • CASE STUDIES
Prompt Entry
7:00 PM–8:00 PM 150
8:00 PM–9:00 PM 150
9:00 PM–10:00 PM 150
10:00 PM–11:00 PM 150
11:00 PM 150
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. 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 modules—Multi-site model
Prompt Entry
Agent Name U.S. Center (Europe Center, Japan Center)
Agent Type Agent
Max Number Available 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
195
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 allows
conditional branching. The Overflow action is also featured.
Finally, note that a Queue for Agent action is necessary to complete each Overflow
action. See Figure 9.10 to see how modules are connected.
Table 9.36 Global Script —Multi-site model
Module 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
Agent Group Europe Center
Agent Group U.S. Center
Agent Group Japan Center
Wait Wait Time 2
196
9 • CASE STUDIES
Module Prompt Entry

Branch (Branch Type) If
Condition Time of Day<=8:00AM
(Branch Type) If
Condition Time of Day<=4:00PM
(Branch Type) Else
Overflow Source Group Europe Center
Destination Group Japan Center
Overflow Source Group U.S. Center
Destination Group Europe Center
Overflow Source Group Japan Center
Destination Group U.S. Center
Agent Group Japan Center
Agent Group Europe Center
Agent Group U.S. Center
End Script
Figure 9.10 Global Script—Multi-site model
197
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 module—Multi-site model
Prompt Entry
Contact Name U.S. Call (Europe Call, Japan Call)
Pattern U.S. Daily Pattern (Europe Daily Pattern, Japan Daily
Pattern)
Other examples
Outbound/blend examples
Any of the preceding examples could 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.
198
A Reserved Words
The following list contains words reserved for internal use within the Arena Contact
Center template:
Abandon Wait Time Call Times Fax

Abandoned Call Type First Available
Adherence Factor Cap First Script
After Call Time Cap Change Flowtime
Agent Availability Child Flowtime1
Agent Group ChildIndex Friday
All Conference General Expression
AllAgents Conference Time Goto
AllParents Contact Type Inbound
AllStates Copy Atb Increase
AM CR Ind
Announcement Day Infinite
AnyParents Day is InitPr
Astate Day Number InitTr
BeenSeized DayofWeek InOut
Begin Script Decrease j
Blocked Disconnect k
Both Disconnected Label_A
Break S Downtm LabelIt
Call Id DummySetEmail Longest Available
Call Id Var End Script Lunch S
Call Priority EndRotation Meeting S
199
Message Remove from Queue Tuesday

Midnight RepDays Uniform by Availability
Monday Research S uptm
New Saturday Wait_A
Next Action sbr Web Hit
No Condition sbr type Wednesday
Noon Script WeekNumber
None Search Q Yes
NxtBlk Set Type
Off Duty S Service Level
On Duty S StartRotation
Other Station Type
Overflow Sunday
Parent Talk Time
ParentIndex Temp
Parent Group Temp Atb
Pattern Terminated
PM Thursday
PQPr Time in Call Center
Pr Time of Day
Pre Work Time Remaining to Wait
Priority Time Spent Waiting
Qblock TimeofDay
Queue for Agent Total Calls
Queue Length Transfer
queuetime Transfer to Script
Probabilistic Branch Trunk Group
200
B Reports
201
202
B • REPORTS
203
204
Index
A C
abandonment  33, 53, 148 case studies  147
accessing external logic  109, 111 Bank model  155
After Talk Time logic  42 Bilingual Contact Center model  147
after-contact work  37 Multi-site model  189
agent costs  43 Premium Service model  170
Agent Group Utilization report  141 Skill-based Routing model  164
agent groups  28, 57 Teamwork model  179
Agent module  35, 57, 78 collecting statistics  61
agent selection  38, 39, 156 conditional dialog input  65
agent skill priorities  40, 82, 165 Conference module  36, 42, 122
agent skill sets  27, 78 conferencing  35, 179
agent states  44 Configuration module  32, 33, 51, 66
Agent Summary  134 consulting services  6
Cost  135 contact arrival  32
Inbound Utilization  135 contact back  32, 37, 148
Outbound Utilization  135 contact behavior  25
Usage  134 abandonment  25
Agents and Trunks report  134 After-Contact Work  25
Animate module  61, 93 Contact Back  25
animation  29 Prioritization  25
counters  29 contact centers
enabling/disabling  49 blended  198
graphs  29 outbound  198
plots  29 Contact Count Statistics report  138
Arena Contact Center template  1 Contact Counts
Arena examples  4 Contact Backs  137
arrival patterns  25 Counts  136
Assignment module  43, 128 Outcomes  136
attributes of contact  128 Contact Data panel  65
Agent module  78
B Animate module  93
Configuration module  66
Bank model  155
Contact module  84
Begin Script module  41, 58, 107
Pattern module  74
Bilingual Contact Center model  147
Report module  101
blended contact center  198
Schedule module  70
blocked contacts  32
contact information  7
Branch module  42, 124
contact life span stages  31
Buzacott, J. A.  21
abandonment  33
after-contact work  37
205
contact life span stages (cont.) G

arrival  32
global contact priorities  171
blocked  32
global variables  128
conference  36
contact back  37
disconnected  34 H
handled  34 handle time  155
leave a message  34 handled contacts  34, 139
offered  33
talk time  35 J
transfer  36
identifier  108
Contact module  32, 33, 34, 35, 37, 53,
implementing your model design  21
84
individual agents  44
contact termination  116
Contact Time Statistics report  139
Contact Times and Counts report  135 L
Contact Counts  136 lists of object names  49
Contact Times  136 logic
Other Contact Data  137 accessing external blocks  109
contact types  25
contact-routing logic  41 M
contacts leaving messages  34 McKay, K. N  21
costing of contact center operations  43 Message module  42, 60, 115
agents  43 models  10
trunk group  43 building a sample contact center
counters  128 structure  50
Crystal Reports  133 defining the objectives  16
customer service center  155 documenting and implementing  21
Customer Support Center  6 experimental design  17
input data  18
D level of detail  17
data input  18 pitfalls in the plan design  16
decision-making in a script  124 verification and validation  19
direct queueing  38 modules
Disconnect module  42, 116 Agent  35, 77
disconnected contacts  34 Animate  93
documentation of your model  21 Assignment  43, 128
duplicate (Ctrl+D)  55 Begin Script  41, 108
Branch  42, 124
E Conference  36, 42, 122
Configuration  32, 33, 66
End Script module  43, 60, 130
Contact  33, 34, 35, 37, 84
experimental model design  17
copy and paste  49
Disconnect  42, 116
End Script  43, 130
206
INDEX
modules (cont.) priorities

Message  42, 115 global  171
Overflow  42, 117 Priority module  41
Pattern  32, 74 project definition  13
Priority  41, 113 project planning  14
Queue for Agent  35, 38, 41, 109
Remove from Queue  41, 112 Q
Report  100
queue behavior  38
Schedule  70
queue construction  38
Transfer to Agent  35, 36, 42, 120
Queue for Agent module  35, 38, 41, 59,
Transfer to Script  42, 119
109
Wait  41, 112
queue ranking  38
multiple agents  40
queueing  29, 110, 155
multiple-agent schedules  171
direct  38
multiple-trunk groups  171
rank based on priority  39
Multi-site model  189
simultaneous  38
N R
no agents available  40
Remove from Queue module  41, 59, 111
repeat group  51, 65
O duplication  49
offered contact  33 replication  44
online help  5 Report module  61, 101, 133
Other Contact Data reports  201
Contact Return Counts  137 Agent Group Utilization  141
Service Level  137 Agents and Trunks  134
Overflow Count Statistics report  145 as performance measures  29
Overflow module  42, 117 Contact Count Statistics  138
outbound contact centers  198 Contact Time Statistics  139
output statistics  133 Contact Times and Counts  135
Overflow Count Statistics  145
P Parent Group Utilization  142
Trunk Group Utilization  144
Parent Group Utilization report  142
reserved words  49, 199
parent groups  28
resource proficiency level  159
pattern entry  44
resource proficiency levels  157
Pattern module  25, 32, 54, 74
resource sharing  155
patterns  76
routing scripts  26, 155
for multiple agents  171
construction  41
Pegden, C. D.  9
planning horizon  24, 70, 74, 133
preferences  40, 155 S
Premium Service model  170 Sadowski, R. P.  9
primary agent  34 Schedule module  55, 70
schedules  27
207
schedules for multiple agents  171 Smarts library  5

Schriber, T. J.  22 statistics collection  103
script examples  131 Strang, C. J.  21
Script panel  35, 38, 58, 107 systems  10
Assignment  128
Begin Script  108 T
Branch  124
talk time  35, 58
Conference  122
talk time multipliers  157, 159
Disconnect  116
Teamwork model  179
End Script  130
technical support  5
Message  115
timeslots  24, 54, 70, 74, 133
Overflow  117
training courses  6
Priority  113
transfer agent  36
Queue for Agent  109
Transfer to Agent module  35, 36, 42, 120
Remove from Queue  112
Transfer to Script module  42, 118
Transfer to Agent  120
Trunk Group Utilization report  144
Transfer to Script  119
trunk groups  26
Wait  112
costs  43
script restrictions  130
Trunk Summary  134
sensitivity analysis  19
Cost  134
served contacts  38
Usage  134
Shannon, R. E.  9
Sheppard, S.  22
shifts  72 W
simulation Wait module  41, 59, 112
advantages of  12 validation  19
definition of  9 Web support  6
the process  12 Weinburg, G. M.  22
simulation process overview  23 verification  19
simultaneous queueing  38, 40 worldwide operations  189
skill-based routing  38, 40, 82 utilization  135
agent skill priorities  40 of Agent Group resources  141, 155
preferences  40 of Parent Group resources  142
simultaneous queueing  40 of Trunk Group resources  144
Skill-based Routing model  164
208

Contact Center Template User's Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Contact Center Template User's Guide PDF

Uploaded by

Copyright:

Available Formats

®

Arena Contact Center

1 • Welcome to Arena Contact Center Template 1

6 • The Contact Data Panel 65

7 • The Script Panel 107

9 • Case Studies 147

A • Reserved Words 199

Simulation of contact centers

The Arena Contact Center template: A

Where can I go for help?

Refer to the user’s guides

Explore our examples

Use the Smarts library

Get phone support

ARENA TECHNICAL SUPPORT INCLUDES:

International technical support is provided by the global representatives. For contact

Get Web support

Refer to the Arena Web site

Get consulting services

Support E-mail: Arena-Support@ra.rockwell.com

Systems and models

conceptualizations of any particular real-world system—and thereby several different

The simulation process

4. Conceptual Model Formulation. Developing a preliminary model either

Problem definition and project planning

We begin our analysis by collecting enough information and data to provide an

should build a model without having an explicit experimental goal in mind.

Style definition and model formulation

Verification and validation

Documentation and implementation

Schriber, T. J.(1987), “The Nature and Role of Simulation in the Design of

The basic components of this process are:

The relationships between these components are illustrated below.

4. Contact prioritization within queues (ranking)

Agent Skill Sets

Different stages in the contact life span

Figure 4.1 The path of a contact before processing begins

Figure 4.2 The path of a contact after processing begins

Contact arrival (required)

RELEVANT MODULES AND RELATED CONCEPTS

Blocked contacts (required)

RELEVANT MODULES AND RELATED CONCEPTS

Offered contacts (required)

RELEVANT MODULES AND RELATED CONCEPTS

Abandoned contacts (optional)

 Abandonment is defined in the Abandonment section of the Contact module.

Disconnected contacts (optional)

Contacts leaving messages (optional)

RELEVANT MODULES AND RELATED CONCEPTS

Handled contacts (required)

RELEVANT MODULES AND RELATED CONCEPTS

Talk time (required)

RELEVANT MODULES AND RELATED CONCEPTS

A conference is done in addition to talk time. The length of the conference is

RELEVANT MODULES AND RELATED CONCEPTS

After-contact work (optional)

RELEVANT MODULES AND RELATED CONCEPTS

Contact back (optional)

MULTIPLE AGENTS AVAILABLE

Routing script construction

Queue for Agent

Remove from Queue

Advanced configuration agents