Download - Contact Center Template User's Guide
-
7/31/2019 Contact Center Template User's Guide
1/217
USERS GUIDE
PUBLICATION ARENCC-UM001H-EN-PJanuary2012Supersedes Publication ARENCC-UM001G-EN-P
PN-111657
ArenaContact Center
-
7/31/2019 Contact Center Template User's Guide
2/217
i
Contact Rockwell Automation Customer Support Telephone 1-440-646-3434Online 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. Anyreproduction 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, WindowsME, Windows NT, Windows 2000, Windows Server 2003, and Windows XP are either registered trademarks ortrademarks 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 theUnited 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 products performance may be affected by system
configuration, the application being performed, operator control, maintenance, and other related factors. RockwellAutomation is not responsible for these intervening factors. The instructions in this document do not cover all thedetails 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 products implementation may vary amongusers.
This document is current as of the time of release of the product; however, the accompanying software may havechanged since the release. Rockwell Automation, Inc. reserves the right to change any information contained in thisdocument or the software at anytime without prior notice. It is your responsibility to obtain the most current informationavailable from Rockwell when installing or using this product.
Version: 14.00.00
Modified: January 18, 2012 11:02:10 AM
http://www.rockwellautomation.com/http://www.rockwellautomation.com/http://www.rockwellautomation.com/http://www.rockwellautomation.com/ -
7/31/2019 Contact Center Template User's Guide
3/217
ii
-
7/31/2019 Contact Center Template User's Guide
4/217
iii
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 systemfor contact centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Refer to the users guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Use the Smarts library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Get Web support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Refer 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 General Concepts 23
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Planning horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Contact types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Contents
-
7/31/2019 Contact Center Template User's Guide
5/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
iv
Arrival pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Trunk Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Routing Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Agent Skill Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Data 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) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Contacts 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Queue 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
-
7/31/2019 Contact Center Template User's Guide
6/217
CONTENTS
v
Wait. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Overflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Transfer to Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Transfer to Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Conference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Branch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
End Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Agent costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Trunk costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Miscellaneous features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Pattern entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Agent states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Individual 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Model construction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Running the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 The Contact Data Panel 65
Configuration module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Schedule module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Pattern module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
-
7/31/2019 Contact Center Template User's Guide
7/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
vi
Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Contact 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Branch 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Contact 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
-
7/31/2019 Contact Center Template User's Guide
8/217
CONTENTS
vii
9 Case Studies 147
Purposes of cases and examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Example 1Bilingual 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 2Bank model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 155
The data detail for the Bank example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Example 3Skill-based Routing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 164
The data detail for the Skill-based Routing example . . . . . . . . . . . . . . . . . . . . . 165
Example 4Premium Service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 171
The data detail for the Premium Service example . . . . . . . . . . . . . . . . . . . . . . . 172Example 5Teamwork model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
The data detail for the Teamwork example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Example 6Multi-site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 190
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
-
7/31/2019 Contact Center Template User's Guide
9/217
-
7/31/2019 Contact Center Template User's Guide
10/217
1
1 Welcome to Arena Contact CenterTemplateWhat is the Arena Contact Center template?
The Arena Contact Center template is a simulation system developed by RockwellAutomation, Inc., for the performance analysis of contact centers. It is built on
Rockwell Automations 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. Afamiliarity 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:
Ive got my staffing budget for the next fiscal year, but I dont know how manypeople I need to make service levels, what shifts to hire for, or what skills to train
my workers on.
Service levels look pretty good right now, but our peak season is coming up.
What I dont know is how badly our service levels and abandonment rates will
suffer if our forecasts turn out to be too low.
-
7/31/2019 Contact Center Template User's Guide
11/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
2
Our service levels are in bad shape. We are considering either hiring anoutsourcer to help share the handling load or extending our hours. I wish I knew
where to get the most bang for the buck.
My telecomm guy has a new set of routing scripts to make use of some of our
advanced phone switch capabilities. I wonder how this is going to impact our
average speed of answer and our staff utilization.
Marketing has come up with a new program giving our preferred customers a
special priority when they contact us with questions. What Im worried about ishow this new program will affect the waiting times that the rest of our customers
experience.
Weve been asked to provide telephone service and support for another business
unit. Theyre asking us how much staff we need to hire or cross-train in order to
handle this increased load.
Contact center managers have traditionally approached such problems using various
methods, including gut feel estimates, back-of-the-envelope calculations, elaboratespreadsheets, 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, customerabandonment, 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.
-
7/31/2019 Contact Center Template User's Guide
12/217
1 WELCOME TOARENA CONTACT CENTER TEMPLATE
3
The Arena Contact Center template: Acustom-designed simulation system forcontact 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.
-
7/31/2019 Contact Center Template User's Guide
13/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
4
Use standard contact center terminology wherever possible to make the modelbuilding 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 Arenas development
environment to create a focused and easy-to-use tool for contact center managers and
analysts.
Where can I go for help?
Our commitment to your success starts with the suite of learning aids and assistance
we provide for Arena. Whether youre new to simulation or a seasoned veteran using
a new tool, youll quickly feel at home with the Arena Contact Center template.
Refer to the users guides
The documentation set includes this manual,Arena Contact Center Template Users
Guide, which cover the product basics; theArena Users 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 CONVENTIONSThroughout 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, clickOK).
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 Arenas examples, go to Help > Arena
Help. On the Contents tab, choose Model Building Basics, and then select Viewing
Arena Example Models.
-
7/31/2019 Contact Center Template User's Guide
14/217
1 WELCOME TOARENA CONTACT CENTER TEMPLATE
5
Get helpOnline help is always at your fingertips! Arena incorporates the latest in help
features, including Whats This? help that displays a brief description of fields in
dialog boxes, context-sensitive help on menu and toolbar buttons, and a help button
on each of Arenas modules. See the Arena Help table of contents and index for a list
of all help topics.
Use the Smarts libraryAs you craft models of your own systems processes, use our Smarts library to
explore how to best use Arena. This suite of tutorial models covers topics ranging
from modeling resources to animation techniques. The library is organized into
categories to help you find the right model with ease. When youre wondering how to
take the next step in your model, browse the Smarts library for a ready-made solution.
For a list of categories and their related Smarts, go to Help > Arena Help. On the
Contents tab, first clickModel 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 softwares 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.
-
7/31/2019 Contact Center Template User's Guide
15/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
6
International technical support is provided by the global representatives. For contactinformation 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 oursupport 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 cant find the answer you need, contact your local representative or Arenatechnical 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 thats right for you! Simply contact ourconsulting 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.
-
7/31/2019 Contact Center Template User's Guide
16/217
1 WELCOME TOARENA CONTACT CENTER TEMPLATE
7
Contact usWe 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 Users Group on
LinkedIn.
Support E-mail: [email protected] Phone: 1.440.646.3434 (options 3 & 7)
General E-mail: [email protected]
U. S. Sales Phone: 1.724.741.4000
URL: www.ArenaSimulation.com
URL: www.rockwellautomation.com
-
7/31/2019 Contact Center Template User's Guide
17/217
-
7/31/2019 Contact Center Template User's Guide
18/217
9
2 Introduction to SimulationThis chapter contains excerpts from the simulation textbook entitledIntroduction to
Simulation Using SIMAN, Second Edition (McGraw-Hill, 1995) written by C. Dennis
Pegden, Randall P. Sadowski, and Robert E. Shannon.
Simulation definedSimulation 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 Websters Collegiate Dictionary, is to feign, to obtain the
essence of, without the reality. According to Schriber [1987], Simulation involves
the modeling of a process or system in such a way that the model mimics the response
of the actual system to events that take place over time. We will define simulation as
the process of designing a model of a real system and conducting experiments with
this model for the purpose of understanding the behavior of the system,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 experimentaland 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. Bysystem, 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.
-
7/31/2019 Contact Center Template User's Guide
19/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
10
Systems and modelsThe 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 theprogress of our ability to develop and use models.
One of the major elements required in attacking any problem is the construction and
use of a model. We use models because we want to learn something about some real
system that we cannot observe or experiment with directlyeither because the
system does not yet exist, or because it is too difficult to manipulate. A carefully
conceived model can strip away the complexity, leaving only that which the analyst
finds important. Such a model can take many forms, but one of the most usefulandcertainly the most often usedis 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
-
7/31/2019 Contact Center Template User's Guide
20/217
2 INTRODUCTION TO SIMULATION
11
conceptualizations of any particular real-world systemand thereby several differentmodelscan 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 comparethat is, to provide a logical way offorecasting 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
-
7/31/2019 Contact Center Template User's Guide
21/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
12
that isnt available from known sources. The following list describes some of thebenefits 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 reallyoperates as opposed to how everyone thinks it operates.
New situations, about which we have limited knowledge and experience, can be
manipulated in order to prepare for theoretical future events. Simulations great
strength lies in its ability to let us explore what if questions.
The simulation processThe 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.
-
7/31/2019 Contact Center Template User's Guide
22/217
2 INTRODUCTION TO SIMULATION
13
4. Conceptual Model Formulation. Developing a preliminary model eithergraphically (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 thesimulation.
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 theproblem 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 cant necessarily make the final decision, but who is responsible for
making recommendations. In such a case, the results of the study may have to serve
two purposes simultaneously: helping the sponsor to formulate the recommendations;
and justifying, supporting, and helping to sell those recommendations.
-
7/31/2019 Contact Center Template User's Guide
23/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
14
We begin our analysis by collecting enough information and data to provide anadequate understanding of both the problem and the system to be studied. A typical
project begins with the description of the situation to be modeled in a general and
imprecise way, in terms such as service levels, agent utilization, abandonment rates,
or other key system performance measures. We must view the problem description as
a set of symptoms requiring diagnosis. We begin, therefore, by diagnosing the
symptoms; then we define the problem; and, finally, we formulate a model.
To make that diagnosis, we must become thoroughly familiar with all relevant aspects
of the organizations operations, including influential forces (or factors) outside theorganization 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 studythat 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?
-
7/31/2019 Contact Center Template User's Guide
24/217
2 INTRODUCTION TO SIMULATION
15
Competent project manager and team members. Are we assured of having thenecessary skills and knowledge available for successful completion of the
project?
Responsiveness to the clients. Have all potential users of the results been
consulted and regularly apprised of the projects progress?
Adequate communication channels. Are we continually concerned that
sufficient information is available on project objectives, status, changes, user or
client needs, and so on, to keep everyone (team members, management, andclients) 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 producesthe best overall system response.
Functional relations: establishing the nature of the relationships among one or
more significant factors and the systems 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 models goal is to
evaluate a proposed (or existing) system in an absolute sense, then the model must be
accurate; and there must be a high degree of correspondence between the model and
the real system. On the other hand, if the goal for a model is the relative comparison
of two or more systems or operating procedures, the model can be valid in a relative
sense even though the absolute magnitude of responses varies widely from that which
would be encountered in the real system. The entire process of designing the model,
validating it, designing experiments, and drawing conclusions from the resulting
experimentation must be closely tied to the specific purpose of the model. No one
-
7/31/2019 Contact Center Template User's Guide
25/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
16
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-nents 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 realitybut only to the point where there is no
significant loss of accuracy of outputs with respect to the studys objectives.
We want to design a model of the real system that neither oversimplifies the system to
the point where the model becomes trivial (or worse, misleading) nor carries so much
detail that it becomes clumsy and prohibitively expensive. The most significant danger
lies in having the models become too detailed and including elements that contribute
little or nothing to understanding the problem. Frequently, the analyst includes too
much detail, rather than too little. The inexperienced tend to try to transfer all the
detailed difficulties in the real situation into the model, hoping that the computer will
somehow solve the problem.
This approach is unsatisfactory: it increases programming complexity (and theassociated costs for longer experimental runs), and it dilutes the truly significant
-
7/31/2019 Contact Center Template User's Guide
26/217
2 INTRODUCTION TO SIMULATION
17
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 Paretos law, in every group or
collection of entities there exist a vital few and a trivial many. In fact, 80% of system
behavior can be explained by the action of 20% of its components. Nothing really
significant happens unless it happens to the significant few. Our problem in designingthe 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 studys goal orpurpose.
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
-
7/31/2019 Contact Center Template User's Guide
27/217
-
7/31/2019 Contact Center Template User's Guide
28/217
2 INTRODUCTION TO SIMULATION
19
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 todo? 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 theother 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
-
7/31/2019 Contact Center Template User's Guide
29/217
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
20
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 users 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 systemsbehavioral data?
Does the simulation model user have confidence in the models results?
Consequently, we are concerned with tests that fall into three groups: tests of model
structure, tests of model behavior, and tests of the policy implications of the model.
Because a model is constructed for a specific purpose, its adequacy or validity can
only be evaluated in terms of that purpose. We try to build a model that creates thesame 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 communicatethe basis for confidence in a model to a target audience. Unless that confidence can be
transferred, the models usefulness will never be realized. Thus, through verification
testing, we develop personal confidence in the model and, through validation
measures, transfer that confidence to others.
We must realize that there are degrees of validation; it is not merely an either-or
notion. Validation is not a binary decision variable indicating whether the model is
valid or invalid. No one or two tests can validate a simulation model. Rather,
confidence in the usefulness of a model must gradually accumulate as the model
passes more tests and as new points of correspondence between model and reality are
found. Validation testing occurs continually in the process of designing, constructing,
and using the model.
We should also remember that verification and validation are never really finished. If the
model is to be used for any period of time, the data and the model itself will need periodic
review to ensure validity. Verification and validation are intertwined and proceed
throughout the study. They are not tacked on toward the end of the study; rather, they are
2 INTRODUCTION TO SIMULATION
-
7/31/2019 Contact Center Template User's Guide
30/217
2 INTRODUCTION TO SIMULATION
21
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
models useful life and greatly increase the chances that recommendations based on
the model will be accepted. Good documentation facilitates modification and ensuresthat the model can be usedeven if the services of the original developers are no
longer available. In addition, careful documentation can help us to learn from
previous mistakes; it may even provide a source of submodels that can be used again
in future projects.
Amazingly, modelers often spend a great deal of time trying to find the most elegant
and efficient ways to model a system, and then they throw together a report for the
sponsor or user at the last minute. If the results are not clearly, concisely, andconvincingly 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, inProceedings of the 1986 Winter
Simulation Conference, Washington, D.C., pp. 485-493.
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
-
7/31/2019 Contact Center Template User's Guide
31/217
ARENA CONTACT CENTER TEMPLATE USER S GUIDE
22
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.
-
7/31/2019 Contact Center Template User's Guide
32/217
23
3 General ConceptsThis 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. Tocreate 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
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
-
7/31/2019 Contact Center Template User's Guide
33/217
24
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 Timeslots) need to be specified. Animation
and performance measure reporting are also important components of models.
Planning horizon
Theplanning 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.
3 GENERAL CONCEPTS
-
7/31/2019 Contact Center Template User's Guide
34/217
25
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 theassociated 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 centers
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
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
-
7/31/2019 Contact Center Template User's Guide
35/217
26
contacts during the 10:00 AM-11:00 AM timeslot. The Poisson arrival rate for the
timeslot is 0.25 (60/240) or, on average, one contact every 15 seconds.
Data sources
Arrival pattern data is available either from contact center ACD databases or from a
contact centers tracking system.
Trunk GroupsTrunk 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
centers 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 nothingwaiting)
2. Conditional route branching (caller-entered information, center dynamics)
3. Allocation of contacts into queues (single or simultaneous) or message ports
3 GENERAL CONCEPTS
-
7/31/2019 Contact Center Template User's Guide
36/217
27
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, CallControl Table). These scripts specify the actions, activities, and states that each
contact undergoes as it attempts to reach an agent.
The process of creating routing scripts that match the behavior of your ACD switch
and assigning these scripts to specific contact names is described in more detail in
Chapter 6.
Agent Skill Sets
Agent Skill Sets are composed of three elements that define how particular contacts
are processed. The agents repertoire of handling skills specifies what contacts the
agent is sufficiently skilled to handle, the priority (or order) in which the agent will
perform available work, and the agents proficiency in each contact name, expressed
as a multiplier of average talk time for the contact name.
Data sources
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.
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
-
7/31/2019 Contact Center Template User's Guide
37/217
28
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. AnAgent Group represents a
group of agents within the contact center who have the same skill sets and follow thesame 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
AParent 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.
3 GENERAL CONCEPTS
-
7/31/2019 Contact Center Template User's Guide
38/217
29
QueuesQueues 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 moduleslocated 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 animatespecific 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 quantifythe impact of various changes on contact center operations. Contact center reports are
available for:
contact counts
contact times
agent utilization
trunk utilization
overflowThe output of these reports is discussed in detail in Chapter 7.
-
7/31/2019 Contact Center Template User's Guide
39/217
-
7/31/2019 Contact Center Template User's Guide
40/217
31
4 FeaturesThis chapter is intended to provide a description of all Arena Contact Center templatefeatures. 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
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
-
7/31/2019 Contact Center Template User's Guide
41/217
32
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 backfollowing a specified delay.
4 FEATURES
-
7/31/2019 Contact Center Template User's Guide
42/217
33
RELEVANT MODULES AND RELATED CONCEPTS
Trunk groups are defined in the Configuration module and associated with a
contact name in the Contact module.
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 offeredtothe contact center for service. The newly offered contact then begins to follow the
routing logic specified in its associated script.
RELEVANT MODULES AND RELATED CONCEPTS
Trunk groups are defined in the Configuration module and associated with a
contact name in the Contact module.
Scripts are defined by connecting a series of modules located on the Script paneland 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)
Abandonmentoccurs 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.
RELEVANT MODULES AND RELATED CONCEPTS 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.
Contact back is defined in the Contact Back section of the Contact module. It is
described in greater detail later in this chapter.
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
-
7/31/2019 Contact Center Template User's Guide
43/217
34
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