Contact Center Template User's Guide

Arena Contact Center
USERS GUIDE
PUBLICATION ARENCC-UM001H-EN-PJanuary 2012
Supersedes Publication ARENCC-UM001G-EN-P PN-111657
Contact Copyright Notice
Trademark Notices Other Trademarks
Rockwell Automation Customer Support Telephone 1-440-646-3434 Online Support http://www.rockwellautomation.com/support 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. Arena, Rockwell Automation, and SIMAN are registered trademarks of Rockwell Automation, Inc. 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. 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. 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 products 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
Warranty
ii
Contents
1 Welcome to Arena Contact Center Template
What is the Arena Contact Center template? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulation of contact centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Arena Contact Center template: A custom-designed simulation system for contact centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Refer to the users guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Use the Smarts library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get Web support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Refer to the Arena Web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Get consulting services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1 1 1 3 4 4 4 5 5 5 6 6 6 6 7
2 Introduction to Simulation
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
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planning horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
23 24 24 25 25
iii
ARENA CONTACT CENTER TEMPLATE USERS GUIDE
Arrival pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trunk Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agent Skill Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agent Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parent Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Animation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance measures/reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25 26 26 26 26 27 27 27 27 28 28 28 28 28 29 29 29
4 Features
Different stages in the contact life span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact arrival (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Blocked contacts (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Offered contacts (required). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abandoned contacts (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disconnected contacts (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contacts leaving messages (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handled contacts (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Talk time (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conference (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transfer (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . After-contact work (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact back (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Queue behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Queue construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Queue ranking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agent selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Skill-based routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing script construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Begin Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Queue for Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remove from Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31 32 32 33 33 34 34 34 35 35 36 37 37 38 38 39 39 40 41 41 41 41
iv
CONTENTS
Wait. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transfer to Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transfer to Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Branch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agent costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trunk costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Miscellaneous features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pattern entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agent states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Individual agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced configuration agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41 41 42 42 42 42 42 42 42 43 43 43 43 43 44 44 44 44 44
5 Getting Started
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading and running an existing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General modeling skills and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Panels and modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module copy and paste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Repeat group duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disable animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building an Arena Contact Center template model . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the business application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Model construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
47 47 48 48 49 49 49 49 49 50 50 50 51 62 63
6 The Contact Data Panel
65
Configuration module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Schedule module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Pattern module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Contact module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Animate module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Report module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7 The Script Panel

Begin Script module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Queue for Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Remove from Queue module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wait module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Priority module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disconnect module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overflow module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transfer to Script module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transfer to Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conference module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Branch module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Assignment module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . End Script module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Script restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arena Contact Center template script examples . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107
107 109 111 112 113 115 116 117 118 120 122 124 128 130 130 131
8 Reports
Agents and Trunks report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trunk Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agent Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact Times and Counts report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Contact Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact Count Statistics report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contact Time Statistics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agent Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parent Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trunk Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overflow Count Statistics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
133
134 134 134 135 135 136 136 137 138 139 141 142 144 145
vi
CONTENTS
9 Case Studies
Purposes of cases and examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 1Bilingual Contact Center model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . The data detail for the Bilingual Contact Center example . . . . . . . . . . . . . . . . . Example 2Bank model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . The data detail for the Bank example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 3Skill-based Routing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . The data detail for the Skill-based Routing example . . . . . . . . . . . . . . . . . . . . . Example 4Premium Service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . The data detail for the Premium Service example . . . . . . . . . . . . . . . . . . . . . . . Example 5Teamwork model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The data detail for the Teamwork example . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example 6Multi-site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . The data detail for the Multi-site example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outbound/blend examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
147
147 147 147 147 149 155 155 155 157 164 164 165 170 170 171 172 179 180 189 189 190 190 198 198
A Reserved Words B Reports Index
199 201 205
vii
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 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. 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:
Ive got my staffing budget for the next fiscal year, but I dont know how many people I need to make service levels, what shifts to hire for, or what skills to train my workers on. Service levels look pretty good right now, but our peak season is coming up. What I dont know is how badly our service levels and abandonment rates will suffer if our forecasts turn out to be too low.
Our service levels are in bad shape. We are considering either hiring an outsourcer to help share the handling load or extending our hours. I wish I knew where to get the most bang for the buck. My telecomm guy has a new set of routing scripts to make use of some of our advanced phone switch capabilities. I wonder how this is going to impact our average speed of answer and our staff utilization. Marketing has come up with a new program giving our preferred customers a special priority when they contact us with questions. What Im worried about is how this new program will affect the waiting times that the rest of our customers experience. Weve been asked to provide telephone service and support for another business unit. Theyre asking us how much staff we need to hire or cross-train in order to handle this increased load.
Contact center managers have traditionally 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.
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.
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 systembased 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; the Arena 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
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 Arenas examples, go to Help > Arena Help. On the Contents tab, choose Model Building Basics, and then select Viewing Arena Example Models.
Get help
Online help is always at your fingertips! Arena incorporates the latest in help features, including Whats This? help that displays a brief description of fields in 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 library

As 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 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 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.
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 cant 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 thats right for you! Simply contact our consulting services group to discuss how we can help you achieve success in your simulation efforts.
Get consulting services

Rockwell Automation provides expert consulting and turnkey implementation of the entire Arena product suite. Please contact your local representative for more information.
Contact us
We strive to help all of our customers become successful in their manufacturing improvement efforts. 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: 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
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 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 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.
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 directlyeither because the system does not yet exist, or because it is too difficult to manipulate. A carefully conceived model can strip away the complexity, leaving only that which the analyst finds important. Such a model can take many forms, but one of the most usefuland certainly the most often usedis simulation. 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 contemporary practice that we tend to take it for granted. The systems approach tries to consider total system performance rather than simply concentrating on the parts [Weinberg, 1975]; it is based on our recognition that, even if each element or subsystem is optimized from a design or operational viewpoint, overall performance of the system may be suboptimal because of interactions among the parts. The increasing complexity of modern systems and the need to cope with this complexity underscore the need for engineers and managers to adopt a systems approach to thinking. Although complex systems and their environments are objective (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 systemand thereby several different modelscan 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 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 isnt available from known sources. The following list describes some of the benefits associated with simulation.
In a contact center, the impact of new types of contacts, new agent schedules, modified contact priorities, contact volumes, and other key inputs can be explored without disrupting ongoing operations. New routing scripts or transfer logic can be tested before committing resources to implementation. Hypotheses about how or why certain phenomena occur can be tested for feasibility. Time can be controlled: it can be compressed, expanded, 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. Simulations great strength lies in its ability to let us explore what if questions.
The simulation process

The essence or purpose of simulation modeling is to help the ultimate decision maker solve a problem. Therefore, to learn to be a good simulation modeler, you must merge good problem-solving techniques with good software engineering practice. The following steps should be taken in every simulation study. 1. Problem Definition. Defining the goals of the study clearly so that we know the purpose; 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 success and failure. Simulation studies are initiated because a decision maker or group of decision makers face a problem and need a solution. Often the project is initiated by someone who cant necessarily make the final decision, but who is responsible for making recommendations. In such a case, the results of the study may have to serve two purposes simultaneously: helping the sponsor to formulate the recommendations; and justifying, supporting, and helping to sell those recommendations.
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 organizations operations, including influential forces (or factors) outside the organization and the subjective and objective aspects of the problem. Minimally, we should perform the following steps. 1. Identify the primary decision maker(s) and the decision-making process relative to the system being studied. 2. Determine the relevant objectives of each of those responsible for some aspect of the decision. 3. Identify other participants in the final decision (especially those likely to oppose changes in the system) and determine their objectives and vested interests. 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?
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 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, 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 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
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 components. This process entails itemizing all system components that contribute to the effectiveness or ineffectiveness of its operation. After we have specified a complete list, we determine whether each component should be included in our model; this determination may be difficult because, at this stage of model development, a components significance to the overall goal is not always clear. One of the key questions to be answered is whether a particular component should be considered part of the model or part of the outside environment, which is represented as inputs to the model. In general, we have little difficulty deciding on the output variables. If we have done a good job specifying the goals or purposes of the study, the required output variables become apparent. The real difficulty arises when we try to determine which input and status variables produce the effects observed and which can be manipulated to produce the effects desired. We also face conflicting objectives. On the one hand, we try to make the model as simple as possible for ease of understanding, ease of formulation, and computational efficiency. On the other hand, we try to make the model as accurate as possible. Consequently, we must simplify realitybut only to the point where there is no significant loss of accuracy of outputs with respect to the studys objectives. We want to design a model of the real system that neither oversimplifies the system to the point where the model becomes trivial (or worse, misleading) nor carries so much detail that it becomes clumsy and prohibitively expensive. The most significant danger lies in having the models become too detailed and including elements that contribute little or nothing to understanding the problem. Frequently, the analyst includes too much detail, rather than too little. The inexperienced tend to try to transfer all the detailed difficulties in the real situation into the model, hoping that the computer will somehow solve the problem. This approach is unsatisfactory: it increases programming complexity (and the associated costs for longer experimental runs), and it dilutes the truly significant
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 Paretos law, in every group or collection of entities there exist a vital few and a trivial many. In fact, 80% of system behavior can be explained by the action of 20% of its components. Nothing really significant happens unless it happens to the significant few. Our problem in designing the simulation model is to ensure that we correctly identify those few vital components and include them in our model. Once we have tentatively decided which components and variables to include in our model, we must then determine the functional relationships among them. At this point, we are trying to show the logic of the model; 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 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 investigators 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 contactvolume 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 realworld 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 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 systems behavioral data? Does the simulation model user have confidence in the models results?
Consequently, we are concerned with tests that fall into three groups: tests of model structure, tests of model behavior, and tests of the policy implications of the model. Because a model is constructed for a specific purpose, its adequacy or validity can only be evaluated in terms of that purpose. We try to build a model that creates the same problems and behavioral characteristics as the process or system being studied. Validation occurs throughout model development, beginning with the start of the study and continuing as the model builder accumulates confidence that the model behaves plausibly and generates symptoms or modes of behavior seen in the real system. Validation then expands to include persons not directly involved in constructing the model. Validation is a communication process requiring the model builder to communicate the basis for confidence in a model to a target audience. Unless that confidence can be transferred, the models usefulness will never be realized. Thus, through verification testing, we develop personal confidence in the model and, through validation measures, transfer that confidence to others. We must realize that there are degrees of validation; it is not merely an either-or notion. Validation is not a binary decision variable indicating whether the model is valid or invalid. No one or two tests can validate a simulation model. Rather, confidence in the usefulness of a model must gradually accumulate as the model passes more tests and as new points of correspondence between model and reality are found. Validation testing occurs continually in the process of designing, constructing, and using the model. We should also remember that verification and validation are never really finished. If the model is to be used for any period of time, the data and the model itself will need periodic review to ensure validity. Verification and validation are intertwined and proceed throughout the study. They are not tacked on toward the end of the study; rather, they are
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 running of the model and for analyzing the results; the final elements in the simulation effort are implementation and documentation. No simulation project can be considered successfully completed until its results have been understood, accepted, and used. Although documentation and implementation are obviously very important, many studies fall short in the reporting and explaining of study results. Documentation and reporting are closely linked to implementation. Careful and complete documentation of model development and operation can lengthen the models useful life and greatly increase the chances that recommendations based on the model will be accepted. Good documentation facilitates modification and ensures that the model can be usedeven if the services of the original developers are no longer available. In addition, careful documentation can help us to learn from previous mistakes; it may even provide a source of submodels that can be used again in future projects. Amazingly, modelers often spend a great deal of time trying to find the most elegant and efficient ways to model a system, and then they throw together a report for the sponsor or user at the last minute. If the results are not clearly, concisely, and convincingly presented, they will not be used. If the results are not used, the project is a failure. Presenting results is as critical a part of the study as any other part, and it merits the same careful planning and design. Several issues should be addressed in model and study documentation: appropriate vocabulary (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
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 Timeslots) need to be specified. Animation and performance measure reporting are also important components of models.
Planning horizon
The planning horizon is defined as the time period that is being examined by a particular simulation model. The planning horizon is typically one day, one week, or one month.
Timeslots
The planning horizon is broken into specific timeslots for data specification and collection. These intervals are typically 30 minutes or one hour long.
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 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
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 centers 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 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
26
3 GENERAL CONCEPTS
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 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.
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
3 GENERAL CONCEPTS
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
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
RELEVANT
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 offered to the contact center for service. The newly offered contact then begins to follow the routing logic specified in its associated script. RELEVANT
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 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. RELEVANT

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.
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. RELEVANT
Contacts may only be disconnected via the Disconnect module located on the Script panel. Contact back is defined in the Contact Back section of the Contact module. It is 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. RELEVANT
Contacts may only be directed to leave a message via the Message module located on the Script panel. Contact back is defined in the Contact Back section of the Contact module. It is 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
RELEVANT

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. RELEVANT
Expected talk time is specified in the Contact module. The distribution for talk time can be overridden in the Advanced section of the Contact module. Adjustments to talk time to reflect agent proficiency are made through multipliers defined within the Talk Time section of the Agent module.
Conference (optional)
Conferencing describes the situation where an agent can include an additional agent (like a supervisor) for assistance in contact resolution. Conference is modeled using the Conference module located on the Script panel. This module is for use within the Queue for Agent module only. The Queue for Agent module has three Advanced features that allow external logic to be specified at three different times; After Seizing Agent, After Talk Time, and Prior to Post Contact Work. The Conference module must be used with the After Talk Time option. By connecting this module to the special exit point created for the advanced Queue for Agent option, a contact can be conferenced with another agent after the primary agents talk time is complete.
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. RELEVANT
Contacts requiring conference are specified by the contacts script. The contact must be directed to a Conference module. This module can only be used in the After Talk Time external logic of a Queue for Agent module. Specifics of which agent to be included in the conference and the conference time are detailed in the Conference module from the Script panel.
Transfer (optional)
Transfer describes the situation where the primary agent routes a contact to a transfer agent who then takes over complete responsibility for the contact. Transfer is modeled by using the Transfer to Agent module in a contacts script. The Transfer to Agent module is for use within the Queue for Agent module only. The Queue for Agent module has three Advanced features that allow external logic to be specified at three different times: After Seizing Agent, After Talk Time, and Prior to Post Contact Work. The Transfer to Agent module must be used with the Prior to Post Contact Work option. By connecting this module to the special exit point created for the advanced Queue for Agent option, a contact can be directed to another agent after the first agents tasks are complete. Multiple-agent transfer can be modeled by connecting a series of Transfer to Agent modules. The original agent is released before the contact is transferred to the next agent. Each transfer is performed in series. Therefore, the primary agent does not participate in the next (transfer) agents activities, and so on. Transfer takes place immediately following the completion of talk time. Transfer is an optional consideration in that a contact will only be transferred if the transfer agent is available immediately to receive the contact (that is, the contact will not be re-queued).
36
4 FEATURES
RELEVANT
Contacts potentially requiring transfer are specified by the contacts script. The contact must be directed to a Transfer to Agent module. This module can only be used in the Prior to Post Contact Work external logic of a Queue for Agent module. Specifics of 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). RELEVANT
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. RELEVANT

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 contacts priority will revert to its pre-queue priority upon leaving a queue and revert to its initial priority when contacting back.
Agent selection
Once a contact has reached the front of its queue, the only remaining consideration is which agent resource to select for service. All agents within an agent group are identical. Therefore, if the queue belongs to an agent group, resource selection is quite simplethe contact is assigned to the next available agent. If the queue belongs to a parent group, resource selection is considerably more complicated, although it falls 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 agents 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 scripts 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 contacts 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 Arenas 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
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 Arenas 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 contacts routing script. A script is a sequence of actions that controls the flow of a contact through the centers system. The Script modules are:

Begin Script Queue for Agent Remove from Queue Wait Priority Message Disconnect Overflow Transfer to Script Transfer to Agent Conference Branch Assignment End Script
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 companys 24-line phone bank. From a business perspective, there are a limited number of potential donors, so the number lost due to busy signals or abandonment must be minimized. Therefore, from a contact center perspective, the key performance measures are blocked contacts and average speed of answer. Once the basic model is in place, it will be used to assess the wait time faced by donors and 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
5 GETTING STARTED
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 INFRASTRUCTURETHE 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 definitions 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 moduletrunk definitions
The features described in the Advanced section of the Configuration module in Chapter 6 are accessed by clicking on the Advanced button, but will not be needed in this simple example. Finally, click OK to accept the module into the simulation model. The planning horizon is now documented in the model window.
52
5 GETTING STARTED
DEFINING
THE CONTACTSTHE
CONTACT
MODULE
The Contact module is used to define the characteristics of the donor calls that are responding to the radio telethon. Their expected talk time is defined along with the associated contact pattern and trunk group. An abandonment model is also specified that 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 PATTERNTHE
PATTERN
MODULE
The Pattern module is the mechanism for describing the expected contact volumes for all timeslots within the planning horizon. In the Telethon model, we expect calls to be distributed evenly throughout the on-air pledge-solicitation period. 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
5 GETTING STARTED
A quick method of completing the set of arrival patterns is to duplicate entries using Ctrl+D. First, complete all of the entries for the Monday arrival pattern. Then hit Ctrl+D simultaneously. Each hit of Ctrl+D will create a duplicate of the highlighted arrival pattern. Then simply edit the duplicate entry and change the Day of the Week.
Note: You can use Ctrl+D to duplicate the initial daily pattern for all weekdays.
Figure 5.6 Pattern moduleDaily Arrival Pattern
DEFINING
THE TELETHON HOURSTHE
SCHEDULE
MODULE
The volunteer group fielding donor calls at the radio station must have their schedules defined to correspond with the on-air solicitation period. This is done by placing a Schedule module and defining on-duty hours of 6:00 AM to 10:00 AM on each weekday.
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
5 GETTING STARTED
Figure 5.8 Schedule moduleShift
DEFINING
THE WORKERSTHE
AGENT
MODULE
In the Telethon model, a group of volunteers will be manning the phone lines at the radio station. These volunteers will service incoming donor calls. This is a very simple agent group to represent, requiring the absolute minimum input. Place an Agent module within the model window and open the main dialog 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 groups 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 moduleTalk 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 LOGICTHE
SCRIPT
PANEL
Donor calls start the phones ringing at the radio station. If not answered, the calls will roll over to voice mail after two minutes. 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
5 GETTING STARTED
Next place a Queue for Agent module in the model window. If a connector was not automatically added from the Begin Script module to the Queue for Agent module, use the Connect button located on the standard toolbar to connect the exit point of the Begin Script module to the entry point of the Queue for Agent module. 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 GRAPHICSTHE
ANIMATE
MODULE
Animation is often useful to provide visual insight into contact center conditions during a simulation run. In the Telethon model, agent utilization is a valuable indicator of whether the size of the volunteer staff is adequate to handle all donor callsa critical component in making the pledge drive a success. Therefore, we will animate the utilization level of the volunteer group both numerically and with a plot.
60
5 GETTING STARTED
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
STATISTICSTHE
REPORT
MODULE
The purpose of constructing simulation models is to gain insight into contact center business processes and drive the planning and improvement of those operations. The Report module supports detailed data collection of important performance measures throughout the planning horizon under study. In the Telethon model, managers are interested in the experience of donors as they wait for agents. In particular, long answer times may indicate that potential pledges are abandoning the center without being served. Place a Report module within the model window and complete its dialog 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
5 GETTING STARTED
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 telethons hours of operation (remember that both arrival pattern and agent schedules must be adjusted). Add an agent group to handle overflow from the regular volunteers after calls have been on the line more than one minute. Modify the routing script to overflow calls to this group.
63
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 panelthe 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 modules purpose is to specify the layout of the contact center simulation. The planning horizon and all trunk groups applicable to the contact center are defined here. PROMPTS Planning HorizonLength of the planning horizon chosen from the following predefined list of options: Month, Bi-Week, Week, Day. The planning horizon defines the length of the simulation run. Trunk DefinitionsThis repeat group defines the contact capacity of the contact center in terms of trunk lines. Trunk groups will be useful in defining different functions within a contact center and for networked contact centers that are not at the same physical location. Trunk GroupText descriptor of the trunk group being defined (for example, Sales, Dallas Office, Outsourcer). Trunk CapacityNumber of trunks in this trunk group. Inbound ContactsIndicates if this trunk is used for inbound contacts.
66
6 THE CONTACT DATA PANEL
Inbound Contact ScriptRouting script for inbound contact associated with this trunk group, chosen from the list of defined Scripts. Inbound Contact PriorityInteger used to rank inbound contact associated with Trunk Group when queued to a priority queue. Outbound ContactsIndicates if this trunk is used for outbound contact. Outbound Contact ScriptRouting script for outbound contact associated with this trunk group, chosen from the list of defined Scripts. Outbound Contact PriorityInteger used to rank outbound contact associated with Trunk Group when queued to a priority queue. Trunk Cost/HourCost of trunk lines in $/hour/trunk line.
AdvancedThe following items support several advanced features of the run. Number of ReplicationsNumber of simulation runs to be performed during this analysis. Each runs length is determined by the Planning Horizon. Initialize System Between ReplicationsControls whether each replication is started with an empty contact center or continues from the endpoint of the previous replication. Initialize Statistics Between ReplicationsControls whether statistics collection is reset at the beginning of each replication or accumulates throughout all replications.
67
Max Number of Agent GroupsUpper bound on the number of Agent Groups to be included in the simulation model. This value may need to be increased for very large simulation runs. Prompt
Planning Horizon Trunk Definitions Trunk Group Trunk Capacity Inbound Contacts Inbound Contact Script Inbound Contact Priority Outbound Contacts Outbound Contact Script Outbound Contact Priority Trunk Cost/Hour Advanced Number of Replications Initialize System Initialize Statistics Integer >= 1 Checked, Cleared Checked, Cleared 1 Checked Checked 50 Symbol Name [Trunk Group] Integer >= 1 Checked, Cleared Symbol Name [Scripts] Expression Checked, Cleared Symbol Name [Scripts] Expression Real Number >= 0 Trunk 1 100 Checked Script 1 5 Cleared Script 1 100 0.00
Valid Entry
Day, Week, Bi-Week, Month
Default
Day
Max Number of Agent Groups Integer >= 1
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
Planning Horizon Trunk Definitions Trunk Group Trunk Capacity Inbound Contacts Inbound Contact Priority Inbound Contact Script Outbound Contacts Phone Bank 24 Checked 1 Direct Routing Cleared
Entry
Week
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 NameText descriptor of the schedule being defined (for example, Graveyard). Planning HorizonLength of the planning horizon chosen from the following predefined list of options: Month, Bi-Week, Week, Day. Timeslot (in minutes)Length of the intervals composing the schedule: 15, 30, or 60 minutes.
70
Daily ScheduleThis repeat group is used to define a schedule for each individual day within the planning horizon. Each day is identified by its week and day of week, if applicable. Within each day, multiple agent shifts can be defined. WeekSelection of the week within the planning horizon for which the agent shifts apply. Day of WeekSelection of the day within the planning horizon for which the agent shifts apply. Shift ScheduleThis repeat group is used to define the agent shifts that are in effect on the particular day. Each shift is specified by an agent availability state and a starting and ending time. Agent StateThis field defines the agent availability state for this particular shift. Alter Capacity byThis field allows you to specify whether the shift schedule being defined applies to the entire agent group capacity or for a specified number of the group. Number of AgentsThis option defines the number of agents for which the shift schedule applies. Group Capacity This option defines the absolute capacity of the agent. It must be a positive integer and cannot be larger than the Agents capacity as defined in the Agent module.
71
Schedule Adherence FactorMultiplier used to calculate the actual number of agents used for a given timeslot. Shift Begins atThis dialog box specifies the time the shift begins (for example, 8:00 AM). Shift Ends atThis dialog box specifies the time the shift ends (for example, noon). Prompt
Schedule Name Planning Horizon Timeslot Week Day Of Week Agent State Alter Capacity by Number of Agents Schedule Adherence Factor Shift Begins at Shift Ends at
Valid Entry
Symbol Name [Schedule] Day, Week, Bi-Week, Month 15, 30, 60 Week 1, Week 2, Week 3, Week 4 Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday On Duty, Lunch, Break, Meeting, Research Group Capacity, Number of Agents Integer > 1 Integer > 1 Time (hour, minute, AM/PM) Time (hour, minute, AM/PM)
Default
<Module Name and instance number> Day 30 Week 1 Monday On Duty Group Capacity 0 0 12 AM 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
Schedule Name Planning Horizon
Entry
Telethon Hours Week
73
Prompt
Timeslot Daily Schedule Day of Week Agent State Shift Begins at Shift Ends at Day Of Week Day Of Week
Entry
60
Monday/Tuesday/Wednesday/Thursday/ Friday On-Duty 6:00 AM 10:00 AM Saturday 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 PatternText descriptor of the contact pattern being defined (for example, Windows, DOS). Planning HorizonLength of the planning horizon chosen from the following predefined list of options: Month, Bi-Week, Week, Day. Timeslot (in minutes)Length of the intervals composing the pattern: 30 or 60 minutes. Scale FactorMethod of scaling the arrival pattern data up or down. Each timeslot value will be multiplied by the scale factor to determine the expected total contacts for each timeslot.
Daily Arrival PatternThis repeat group is used to define a pattern for each individual day within the planning horizon. For each day, the expected total contacts arriving within each timeslot are specified. WeekSelection of the week within the planning horizon for which the pattern applies.
75
Day Of WeekSelection of the day within the planning horizon for which the pattern applies. Daily Contact PatternSpecification of the expected total contacts for each timeslot for the given day. EXAMPLE Prompt
Pattern Planning Horizon Timeslot Scale Factor Daily Arrival Pattern Week Day Of Week Daily Contact Pattern Week 1, Week 2, Week 3, Week 4 Week 1
Valid Entry
Symbol Name [Pattern] Day, Week, Bi-Week, Month 30, 60 Real Number
Default
<Module Name and instance number> Day 30 1.0
Mon, Tue, Wed, Thu, Fri, Sat, Sun Mon 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
Pattern Planning Horizon Day Of Week Daily Arrival Pattern (6:00 AM - 7:00 AM) Daily Arrival Pattern (7:00 AM - 8:00 AM) Daily Arrival Pattern (8:00 AM - 9:00 AM) Daily Arrival Pattern (9:00 AM - 10:00 AM)
Entry
Basic Pattern Week Mon/Tue/Wed/Thu/Fri 50 50 50 50
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 talktime 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 NameText descriptor of the group being defined. Agent TypeChoice of Agent Group or Parent Group. If Agent Type = Agent Group: These items define the generic agents that belong to this Agent Group and the specific agent operational details. The Agent Group will be defined by the number of agents, their associated skill set, and the schedule they follow. Max Number AvailableMaximum number of agents available in the Agent Group. ScheduleAssociated Agent Schedule, chosen from the list of the defined Agent Schedules. Clear Queue when Off DutySpecifies whether a check is made every 15 minutes to determine if all agent groups comprising the parent group are off-duty and to clear the parent queue by disconnecting all the contacts in the queue. Aparent group queue can be cleared several times daily depending upon the member agent group schedules. Busy Cost/HourCost per hour incurred while a single agent is busy. Idle Cost/HourCost per hour incurred while a single agent is idle. Per Use CostCost per contact incurred for a single agent.
78
Talk Time SpecificsDialog box containing a repeat group that defines talk time specifics for each contact name. Contact NameParticular contact name that can be handled by agents with the given skill set. Talk Time MultiplierNumerical expression quantifying the skill of the agent with respect to the specified contact name (for example, 0.9 implies agents with this skill set handle this contact in 90% of the average time). Conference Time MultiplierNumerical 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 PriorityIndicates whether contact priority should be redefined when served by this Agent Group. Agent Skill PriorityNumber 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 DutySpecifies whether contacts are disconnected when all agent groups comprising the parent group go off duty at the end of a day. MembersThis repeat group specifies the various Agent Groups that compose the given Parent Group. Agent GroupText descriptor of the Agent Group that belongs to the Parent Group, chosen from the list of Agent Groups that have been defined. PreferenceNumber indicating the preference of this Agent Group within Parent Group (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 PriorityDialog box containing a repeat group that specifies agent skill priorities by contact name. Contact NamesThis repeat group specifies agent skill priorities by contact name. Contact NameParticular contact name that can be handled by agents with the given skill set.
80
Agent Skill PriorityNumber 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. Prompt
Agent Name Agent Type Agent Group Max Number Available Schedule Busy Cost Idle Cost Per Use Cost Talk Time/Contact Names Contact Name Talk Time Multiplier Conference Time Multiplier Override Contact Priority Agent Skill Priority Parent Group Clear Queue when Off-Duty Checked, Cleared Members Agent Group Preference Agent Skill Priority Contact Names Contact Name Agent Skill Priority Symbol Name [Contact] Integer >= 1 Contact 1 5 Symbol Name [Agent Group] Integer >= 1 Agent Group 1 5 Checked Symbol Name [Contact] Real Number >= 0 Real Number >= 0 Checked, Cleared Integer >= 1 Contact 1 1 1 Cleared 5 Integer >= 1 Symbol Name [Schedule] Real Number >= 0 Real Number >= 0 Real Number >= 0 1 Schedule 1 0.00 0.00 0.00
Valid Entry
Symbol Name [Agent] Agent Group or Parent Group
Default
Agent Group Agent Group
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 1BASIC
USE
This example defines the volunteers in the Basic Telethon case study as an Agent group of 12 generic agents. Prompt
Agent Name Agent Type Max Number Available Schedule Clear Queue when Off-Duty Busy Cost Idle Cost Per Use Cost Talk Time Contact Name
82
Entry
Volunteers Agent Group 12 Telethon Hours Checked 0.0 0.0 0.0
Donor
Prompt
Talk Time Multiplier Conference Time Multiplier Override Contact Priority
Entry
1 1 Cleared
EXAMPLE 2USING
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
Agent Name Agent Type Max Number Available Schedule Clear Queue when Off-Duty Busy Cost Idle Cost Per Use Cost Talk Time Contact Name Talk Time Multiplier Regular 0.8
Entry
Expert Agent Group 1 First Shift Checked 0.0 0.0 0.0
Conference Time Multiplier 0.8 Contact Name Talk Time Multiplier Premium 0.8
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 TypeDefines the type of contact (for example, Call, Email, Fax, Web Hit or Other). OptionDefines a contact as inbound or outbound. Contact NameText descriptor of the contact being defined (for example, Reservations). PatternAssociated Pattern, chosen from the list of the defined Patterns. Expected Talk TimeAverage talk time for contacts of Contact Name. This value is used as the mean of an exponential distribution from which talk time values are generated for each contact. Trunk GroupAssociated Trunk Group, chosen from the list of the defined Trunk Groups.
84
Contact BackDialog box that defines contact-back behavior: Contact Back ReasonsBlocked, Disconnected, Message, Abandoned, Served. ProbabilityNumerical expression for probability of contact back. Wait TimeDistribution for the delay (in minutes) before contacting back.
AbandonmentSpecification of Abandonment module to apply to the contact. Wait Time Until AbandonmentDistribution specifying time until abandonment.
85
AdvancedDialog box that allows incorporation of the following advanced modeling features: Override Trunk PriorityCheck box determines whether or not the priority specified in the Configuration module will be used for a given contact name. Override Trunk PriorityExpression used to rank contacts of Contact Name when queued in a priority queue. If not entered, Priority is inherited from Trunk Group Priority (see Configuration module). Override Trunk ScriptCheck box used to indicate whether the Script inherited from Trunk Group Script (see 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 ScriptOverriding Script, chosen from the list of defined Routing Scripts. If not specified, Script is inherited from Trunk Group Script (see the Configuration module on page 66). [Agent Type]Defines whether the overriding agent type is a parent group or basic agent group.
86
Agent GroupName of the overriding agent group to which contacts of Contact Name will be sent directly to its associated queue. Parent GroupName of the overriding parent group to which contacts of Contact Name will be sent directly to its associated queue. Selection RuleRule used to determine which agent is selected from among multiple member agent groups. Talk Time DistributionOverrides default talk-time distribution by allowing specification of any general distribution. After Contact TimeSpecifies the distribution for after-contact delay. This is the amount of time the primary agent spends in contact wrap-up before becoming ready for another contact. Service Level (seconds)Number defining the target amount of time in seconds (service level) by which this Contact Name should be answered. The percentage of contacts meeting this target is reported in the simulation output. Can PreemptIndicates whether a contact of Contact Name can preempt another contact that is being served by an agent. Can Be PreemptedIndicates whether a contact of Contact Name currently being serviced by an agent can be preempted by another contact. Contact Picture NameDefines the name of the entity symbol used for animating Contact Name contacts. Create ContactIndicates if a Contact Name contact is created when another entity executes the Contact module. Contact CharacteristicsDialog box that allows the assignment of user-defined contact attributes or user-defined global variables. AssignmentsSpecified one or more assignments that will be made when a contact of Contact Name is generated. [Assignment Type]Type of assignment to be made. This is a choice of either a user-defined contact attribute or a global variable. Contact Attribute NameName of the user-defined contact attribute that will be assigned a value when a contact of Contact Name is generated. Global Variable NameName of the global variable being assigned. ValueAssignment value of the attribute or variable.
87
Contact Return check boxDisplays a dialog box that defines return contact characteristics. Contact ReturnDialog box that specifies contact return behavior. PriorityInteger used to rank returned contacts in an agents queue. [Contact Return Logic Type]Determines whether a returned contact follows a script or is queued for an agent. Contact Return ScriptThe script that returned contacts will follow. [Contact Return Agent Type]Determines whether the returned contact is queued to an agent group or a parent group. Contact Return Agent GroupThe name of the agent group that will service the returned contact. Contact Return Parent GroupThe name of the parent group of agents that will service the returned contact. Selection RuleThe rule to use when there is more than one available agent to handle the returned contact. Pre WorkThe amount of time an agent needs prior to returning a contact. Connection TimeThe amount of time it takes to connect with the returned contactor. Probability of ConnectionThe probability that an agent will be able to connect with the returned contactor. Max Number of AttemptsThe number of attempts an agent will make to connect with a returned contactor prior to abandoning it. Time Between AttemptsThe time between subsequent contact return attempts. Outbound ContactsDialog box that specifies outbound contact behavior. Pre WorkThe amount of time an agent needs prior to making an outbound contact. Connection TimeThe amount of time it takes to connect the outbound contact. Probability of ConnectionThe probability that an agent will be able to connect with the outbound contact. Max Number of AttemptsThe number of attempts an agent will make to connect with an outbound contact prior to abandoning it.
88
Time Between AttemptsThe time between subsequent outbound contact attempts Prompt
Contact Name Contact Type Pattern Expected Talk Time Trunk Group Contact Back Checked, Cleared Contact Back Reason: Blocked, Disconnected, Message, Abandoned, Served Probability Wait Time Abandonment Wait Time Until Abandonment Advanced Override Trunk Priority Checked, Cleared Check box Override Trunk Priority Integer >= 1 Override Trunk Script [Override Type] Call Routing Script [Agent Type] Agent Group Checked, Cleared Script, Agent Symbol Name [Script] Agent Group, Parent Group Symbol Name [Agent Group] Cleared 5 Cleared Script Script 1 Agent Group Agent Group 1 Expression (Distribution) None 0 <= Real Number <= 1.0 or expression Expression (Distribution) Cleared
Valid Entry
Symbol Name [Contact]
Default
<module name and instance number>
Call, Email, Fax, Web Hit or Other Call Call Symbol Name [Pattern] Real Number > 0 Symbol Name [Trunk Group] Pattern 1 1 Trunk 1
1 1
89
Prompt
Parent Group Selection Rule Talk Time Distribution
Valid Entry
Symbol Name [Parent Group]
Default
Parent Group 1
First Available, Longest Available, Uniform by Availability Uniform by Availability Expression (Distribution) (Uses Expected Talk Time from main dialog box) 0.0 60 Cleared Cleared Contact 1 Picture Cleared
After Contact Time Distribution Service Level Can Preempt Can Be Preempted Contact Picture Name Create Contact Contact Characteristics [Assignment Type]
Expression (Distribution) Real Number > 0 Checked, Cleared Checked, Cleared Symbol Name [Pictures] Checked, Cleared
Contact Attribute, Global Variable
Contact Attribute Attribute 1 Variable 1 1 Cleared
Contact Attribute Name Symbol Name [Attributes] Global Variable Name Value Symbol Name [Variables] Expression
Contact Return Check box Checked, Cleared Contact Return Priority [Contact Return Logic Type] Contact Return Script [Contact Return Agent Type] Contact Return Script Integer>=1 Script, Agent Symbol Name [Script] Agent Group, Parent Group Symbol Name [Script]
50 Script Script 1 Agent Group Script 1
90
Prompt
Contact Return Agent Group Contact Return Parent Group Selection Rule Pre Work Connection Time Probability of Connection Max Number of Attempts Time Between Attempts Outbound Contacts Pre Work Connection Time Probability of Connection Max Number of Attempts Time Between Attempts
Valid Entry
Symbol Name [Agent Group] Symbol Name [Parent Group]
Default
Agent Group 1 Parent Group 1
First Available, Longest Available, Uniform by Availability Uniform by Availability Expression (Distributions) Expression (Distributions) 0<=Expression<=1 Integer>=1 Expression (Distributions) 0.0 0.0 1 1 0.0
Expression (Distributions) Expression (Distributions) 0<=Expression<=1 Integer>=1 Expression (Distributions)
0.0 0.0 1 1 0.0
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
Contact Name Pattern Talk Time Trunk Group Abandonment Wait Time Until Abandonment EXPO(1)
Entry
Donor Basic Pattern 10 Phone Bank
92
Animate module
DESCRIPTION The Animate module allows animation of real-time statistics during the simulation run. PROMPTS Data ObjectIndicates the type of contact center statistic to be displayed. If Data Object = Contact: Contact NameSelection of the Contact Name to animate, from a list of all defined Contact Names. Contact Statistic TypeSelection of the Contact Statistic Type to animate. Choices are: Contact CountRunning total number of contacts in particular stages. Contact Back CountRunning totals of contact backs by contact-back reason. Contact TimesAverage time contacts spend in a particular state. PercentagesPercentages of contacts in various categories. Contact DataSelection of the particular real-time statistic to animate. Choices depend on the Contact Statistic Type being animated and are summarized in Table 6.1.
93
Table 6.1 Summary of Contact Statistic Type
Contact Statistic
Contact Count Created Blocked Offered Abandoned Handled
Definition
Count of number of original contacts created Count of the number of blocked (denied entry) contacts Count of the number of contacts entering the center Count of the number of contacts that abandon (hang up) before being connected to an agent 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 Disconnected In System Waiting Contact Back Counts Blocked Abandoned Disconnected Leaving Message Served Count of the number of contacts contacting back after being blocked (denied entry) Count of the number of contacts contacting back after abandoning the center Count of the number of contacts contacting back after being disconnected Count of the number of contacts contacting back after leaving messages Count of the number of contacts contacting back after being served by an agent Count of the number of contacts leaving messages Count of the number of contacts disconnected Count of the number of contacts currently in the contact center Count of the number of contacts currently waiting for service
94
Contact Statistic
Contact Times Speed of Answer Handle Time Time in Contact Center Percentages Blocking Abandonment
Definition
Average time between contact-center entry and connection with an agent Average time the primary agents spends serving the contact, including both talk and after-contact time Average amount of time the contact spends in the contact center
Percentage of attempted contacts that are blocked Percentage of offered contacts that abandon the center
Serviced in X minutes Percentage of served contacts that are handled within the specified service cutoff
If Data Object = Agent Group or Parent Group:
Agent/ParentSelection of the Agent/Parent Group to animate, from a list of all defined Agent/Parent Groups. Object DataSelection of the particular cumulative real-time statistic to animate. Choices are:
95
UtilizationThe fraction of on-duty time during which members of the Agent Group are serving customers. Number BusyThe average number of agents concurrently serving customers. Number AvailableThe average number of idle agents. If Data Object = Trunk Group:
TrunkSelection of the Trunk Group to animate, from a list of all defined Trunk Groups. Object DataSelection of the particular cumulative real-time statistic to animate. Choices are: UtilizationThe fraction of time during which trunk lines of the Trunk Group are busy. Number in UseThe average number of trunk lines concurrently in use. Number AvailableThe average number of trunk lines that are idle.
96
If Data Object = Overflow:
Source GroupSelection of the Agent Group from which overflowed contact counts should be animated. Destination GroupSelection of the Agent Group to which overflowed contact counts should be animated. If Data Object = System Time:
Display AsSelection of the view(s) by which the system time should be animated. Choices are: VariableDisplay of the day of the simulation run as a numerical quantity (1-28).
97
Analog ClockIllustration of the day of simulation run as a clock face. Digital ClockIllustration of digital 24-hour clock in numeric form. If Data Object = Other:
Other DataSpecification of an expression to be animated throughout the simulation run. If Data Object is not System Time: Display AsSelection of the view(s) by which the chosen statistic should be animated. Choices are: VariableDisplay of the statistic as a numerical quantity. LevelIllustration of the statistic as a graphical quantity. HistogramIllustration of the statistic as a histogram of values it assumes over time. PlotDisplay of the statistic as a plot over time.
98
Prompt
Data Object
Valid Entry
Default
Contact Contact, Agent Group, Parent Group, Trunk Group, Overflow, System Time or Other
Contact Contact Name Symbol Name [Contact] Contact 1 Contact Count Abandoned
Contact Statistic Type Contact Count, Contact-Back, Count, Contact Times, Percentages Contact Data Agent Group Agent Group Agent Data Parent Group Parent Group Parent Data Trunk Group Trunk Group Trunk Data Overflow Source Group Destination Group System Time Display As Other Other Data Display As Expression Selection of the views (multiple choices allowed) to animate the statistic Selection of the views (multiple choices allowed) to animate the statistic Symbol Name [Agent] Symbol Name [Agent] Symbol Name [Trunk Group] Selection from list of available statistics Symbol Name [Parent Group] Selection from list of available statistics Symbol Name [Agent Group] Selection from list of available statistics Selection from list of available statistics
Agent Group 1 Utilization
Parent Group 1 Utilization
Trunk 1 Utilization
Agent Group 1 Agent Group 2
All
Required All
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
Data Object Agent Group Agent Data Display As Display As
Entry
Agent Group Volunteers Utilization Variable Plot
Report module
100
DESCRIPTION This modules purpose is to specify data collection and report generation for various contact-center statistics. The statistics type, length of data collection timeslot, and output file name are defined in this module, and the corresponding report is generated during the simulation run. PROMPTS Report TypeThe type of statistical report and the particular value to be tracked are chosen from among the following: Contact TimesSelection of a particular Contact Name for which contact-time statistics will be collected. Contact CountsSelection of a particular Contact Name for which counts will be tallied as contacts enter various stages. Agent GroupSelection of a particular Agent Group for which utilization statistics will be collected. Parent GroupSelection of a particular Parent Group for which utilization statistics will be collected. Trunk GroupSelection of a particular Trunk Group for which utilization statistics will be collected. OverflowSelection of a particular pair of Source and Destination Agent groups for which overflow counts will be collected. Contact NameThis field, visible if Report Type is Contact Times or Contact Counts, defines the contact type for which the report will be written. Agent GroupThis field, visible if Report Type is Agent Group, defines the agent group for which the report will be written. Parent GroupThis field, visible if Report Type is Parent Group, defines the parent group for which the report will be written. Trunk GroupThis field, visible if Report Type is Trunk Group, defines the trunk group for which the report will be written. Source GroupThis field, visible if Report Type is Overflow, defines the source agent or parent group for which the overflow statistics are to be reported. Destination GroupThis field, visible if Report Type is Overflow, defines the destination agent or parent group for which the overflow statistics are to be reported.
101
Time IntervalNumerical value, in minutes, defining the interval length for which statistics will be collected. Form of OutputChoice of Data or Text File, which determines whether the output report is generated in a spreadsheet-based or text format. Output FileName of the output file to which the report will be written. OptionsDialog box that allows the specification of advanced options. Exclude empty time slotsControls whether empty timeslots are displayed. Highlight time slots with a specified conditionDetermines if specified timeslots will be highlighted. ConditionThe condition that must be met so that a timeslot will appear highlighted. The first two fields must be selected from the drop-down list supplied. Prompt
Report Type
Valid Entry
Default
Contact Times Contact Times, Contact Counts, Agent Group, Parent Group, Trunk Group, Overflow Symbol Name [Contact] Symbol Name [Contact Counts] Symbol Name [Agent Group] Symbol Name [Parent Group] Symbol Name [Trunk Group] Symbol Name [Agent Group] Symbol Name [Agent Group] Integer >= 1 Data or Text File Symbol Contact 1 Contact 1 Agent Group 1 Parent Group 1 Trunk 1 Agent Group 1 Agent Group 2 30 Data Default value based on Report type, name, and time interval
Contact Name Contact Counts Agent Group Parent Group Trunk Group Source Group Destination Group Time Interval Form of Output Output File
102
Prompt
Options
Valid Entry
Default
Exclude empty time slots Checked, Cleared Highlight time slots with Checked, Cleared a specified condition Condition Expression
Cleared Cleared 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, dont use time intervals that are unnecessarily detailed). In practice, care must be taken to synchronize the timeslots within the Report modules with the timeslots defined in the Schedule modules. Agent Group statistics collection will be disrupted if groups go on/off duty in the middle of a reporting timeslot. Therefore, reporting timeslots should be shorter than agent shifts and coincide with their start and end. For instance, when shifts change on the hour, statistics can be collected on the hour or half-hour. However, if shifts change on the half-hour, statistics must be collected on the half-hour. 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 columnoriented 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 outputtext form (Notepad)
The data file form of output, Figure 6.2, saves the same information with commas between each value. This form is commonly referred to as comma-separated values and uses the default extension .csv. Many programs like Microsoft Excel 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 outputdata 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
Report Type Contact Name Time Interval Form of Output Output File
Entry
Contact Times Donor 60 Data File Donor Time 60.csv
105
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 Remove from Queue 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 modules purpose is to identify the script. The option of obtaining a trunk line can also be specified. PROMPTS Script NameIdentifier of script. Seize Trunk GroupIndicates whether a trunk should be seized. Trunk NameName of trunk to be seized. Prompt
Script Name Seize Trunk Group Trunk Name
Valid Entry
Symbol Name [Scripts] Checked, Cleared Symbol Name [Trunks]
Default
Script <module instance number> Cleared 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
Script Name Seize Trunk
Entry
Direct Routing 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 GroupName of the agent group. Parent GroupName of the parent group. Selection RuleThis field, visible if Group Type is Parent Group, defines the rule used to determine which agent is selected from among multiple member agent groups.
109
AdvancedThis dialog box shows several options to access external logic. After seizing agentAllows the contact entity to access external logic after seizing an agent (before talk time starts). After talk timeAllows the contact entity to access external logic after talk time. Prior to post contact workAllows the contact entity to access external logic prior to post-contact work. Prompt
Group Type Agent Group Parent Group Selection Rule Advanced After seizing agent After talk time Prior to post contact work Checked, Cleared Checked, Cleared Checked, Cleared Cleared Cleared Cleared
Valid Entry
Agent Group, Parent Group Symbol Name [Agent Group] Symbol Name [Parent Group] First Available, Longest Available, Uniform by Availability
Default
Agent Group Agent Group 1 Parent Group 1 Uniform by Availability
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
7 THE SCRIPT PANEL
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
Group Type Agent Group
Entry
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 TimeDistribution of the delay for the contact. Prompt
Wait Time
Valid Entry
Expression (Distributions)
Default
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
7 THE SCRIPT PANEL
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
Wait Time
Entry
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: IncreaseIncreases the importance of the contact by the specified amount. This will result in the contact being ranked higher in queue and having greater claim on available agent resources. DecreaseDecreases the importance of the contact by the specified amount. This will result in the contact being ranked lower in queue and having reduced claim on available agent resources. NewRedefine the importance of the contact to the specified priority. Queue ranking and claim to available agent resources will be adjusted accordingly. Increase Priority byQuantity by which the current value will be increased.
113
Decrease Priority byQuantity by which the current value will be decreased. New PriorityNew value assigned to the current priority. Prompt
Priority Change Increase Priority by Decrease Priority by New Priority
Valid Entry
Increase, Decrease, New Expression Expression Expression
Default
Increase 1 1 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
Priority Change Increase Priority by
Entry
Increase 2
114
7 THE SCRIPT PANEL
Message module
DESCRIPTION This module allows a contact to leave a message, possibly generating a contact return. PROMPTS Message Wait TimeAmount of time to leave a message. Disable Contact BackDisable the option for messaged contacts to contact back (re-enter the system). Disable Contact ReturnDisable the option to turn a messaged contact into a contact return. Prompt
Message Wait Time Disable Contact Back
Valid Entry
Expression (Distribution) Checked, Cleared
Default
0.0 Cleared Checked
Disable Contact Return Checked, Cleared
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 contacts 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
Message Wait Time Disable Contact Back
Entry
UNIF(1,2) Cleared
Disable Contact Return Checked
Disconnect module
DESCRIPTION The Disconnect module terminates a contact. PROMPTS Disable Contact BackDisable the option for messaged contacts to contact back (re-enter the system). Prompt
Disable Contact Back
Valid Entry
Checked, Cleared
Default
Cleared
116
7 THE SCRIPT PANEL
REMARKS When a Disconnect module is encountered in a routing script, the contact is immediately dispatched from the contact center. This Disconnect module is not permitted if the contact is in queue. A Remove from Queue module must be executed first. Any contact back from disconnected contacts (specified in the contacts corresponding Contact module) may optionally be disabled using this action. EXAMPLE 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
Disable Contact Back
Entry
Cleared
Overflow module
DESCRIPTION The Overflow module removes the contact from its Source queue and sends it to its Destination queue.
117
PROMPTS Source GroupThe queue from which the contact will be removed. Destination GroupThe queue to which the removed contact will be sent. Prompt
Source Group Destination Group
Valid Entry
Symbol Name [Agent Group] Symbol Name [Agent Group]
Default
Agent Group 1 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
Primary Agents Secondary Agents
Transfer to Script module
118
7 THE SCRIPT PANEL
DESCRIPTION This module shifts the routing control to another script. PROMPTS Script NameName of the routing script to which the contact will be transferred. Release Trunk GroupOption to indicate that the current trunk group should be released. Prompt
Script Name Release Trunk Group
Valid Entry
Symbol Name [Script] Checked, Cleared
Default
Script 1 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 contacts routing control flow to be transferred to the Advanced script for continued processing. Prompt
Script Name Release Trunk Group
Entry
Advanced 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 GroupThe name of the agent group. Parent GroupThe name of the parent group. Selection RuleDetermines which agent is selected from among multiple available agent groups. Transfer Talk TimeDelay time incurred by the contact with the transfer agent. Prompt
(Group Type) Agent Group Parent Group Selection Rule Transfer Talk Time
Valid Entry
Agent Group, Parent Group Symbol Name [Agent Group] Symbol Name [Parent Group] First Available, Longest Available, Uniform by Availability Expression (Distributions)
Default
Agent Group Agent Group 1 Parent Group 1 Uniform by Availability 0.0
120
7 THE SCRIPT PANEL
REMARKS The Transfer to Agent module is for use within the Queue for Agent module only. The Queue for Agent module has three Advanced features that allow external logic to be specified at three different times: After Seizing Agent, After Talk Time, and Prior to Post Contact Work. The Transfer to Agent module must be used with the Prior to Post Contact Work option. By connecting this module to the special exit point created for the advanced Queue for Agent option, a contact can be directed to another agent after the first agents tasks are complete. If the requested transfer agent is not available, the transfer will not be completed. Multiple-agent transfer can be modeled by connecting a series of Transfer to Agent modules. The original agent is released before the contact is transferred to the next agent. Each transfer is performed in series. Therefore, the primary agent does not participate in the next (transfer) agents activities, and so on. EXAMPLE 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
(Group Type) Agent Group Transfer Talk Time
Entry
Agent Group Manager 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 GroupThe name of the agent group. Parent GroupThe name of the parent group. Selection RuleDetermines which agent is selected from among multiple member agent groups. Conference Talk TimeDelay time incurred by the contact with the conference agent and the primary agent. Prompt
(Group Type) Agent Group Parent Group Selection Rule
Valid Entry
Agent Group, Parent Group Symbol Name [Agent Group] Symbol Name [Parent Group] First Available, Longest Available, Uniform by Availability
Default
Agent Group Agent Group 1 Parent Group 1 Uniform by Availability 0.0
Conference Talk Time Expression (Distributions)
122
7 THE SCRIPT PANEL
REMARKS The Conference module is for use within the Queue for Agent module only. The Queue for Agent module has three Advanced features that allow external logic to be specified at three different times: After Seizing Agent, After Talk Time, and Prior to Post Contact Work. The Conference module must be used with the After Talk Time option. By connecting this module to the special exit point created for the advanced Queue for Agent option, a contact can be conferenced with another agent after the first agents talk time is complete. If the required conference agent is not available, the conference will not take place. Multiple-agent conferencing can be modeled by connecting a series of Conference modules. The original agent is not released until all the conferences are complete. However, each conference is performed in series. Therefore, the first conference agent is not a part of the second conference with the next conference agent, and so on. 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
(Group Type) Agent Group
Entry
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 contacts priority is greater than five or based on one or more probabilities (for example, 75%). PROMPTS Branch OptionsSpecifies 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. ConditionCondition to be evaluated. This field is visible when Branch Type is If. There are 11 conditions that can be evaluated. Condition is Agent Availability Agent GroupName of the Agent or Parent Group whose availability is evaluated. If at least one member of the parent or agent group is available, this condition is evaluated as TRUE.
124
7 THE SCRIPT PANEL
Condition is Contact Attribute Value Contact Attribute NameName of contact attribute to be evaluated. (Operator)Mathematical operator used in the condition. (Contact Attribute Value)Value to which the Contact Attribute Name will be compared. Condition is Contact Priority (Operator)Mathematical operator used in the condition. (Contact Priority)Value to which the contacts current priority value will be compared. Condition is Contact Name Is Contact NameName of contact type to which the contacts type will be compared. If the contacts type is the same as Contact Type, the condition is TRUE. Condition is Day Is DayDay of week to which the current simulation day will be compared. If the current day of the week is the same as Day, the condition is evaluated as TRUE. Condition is General Expression SIMAN ExpressionAny valid SIMAN expression. Condition is Queue Length Agent QueueName of the Agent or Parent Group whose queue length will be evaluated against (Agent Queue Length). (Operator)Mathematical operator used in the condition. (Agent Queue Length)Value to which the queue length of the specified Agent Queue will be compared. Condition is Time in Call Center (Operator)Mathematical operator used in the condition. (Time in Call Center)Time (in minutes) to which that the contacts current total time spent in the center will be compared.
125
Condition is Global Variable Value Global Variable NameName of the global variable whose value will be evaluated against (Global Variable Value). (Operator)Mathematical operator used in the condition. (Global Variable Value)Value to which the global variable will be compared. Condition is Time of Day (Operator)Mathematical operator used in the condition. (Time of Day)Specifies the point in time to which the current simulation time will be compared (AM, PM, noon, or midnight). (Hour)Specifies the hour to which the current simulation time will be compared. (Minute)Specifies the minute in time to which the current simulation time will be compared. Condition is Agent Expressions (Agent Expression)Specifies the type of agent statistic that will be used for the condition. Agent GroupName of the Agent or Parent Group for whom the (Agent Expression) is referring. (Operator)Mathematical operator used in the condition. (Agent Expression Value)Value to which the agent statistic expression will be compared. Branching ProbabilityProbability of selecting branch. Used only when Branch Type is set to With.
126
7 THE SCRIPT PANEL
Prompt
Branch Type Condition
Valid Entry
If, With, Else
Default
If
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 Symbol Name [Agent Group] Agent Group 1 Attribute 1 1 1 Contact 1 Monday Required Agent Group 1 1 1 Variable 1 1
AM
Agent Group
Contact Attribute Name Symbol Name [Contact Attribute] (Contact Attribute Value) (Contact Priority) Contact Name Day SIMAN Expression Agent Queue Expression Expression Symbol Name [Contact] Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday Expression Symbol Name [Agent Group]
(Agent Queue Length) Expression (Time in Call Center) Expression
Global Variable Name Symbol Name [Variable] (Global Variable Value) Expression (Time of Day) (Hour) (Minute) (Agent Expression) (Agent Expression Value) (Operator)
AM, PM,
Midnight, Noon
Integer (0-12) Integer (0 - 59) Average Wait Time, Average Handle Time, Expected Wait Time Expression <, <=, <>, ==, >, >=
1 0 Average Wait Time 1 ==
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
Branch Type Condition Agent Queue (Operators)
Entry
If Queue Length IRA specialists <=
(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
7 THE SCRIPT PANEL
PROMPTS (Assignment Type)Type of assignment to be made. Contact Attribute NameName of the contact attribute to be assigned. Global Variable NameName of Contact Center global variable to be assigned. ValueThe value to be assigned to the attribute or variable. Contact Picture NameName of the contacts picture used for animation. Counter NameName of the counter to be incremented. IncrementValue by which the counter is incremented. Prompt
(Assignment Type)
Valid Entry
Contact Attribute, Contact Picture, Global Variable, Counter
Default
Contact Attribute Attribute 1
Contact Attribute Name Symbol Name [Contact Attribute]
Global Variable Name Symbol Name [Contact Center Global Variable 1 Variable] Value Contact Picture Name Counter Name Increment Expression Symbol Name [Picture] Symbol Name [Counter] Integer 1 Picture 1 Counter 1 1
REMARKS User-defined counters appear in the Category Overview, Category by Replication, and User-Specified reports. EXAMPLE This example reassigns the contacts picture to Transferred Picture. Prompt
(Assignment Type) Contact Picture Name
Entry
Contact Picture Transferred Picture
129
End Script module
DESCRIPTION This modules purpose is to identify the end of the script. PROMPTS No values are required. REMARKS All straight-flow scripts must end with either an End Script or Transfer to Script module. Scripts that loop contacts until they are answered do not need an End Script module.
Script restrictions
The following actions are not permitted as the last action in a script:

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

The following actions are not permitted if the contact is in queue:

Each Overflow action must be followed eventually by a Queue for Agent action specifying the appropriate overflow destination group.
130
7 THE SCRIPT PANEL
Arena Contact Center template script examples

EXAMPLE 1BASIC
QUEUEING
The most basic routing script consists of a single Queue for Agent module. This type of script places the contact in the specified queue, where it will remain until it is served or abandons the center. 1. Begin Script 2. Queue for Agent 3. End Script EXAMPLE 2QUEUEING
WITH MESSAGE OPTION
A common script in contact centers that takes messages during periods of high demand will queue for an agent, but will take a message if the contact has not been served within a certain period of time. 1. 2. 3. 4. 5. 6. Begin Script Queue for Agent: Volunteers Wait: 2 Remove from Queue Message: 0.5 End Script
OVERFLOW
EXAMPLE 3BASIC
The overflow of contacts from one group or location to another is an increasingly common routing script feature. The most basic case of overflow is illustrated in the following script where a contact is queued to a specialist group, where it waits for a period of time, and is then overflowed to all potential servers if not yet served. 1. 2. 3. 4. 5. Begin Script Queue for Agent: IRA specialists Wait: 2 Overflow: IRA Specialists to General Customer Service Queue for Agent: General Customer Service (Selection rule: uniform by availability) 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
Reports
The Arena Contact Center template produces the following eight reports:

Agents and Trunks Contact Times and Counts Contact Count Statistics Contact Time Statistics
Agent Group Utilization Parent Group Utilization Trunk Group Utilization Overflow Count Statistics
This chapter describes each type of report. The Agents and Trunks and the Contact Times and Counts are produced by default with each simulation run. These reports are generated using 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
Timeslot Week Day Daily Timeslot
Description
The number of the timeslot within the planning horizon for which the statistics were collected The number of the week within the planning horizon on which the statistics were collected The number of the day of the week on which the statistics were collected 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 AvailableThis section reports the average number of available trunk lines for the specified planning horizon. Available is a time-persistent statistic. The value is weighted to take into consideration the value as a function of time. In UseThis section reports the average number of busy trunk lines for the specified planning horizon. In Use is a time-persistent statistic. The value is weighted to take into consideration the value as a function of time. UtilizationThis section reports each trunk lines utilization for the specified planning. Utilization is a time-persistent statistic. The average is weighted to take into consideration the value as a function of time. COST Busy CostThis section reports the busy cost for all trunk lines. The busy cost for each trunk line is the product of the average number of busy lines, the simulation run length, and the trunks busy cost rate.
Agent Summary
The Agent Summary is broken into three groups: Usage, Cost, and Inbound and Outbound Utilization. Listed below are the statistics reported for each group. Each group displays a value for each parent and agent group defined in the system. USAGE AvailableThe average number of agents available over the simulation run length. BusyThe utilization over the simulation run length. This can include times when an agent group cannot be scheduled in the system.
134
8 REPORTS
Est on DutyThis section reports the total time for each entity type. Total time for an entity is calculated based on the time the entity enters the system until the time the statistics are generated. UtilizationThis section reports the total time for each entity. Total time for an entity is calculated based on the time the entity enters the system until when statistics are generated. COST Busy CostThe product of the average number of busy agents, the simulation run length, and the agent busy cost specified in the Agent module. Idle CostThe product of the average number of idle agents, the simulation run length, and the agent idle cost specified in the Agent module. Per Use CostThe cost incurred for using an agent. Usage cost is calculated based on the agent per-use cost and the number of times the agent is seized or allocated to an entity. INBOUND
AND
OUTBOUND UTILIZATION
Inbound UtilThis section reports each trunks busy cost. Busy cost is the cost accrued by a trunk while it is in a non-value-added activity. Outbound UtilThis section reports each trunks busy cost. Busy cost is the cost accrued by a trunk while it is in a non-value-added activity. 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 TimeThe amount of time a contact spends from when the agent is available until the contact is complete. Message to Return TimeThe time from when a contact leaves a message to when an agent returns the contact. Speed of Answer TimeThe time a contact spends waiting for an available agent. Time in Contact CenterThe time span from when a contact enters the center until the contact is completed.
Contact Counts
Contact Counts is broken into three groups: Counts, Outcomes, and Contact Backs. Listed below are the statistics reported for each group. Each group displays a value for each contact type defined in the system. COUNTS BlockedThe total number of contacts blocked as of the end of the replication. CreatedThe total number of contacts that arrived at the contact center as of the end of the replication. This number includes contact backs generated from blocked, abandoned, disconnected, served, and messages. In SystemThe total number of contacts that were left in the system as of the end of the replication. OfferedThe total number of contacts offered as of the end of the simulation. WaitingThe total number of contacts that were left waiting for an agent as of the end of the replication. OUTCOMES AbandonedThe total number of contacts abandoned as of the end of the replication. DisconnectedThe total number of contacts disconnected as of the end of the replication. HandledThe total number of contacts handled as of the end of the replication. In TargetThe total number of contacts answered within the specified service-level time as of the end of the replication.
136
8 REPORTS
MessageThe total number of messages generated as of the end of the replication. CONTACT BACKS AbandonedThe total number of contact backs generated due to abandoned contacts for the duration of the simulation. BlockedThe total number of contact backs generated due to blocked contacts for the duration of the simulation. DisconnectedThe total number of contact backs generated due to disconnected contacts for the duration of the simulation. MessageThe total number of contact backs generated due to messages for the duration of the simulation. ServedThe total number of contact backs generated due to served contacts for the duration of the simulation.
Other Contact Data

Contact Counts is broken into four groups: Service Level, Abandoned Percent, Blocking Percent, and Contact Return Counts. Listed below are the statistics reported for each group. Each group displays a value for each contact type defined in the system. SERVICE LEVEL PercentThe number of contacts answered within the specified service level divided by the number of contacts that enter the system. Target LevelThe number of seconds, specified in the Contact module, for a contacts service level. Abandoned PercentThe number of contacts abandoned divided by the number of calls that enter the system. Blocking PercentThe number of contacts blocked divided by the number of contacts generated. CONTACT RETURN COUNTS AbandonedThe total number of contact returns generated due to abandoned contacts. OutstandingThe total number of messages for which no action was taken (a contact return). This counter is incremented even when Disable Contact Return is checked in the Message module or when Contact Return is not checked in the Contact module. ReturnedThe total number of return contacts made due to messages generated.
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
Column Heading
Contacts Waiting Contacts In System Contacts Created Contact Backs Contacts Blocked Contacts Offered Contacts Abandoned
Description
The number of contacts waiting for an agent, as of the end of the specified timeslot The number of contacts in the contact center, as of the end of the specified timeslot The number of contacts created according to the contact pattern that attempts to enter the system The number of previously created contacts that are attempting to return to the contact center The number of contacts that were denied access to the contact center due to lack of available trunk lines The number of contacts that were assigned a trunk line and successfully enter the contact center 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 Contacts Handled The number of offered contacts resulting in a message 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 centers hours of operation, all arriving contacts attain trunk lines and enter the contact center. In fact, all contacts are ultimately handled, since no contacts are listed as abandoned, leaving messages, or being disconnected. 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
Time in Center Service Level Answer Time Talk Time After Contact Time Handle Time Additional Service
Description
The average time each handled contact spends in the contact center The percentage of handled contacts that were handled within the specified service interval The average time each handled contact waits before being connected to an agent The average time each handled contact spends with an agent The average time the primary agent spends completing aftercontact work The average time the primary agent spends serving a contact (in terms of talk time and after-contact time) 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 centers hours of operation, the service level for contacts within 1 minute is 100%. Further, the average speed of answer is zero. This indicates that there was always an available agent to meet every incoming contactan extremely overstaffed contact center. This suggests that acceptable service levels could be maintained by reducing the number of agents on-duty, perhaps by staffing them at other times to extend the hours the center is open for business.
Agent Group Utilization report

Agent Statistics for [Agent Group] by [N] Minute Time Period
This report details the utilization of Agent Group resources for each timeslot within the planning horizon. Each report covers one particular Agent Group.
Table 8.4 Agent Group Utilization report column descriptions
Column Heading
Agents Busy Agents On Duty Agent Utilization
Description
The average number of agents busy throughout the timeslot The number of agents on duty throughout the timeslot 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
Column Heading
Agents Busy Agents On Duty Agent Utilization
Description
The average number of agents busy throughout the timeslot The number of agents on duty throughout the timeslot The average utilization of agents throughout the timeslot
EXAMPLE Agent Statistics for Savings Servers 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. 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
Column Heading
Trunks In Use Total Trunks Trunk Utilization
Description
The average number of trunk lines in use throughout the timeslot The number of trunk lines within the trunk group The average utilization of trunk lines throughout the timeslot
EXAMPLE Trunk Statistics for Central Trunks by 60-Minute Time Period
144
8 REPORTS
In this example, the contact center is open only during (that is, Schedules and Patterns are only defined for) normal business hours. Thus, the central trunk group is utilized only during this time period. Average trunk utilization ranges between 0.94% to 9.09%.
Overflow Count Statistics report
This report details, by timeslot, the total number of contacts that overflow from one specific agent group to another. Each report covers a particular source and destination pair of agent groups.
Table 8.7 Overflow Count Statistics report column description
Column Heading
Number of Contacts
Description
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
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 products animation features to watch your models run can also be very informative.
Example 1Bilingual Contact Center model

Overview and business objective
The business objective is to model a contact center that serves an English and Spanish population with three types of agents: English-speaking, Spanish-speaking, and Bilingual. The utilization of the various groups can then be assessed under different demand forecasts to ascertain staffing levels and to quantify the added value of hiring bilingual agents. The focus of this example is on the definition of the agent and parent groups, which support sharing of contact-center agent resources across functions and simultaneous queueing to those resources. In addition, this example also illustrates the Arena Contact Center templates 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: Englishspeaking, Spanish-speaking, and Bilingual. In addition, there will be two parent groups: the English Servers (comprised of English-speaking and Bilingual agents) and the Spanish Servers (comprised of Spanish-speaking and Bilingual agents). With this parent group structure, English calls will then be queued to the English Group and Spanish calls can be queued to the Spanish Group. This means that all English calls 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 moduleBilingual Center
Prompt
Planning Horizon Trunk Definitions Trunk Group Trunk Capacity Inbound Contacts Inbound Contact Script Inbound Contact Priority
Entry
Week
Central Trunks 100 Checked English Script 5
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 moduleBilingual Center
Prompt
Schedule Name Planning Horizon Timeslot Day of Week Shift Schedule Agent State Shift Begins At Shift Ends At Day of Week Day of Week
Entry
Business Hours Week 60 Monday/Tuesday/Wednesday/Thursday/Friday
On-Duty 8:00 AM 5:00 PM Saturday 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 moduleBilingual Center
Prompt
Pattern Planning Horizon Timeslot Daily Arrival Pattern Day of Week 8:00 AM9:00 AM
Entry
Weekly Pattern Week 60
Monday/Tuesday/Wednesday/Thursday/Friday 100
150
9 CASE STUDIES
Prompt
9:00 AM10:00 AM 10:00 AM11:00 AM 11:00 AMNoon Noon1:00 PM 1:00 PM2:00 PM 2:00 PM3:00 PM 3:00 PM4:00 PM 4:00 PM5:00 PM Day of Week Day of Week
Entry
50 50 50 50 50 50 50 50 Saturday 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 modulesBilingual Center
Prompt
Agent Name Agent Type Max Number Available Schedule
Entry
English Only Agent Group 20 Business Hours
Clear Queue when Off Duty Checked
151
Prompt
Talk Time Contact Name Talk Time Multiplier Agent Name Agent Type Max Number Available Schedule
Entry
English 1 Spanish Only Agent 20 Business Hours
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Agent Name Agent Type Max Number Available Schedule Spanish 1 Bilingual Agent 10 Business Hours
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Contact Name Talk Time Multiplier Agent Name Agent Type Members Agent Group Preference Agent Group English Only 5 Bilingual English 1 Spanish 1 English Servers Parent
152
9 CASE STUDIES
Prompt
Preference Agent Name Agent Type Members Agent Group Preference Agent Group Preference
Entry
5 Spanish Servers Parent
Spanish Only 5 Bilingual 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 modulesBilingual Center
Module
Begin Script Queue for Agent
Prompt
Script Name Group Type Parent Group Selection Rule
Entry
English Script Parent Group English Servers Uniform by Availability
End Script Begin Script Script Name Spanish Script
153
Module
Queue for Agent
Prompt
Group Type Parent Group Selection Rule
Entry
Parent Group Spanish Servers Uniform by Availability
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 modulesBilingual Center
Prompt
Contact Name Pattern Trunk Group Contact Back Contact Back Reason Probability Wait Time Abandonment
Entry
English/Spanish Weekly Pattern Central Trunks
Abandoned 0.75 20
Wait Time Until Abandonment EXPO(2) Advanced Override Trunk Script (Override Type) Routing Script Talk Time Distribution
154
Checked Script English Script/Spanish Script UNIF(3,7)/UNIF(4,6)
9 CASE STUDIES
Example 2Bank model

In this case study, the business objective is to model a customer service center for a bank where each agent can handle any type of contact, but is able to handle contacts within their specialty more efficiently than others. Account Balance, Savings, and Checking contacts are processed by this contact center, and specialty groups have been created for everything but common account balance inquiries. The impact of different contact loads on the utilization of the agent groups is of interest, as well as the handle time of each contact name type. In particular, the goal is to maximize 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. CONFIGURATION

MODULE
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
Planning Horizon Trunk Definitions Trunk Group Trunk Capacity Inbound Contacts Inbound Contact Script Inbound Contact Priority Outbound Contacts Trunk Cost/Hour
Entry
Week
Central Trunks 15 Checked Balance Script 5 Cleared 9
SCHEDULE
MODULE
Agents in the Bank model work normal business hours.

Table 9.8 Agent Schedule moduleBank model
Prompt
Schedule Name Planning Horizon Timeslot Day Of Week Shift Schedule Agent State Shift Begins at Shift Ends at Day Of Week Day Of Week
Entry
158
9 CASE STUDIES
PATTERN
MODULE
Each contact name within the Bank model follows its own unique arrival pattern.
Table 9.9 Pattern moduleBank model
Prompt
Pattern Planning Horizon Timeslot Daily Arrival Pattern Day Of Week 8:00 AM9:00 AM 9:00 AM10:00 AM 10:00 AM11:00 AM 11:00 AMNoon Noon1:00 PM 1:00 PM2:00 PM 2:00 PM3:00 PM 3:00 PM4:00 PM 4:00 PM5:00 PM Day Of Week Day Of Week
Entry
Savings Pattern (Checking Pattern, Account Balance Pattern) Week 60
Monday/Tuesday/Wednesday/Thursday/Friday 4 (40,100) 2 (20,50) 2 (20,50) 2 (20,50) 2 (20,50) 2 (20,50) 2 (20,50) 2 (20,50) 2 (20,50) Saturday 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
Savings Specialists Agent 3 Business Hours
Clear Queue when Off-Duty Checked Busy Cost/Hour Idle Cost/Hour Per Use Cost Talk Time Contact Name Talk Time Multiplier Call Type Talk Time Multiplier Contact Name Talk Time Multiplier Agent Name Agent Type Max Number Available Schedule Savings 0.75 Checking 1 Account Balance 1 Checking Specialists Agent 4 Business Hours 12 12 0.0
Clear Queue when Off-Duty Checked Busy Cost/Hour Idle Cost/Hour Per Use Cost 7.5 7.5 0.0
160
9 CASE STUDIES
Prompt
Talk Time Contact Name Talk Time Multiplier Contact Name Talk Time Multiplier Contact Name Talk Time Multiplier
Entry
Checking 0.75 Savings 1 Account Balance 1
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
Agent Name Agent Type
Entry
Savings Servers Parent
Clear Queue when Off-Duty Checked Members Agent Group Preference Agent Group Preference Savings Specialists 1 Checking Specialists 5
161
Prompt
Entry
Checking Servers Parent
Clear Queue when Off-Duty Checked Members Agent Group Preference Agent Group Preference Agent Name Agent Type Checking Specialists 1 Savings Specialists 5 Balance Servers Parent
Clear Queue when Off-Duty Checked Members Agent Group Preference Agent Group Preference Savings Specialists 5 Checking Specialists 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 modulesBank model
Module
Prompt
Entry
Savings Script Parent Group Savings Servers Uniform by Availability
End Script
162
9 CASE STUDIES
Module
Prompt
Entry
Checking Script Parent Group Checking Servers Uniform by Availability
End Script Begin Script Queue for Agent Script Name Group Type Parent Group Selection Rule End Script Balance Script Parent Group Balance Servers Uniform by Availability
CONTACT
MODULE
The definitions for contact names in the bank model are all basically parallel. There are minor differences in expected handle time. Each call is associated with its own custom routing script.
Table 9.13 Contact moduleBank model
Prompt
Contact Name Pattern Expected Talk Time Trunk Group Advanced Override Trunk Script (Override Type) Routing Script
Entry
Savings (Checking, Account Balance) Savings Pattern (Checking Pattern, Account Balance Pattern) 5 (Savings, Checking) or 1 (Account Balance) Central Trunks
Checked Script Savings Script (Checking Script, Balance Script)
163
Example 3Skill-based Routing model

OVERVIEW
AND BUSINESS OBJECTIVE
The business objective is to model a contact center that serves three different contact names, which we refer to 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 As have the lowest priority value for AB agents. Similarly, when a BC agent becomes available, it will choose a Type B call, because Type Bs have the lowest priority value for BC agents.
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. CONFIGURATION

MODULE
The Skill-based Routing case study is based on a weekly planning horizon and a center with a single trunk group of 100 lines.
Table 9.14 Configuration moduleSkill-based Routing model
Prompt
Entry
Week
Central Trunks 100 Checked Skill A Script 5

165
SCHEDULE
MODULE
All agents in the Skill-based Routing model are on-duty during normal business hours.
Table 9.15 Agent Schedule moduleSkill-based Routing model
Prompt
Schedule Name Planning Horizon Timeslot Day Of Week Shift Schedule Agent State Shift Begins at Shift Ends at Day Of Week Day Of Week
Entry
PATTERN
MODULE
All contact names within the Skill-based Routing model follow the same arrival pattern.
Table 9.16 Pattern moduleSkill-based Routing model
Prompt
Pattern Planning Horizon Timeslot Daily Arrival Pattern Day of Week 8:00 AM9:00 AM 9:00 AM10:00 AM
Entry
Weekly Pattern Week 60
Monday/Tuesday/Wednesday/Thursday/Friday 40 20
166
9 CASE STUDIES
Prompt
10:00 AM11:00 AM 11:00 AMNoon Noon1:00 PM 1:00 PM2:00 PM 2:00 PM3:00 PM 3:00 PM4:00 PM 4:00 PM5:00 PM Day Of Week Day Of Week
Entry
20 20 20 20 20 20 20 Saturday Sunday
AGENT
MODULE
The key component of Agent Group definitions in the Skill-based Routing example is the inclusion of Agent Skill Priorities. These priorities express the agents preference for what contact name to serve when faced with multiple options. In this model, both agent groups are multi-skilled, handling Call B and either Call A or Call C. The AB skilled agents have a primary focus on Call A, and therefore assign it top priority. Similarly, the BC skilled agents have a primary focus on Call B. Thus, when faced with a choice between Call A and Call B, AB agents will select Call A. Given a similar choice between Call B and Call C, BC agents will service Call B.
Table 9.17 Agent modulesSkill-based Routing model
Prompt
Entry
AB Agents Agent 5 Business Hours
Clear Queue when Off-Duty Checked Talk Time Contact Name Talk Time Multiplier Call A 1
167
Prompt
Entry
Conference Time Multiplier 1 Override Contact Priority with Skill Priority Agent Skill Priority Contact Name Talk Time Multiplier Checked 1 Call B 1
Conference Time Multiplier 1 Override Contact Priority Agent Skill Priority Agent Name Agent Type Max Number Available Schedule Checked with Skill Priority 2 BC Agents Agent 5 Business Hours
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Call B 1
Conference Time Multiplier 1 Override Call Priority with Skill Priority Agent Skill Priority Call Type Talk Time Multiplier Checked 1 Call C 1
Conference Time Multiplier 1 Override Call Priority with Skill Priority Agent Skill Priority Checked 2
168
9 CASE STUDIES
Prompt
Entry
B Servers Parent Group
Clear Queue when Off Duty Checked Members Agent Group Preference Agent Group Preference AB Agents 5 BC Agents 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 modulesSkill-based Routing model
Module
Prompt
Script Name Group Type Agent Group
Entry
Skill A Script Agent Group AB Agents
End Script Begin Script Queue for Agent Script Name Group Type Parent Group Selection Rule End Script Skill B Script Parent Group B Servers Uniform by Availability
169
Module
Prompt
Entry
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 modulesSkill-based Routing model
Prompt
Contact Name Pattern Expected Talk Time Trunk Group Advanced Override Trunk Script (Override Type) Routing Script
Entry
Call A (Call B, Call C) Weekly Pattern 5 Central Trunks
Checked Script Skill A Script (Skill B Script, Skill C Script)
Example 4Premium 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 multipletrunk 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. CONFIGURATION

MODULE
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 modulePremium Service model
Prompt
Planning Horizon Trunk Definitions Trunk Group Trunk Capacity Inbound Contacts Inbound Contact Script Inbound Call Priority Trunk Group Trunk Capacity Inbound Contacts Inbound Contact Script Inbound Contact Priority
Entry
Day
Regular Trunks 100 Checked Regular Script 2 Premium Trunks 20 Checked Premium Script 1
SCHEDULE
MODULE
In addition to a standard business hour schedule, a 24-hour schedule has been defined to provide premium contacts with round-the-clock service.
Table 9.21 Agent Schedule modulesPremium Service model
Prompt
Schedule Name Planning Horizon Timeslot Shift Schedule Agent State Shift Begins at Shift Ends at
Entry
Business Hours Day 60
On-Duty 8:00 AM 5:00 PM
173
Prompt
Entry
24 Hours Day 60
On-Duty Midnight 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 modulesPremium Service model
Prompt
Pattern Planning Horizon Timeslot Daily Arrival Pattern 8:00 AM9:00 AM 9:00 AM10:00 AM 10:00 AM11:00 AM 11:00 AMNoon Noon1:00 PM 1:00 PM2:00 PM 2:00 PM3:00 PM 3:00 PM4:00 PM
Entry
Regular Pattern Day 60
160 80 80 80 80 80 80 80
174
9 CASE STUDIES
Prompt
4:00 PM5:00 PM Pattern Planning Horizon Timeslot Daily Arrival Pattern Midnight1:00 AM 1:00 AM2:00 AM 2:00 AM3:00 AM 3:00 AM4:00 AM 4:00 AM5:00 AM 5:00 AM6:00 AM 6:00 AM7:00 AM 7:00 AM8:00 AM 8:00 AM9:00 AM 9:00 AM10:00 AM 10:00 AM11:00 AM 11:00 AMNoon Noon1:00 PM 1:00 PM2:00 PM 2:00 PM3:00 PM 3:00 PM4:00 PM 4:00 PM5:00 PM 5:00 PM6:00 PM 6:00 PM7:00 PM 7:00 PM8:00 PM 8:00 PM9:00 PM
Entry
80 Premium Pattern Day 60
8 8 8 8 8 8 8 8 160 72 64 64 64 64 64 64 64 8 8 8 8
175
Prompt
9:00 PM10:00 PM 10:00 PM11:00 PM 11:00 PM
Entry
8 8 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 modulesPremium Service model
Prompt
Entry
Regular Agents Agent Group 10 Business Hours
Clear Queue when Off-Duty Checked Talk Time Contact Name Talk Time Multiplier Agent Name Agent Type Max Number Available Schedule Regular Call 1 Premium Agents Agent Group 5 24 Hours
176
9 CASE STUDIES
Prompt
Talk Time Contact Name Talk Time Multiplier Agent Name Agent Type Max Number Available Schedule
Entry
Premium Call 1 Utility Agents Agent Group 5 Business Hours
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Contact Name Talk Time Multiplier Agent Name Agent Type Regular Call 1 Premium Call 1 Regular Servers Parent Group
Clear Queue when Off Duty Checked Members Agent Group Preference Agent Group Preference Agent Name Agent Type Regular Agents 5 Utility Agents 5 Premium Servers Parent Group
177
Prompt
Members Agent Group Preference Agent Group Preference
Entry
Premium Agents 5 Utility Agents 5
SCRIPTS The routing scripts in the Premium Service model are straightforward.
Table 9.24 Script modulesPremium Service model
Module
Prompt
Entry
Regular Script Parent Group Regular Servers Uniform by Availability
End Script Begin Script Queue for Agent Script Name Group Type Parent Group Selection Rule End Script Premium Script Parent Group Premium Servers Uniform by Availability
178
9 CASE STUDIES
CONTACT
MODULE
The contact-type definitions in the Premium Service model are very basic.
Table 9.25 Contact modulesPremium Service model
Prompt
Contact Type Contact Name Pattern Expected Talk Time Trunk Group Contact Type Contact Name Pattern Expected Talk Time Trunk Group
Entry
Call Regular Call Regular Pattern 10 Regular Trunks Call Premium Premium Pattern 10 Premium Trunks
Example 5Teamwork 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 contactrouting 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
CONFIGURATION
MODULE
The Teamwork model is based on a daily planning horizon and a center with a central trunk group of 100 lines.
Table 9.26 Configuration moduleTeamwork model
Prompt
Entry
Week
Central Trunks 25 Checked Direct Routing 5
SCHEDULE
MODULE
All agent groups in the Teamwork model work normal business hours.
Table 9.27 Agent Schedule moduleTeamwork model
Prompt
Entry
Business Hours Day 60
On-Duty 8:00 AM 5:00 PM
181
PATTERN
MODULE
All customer requests within the Teamwork model follow a basic arrival pattern.
Table 9.28 Pattern moduleTeamwork model
Prompt
Pattern Planning Horizon Timeslot Daily Arrival Pattern 8:00 AM9:00 AM 9:00 AM10:00 AM 10:00 AM11:00 AM 11:00 AMNoon Noon1:00 PM 1:00 PM2:00 PM 2:00 PM3:00 PM 3:00 PM4:00 PM 4:00 PM5:00 PM
Entry
Daily Pattern Day 60
200 100 100 100 100 100 100 100 100
AGENT
MODULE
The Agent Group definitions identify all the key players in the Teamwork model and how they work together. All contacts arrive at a central receptionist. The receptionist will ascertain the nature of the customer request (represented by the talk time specified in the contact module) and potentially conference in a member of the accounting department before transferring the contact to either technical support or a manager. The receptionist will then update the customers folder (after-contact time) before taking a new contact. 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 contactors technical questions (represented by the talk time specified in the contact module, multiplied by the technical support agents talk time multiplier specified in the agent module) and potentially conference in a member of the development team. Since the contact was transferred to a script instead of an agent, if the contactor disconnects 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 modulesTeamwork model
Prompt
Entry
Reception Agent Group 2 Business Hours
183
Prompt
Entry
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Conference-Time Multiplier Agent Name Agent Type Max Number Available Schedule Customer Request 1 2 Accounting Agent Group 1 Business Hours
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Agent Name Agent Type Max Number Available Schedule Customer Request 1 Technical Support Agent Group 5 Business Hours
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Conference-Time Multiplier Agent Name Agent Type Max Number Available Customer Request 10 5 Development Agent Group 1
184
9 CASE STUDIES
Prompt
Schedule
Entry
Business Hours
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Agent Name Agent Type Max Number Available Schedule Customer Request 1 Managers Agent Group 1 Business Hours
Clear Queue when Off Duty Checked Talk Time Contact Name Talk Time Multiplier Customer Request 3
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.79.9 below to see how the modules are connected.
185
Table 9.30 Script modulesTeamwork Model
Module
Prompt
Entry
Direct Routing Agent Group Receptionist
After Talk Time Logic Branch Branch Type Branching Probability Branch Type Conference Agent Type Agent Group Conference Talk Time Prior to Post Contact Work Logic Branch Branch Type Branching Probability Branch Type Transfer to Script Transfer to Script End Script Begin Script Queue for Agent Script Name Group Type Agent Group End Script Begin Script Queue for Agent Script Name Group Type Agent Group Tech Script Agent Group Technical Support Manager Script Agent Group Managers Script Name Script Name With 8 Else Manager Script Tech Script With 8 Else Agent Group Accounting UNIF(0,1)
186
9 CASE STUDIES
Module
After Talk Time Logic Branch
Prompt
Entry
Branch Type Branching Probability Branch Type
With 8 Else Agent Group Development UNIF(0,1)
Conference
Agent Type Agent Group Conference Talk Time
Remove from Queue Disconnect End Script
Figure 9.7 Manager ScriptTeamwork model
187
Figure 9.8 Direct-Routing ScriptTeamwork model
Figure 9.9 Tech ScriptTeamwork model
CONTACT
MODULE
The contacts in the Teamwork model cover a wide range of customer requests and, as a result, advanced distributions are used to model talk time and after-contact work. The talk-time distribution specified in the Advanced section of the Contact module replaces the traditional exponential distribution used in the Main section. In this case, a triangular distribution is used having a mean of 1 minute and minimum and maximum of 30 seconds and 5 minutes, respectively.
188
9 CASE STUDIES
An exponential distribution with a mean of 1 minute is used to model the aftercontact paperwork that must be completed by the receptionist following each contact.
Table 9.31 Contact moduleTeamwork model
Prompt
Contact Name Pattern Talk Time Trunk Group Advanced Talk-Time Distribution After-Contact Time Distribution
Entry
Customer Request Daily Pattern (See Advanced section) Central Trunks
TRIA(0.5, 1, 5) EXPO(1)
Example 6Multi-site model

The business objective is to model the worldwide operations of an organization providing 24 x 7 support. Of particular interest is overflow between contact center locations and the impact staffing decisions one location may have on others. The three contact centers in the model are located in the U.S., Europe, and Japan. Each center works an 8-hour shift as the primary service provider followed by an 8-hour shift handling overflow, according to the following schedule (all times in Eastern Standard Time): Primary Service
Midnight to 8:00 AM 8:00 AM to 4:00 PM 4:00 PM to Midnight Europe U.S. Japan
Overflow Service
Japan Europe 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 modelingno reference is ever made to the physical location of an agent group; therefore, whether they are in the same building or positioned around the globe is immaterial. For the purpose of constructing a model, only the group definitions, schedules, and routing script logic need to reflect the multi-site configuration, and this is often indistinguishable from that applying to groups within the same building. MULTIPLE
PATTERNS
Separate contact names have been defined to represent service requests originating from each service zone. To further reflect the worldwide nature of this example, an individual pattern has been associated with each contact name to tie the arrivals to the local business hours. COMPLEX
SCRIPT
The strategy in this organization is to route all contacts to the primary center regardless of their origin. Then, if the contact is not handled within a short period of time, it is sent to the overflow center. A single script 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. CONFIGURATION

MODULE
The Multi-site model is based on a daily planning horizon and a center with a central trunk group of 100 lines.
190
9 CASE STUDIES
Table 9.32 Configuration moduleMulti-site model
Prompt
Entry
Week
Central Trunks 100 Checked Global Script 5
SCHEDULE
MODULE
Agents in each of the three international centers staff two consecutive 8-hour shifts: a primary shift where all contacts are routed to them and a secondary shift where all overflow is routed to them. These shifts are staggered so that there are always two centers on dutya primary center and a secondary center to handle overflow. All times are in Eastern Standard Time.
Table 9.33 Schedule modulesMulti-site model
Prompt
Schedule Name Planning Horizon Timeslot Shift Schedule Agent State Shift Begins at Shift Ends at Schedule Name Planning Horizon Timeslot
Entry
U.S. On-Duty Day 60
On-Duty 8:00 AM Midnight Europe On-Duty Day 60
191
Prompt
Shift Schedule Agent State Shift Begins at Shift Ends at Schedule Name Planning Horizon Timeslot Shift Schedule Agent State Shift Begins at Shift Ends at Agent State Shift Begins at Shift Ends at
Entry
On-Duty Midnight 4:00 PM Japan On-Duty Day 60
On-Duty Midnight 8:00 AM On-Duty 4:00 PM Midnight
PATTERN
MODULE
In the Multi-site model, contacts originate from each of the three international zones. All contacts follow the same basic pattern, each pattern just begins at different times depending on the zone of origination. 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 modulesMulti-site model
Prompt
Pattern Planning Horizon Timeslot
Entry
U.S. Daily Pattern Day 60
192
9 CASE STUDIES
Prompt
Daily Arrival Pattern 8:00 AM9:00 AM 9:00 AM10:00 AM 10:00 AM11:00 AM 11:00 AMNoon Noon1:00 PM 1:00 PM2:00 PM 2:00 PM3:00 PM 3:00 PM4:00 PM 4:00 PM5:00 PM 5:00 PM6:00 PM 6:00 PM7:00 PM 7:00 PM8:00 PM 8:00 PM9:00 PM 9:00 PM10:00 PM 10:00 PM11:00 PM 11:00 PM Pattern Planning Horizon Timeslot Daily Arrival Pattern Midnight1:00 AM 1:00 AM2:00 AM 2:00 AM3:00 AM 3:00 AM4:00 AM 4:00 AM5:00 AM
Entry
600 150 150 150 150 150 150 150 300 150 150 150 150 150 150 150 Europe Daily Pattern Day 60
600 150 150 150 150
193
Prompt
5:00 AM6:00 AM 6:00 AM7:00 AM 7:00 AM8:00 AM 8:00 AM9:00 AM 9:00 AM10:00 AM 10:00 AM11:00 AM 11:00 AMNoon Noon1:00 PM 1:00 PM2:00 PM 2:00 PM3:00 PM 3:00 PM4:00 PM Pattern Planning Horizon Timeslot Daily Arrival Pattern Midnight1:00 AM 1:00 AM2:00 AM 2:00 AM3:00 AM 3:00 AM4:00 AM 4:00 AM5:00 AM 5:00 AM6:00 AM 6:00 AM7:00 AM 7:00 AM8:00 AM 4:00 PM5:00 PM 5:00 PM6:00 PM 6:00 PM7:00 PM
Entry
150 150 150 300 150 150 150 150 150 150 150 Japan Daily Pattern Day 60
300 150 150 150 150 150 150 150 600 150 150
194
9 CASE STUDIES
Prompt
7:00 PM8:00 PM 8:00 PM9:00 PM 9:00 PM10:00 PM 10:00 PM11:00 PM 11:00 PM
Entry
150 150 150 150 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 modulesMulti-site model
Prompt
Agent Name Agent Type Max Number Available Schedule Talk Time Contact Name Talk Time Multiplier Contact Name Talk Time Multiplier Contact Name Talk Time Multiplier
Entry
U.S. Center (Europe Center, Japan Center) Agent 10 (10,5) U.S. On-Duty (Europe On-Duty, Japan On-Duty)
U.S. Call 1 Europe Call 1 Japan Call 1
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
Begin Script Branch
Prompt
Script Name (Branch Type) Condition (Branch Type) Condition (Branch Type) Condition (Branch Type)
Entry
Global Script If Time of Day>=11:58PM If Time of Day<=7:58AM If Time of Day<=3:58PM Else Agent Group Europe Center Agent Group U.S. Center Agent Group Japan Center 2
Queue for Agent
Queue for Agent
Queue for Agent
Wait
Wait Time
196
9 CASE STUDIES
Module
Branch
Prompt
(Branch Type) Condition (Branch Type) Condition (Branch Type)
Entry
If Time of Day<=8:00AM If Time of Day<=4:00PM Else Europe Center Japan Center U.S. Center Europe Center Japan Center U.S. Center Agent Group Japan Center Agent Group Europe Center Agent Group U.S. Center
Overflow
Overflow
Overflow
Queue for Agent
Queue for Agent
Queue for Agent
End Script
Figure 9.10 Global ScriptMulti-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 moduleMulti-site model
Prompt
Contact Name Pattern Expected Talk Time Trunk Group
Entry
U.S. Call (Europe Call, Japan Call) U.S. Daily Pattern (Europe Daily Pattern, Japan Daily Pattern) 10 Central Trunks
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
Reserved Words
The following list contains words reserved for internal use within the Arena Contact Center template: Abandon Wait Time Abandoned Adherence Factor After Call Time Agent Availability Agent Group All AllAgents AllParents AllStates AM Announcement AnyParents Astate BeenSeized Begin Script Blocked Both Break S Call Id Call Id Var Call Priority Call Times Call Type Cap Cap Change Child ChildIndex Conference Conference Time Contact Type Copy Atb CR Day Day is Day Number DayofWeek Decrease Disconnect Disconnected Downtm DummySetEmail End Script EndRotation Fax First Available First Script Flowtime Flowtime1 Friday General Expression Goto Inbound Increase Ind Infinite InitPr InitTr InOut j k Label_A LabelIt Longest Available Lunch S Meeting S
199
Message Midnight Monday New Next Action No Condition Noon None NxtBlk Off Duty S On Duty S Other Overflow Parent ParentIndex Parent Group Pattern PM PQPr Pr Pre Work Priority Qblock Queue for Agent Queue Length queuetime Probabilistic Branch
Remove from Queue RepDays Research S Saturday sbr sbr type Script Search Q Set Type Service Level StartRotation Station Type Sunday Talk Time Temp Temp Atb Terminated Thursday Time in Call Center Time of Day Time Remaining to Wait Time Spent Waiting TimeofDay Total Calls Transfer Transfer to Script Trunk Group
Tuesday Uniform by Availability uptm Wait_A Web Hit Wednesday WeekNumber Yes
200
Reports
201
202
B REPORTS
203
204
Index
A
abandonment 33, 53, 148 accessing external logic 109, 111 After Talk Time logic 42 after-contact work 37 agent costs 43 Agent Group Utilization report 141 agent groups 28, 57 Agent module 35, 57, 78 agent selection 38, 39, 156 agent skill priorities 40, 82, 165 agent skill sets 27, 78 agent states 44 Agent Summary 134 Cost 135 Inbound Utilization 135 Outbound Utilization 135 Usage 134 Agents and Trunks report 134 Animate module 61, 93 animation 29 counters 29 enabling/disabling 49 graphs 29 plots 29 Arena Contact Center template 1 Arena examples 4 arrival patterns 25 Assignment module 43, 128 attributes of contact 128
C
case studies 147 Bank model 155 Bilingual Contact Center model 147 Multi-site model 189 Premium Service model 170 Skill-based Routing model 164 Teamwork model 179 collecting statistics 61 conditional dialog input 65 Conference module 36, 42, 122 conferencing 35, 179 Configuration module 32, 33, 51, 66 consulting services 6 contact arrival 32 contact back 32, 37, 148 contact behavior 25 abandonment 25 After-Contact Work 25 Contact Back 25 Prioritization 25 contact centers blended 198 outbound 198 Contact Count Statistics report 138 Contact Counts Contact Backs 137 Counts 136 Outcomes 136 Contact Data panel 65 Agent module 78 Animate module 93 Configuration module 66 Contact module 84 Pattern module 74 Report module 101 Schedule module 70 contact information 7 contact life span stages 31 abandonment 33 after-contact work 37
B
Bank model 155 Begin Script module 41, 58, 107 Bilingual Contact Center model 147 blended contact center 198 blocked contacts 32 Branch module 42, 124 Buzacott, J. A. 21
205
contact life span stages (cont.) arrival 32 blocked 32 conference 36 contact back 37 disconnected 34 handled 34 leave a message 34 offered 33 talk time 35 transfer 36 Contact module 32, 33, 34, 35, 37, 53, 84 contact termination 116 Contact Time Statistics report 139 Contact Times and Counts report 135 Contact Counts 136 Contact Times 136 Other Contact Data 137 contact types 25 contact-routing logic 41 contacts leaving messages 34 costing of contact center operations 43 agents 43 trunk group 43 counters 128 Crystal Reports 133 customer service center 155 Customer Support Center 6
G
global contact priorities 171 global variables 128
H
handle time 155 handled contacts 34, 139
J
identifier 108 implementing your model design 21 individual agents 44
L
lists of object names 49 logic accessing external blocks 109
M
McKay, K. N 21 Message module 42, 60, 115 models 10 building a sample contact center structure 50 defining the objectives 16 documenting and implementing 21 experimental design 17 input data 18 level of detail 17 pitfalls in the plan design 16 verification and validation 19 modules Agent 35, 77 Animate 93 Assignment 43, 128 Begin Script 41, 108 Branch 42, 124 Conference 36, 42, 122 Configuration 32, 33, 66 Contact 33, 34, 35, 37, 84 copy and paste 49 Disconnect 42, 116 End Script 43, 130
D
data input 18 decision-making in a script 124 direct queueing 38 Disconnect module 42, 116 disconnected contacts 34 documentation of your model 21 duplicate (Ctrl+D) 55
E
End Script module 43, 60, 130 experimental model design 17
206
INDEX
modules (cont.) Message 42, 115 Overflow 42, 117 Pattern 32, 74 Priority 41, 113 Queue for Agent 35, 38, 41, 109 Remove from Queue 41, 112 Report 100 Schedule 70 Transfer to Agent 35, 36, 42, 120 Transfer to Script 42, 119 Wait 41, 112 multiple agents 40 multiple-agent schedules 171 multiple-trunk groups 171 Multi-site model 189
priorities global 171 Priority module 41 project definition 13 project planning 14
Q
queue behavior 38 queue construction 38 Queue for Agent module 35, 38, 41, 59, 109 queue ranking 38 queueing 29, 110, 155 direct 38 rank based on priority 39 simultaneous 38
N
no agents available 40
R
Remove from Queue module 41, 59, 111 repeat group 51, 65 duplication 49 replication 44 Report module 61, 101, 133 reports 201 Agent Group Utilization 141 Agents and Trunks 134 as performance measures 29 Contact Count Statistics 138 Contact Time Statistics 139 Contact Times and Counts 135 Overflow Count Statistics 145 Parent Group Utilization 142 Trunk Group Utilization 144 reserved words 49, 199 resource proficiency level 159 resource proficiency levels 157 resource sharing 155 routing scripts 26, 155 construction 41
O
offered contact 33 online help 5 Other Contact Data Contact Return Counts 137 Service Level 137 Overflow Count Statistics report 145 Overflow module 42, 117 outbound contact centers 198 output statistics 133
P
Parent Group Utilization report 142 parent groups 28 pattern entry 44 Pattern module 25, 32, 54, 74 patterns 76 for multiple agents 171 Pegden, C. D. 9 planning horizon 24, 70, 74, 133 preferences 40, 155 Premium Service model 170 primary agent 34
S
Sadowski, R. P. 9 Schedule module 55, 70 schedules 27
207
schedules for multiple agents 171 Schriber, T. J. 22 script examples 131 Script panel 35, 38, 58, 107 Assignment 128 Begin Script 108 Branch 124 Conference 122 Disconnect 116 End Script 130 Message 115 Overflow 117 Priority 113 Queue for Agent 109 Remove from Queue 112 Transfer to Agent 120 Transfer to Script 119 Wait 112 script restrictions 130 sensitivity analysis 19 served contacts 38 Shannon, R. E. 9 Sheppard, S. 22 shifts 72 simulation advantages of 12 definition of 9 the process 12 simulation process overview 23 simultaneous queueing 38, 40 skill-based routing 38, 40, 82 agent skill priorities 40 preferences 40 simultaneous queueing 40 Skill-based Routing model 164
Smarts library 5 statistics collection 103 Strang, C. J. 21 systems 10
T
talk time 35, 58 talk time multipliers 157, 159 Teamwork model 179 technical support 5 timeslots 24, 54, 70, 74, 133 training courses 6 transfer agent 36 Transfer to Agent module 35, 36, 42, 120 Transfer to Script module 42, 118 Trunk Group Utilization report 144 trunk groups 26 costs 43 Trunk Summary 134 Cost 134 Usage 134
W
Wait module 41, 59, 112 validation 19 Web support 6 Weinburg, G. M. 22 verification 19 worldwide operations 189 utilization 135 of Agent Group resources 141, 155 of Parent Group resources 142 of Trunk Group resources 144
208

Contact Center Template User&#39;s Guide

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Contact Center Template User&#39;s Guide

Transféré par

Droits d'auteur :

Formats disponibles

Arena Contact Center

Contact Copyright Notice

Trademark Notices Other Trademarks

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

6 The Contact Data Panel

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

7 The Script Panel

A Reserved Words B Reports Index

199 201 205

Welcome to Arena Contact Center Template

Simulation of contact centers

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

1 WELCOME TO ARENA CONTACT CENTER TEMPLATE

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Where can I go for help?

Refer to the users guides

Explore our examples

1 WELCOME TO ARENA CONTACT CENTER TEMPLATE

Use the Smarts library

Get phone support

TECHNICAL SUPPORT INCLUDES:

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Get Web support

Refer to the Arena Web site

Get consulting services

1 WELCOME TO ARENA CONTACT CENTER TEMPLATE

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Systems and models

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

The simulation process

Problem definition and project planning

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Style definition and model formulation

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Verification and validation

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Documentation and implementation

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

The basic components of this process are:

Contacts Arrival Patterns Trunk Groups Routing Scripts Schedules Agents

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

The relationships between these components are illustrated below.

Abandonment After-Contact Work Prioritization Contact Back

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Agent Skill Sets

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

contact counts contact times agent utilization trunk utilization overflow

The output of these reports is discussed in detail in Chapter 7.

Different stages in the contact life span

Figure 4.1 The path of a contact before processing begins

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Figure 4.2 The path of a contact after processing begins

Contact arrival (required)

MODULES AND RELATED CONCEPTS

Blocked contacts (required)

MODULES AND RELATED CONCEPTS

Offered contacts (required)

MODULES AND RELATED CONCEPTS

Abandoned contacts (optional)

MODULES AND RELATED CONCEPTS

ARENA CONTACT CENTER TEMPLATE USERS GUIDE

Disconnected contacts (optional)

Contact Center Template User's Guide

Contact Center Template User's Guide