Rockwell Automation Arena Contact Center Edition User Manual

Download

Arena®Contact Center

USER’S GUIDE

PUBLICATION ARENCC-UM001E-EN-P–November 2007

Supersedes Publication ARENCC-UM001D-EN-P

Contact Rockwell

Trademark Notices

Customer Support Telephone — 1-440-646-3434 Online Support— http://www.rockwellautomation.com/support

This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation Technologies, Inc. Any reproduction and/or distribution without prior written consent from Rockwell Automation Technologies, Inc. is strictly prohibited. Please refer to the license agreement for details.

Arena, Rockwell Automation, and SIMAN are registered trademarks of Rockwell Automation, Inc.

Other Trademarks

Warran ty

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 product’s performance may be affected by system configuration, the application being performed, operator control, maintenance and other related factors. Rockwell Automation is not responsible for these intervening factors. The instructions in this document do not cover all the details or variations in the equipment, procedure, or process described, nor do they provide directions for meeting every possible contingency during installation, operation, or maintenance. This product’s implementation may vary among users.

This document is current as of the time of release of the product; however, the accompanying software may have changed since the release. Rockwell Automation, Inc. reserves the right to change any information contained in this document or the software at anytime without prior notice. It is your responsibility to obtain the most current information available from Rockwell when installing or using this product.

Version: 12.00.00 (CPR9) Modified: October 8, 2007 9:55 am

1 • Welcome to Arena Contact Center Edition 1

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

Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Simulation of contact centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Arena Contact Center Edition: A custom-designed simulation system for contact centers

Where can I go for help? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Reference the user’s guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Explore our examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Get help. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Use the SMARTs library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Access the Arena Symbol Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Get phone support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Get Web support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Get training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Get consulting services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Contact us . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 • Introduction to Simulation 7

Simulation defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Systems and models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Advantages of simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

The simulation process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Problem definition and project planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Style definition and model formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Experimental design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Input data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Verification and validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Documentation and implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 • General Concepts 19

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Planning horizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Contact types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

iii

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Arrival pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Trunk Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Routing Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Agent Skill Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Agent Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Parent Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Animation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Performance measures/reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 • Features 27

Different stages in the contact life span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Contact arrival (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Blocked contacts (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Offered contacts (required). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Abandoned contacts (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Disconnected contacts (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Contacts leaving messages (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Handled contacts (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Talk time (required) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Conference (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Transfer (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

After-contact work (optional). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Contact back (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Queue behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Queue construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Queue ranking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Agent selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Skill-based routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Routing script construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Begin Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Queue for Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Remove from Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

CONTENTS

Wait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Disconnect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Overflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Transfer to Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Transfer to Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Conference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Branch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

End Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Agent costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Trunk costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Miscellaneous features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Pattern entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Agent states. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Individual agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Advanced configuration agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

• • • • •

5 • Getting Started 41

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Loading and running an existing example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

General modeling skills and concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Panels and modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Module copy and paste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Repeat group duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Disable animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Building an Arena Contact Center Edition model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Defining the business application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Model construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Running the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6 • The Contact Data Panel 59

Configuration module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Schedule module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Pattern module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Contact module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Animate module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Report module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7 • The Script Panel 99

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

Queue for Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Remove from Queue module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Wait module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Priority module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Message module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Disconnect module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Overflow module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Transfer to Script module. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Transfer to Agent module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Conference module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Branch module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Assignment module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

End Script module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Script restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Arena Contact Center Edition script examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

8 • Reports 123

Agents and Trunks report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Trunk Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Agent Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Contact Times and Counts report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Contact Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Contact Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Other Contact Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Contact Count Statistics report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Contact Time Statistics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Agent Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Parent Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Trunk Group Utilization report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Overflow Count Statistics report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

CONTENTS

9 • Case Studies 137

Purposes of cases and examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Example 1—Bilingual Contact Center model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 137

The data detail for the Bilingual Contact Center example . . . . . . . . . . . . . . . . . 139

Example 2—Bank model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 145

The data detail for the Bank example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Example 3—Skill-based Routing model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 153

The data detail for the Skill-based Routing example . . . . . . . . . . . . . . . . . . . . . 154

Example 4—Premium Service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 159

The data detail for the Premium Service example . . . . . . . . . . . . . . . . . . . . . . . 161

Example 5—Teamwork model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

The data detail for the Teamwork example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Example 6—Multi-site model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Overview and business objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Key modeling techniques illustrated in this example . . . . . . . . . . . . . . . . . . . . . 177

The data detail for the Multi-site example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Other examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Outbound/blend examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

• • • • •

A • Reserved Words 187

B • Reports 189

Index 193

vii

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

viii

Welcome to Arena Contact Center Edition

What is Arena Contact Center Edition?

Arena Contact Center Edition is a simulation system developed by Rockwell Automation, Inc. for the performance analysis of contact centers. It is built on Rockwell Automation’s Arena simulation system and has been customized to enable its users to build and run simulation models of contact center operations quickly and easily and to analyze the results that these models produce.

Intended audience

Arena Contact Center Edition is designed for contact center managers and analysts and industrial or systems engineers. It is typically deployed as an enterprise business analysis and productivity tool.

We assume that you are familiar with the basic concepts and terms used in these types of systems. You are interested in improving business productivity and are responsible for evaluating and predicting the impact of proposed strategic and tactical changes to help improve performance. A familiarity with computers and the Microsoft operating system is assumed. A familiarity with the concepts and terms used in simulation is also helpful.

Simulation of contact centers

For contact center managers and analysts, their planning problems are far easier to describe than to model or to solve.

Windows®

1 • Welcome

 “I’ve got my staffing budget for the next fiscal year, but I don’t know how many

people I need to make service levels, what shifts to hire for, or what skills to train my workers on.”

 “Service levels look pretty good right now, but our peak season is coming up. What I

don’t know is how badly our service levels and abandonment rates will suffer if our forecasts turn out to be too low.”

 “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.”

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

 “Marketing has come up with a new program giving our ‘preferred customers’ a

special priority when they contact us with questions. What I’m worried about is how this new program will affect the waiting times that the rest of our customers experience.”

 “We’ve been asked to provide telephone service and support for another business unit.

They’re asking us how much staff we need to hire or cross-train in order to handle this increased load.”

Contact center managers have traditionally attacked these types of problems with several methods, including “gut feel” estimates, back-of-the-envelope calculations, elaborate spreadsheets, and analytical queueing formulas such as Erlang C. Each of these approaches, however, has significant limitations when applied to contact centers and contact center networks.

Simulation is the only analysis method that can effectively and accurately model a contact center (or a network of contact centers). Such models can be used to study the performance of the system. The simulation method is based on creating a computerized “copy” of the actual contact center system and running this system on the computer for a period of time representing a day, a week, or a month.

In particular, simulation explicitly models the interaction between contacts (e.g., calls or email), routes, and agents, as well as the randomness of individual contact arrivals and handle times.

By using simulation, managers and analysts translate contact center data (forecasts, contact-routing vectors, contact-handle time distributions, agent schedules, agent skills, etc.) into actionable information about service levels, customer abandonment, agent utilization, first-contact resolution, and other important contact center performance measures. These results are used to support key management decisions that drive contact center operations and expenditures.

Agent Population

(# of Agents, Skills, Priorities,

Shifts, Breaks )

Routing Scripts

(By Contact Name)

Call-Volume Forecasts

(By Contact Name, Time Slots)

Center Configuration Data

(Hours of Operation,

Trunk Line Capacity, etc.)

1 • WELCOME TO ARENA CONTACT CENTER EDITION

Contact Center

Simulation

Model

Contact Center

Performance

Statistics

• • • • •

1 • Welcome

Arena Contact Center Edition: A custom-designed simulation system for contact centers

The successful use of simulation in many contact center environments led to the development of Arena Contact Center Edition. It was developed by Rockwell Automation in partnership with Onward, a management consulting firm based in Mountain View, California, specializing in contact center operations.

In conjunction with a team of contact center managers and analysts from many different types of business environments, Rockwell Automation and Onward have designed Arena Contact Center Edition to:

1. Make it easy for analysts to build accurate and detailed simulation models of contact centers, ranging from fairly simple to very complex, without extensive simulation or management science training.

2. Support a process of managing input data into these contact center simulation models that is as easy and sensible as possible.

3. Have the capacity to deliver real-time statistics, animation, and output statistics that provide insight into key contact center performance measures.

4. Use standard contact center terminology wherever possible to make the model building and usage process as intuitive as possible for contact center professionals.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Arena Contact Center Edition is a Microsoft® Windows® operating system-based simulation system. It is one of a family of application solution templates (ASTs) built on top of the Arena simulation system, leveraging Arena’s development environment to create a focused and easy-to-use tool for contact center managers and analysts.

Where can I go for help?

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

Reference the user’s guides

The documentation set includes this manual, Arena Contact Center Edition User’s Guide, which cover the product basics; the Arena User’s Guide, which covers the standard product modules and offers an easy, “click-by-click” tutorial; and the Variables Guide, a separate reference booklet providing complete descriptions of Arena variables found in the Arena product templates.

OCUMENT CONVENTIONS

Throughout the guides, a number of style conventions are used to help identify material. New terms and concepts may be emphasized by use of italics or bold; file menu paths are in bold with a (>) separating the entries (e.g., go to Help > Arena Help); text you are asked to type is shown in Courier Bold (e.g., in this field, type and window button names are shown in bold (e.g., click OK).

Work Week

), and dialog

Explore our examples

Arena is accompanied by a number of sample models that illustrate many of the commonly used approaches for capturing the essence of manufacturing processes. Examples are provided for both job shop and flow shop environments. For a description of and list of Arena’s 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 What’s This? help that displays a brief description of fields in dialogs, context- sensitive help on menu and toolbar buttons, and a help button on each of Arena’s modules. Just refer to the Arena help table of contents and index for a list of all help topics.

1 • WELCOME TO ARENA CONTACT CENTER EDITION

Use the SMARTs library

As you craft models of your own manufacturing processes, use our SMARTs library to explore how to best use Arena. This suite of tutorial models covers topics ranging from modeling resources to animation techniques. The library is organized into categories to help you find the right model with ease. When you’re wondering how to take the next step in your model, browse the SMARTs library for a ready-made solution. For a list of categories and their related SMARTS, go to Help > Arena Help. On the Contents tab, first click Model Building Basics, and then Learning Arena with SMART Files.

Access the Arena Symbol Factory

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

Get phone support

Rockwell Automation provides full support for the entire Arena family of products. Questions concerning installation, how modules work, the use of the model editor, and the use of the software are handled by technical support.

• • • • •

1 • Welcome

RENA TECHNICAL SUPPORT INCLUDES

 (for users on active maintenance) a technical support hotline and e-mail address

staffed by full-time, experienced professionals

 help with installation problems or questions related to the software’s requirements  troubleshooting  limited support regarding the interaction of Arena with other programs  support of the Arena Object Model, which is used in Microsoft Visual Basic for

Applications.

If you call the support line (1.440.646.3434), 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.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Get Web support

In addition to phone support, the Rockwell Automation Customer Support Center offers extensive online knowledgebases of tech notes and frequently asked questions for support of non-urgent issues. These databases are updated daily by our support specialists.

To receive regular e-mail messages with links to the latest tech notes, software updates, and firmware updates for the products that are of interest to you or to submit an online support request, register through http://support.rockwellautomation.com/

And be sure to check the Arena User Zone section of our Web site at www.ArenaSimulation.com. The User Zone links to a peer-to-peer forum on Arena topics and has a link to a download page where you can check for possible software updates (patches). If you can’t find the answer you need, contact your local representative or Arena technical support.

Get training

Do you need training? Rockwell Automation offers a standard training course comprised of lecture and hands-on workshops designed to introduce you to the fundamental concepts of modeling with Arena.

We also offer customized training courses designed to meet your specific needs. These courses can be held in our offices or yours, and we can accommodate one person or twenty. You design the course that’s right for you! Simply contact our consulting services group to discuss how we can help you achieve success in your simulation efforts.

Get consulting services

Rockwell Automation provides expert consulting and turnkey implementation of the entire Arena product suite. Please contact your local representative for more information.

Contact us

We strive to help all of our customers become successful in their manufacturing improvement efforts. Toward this objective, we invite you to contact your local representative or Rockwell Automation at any time that we may be of service to you.

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

Corporate E-mail: Arena-Info@ra.rockwell.com

Support phone: 1.440.646.3434

URL: www.ArenaSimulation.com

URL: www.rockwellautomation.com

Introduction to Simulation

This chapter contains excerpts from the simulation textbook written by C. Dennis Pegden, Randall P. Sadowski, and Robert E. Shannon entitled Introduction to Simulation Using SIMAN, Second Edition (McGraw-Hill, 1995).

Simulation defined

Simulation is one of the most powerful analysis tools available to those responsible for the design, analysis, and operation of complex processes or systems. In an increasingly competitive world, simulation has become a very powerful tool for the planning, design, and control of systems. It is viewed today as an indispensable problem-solving methodology for engineers, designers, and managers.

To simulate, according to Webster’s Collegiate Dictionary, is “to feign, to obtain the essence of, without the reality.” According to Schriber [1987], “Simulation involves the modeling of a process or system in such a way that the model mimics the response of the actual system to events that take place over time.” We will define simulation as the process of designing a model of a real system and conducting experiments with this model for the purpose of understanding the behavior of the system and/or evaluating various strategies for the operation of the system. We consider simulation to include both the construction of the model and the experimental use of the model for studying a problem. Thus, you can think of simulation modeling as an experimental and applied methodology that seeks to accomplish the following:

 describe the behavior of systems,

 construct theories or hypotheses that account for the observed behavior, and

 use the model to predict future behavior; i.e., the effects produced by changes in the

system or in its method of operation.

The terms “model” and “system” are key components of our definition of simulation. By model, we mean a representation of a group of objects or ideas in some form other than that of the entity itself. By system, we mean a group or collection of interrelated elements that cooperate to accomplish some stated objective. We can simulate systems that already exist and those that can be brought into existence; i.e., those in the preliminary or planning stage of development.

2 • Introduction to Simulation

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

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

express ideas and objects. Historically, modeling has taken many forms: from communicating through wall paintings to writing complex systems of mathematical equations for the flight of a rocket through outer space. As a matter of fact, the progress and history of science and engineering are reflected most accurately in the progress of our ability to develop and use models.

One of the major elements required in attacking any problem is the construction and use of a model. We use models because we want to learn something about some real system that we cannot observe or experiment with directly—either because the system does not yet exist, or because it is too difficult to manipulate. A carefully conceived model can strip away the complexity, leaving only that which the analyst finds important. Such a model can take many forms, but one of the most useful—and certainly the most often used—is simulation.

Likewise, the concept of systems plays a critical role in our modern view of the world. The fundamental idea of thinking about the world in terms of systems and trying to take the systems approach to attacking problems has become so ingrained in contemporary practice that we tend to take it for granted. The systems approach tries to consider total system performance rather than simply concentrating on the parts [Weinberg, 1975]; it is based on our recognition that, even if each element or subsystem is optimized from a design or operational viewpoint, overall performance of the system may be suboptimal because of interactions among the parts. The increasing complexity of modern systems and the need to cope with this complexity underscore the need for engineers and managers to adopt a systems approach to thinking.

Although complex systems and their environments are objective (i.e., they exist), they are also subjective (i.e., the particular selection of included (and excluded) elements and their configuration is dictated by the problem solver). Different analyses of the same objective process or phenomenon can conceptualize it into very different systems and environments. For example, a telecommunications engineer may think of a contact center system as a collection of trunk lines and routing scripts. The contact center director, however, is more likely to view the system as the combination of phone lines, scripts, contacts, agents, and schedules. The vice president in charge of contact center operations may see the system as the collection of all the centers her company runs/along with all outsourcers under contract. Hence, several different conceptualizations of any particular real-world system— and thereby several different models—can simultaneously exist.

System elements are the components, parts, and subsystems that perform a function or process. The relationships among these elements and the manner in which they interact determine how the overall system behaves and how well it fulfills its overall purpose. Therefore, the first step in creating any model is to specify its purpose. There is no such thing as the model of a system: we can model any system in numerous ways, depending on what we wish to accomplish. Both the elements and the relationships included must be

chosen to achieve a specific purpose. The model developed should be as simple as the stated purpose will allow.

The types of simulations of interest here are those used to develop an understanding of the performance of a system over time. We typically use simulation models to help us explain, understand, or improve a system. To be effective, simulation must concentrate on some previously defined problem (otherwise, we do not know what elements to include in the model or what information to generate and collect). We typically use models to predict and compare—that is, to provide a logical way of forecasting the outcomes that follow alternative actions or decisions and (we hope) to indicate a preference among them. Although this use of models is important, it is by no means its only purpose. Model building also provides a systematic, explicit, and efficient way to focus judgment and intuition. Furthermore, by introducing a precise framework, a simulation model can effectively communicate system configuration and assist the thought process.

Advantages of simulation

Because its basic concept is easy to comprehend, a simulation model is often easier to justify to management or customers than some of the analytical models. In addition, simulation might have more credibility because its behavior has been compared to that of the real system or because it has required fewer simplifying assumptions and thereby has captured more of the true characteristics of the real system.

• • • • •

2 • INTRODUCTION TO SIMULATION

2 • Introduction to Simulation

Virtually all simulation models are so-called input-output models; that is, they yield the output of the system for a given input. Simulation models are therefore “run” rather than “solved.” They cannot generate an optimal solution on their own as analytical models can; they can only serve as tools for the analysis of system behavior under specified conditions. (The exception is a simulation model used to find the optimum values for a set of control variables under a given set of inputs.)

We have defined simulation as experimentation with a model of the real system. An experimental problem arises when a need develops for specific system information that isn’t available from known sources. The following list describes some of the benefits associated with simulation.

 In a contact center, the impact of new types of contacts, new agent schedules, modi-

fied contact priorities, contact volumes, and other key inputs can be explored without disrupting ongoing operations.

 New routing scripts or transfer logic can be tested before committing resources to

implementation.

 Hypotheses about how or why certain phenomena occur can be tested for feasibility.

 Time can be controlled: it can be compressed, expanded, etc., allowing us to speed up

or slow down a phenomenon for study.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

 Insight can be gained about which variables are most important to performance and

how these variables interact.

 A simulation study can prove invaluable to understanding how the system really

operates as opposed to how everyone thinks it operates.

 New situations, about which we have limited knowledge and experience, can be

manipulated in order to prepare for theoretical future events. Simulation’s great strength lies in its ability to let us explore “what if” questions.

The simulation process

The essence or purpose of simulation modeling is to help the ultimate decision maker solve a problem. Therefore, to learn to be a good simulation modeler, you must merge good problem-solving techniques with good software engineering practice. The following steps should be taken in every simulation study.

1. Problem Definition. Defining the goals of the study clearly so that we know the purpose; i.e., why are we studying this problem and what questions do we hope to answer? What is the business impact of these answers?

2. Project Planning. Being sure that we have sufficient personnel, management support, computer hardware, and software resources to do the job with a relevant timetable.

3. System Definition. Determining the boundaries and restrictions to be used in defining the system (or process) and investigating how the system works.

4. Conceptual Model Formulation. Developing a preliminary model either graphically (e.g., block diagrams) or in pseudo-code to define the components, descriptive variables, and interactions (logic) that constitute the system.

5. Preliminary Experimental Design. Selecting the measures of effectiveness to be used, the factors to be varied, and the levels of those factors to be investigated; i.e., what data need to be gathered from the model, in what form, and to what extent.

6. Input Data Preparation. Identifying and collecting the input data needed by the model.

7. Model Translation. Formulating the model in an appropriate simulation language or software package such as Arena Contact Center Edition.

8. Verification and Validation. Confirming that the model operates the way the analyst intended (debugging) and that the output of the model is believable and representative of the output of the real system.

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 can’t necessarily make the final decision, but who is responsible for making recommendations. In such a case, the results of the study may have to serve two purposes simultaneously: helping the sponsor to formulate the recommendations; and justifying, supporting, and helping to sell those recommendations.

• • • • •

2 • INTRODUCTION TO SIMULATION

2 • Introduction to Simulation

We begin our analysis by collecting enough information and data to provide an adequate understanding of both the problem and the system to be studied. A typical project begins with the description of the situation to be modeled in a general and imprecise way, in terms such as service levels, agent utilization, abandonment rates, or other key system performance measures. We must view the problem description as a set of symptoms requiring diagnosis. We begin, therefore, by diagnosing the symptoms; then we define the problem; and, finally, we formulate a model.

To make that diagnosis, we must become thoroughly familiar with all relevant aspects of the organization’s operations, including influential forces (or factors) outside the organization and the subjective and objective aspects of the problem. Minimally, we should perform the following steps.

1. Identify the primary decision maker(s) and the decision-making process relative to the system being studied.

2. Determine the relevant objectives of each of those responsible for some aspect of the decision.

3. Identify other participants in the final decision (especially those likely to oppose changes in the system) and determine their objectives and vested interests.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

4. Determine which aspects of the situation are subject to the control of the decision maker(s) and the range of control that can be exercised.

5. Identify those aspects of the environment or problem context that can affect the outcome of possible solutions but that are beyond the control of the decision maker(s).

An important aspect of the planning phase involves ensuring that we have considered certain factors critical to project success:

 Clearly defined goals. Do we know the purpose of the study—i.e., why are we doing

it and what do we expect to find?

 Sufficient resource allocation. Are we sure that there is sufficient time, personnel,

and computer hardware and software available to do the job?

 Management support. Has management made its support for the project known to all

concerned parties?

 Project plans and schedules. Are there detailed plans for carrying out the project?

What are the key dates?

 Competent project manager and team members. Are we assured of having the

necessary skills and knowledge available for successful completion of the project?

 Responsiveness to the clients. Have all potential users of the results been consulted

and regularly apprised of the project’s progress?

 Adequate communication channels. Are we continually concerned that sufficient

information is available on project objectives, status, changes, user or client needs, etc., to keep everyone (team members, management, and clients) fully informed as the project progresses?

The major thrust of the planning and orientation period is the determination of the explicit goals or purpose of the simulation project. Simulation experiments are conducted for a wide variety of purposes, including the following:

 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.

2 • INTRODUCTION TO SIMULATION

 Optimization: determining exactly which combination of factor levels produces the

best overall system response.

 Functional relations: establishing the nature of the relationships among one or more

significant factors and the system’s response.

Although not exhaustive, this list identifies the most common simulation goals or purposes. The explicit purpose of the model has significant implications for the entire model-building and experimentation process. For example, if a model’s goal is to evaluate a proposed (or existing) system in an absolute sense, then the model must be accurate; and there must be a high degree of correspondence between the model and the real system. On the other hand, if the goal for a model is the relative comparison of two or more systems or operating procedures, the model can be valid in a relative sense even though the absolute magnitude of responses varies widely from that which would be encountered in the real system. The entire process of designing the model, validating it, designing experiments, and drawing conclusions from the resulting experimentation must be closely tied to the specific purpose of the model. No one 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.

• • • • •

2 • Introduction to Simulation

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 component’s significance to the overall goal is not always clear. One of the key questions to be answered is whether a particular component should be considered part of the model or part of the outside environment, which is represented as inputs to the model.

In general, we have little difficulty deciding on the output variables. If we have done a good job specifying the goals or purposes of the study, the required output variables become apparent. The real difficulty arises when we try to determine which input and status variables produce the effects observed and which can be manipulated to produce the effects desired.

We also face conflicting objectives. On the one hand, we try to make the model as simple as possible for ease of understanding, ease of formulation, and computational efficiency.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

On the other hand, we try to make the model as accurate as possible. Consequently, we must simplify reality—but only to the point where there is no significant loss of accuracy of outputs with respect to the study’s objectives.

We want to design a model of the real system that neither oversimplifies the system to the point where the model becomes trivial (or worse, misleading) nor carries so much detail that it becomes clumsy and prohibitively expensive. The most significant danger lies in having the models become too detailed and including elements that contribute little or nothing to understanding the problem. Frequently, the analyst includes too much detail, rather than too little. The inexperienced tend to try to transfer all the detailed difficulties in the real situation into the model, hoping that the computer will somehow solve the problem.

This approach is unsatisfactory: it increases programming complexity (and the associated costs for longer experimental runs), and it dilutes the truly significant aspects and relationships with trivial details. The definition of the model boundary is usually a tradeoff between accuracy and cost. The greater the degree of detail to be modeled, the more precise and expensive the required input data. Therefore, the model must include only those aspects of the system relevant to the study objectives.

One should always design the model to answer the relevant questions and not to imitate the real system precisely. According to Pareto’s law, in every group or collection of entities there exist a vital few and a trivial many. In fact, 80% of system behavior can be explained by the action of 20% of its components. Nothing really significant happens unless it happens to the significant few. Our problem in designing the simulation model is to ensure that we correctly identify those few vital components and include them in our model.

Once we have tentatively decided which components and variables to include in our model, we must then determine the functional relationships among them. At this point, we are trying to show the logic of the model; i.e., what happens. Usually we use a flowchart or pseudo-code to describe the system as a logical flow diagram.

Experimental design

We have defined simulation as being experimentation via a model to gain information about a real-world process or system. It then follows that we must concern ourselves with the strategic planning of how to design an experiment (or experiments) that will yield the desired information for the lowest cost. The next step, therefore, is to design an experiment that will yield the information needed to fulfill the study’s goal or purpose.

The design of experiments comes into play at two different stages of a simulation study. It first comes into play very early in the study, before the model design has been finalized. As early as possible, we want to select which measures of effectiveness we will use in the study, which factors we will vary, and how many levels of each of those factors we will investigate. By having this fairly detailed idea of the experimental plan at this early stage, we have a better basis for planning the model to generate the desired data efficiently.

2 • INTRODUCTION TO SIMULATION

Later, after we have developed the model, verified its correctness, and validated its adequacy, we again need to consider the final strategic and tactical plans for the execution of the experiment(s). We must update project constraints on time (schedule) and costs to reflect current conditions, and we must impose these constraints on the design. Even though we have exercised careful planning and budget control from the beginning of the study, we must now take a hard, realistic look at what resources remain and how best to use them. At this point, we adjust the experimental design to account for remaining resources and for information gained in the process of designing, building, verifying, and validating the model.

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 (with-

out excessive expenditure of time and resources) is largely a function of choosing the right design.

• • • • •

2 • Introduction to Simulation

We conduct simulation studies primarily to learn the most about the behavior of the system for the lowest possible cost. We must carefully plan and design not only the model but also its use. Thus, experimental designs are economical because they reduce the number of experimental trials required and provide a structure for the investigator’s learning process.

Input data

Stochastic systems contain one or more sources of randomness. The analyst must be concerned about data related to the inputs for the model such as the contact-volume forecasts, contact-arrival patterns, and contact-handle times. Although data gathering is usually interpreted to mean gathering numbers, this interpretation addresses only one aspect of the problem. The analyst must also decide what data is needed, what data is available, whether the data is pertinent, whether existing data is valid for the required purpose, and how to gather the data.

The design of a stochastic simulation model always involves choosing whether to represent a particular aspect of the system as probabilistic or deterministic. If we opt for probabilistic and if empirical data exist, then we must make yet another decision. Will we sample directly from the empirical data, or will we try to fit the data to a theoretical distribution and, if successful, sample from the theoretical distribution? This choice is fundamentally important for several reasons.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

First, using raw empirical data implies that we are only simulating the past; by using data from one year, we replicate the performance of that year but not necessarily of future years. When sampling directly from historical data, the only events possible are those that transpired during the period when the data was gathered. It is one thing to assume that the basic form of the distribution will remain unchanged with time; it is quite another to assume that the idiosyncrasies of a particular year will always be repeated.

Second, it is much easier to change certain aspects of the input if theoretical random variate generation is being used; i.e., there is greater flexibility. For example, if we want to determine what happens if inputs increase by 10% per week, we need only increase the mean arrival rate of the theoretical distribution by the required 10%. On the other hand, if we are sampling directly from the empirical data, it is not clear how we increase the contact arrival rate by the required amount.

Third, it is highly desirable to test the sensitivity of the system to changes in the parameters. For example, we may want to know how much the contact arrival rate can increase before system performance deteriorates to an unacceptable degree. Again, sensitivity analysis is easier with theoretical distributions than with sampling directly from empirical data.

The problem is exacerbated when no historical behavioral data exist (either because the system has not yet been built or because the data cannot be gathered). In these cases, we must estimate both the distribution and the parameters based on theoretical considerations.

Verification and validation

After the development of the model is functionally complete, we should ask ourselves a question: Does it work? There are two aspects to this question. First, does it do what the analyst expects it to do? Second, does it do what the user expects it to do? We find the answers to these questions through model verification and validation. Verification seeks to show that the computer program performs as expected and intended, thus providing a correct logical representation of the model. Validation, on the other hand, establishes that model behavior validly represents that of the real-world system being simulated. Both processes involve system testing that demonstrates different aspects of model accuracy.

Verification can be viewed as rigorous debugging with one eye on the model and the other eye on the model requirements. In addition to simply debugging any model development errors, it also examines whether the code reflects the description found in the conceptual model. One of the goals of verification is to show that all parts of the model work, both independently and together, and use the right data at the right time.

The greatest aid to program verification is correct program design, followed by clarity, style, and ease of understanding. Very often, simulation models are poorly documented, especially at the model statement level. Verification becomes much easier if the analyst comments the model liberally. This includes comments wherever Arena Contact Center

2 • INTRODUCTION TO SIMULATION

enables the modeler to enter them, as well as separate documentation of model assumptions, model inputs, and logical relationships.

Validation is the process of raising to an acceptable level the user’s confidence that any simulation-derived inference about the system is correct. Validation is concerned with three basic questions:

 Does the model adequately represent the real-world system?

• • • • •

 Are the model-generated behavioral data characteristic of the real system’s behavioral

data?

 Does the simulation model user have confidence in the model’s results?

Consequently, we are concerned with tests that fall into three groups: tests of model structure, tests of model behavior, and tests of the policy implications of the model.

Because a model is constructed for a specific purpose, its adequacy or validity can only be evaluated in terms of that purpose. We try to build a model that creates the same problems and behavioral characteristics as the process or system being studied. Validation occurs throughout model development, beginning with the start of the study and continuing as the model builder accumulates confidence that the model behaves plausibly and generates symptoms or modes of behavior seen in the real system. Validation then expands to include persons not directly involved in constructing the model.

Validation is a communication process requiring the model builder to communicate the basis for confidence in a model to a target audience. Unless that confidence can be transferred, the model’s usefulness will never be realized. Thus, through verification testing, we develop personal confidence in the model and, through validation measures, transfer that confidence to others.

We must realize that there are degrees of validation; it is not merely an either-or notion. Validation is not a binary decision variable indicating whether the model is valid or invalid. No one or two tests can validate a simulation model. Rather, confidence in the usefulness of a model must gradually accumulate as the model passes more tests and as new points of correspondence between model and reality are found. Validation testing occurs continually in the process of designing, constructing, and using the model.

2 • Introduction to Simulation

We should also remember that verification and validation are never really finished. If the model is to be used for any period of time, the data and the model itself will need periodic review to ensure validity. Verification and validation are intertwined and proceed throughout the study. They are not tacked on toward the end of the study; rather, they are an integral process that starts at the beginning of the study and continues through model building and model use. It should also be pointed out that involving the ultimate user in the entire simulation process makes validation much easier.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

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 model’s useful life and greatly increase the chances that recommendations based on the model will be accepted. Good documentation facilitates modification and ensures that the model can be used—even if the services of the original developers are no longer available. In addition, careful documentation can help us to learn from previous mistakes; it may even provide a source of submodels that can be used again in future projects.

Amazingly, modelers often spend a great deal of time trying to find the most elegant and efficient ways to model a system, and then they throw together a report for the sponsor or user at the last minute. If the results are not clearly, concisely, and convincingly presented, they will not be used. If the results are not used, the project is a failure. Presenting results is as critical a part of the study as any other part, and it merits the same careful planning and design.

Several issues should be addressed in model and study documentation: appropriate vocabulary (i.e., suitable for the intended audience and devoid of jargon), concise written reports, and timely delivery. We must also ensure that all reports (both oral and written) are pertinent and address the issues that the sponsor or user considers important.

References

McKay, K. N., J. A. Buzacott, and C. J. Strang (1986), “Software Engineering Applied to

Discrete Event Simulation,” in Proceedings of the 1986 Winter Simulation Confer- ence, Washington, D.C., pp. 485-493.

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

Systems,” in Simulation in CIM and Artificial Intelligence Techniques, J. Retti and K. E. Wichmann (eds.), Society for Computer Simulation, pp. 5-18.

Sheppard, S. (1983), “Applying Software Engineering to Simulation,” Simulation, vol.

10, no. 1, pp. 13-19.

Weinburg, G. M. (1975), An Introduction to General Systems Thinking, John Wiley &

Sons, Inc., New York, NY.

General Concepts

This chapter provides a high-level overview of the components of a model built using Arena Contact Center Edition. In particular, this chapter explains the terminology used within the software and the type of information that is needed to represent the way in which contacts arrive and are processed in a contact center system, which is referred to as the Contact Center Core Process. The major modeling elements are also described in some detail.

Once you have read this chapter, you will have a better understanding of the process of creating a model with Arena Contact Center Edition.

Overview

The basic process of contact center simulation is to generate a stream of arriving contacts, assign them to trunk lines, and route them through the center to an agent. To create a simulation model of a contact center or network of contact centers, you will describe the sequence of events that occur as contacts move through the system, from the arrival of the contacts at the contact center to successful resolution. You will also need to specify information about the contact center itself (trunk-line capacity, agent skills, agent schedules, etc.).

As you build your contact center models, it may be helpful to keep in mind the Contact Center Core Process, as illustrated below.

3 • General Concepts

The basic components of this process are:

 Contacts  Arrival Patterns  Trunk Groups  Routing Scripts  Schedules  Agents

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

The relationships between these components are illustrated below.

Trunk Groups

Contacts

Pattern

In addition, the length of the simulation run (see “Planning horizon”) and granularity of data specification and collection (see Timeslots) need to be specified. Animation and performance measure reporting are also important components of models.

Planning horizon

The planning horizon is defined as the time period that is being examined by a particular simulation model. The planning horizon is typically one day, one week, or one month.

Routing Scripts

Queueing to

Parent Groups

(containing one or

more Agent Groups)

Queueing to

Agent Skills

Agent

Groups

Individual

Agents

Agent Groups

Agent

Schedules

Timeslots

The planning horizon is broken into specific timeslots for data specification and collection. These intervals are typically 30 minutes or one hour long.

With Arena Contact Center Edition, the basic unit of time is the minute. With the exception of the planning horizon, trunk costs, agent costs, and contact service level, all inputs are in terms of minutes or fractions of minutes.

Contact types

Describing the different types of contact is generally the starting point for contact center modeling and analysis. Each contact name represents a particular customer request for agent services. It is characterized by the expected talk time, as well as the associated arrival pattern and the trunk group on which the contacts enter the center.

The following more advanced aspects of contact behavior may also be modeled using Arena Contact Center Edition:

 Abandonment  After-Contact Work  Prioritization  Contact Back

Data sources

Information about contact volumes is typically taken from forecasts while expected talk time is available either from contact center ACD databases or from a contact center’s contact-tracking system.

• • • • •

3 • GENERAL CONCEPTS

3 • General Concepts

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.

XAMPLE

Suppose that the planning horizon is one day (24 hours), the timeslots are 60 minutes long. Then, if the arrival pattern specifies that 240 contacts are handled during the 10:00

11:00 10:00

timeslot, the simulation model would assume 240 expected contacts during the

-11:00 AM timeslot. The Poisson arrival rate for the timeslot is 0.25 (60/240) or,

on average, one contact every 15 seconds.

Data sources

Arrival pattern data is available either from contact center ACD databases or from a contact center’s tracking system.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Trunk Groups

Trunk Groups represent groups of phone lines that are dedicated to a particular set of contact types. A single trunk group can serve multiple contact types and names, but only one trunk group may serve each contact name. Trunk groups have an associated capacity (# of lines), cost, and a default routing script and contact priority. Any incoming contact assumes the default priority and follows the default routing script unless these attributes are overridden at the contact level.

Note that trunk-line capacity determines the maximum number of contacts that the contact center can accommodate simultaneously. If a trunk line is not available when a contact attempts to enter the center, the contact is blocked and does not gain entry. Otherwise, the contact is attached to a trunk line and remains with that particular line until exiting the center or until transferring to another trunk line.

Data sources

Fundamental components of the contact center infrastructure, trunk-line organization, and capacity are typically specified in the phone-switching hardware.

Routing Scripts

Routing Scripts are sequences of actions that control the flow of contacts through the center’s system. This will result in contacts being connected with agents, leaving messages, being disconnected, or abandoning the center.

From a simulation modeling perspective, scripts allow contact flow logic to be categorized into six general areas:

1. Time delays (playing announcements, music, doing nothing—waiting)

2. Conditional route branching (caller-entered information, center dynamics)

3. Allocation of contacts into queues (single or simultaneous) or message ports

4. Contact prioritization within queues (ranking)

5. Contact flow between queues (movement of contacts out of and into queues, overflow from one queue into another)

6. Contact flow between scripts

Data sources

These command sequences are generally referred to as “scripts,” although each switch vendor has a different name for their particular variety (i.e., Vector, Telescript, Call

Control Table). These scripts specify the actions, activities, and states that each contact undergoes as it attempts to reach an agent.

The process of creating routing scripts that match the behavior of your ACD switch and assigning these scripts to specific contact names is described in more detail in Chapter 6.

Agent Skill Sets

Agent Skill Sets are composed of three elements that define how particular contacts are processed. The agent’s repertoire of handling skills specifies what contacts the agent is skilled to handle, the priority (or order) in which the agent will perform available work, and the agent’s proficiency in each contact name, expressed as a multiplier of average talk time for the contact name.

Data sources

Estimates of handling proficiency may be obtained from careful study of handle time statistics collected from the ACD database or tracking system, or based on the expertise of group managers. For example, a group of experienced agents may have a very high proficiency level, while a group of newly hired agents may experience significantly higher handle times.

• • • • •

3 • GENERAL CONCEPTS

3 • General Concepts

Schedules

Schedules dictate when agents are available to handle contacts. Each schedule specifies on-duty shifts for each day in the planning horizon. In addition to phone time, these schedules can include lunches, breaks, meetings, or other off-duty time that is spent away from the phones.

Data sources

Agent schedules can usually be obtained from a human resources or a planning and analysis group.

Agent Groups

Agents are the primary resource of the contact center. An Agent Group represents a group of agents within the contact center who have the same skill sets and follow the same schedule. From a modeling perspective, an agent group is a set of identical agents. In building a model, the key questions to answer regarding agent groups are:

 How many agents are in this group?  What hours do these agents work?  What types of contacts can an agent of this type handle, and in what priority order?  How long does it take for these agents to handle each contact name?

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

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 defini-

tions (multiple schedules, sites, groups, etc.)

 Collect statistics across a set of agent groups

Data sources

Parent group definition typically supports contact routing and may depend on the purpose of the simulation study. However, if a model is being made of current contact center operations, insight into parent groupings may be obtained from examination of existing routing scripts.

Queues

Queues are the mechanism by which contacts and agents interact in the contact center. Each agent group has a queue associated with it to hold its contacts while they wait to be handled. Contacts may move from one queue (i.e., one agent group) to another before being serviced, based upon the routing script that is assigned to that contact name.

Note that while queues are an important concept to understand, the data and logic associated with queues are specified in the Agent and Script modules and related modules located on the Script panel (i.e., Queue for Agent module, Transfer to Agent module, etc.).

Animation

Simulation animation is intended to provide dynamic graphical insight into contact center conditions. A variety of plots, graphs, and counters are available to animate specific contact center elements. These animations are often useful for validation and verification of the contact center model.

Performance measures/reporting

In addition to a default report covering the entire planning horizon, there are focused reports that collect and report data by user-defined timeslot. These results quantify the impact of various changes on contact center operations. Contact center reports are available for:

 Contact counts  Contact times  Agent utilization  Trunk utilization  Overflow

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

• • • • •

3 • GENERAL CONCEPTS

3 • General Concepts

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Features

This chapter is intended to provide a description of all Arena Contact Center Edition features. Once you have read this chapter, you will have a better understanding of the capabilities of the software and the simulation process.

The features described in this chapter are organized as follows:

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

Different stages in the contact life span

This section describes the potential avenues that a contact may travel as it moves through the contact center, as shown in Figures 4.1 and 4.2. Each stage is described and identified as either optional or required to the model. Particular attention is given to the module(s) involved in each stage.

Contact arrives

in Contact Center

TIME

If no trunk line is available, the contact is blocked from entering the Contact Center.

Depending on model input, these contacts may be eligible for contact back.

If not blocked, the contact follows its script and begins to queue for agent group or parent group

While queueing, a contact may become disconnected or leave a message and hang up.

disconnected, or abandoned, the contact

Figure 4.1 The path of a contact before processing begins

If not blocked,

reaches the front of its queue here.

Contact seizes agent, begins to receive service here.

Depending on its abandonment distribution and amount of time spent in queue, the contact may abandon the queue.

4 • Features

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Contact begins to

receive service from

an agent

TIME

Contact receives service from primary agent. Depending upon input data, contact may also receive service from conference agent.

*ACW: "After Contact Work" is time spent by an agent on finishing a contact (paperwork, logging, etc.) after the contact itself has been completed.

Contact completes

service

Contact transferred to another agent or to a script (remains in the center)

ACW*

Contact departs center (may contact back based on model input data)

Figure 4.2 The path of a contact after processing begins

Contact arrival (required)

For each timeslot, contacts of a particular name arrive according to a Poisson process with an arrival rate based on the expected contact volumes per timeslot, which are defined in the associated pattern module. Upon arrival at the contact center, a contact is assigned to a trunk line from the trunk group associated with that contact name.

Arrivals may also be generated by contact returning to the contact center (contact backs) after being blocked, abandoned, or disconnected, as well as contact backs due to messages or previously “served but unresolved” contacts.

ELEVANT 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.

ELEVANT MODULES AND RELATED CONCEPTS

 Trunk groups are defined in the Configuration module and associated with a contact

name in the Contact module.

4 • FEATURES

 Contact back is defined in the Contact Back section of the Contact module. It is

described further in this section.

Offered contacts (required)

When an arriving contact is able to secure a trunk line, it is considered to be offered to the contact center for service. The newly offered contact then begins to follow the routing logic specified in its associated script.

ELEVANT MODULES AND RELATED CONCEPTS

 Trunk groups are defined in the Configuration module and associated with a contact

name in the Contact module.

 Scripts are defined by connecting a series of modules located on the Script 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.

ELEVANT MODULES AND RELATED CONCEPTS

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

 Once defined for a contact, abandonment logic is initiated during 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 further in the “Contact back” section below.

Disconnected contacts (optional)

Contacts may be disconnected (i.e., dispatched from the contact center) by their controlling routing script.

Once a contact has been disconnected, it may contact back, depending on the model.

4 • Features

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

ELEVANT MODULES AND RELATED CONCEPTS

 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.

ELEVANT MODULES AND RELATED CONCEPTS

 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.

ELEVANT MODULES AND RELATED CONCEPTS

 Handling skills are defined in the Talk Time section of the Agent module.

 Contacts are connected to agents through the queueing process triggered by the Queue

for Agent module located on the Script panel and described in greater detail in the following section.

 Contact transfer is defined via the Transfer to Agent module located on the Script

panel. It is described further in the “Contact transfer” section below.

4 • FEATURES

Talk time (required)

Talk time is the time an agent spends on the line with a contactor. The expected talk time for a contact name is specified in the main section of the Contact module. This value is used as the mean of an exponential distribution. In the advanced Contact module dialog, the basic exponential talk time distribution can be replaced with any general distribution.

Individual talk times for each contact are generated whenever the contact is assigned to an agent. Within the Agent module, talk time multipliers are specified to account for agent proficiency. The generated contact time is multiplied by this factor to determine the actual talk time for the contact.

ELEVANT MODULES AND RELATED CONCEPTS

 Expected talk time is specified in the Contact module. The distribution for talk time

can be overridden in the Advanced section of the Contact module.

 Adjustments to talk time to reflect agent proficiency are made through multipliers

defined within the Talk Time section of the Agent module.

Conference (optional)

Conferencing describes the situation where an agent can include an additional agent (like a supervisor) for assistance in contact resolution. Conference is modeled using the Conference module located on the Script panel. This module is for use within the Queue for Agent module only. The Queue for Agent module has three Advanced features that allow external logic to be specified at three different times; After Seizing Agent, After Talk Time, and Prior to Post Contact Work. The Conference module must be used with the After Talk Time option. By connecting this module to the special exit point created for the advanced Queue for Agent option, a contact can be conferenced with another agent after the primary agent’s talk time is complete.

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.

• • • • •

4 • Features

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.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

ELEVANT MODULES AND RELATED CONCEPTS

 Contacts requiring conference are specified by the contact’s script. The contact must

be directed to a Conference module. This module can only be used in the After Talk Time external logic of a Queue for Agent module.

 Specifics of which agent to be included in the conference and the conference time are

detailed in the Conference module from the Script panel.

Transfer (optional)

Transfer describes the situation where the primary agent routes a contact to a transfer agent who then takes over complete responsibility for the contact. Transfer is modeled by using the Transfer to Agent module in a contact’s script.

The Transfer to Agent module is for use within the Queue for Agent module only. The Queue for Agent module has three Advanced features that allow external logic to be specified at three different times: After Seizing Agent, After Talk Time, and Prior to Post Contact Work. The Transfer to Agent module must be used with the Prior to Post Contact Work option. By connecting this module to the special exit point created for the advanced Queue for Agent option, a contact can be directed to another agent after the first agent’s tasks are complete.

Multiple-agent transfer can be modeled by connecting a series of Transfer to Agent modules. The original agent is released before the contact is transferred to the next agent. Each transfer is performed in series. Therefore, the primary agent does not participate in the next (transfer) agent’s activities, and so on.

Transfer takes place immediately following the completion of talk time.

Transfer is an optional consideration in that a contact will only be transferred if the transfer agent is available immediately to receive the contact (i.e., the contact will not be re-queued).

ELEVANT MODULES AND RELATED CONCEPTS

 Contacts potentially requiring transfer are specified by the contact’s script. The

contact must be directed to a Transfer to Agent module. This module can only be used in the Prior to Post Contact Work external logic of a Queue for Agent module.

 Specifics of which agent and the talk time incurred with the transfer agent are detailed

in the Transfer to Agent module from the Script panel.

After-contact work (optional)

To model the time the primary agent must spend completing a contact (wrap-up, documentation, research, etc.) after they are finished with the contactor, an After Contact

4 • FEATURES

Time distribution may be specified in the Advanced section of the Contact module. An individual after-contact time is generated from this distribution for every contact of this contact name.

The primary agent completes all after-contact work, beginning immediately upon completion of primary service. Primary service includes any activity if specified in the After Talk Time logic of the Queue for Agent module (e.g., conferences with other agents).

ELEVANT MODULES AND RELATED CONCEPTS

 The After Contact Time distribution is defined in the Advanced section of the Contact

module.

 Talk time is described earlier in this section.

Contact back (optional)

Contacts can terminate in one of the following ways:

 Blocked  Abandoned  Disconnected  Served  Message

• • • • •

In each case, there is a certain probability that the contactor will attempt to return to the contact center for more service. Therefore, for each case, the probability of contact back and a distribution on the amount of time the contactor will wait before contacting back may be specified.

Served contacts are those that leave the contact center immediately following service from an agent.

ELEVANT MODULES AND RELATED CONCEPTS

 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:

4 • Features

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

 Queue construction. What is the relationship between queues and agents?

 Queue ranking. What happens to the contact while waiting within the queue?

 Agent selection. What happens when the contact gets to the front of the queue?

A discussion of

skill-based routing

, a powerful routing strategy linking all three categories,

is also included.

Queue construction

Queues are automatically created for each defined agent group. Contacts are placed in an agent group queue via the Queue for Agent module located in the Script panel. The only difference, from a functionality standpoint, is whether the associated group is an Agent Group or a Parent Group.

Direct queueing involves placing a contact in the queue directly associated with an agent group. These contacts will be served only by members of that specific agent group.

Simultaneous queueing enables a contact to wait for an agent from any number of agent groups. This is accomplished by queueing the contact to a parent group, effectively queueing it simultaneously to all member agent groups. The contact will then be assigned to an available agent from any of the member agent groups. This type of simultaneous queueing is provided by most ACD vendors.

An agent group may be a member of multiple parent groups in addition to having its own direct queue to serve. Note that this implies that there can be situations in which multiple contacts waiting in multiple queues are simultaneously requesting service from that agent group. It is important to remember that each agent group can potentially serve multiple queues, each being physically separate from the others.

Queue ranking

All queues are ranked based on the priority of the contacts they contain. Different contact names may have different priorities while waiting for service from agents. This priority may depend on the contact names themselves (e.g., Purchase customers get priority over Refund customers) or on the agent group (e.g., Experts give priority to Windows calls over DOS calls).

Contacts are assigned a default priority (associated with the trunk group defined within the Configuration module) upon entering the contact center. This default priority may be overridden (within the Contact module) for each contact name.

When a contact is queued to an agent group, its priority may again be overridden based on the group definition. Within the Agent module, an override contact priority may be specified for each contact name that the agent group services.

4 • FEATURES

Agent skill priorities at the parent group level do not apply to contacts queued directly to a member agent group and vice versa.

Also, the priority of an individual contact may be adjusted by its routing script depending on contact center conditions (see the Priority module). Each time the priority of a contact changes, the contact is reordered within its queue.

A contact’s priority will revert to its pre-queue priority upon leaving a queue and revert to its initial priority when contacting back.

Agent selection

Once a contact has reached the front of its queue, the only remaining consideration is which agent resource to select for service.

All agents within an agent group are identical. Therefore, if the queue belongs to an agent group, resource selection is quite simple—the contact is assigned to the next available agent.

If the queue belongs to a parent group, resource selection is considerably more complicated, although it falls nicely into the following two categories:

 Multiple-member agent groups have available agents  No agents are available

• • • • •

ULTIPLE 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 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).

AGENTS AVAILABLE

If there are no agents available to service the contact immediately, the contact must wait. Once an agent becomes available, the contact normally would be assigned immediately to the agent unless there were multiple waiting contacts simultaneously laying claim to the agent. Recall that this is a possibility in models where agent groups belong to one or more parent groups.

In this case, priorities come back into play. Among those contacts in position to select the newly available agent, the one with the highest priority will be assigned. While that is straightforward, there is one additional concept that applies in this situation. The current

4 • Features

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

contact priorities for all candidate contacts may be overridden one final time by the agent skill priorities associated with the available agent (see Agent module for more details).

Basically, this means that the priorities of the candidate contact names are redefined from the point of view of the agent’s skills, enabling the agent to serve the contact he is most capable of handling. Note that the current contact priority will be preserved for any contact type for which the agent has no defined agent skill priority.

Skill-based routing

Skill-based routing ensures that each contact is assigned to the best available agent and that agents focus on serving the contacts for which they are most proficient.

There are three components to skill-based routing:

 Simultaneous queueing. Contacts are queued to all Agent Groups (via a Parent

Group) capable of serving their particular contact name.

 Preferences. Contacts select the most qualified agent from among all available

agents.

 Agent skill priorities. Agents select the type of work they are most proficient in from

among all waiting contacts requesting their service.

Arena Contact Center Edition supports skill-based routing in a very natural and elegant manner by combining these three features.

Routing script construction

This section describes the features of Arena Contact Center Edition that are available for representing the contact-routing logic employed by your system.

For the purpose of creating a realistic simulation model, the elemental functions of the phone switches have been condensed into modules that are pieced together to form routing scripts within a model. Using these modules as building blocks, extremely complex contact-routing logic can be incorporated into your contact center simulation.

Each module is briefly described below.

Begin Script

The Begin Script module simply identifies a script by defining the script’s name.

Queue for Agent

A Queue for Agent module simply places the contact within the specified agent group queue where it is ranked according to its active priority and proceeds to the next action in

4 • FEATURES

the script. When queueing to a parent group, several Selection Rules are provided to control which agent is selected from among multiple-member agent groups.

Remove from Queue

A Remove from Queue module simply removes the contact from its current agent group queue and proceeds to the next module in the script.

Wait

The Wa it module is used to represent a wide variety of routing activities involving delays experienced by the contactor, including playing welcome messages and announcements, prompting and receiving customer inputs, transfer times, and being placed on hold for an agent.

Priority

A Priority module will adjust the active priority of a contact. This priority may in turn affect its processing, including moving it ahead of other contacts in a queue.

Message

When a Message module is encountered in a routing script, a wait time (representing the time required to record a message) is generated from the specified distribution. The contact is then delayed for that amount of time, counted as leaving a message, and dispatched from the contact center.

• • • • •

Disconnect

When a Disconnect module is encountered in a routing script, the contact is immediately dispatched from the contact center.

Overflow

An Overflow module removes the contact from its current queue and counts it as an overflow between the specified source group and destination group. Routing control flow then continues to the next module in the script, which must be a Queue for Agent action for the appropriate destination group.

Transfer to Script

The Transfer to Script module simply shifts routing-control flow to the actions defined in the specified script.

4 • Features

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

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 Tal k Ti m e logic of the Queue for Agent module.

Branch

A Branch module serves to implement conditional and probabalistic branching logic. If the associated condition is true, routing-control flow is transferred to the module connected to the correponding exit. Flow can be controlled by logical conditions including: Contact Name, Time In Contact Center, Time of Day, Day, Agent Expressions, Queue Length, and Probabilities.

Assignment

The Assignment module allows the assignment of a contact’s picture or attribute, a global variable, or counter.

End Script

The End Script module identifies the end of a script.

Costing

Arena Contact Center Edition currently tracks variable costs associated with contact center operations. These costs pertain to the use of particular trunk and agent resources. The total cost incurred for each resource is summarized in the default report.

Agent costs

A busy and idle hourly cost per agent (hourly wage), as well as a per-use cost, can be associated with each agent group. The busy, idle, and per-use cost of this group over the simulation planning horizon is calculated based on the following formulas:

Busy Agent Cost = (Busy Hourly Cost) * (Average Number of Busy Agents in Agent Group) * (Length of Planning Horizon)

Idle Agent Cost = (Idle Hourly Cost) * (Average Number of Idle Agents in Agent Group) * (Length of Planning Horizon)

Usage Cost = (Per Use Cost) * ( Number of times an agent was seized)

Trunk costs

A cost per trunk hour can be associated with each trunk group. The total cost of operating this trunk group over the simulation planning horizon is calculated based on the total number of hours each trunk line is in use, analogous to the following formula:

Total Trunk Cost = (Cost/Hour) * (Number of Trunks in Trunk Group) * (Utilization) * (Length of Planning Horizon)

Miscellaneous features

Pattern entry

Patterns are defined by entering the expected number of contacts for each timeslot. The Scale Factor field is used to increase or decrease globally the expected number of contacts per timeslot. The Scale Factor value is multiplied by the value entered for each timeslot.

Agent states

Schedules are composed of individual time periods or shifts. An agent state is associated with each shift. The main purpose of the agent state is to differentiate between on- and off-duty states. The off-duty states currently are used only for documentation purposes and to aid in model validation.

• • • • •

4 • FEATURES

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 contacthandling 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:

EPLICATIONS

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

4 • Features

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

multiple replications. The desired number of replications is specified in the Configuration module.

The companion features to the multiple replication functionality determine whether the replications are treated independently or as a continuous run. For more details on when and how to initialize the system and initialize the statistics between each replication, see Arena online help.

UMBER 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.

Getting Started

Introduction

This chapter will help you get started quickly in the Contact Center template by explaining how to load and run an existing model and by demonstrating how to build your own model from scratch. Please see Chapters 3 and 4 for a review of contact center simulation concepts, as well as Chapters 6 and 7 for a detailed description of each Contact Center module.

Loading and running an existing example

The Telethon.doe case study model illustrates a simple contact center application.

To load the telethon case, click on File > Open in Arena. A selection box will appear in the center of the screen. Click on (or Browse for) the file name Telethon.doe and select Open. The telethon model will be loaded and appear within the model window.

Figure 5.1 The Telethon model

To run the model, click Run > Go, and a week of telethon activity will then be simulated. When complete, a dialog will appear asking whether you would like to see the results. Click Ye s to view the Agents and Trunks report. You may also view the Contact Times and Counts report by clicking on Contact Times and Counts on the report panel located on the project bar. When finished viewing these reports, use the Close button to close

5 • Getting Started

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

each report. At this point, to leave Run mode and return to the model, click on Run > End.

For more detail on your options during the simulation run, please consult Arena online help.

Finally, select File > Close to complete the demonstration. The remainder of this chapter will show the step-by-step process of building the telethon model.

General modeling skills and concepts

Panels and modules

There are two template panels associated with Arena Contact Center Edition: Contact Data and Script. The Contact Data panel contains modules that are used to describe the various aspects of the contact center, such as a contact name or an agent group. The Contact Data modules are:

 Pattern  Contact  Schedule  Agent  Animate  Report

The Script panel contains modules that are used to create a contact’s routing script. A script is a sequence of actions that controls the flow of a contact through the center’s system. The Script modules are:

 Begin Script  Queue for Agent  Remove from Queue  Wait  Priority  Message  Disconnect  Overflow  Transfer to Script  Transfer to Agent  Conference  Branch  Assignment  End Script

5 • GETTING STARTED

Names

Certain object names are reserved wo rds 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 (i.e., a model with a contact name named “Express” cannot also have an “Express” agent group).

Lists

Once a Contact Center object has been named (or is referenced from another object), it is placed on an internal list. From then on, the object name may be selected from a dropdown list in the appropriate dialogs. Lists are maintained for the following Contact Center objects:

 Trunk Groups  Contact Names  Patterns  Scripts  Schedules  Agent Groups  Parent Groups

• • • • •

Module copy and paste

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

Repeat group duplication

Entries within a repeat group can be duplicated by highlighting the entry and pressing Ctrl+D. This creates an identical repeat group line item, which can then be customized.

Disable animation

The following steps describe how to disable/enable animation for performance purposes.

1. Select Run > Run Control > Batch Run.

2. Under Mode, check Batch Run (No Animation) for greater performance, unless animation is desired.

Building an Arena Contact Center Edition model

This section describes in detail a development session for a simple contact center model. After completing this section, you will be familiar with the basic structure of a contact

5 • Getting Sttarted

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

center model and will possess the navigational skills necessary to work comfortably in the Arena environment.

This example is also used to illustrate the module descriptions within Chapters 6 and 7. Additionally, Chapter 9 contains several complete case studies, which may be used for further practice with the template.

Defining the business application

The simple contact center model used to demonstrate the Contact Data and Script template panels deals with the organization of a pledge drive for a local public radio station. Each weekday morning during an on-air solicitation period, donors will be calling in to make their pledges to a 12-member volunteer staff manning the company’s 24-line phone bank. From a business perspective, there are a limited number of potential donors, so the number lost due to busy signals or abandonment must be minimized. Therefore, from a contact center perspective, the key performance measures are blocked contacts and average speed of answer.

Once the basic model is in place, it will be used to assess the wait time faced by donors and analyze the impact of various levels of contact volume on the performance of the center. This will allow station management to determine whether an investment in additional phone lines and/or contract telereps would be justified.

Model overview

This simple model consists of:

 1 week-long planning horizon, divided into hourly intervals  1 trunk group (with 24 lines)  1 agent group (with 12 volunteer members)  1 schedule (6:00 am-10:00 am, Monday-Friday)  1 contact name (donor)  1 routing script (queue, wait, and take message)  1 pattern (estimated contact volume by hour)  Animation (Agent Number Busy, Callers Waiting, etc.)  Reporting

Model construction

Once the Arena application has been started, a new model window is automatically opened. If you need to open another new window, select File > New. Select Model Window from the presented dialog and click OK. If you are not familiar with resizing model windows or placing and editing modules, please refer to Arena online help.

5 • GETTING STARTED

Select File > Template Panel > Attach. From the resulting dialog, browse for and select the file called ContactData.tpo and click on the Open button. A panel containing the Contact Data modules appears. Execute the same steps again, this time selecting the file called Script.tpo. This will attach the Script panel.

EFINING PLANNING HORIZON AND CONTACT CENTER INFRASTRUCTURE

HE CONFIGURATION MODULE

—

As described in the model overview, the radio telethon will run for one week. The basic phone system at the radio station will be used to handle incoming donor calls. To represent these items within the Arena Contact Center environment, a Configuration module is employed.

To place a Configuration module in the model, click on the Configuration module on the Contact Data panel, drag and then drop the module in the desired position within the model window. Double-click on the resulting module to open the module dialog.

When the module opens, you will notice a drop-down list for defining the planning horizon. Fill out this dialog to match the inputs in Figure 5.2. Below these items you will see the trunk definition’s scroll list with Add, Edit, and Delete buttons to the right. This is known as a repeat group and enables you to enter multiple items (in this case, trunk group definitions). To add an item to the repeat group, click on the Add button and fill out the resulting dialog, as in Figure 5.3. The Delete button is used to remove items from repeat groups, while an item is edited by highlighting the item within the scroll list and clicking on the Edit button. Many Contact Data and Script panel modules contain one or more repeat groups, which are completed in a similar manner.

• • • • •

Figure 5.2 Configuration module main dialog

5 • Getting Sttarted

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

This defines a week-long planning horizon and a trunk group with 24 trunk lines on which the Direct Routing script will be applied to route the contacts through the contact center.

Figure 5.3 Configuration module—trunk definitions

The features described in the Advanced section of the Configuration module in Chapter 6 are accessed by clicking on the Advanced button, but will not be needed in this simple example.

Finally, click the OK button to accept the module into the simulation model. Note that the planning horizon is now documented in the model window.

EFINING THE CONTACTS—THE CONTACT MODULE

The Contact module is used to define the characteristics of the donor calls that are responding to the radio telethon. Their expected talk time is defined along with the associated contact pattern and trunk group. An abandonment model is also specified that enables callers to abandon the center if not served within a specified amount of time.

Place a Contact module in the model window and open its main dialog. You will notice fields for defining the basic contact characteristics: contact type, contact name, pattern, expected talk time, and associated trunk group. All the fields contain default values. These values can be edited so that more meaningful names can be used. At the bottom of the dialog, note the buttons containing additional dialogs for modeling Contact Back, Abandonment, and other Advanced features.

Complete this dialog as illustrated in Figure 5.4. Note that there is a drop-down selection list associated with the contact name, pattern, and trunk group fields. Use the trunk group selection list to choose the Phone Bank trunk group that was previously defined in the

5 • GETTING STARTED

Configuration module. This is a general ease-of-use Arena feature, where named objects defined in one module may be selected from lists in others.

Figure 5.4 Contact module main dialog

• • • • •

To include donor abandonment in the model, click on the Abandonment button and type

EXPO(2)

in the dialog to define an exponential abandonment model where the average

contact abandons after two minutes. Click OK to close the dialog.

EFINING THE CONTACT ARRIVAL PATTERN

—THE P

ATTERN MODULE

The Pattern module is the mechanism for describing the expected contact volumes for all timeslots within the planning horizon. In the Telethon model, we expect calls to be distributed evenly throughout the on-air pledge-solicitation period.

5 • Getting Sttarted

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Place a Pattern module in the model window and double-click to open its main dialog. Note the correspondence between this dialog and the main dialog of the configuration module. The Daily Arrival Pattern repeat group disappears in the case of day-long planning horizons. Complete the main dialog as illustrated in Figure 5.5.

Figure 5.5 Pattern module main dialog

Following this, a pattern must be defined for each day of the week. To do this, click on the Add button in the main dialog. This opens a data entry screen that partitions a day into the appropriate timeslots. Enter the day of week and

AM and 10:00 AM, as shown in Figure 5.6. When finished, click OK. This process

6:00 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).

into each of the timeslots between

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 module—Daily Arrival Pattern

EFINING THE TELETHON HOURS—THE SCHEDULE MODULE

The volunteer group fielding donor calls at the radio station must have their schedules defined to correspond with the on-air solicitation period. This is done by placing a Schedule module and defining on-duty hours of 6:00

AM to 10:00 AM on each weekday.

5 • Getting Sttarted

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Upon opening the Schedule module, you will notice its similarity to the Pattern module. Complete the dialog, as shown in Figure 5.7.

Figure 5.7 Schedule module main dialog

When this is complete, the individual daily schedules must be defined. This is a slightly different process from the Pattern module because the dialogs are more involved. Click on the Add button to the right of the daily schedule repeat group. This opens another level of repeat groups that facilitates the definition of multiple shifts within a given day. At this point, select Monday as the day of the week and click on the Add button to the right of the shift schedule repeat group. Complete the resulting dialog as shown in Figure 5.8 and click OK to enter the shift.

Since there are no more shifts during the day, click OK to complete the daily schedule for Monday. Repeat this process to define shifts for the remaining days of the week, including Saturday and Sunday, even though no agent shifts will be defined on the weekends. Be careful not to get confused by the extra level of repeat groups; there is a repeat group to define days within the planning horizon and a repeat group to define all shifts within a given day.

5 • GETTING STARTED

Figure 5.8 Schedule module—Shift

EFINING THE WORKERS

—THE A

GENT MODULE

In the Telethon model, a group of volunteers will be manning the phone lines at the radio station. These volunteers will service incoming donor calls. This is a very simple agent group to represent, requiring the absolute minimum input.

Place an Agent module within the model window and open the main dialog. By default, the dialog is initially set up to define agent groups (rather than parent groups). Since this is what we want, complete the dialog to match the one in Figure 5.9. Recall that the schedule associated with the agent group can be selected from the drop-down list. Note the button at the bottom of the dialog for defining the agent group’s handling skills in terms of talktime capabilities.

• • • • •

Figure 5.9 Agent module main dialog

5 • Getting Sttarted

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Following the basic agent definition, the only remaining task is to define the handling skills for the volunteers. This is done by clicking on the Ta l k Tim e button, which exposes a dialog containing a repeat group in which a list of contact names and associated handling characteristics is generated. Since there is only a single contact name in the Telethon model, we will only need to make one entry. To do this, click on Add to reveal the dialog shown in Figure 5.10, select Donor from the list of contact names and click OK to close the dialog and preserve the default talk and conference-time multipliers.

Figure 5.10 Agent module—Talk Time contact names

This completes the basic agent group definition, so click OK in each of the open dialogs to accept the module into the simulation model.

EFINING THE ROUTING LOGIC

—THE S

CRIPT PANEL

Donor calls start the phones ringing at the radio station. If not answered, the calls will roll over to voice mail after two minutes. The functionality of the phone switching system is specified by creating a script using a series of modules from the Script panel.

Place a Begin Script module within the model window and open the main dialog. You will see a field for the script name. Select Direct Routing from the drop-down list as shown in Figure 5.11 and click OK.

Figure 5.11 Begin Script module main dialog

5 • GETTING STARTED

Next place a Queue for Agent module in the model window. If a connector was not automatically added from the Begin Script module to the Queue for Agent module, use the Connect button located on the standard toolbar to connect the exit point of the Begin Script module to the entry point of the Queue for Agent module. Refer to Arena help for more information on connecting modules.

Open the Queue for Agent main dialog. By default, the dialog is initially set up to define agent groups (rather than parent groups). Since this is what we want, complete the dialog to match the one shown in Figure 5.12. At the bottom of the dialog, note the button containing additional dialogs for modeling Advanced features.

• • • • •

Figure 5.12 Queue for Agent module main dialog

Next, place and connect a Wait module after the Queue for Agent module in the model

window. Open the main dialog and enter

in the Wait Time field as illustrated in Figure

5.13.

Figure 5.13 Wait module main dialog

Now place and connect a Remove from Queue module after the Wait module in the model window. This module has no required values to enter.

5 • Getting Sttarted

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Place and connect a Message module after the Remove from Queue module in the model window. Open the main dialog and enter illustrated in Figure 5.14. Note the check boxes for contact back and contact return options. Since neither contact back nor contact return were defined in the Donor Call module, the values specified here are irrelevant.

Figure 5.14 Message module main dialog

To complete the script, place and connect an End Script module after the Message module in the model window. This module has no required values to enter.

This script will model a call immediately queueing for a volunteer. It will implement a two-minute wait before activating the recording of a 30-second voice mail message. The completed script is shown in Figure 5.15.

into the Message Wait Time field as

Figure 5.15 Direct routing script

DDING REAL-TIME GRAPHICS—THE ANIMATE MODULE

Animation is often useful to provide visual insight into contact center conditions during a simulation run. In the Telethon model, agent utilization is a valuable indicator of whether the size of the volunteer staff is adequate to handle all donor calls—a critical component in making the pledge drive a success. Therefore, we will animate the utilization level of the volunteer group both numerically and with a plot.

5 • GETTING STARTED

Place an Animate module within the model window and double-click to open its dialog. Select Agent from among the Data Object options and complete the remaining dialog as shown in Figure 5.16.

Figure 5.16 Animate module main dialog

OLLECTING STATISTICS—THE REPORT MODULE

The purpose of constructing simulation models is to gain insight into contact center business processes and drive the planning and improvement of those operations. The Report module supports detailed data collection of important performance measures throughout the planning horizon under study. In the Telethon model, managers are interested in the experience of donors as they wait for agents. In particular, long answer times may indicate that potential pledges are abandoning the center without being served.

• • • • •

Place a Report module within the model window and complete its dialog as specified in Figure 5.17.

Figure 5.17 Report module main dialog

5 • Getting Sttarted

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Note that multiple Report modules may be placed to collect as many statistics as necessary. Varying the timeslot size in separate modules focused on the same statistic will generate a series of reports detailing that performance measure at various levels of aggregation (for instance, Donor Call Time averages for each hour, day, and the week as a whole).

Running the model

The Telethon model is now ready for execution. Before a run, it is a good idea to save the model. Do so by clicking on the disk icon on the toolbar or by selecting File > Save. After naming the model (choose a model name other than Telethon.doe so as not to overwrite the original) and completing the ensuing dialog, the model is ready to run.

Begin the run by selecting Run > Go. Arena will now check the model for any errors and initiate the run. At this point, the animation tracking the utilization of the volunteer group should be active, as well as a display of elapsed execution time. When complete, a dialog will appear asking whether you would like to see the results. Click on Ye s to view the default summary report. The report window may be resized to better view its contents. When finished viewing the default report, click on File > Exit to return to Arena. At this point, to leave Run mode and return to the model, click Run > End.

You may also examine the file generated by the Report module that contains statistics on donor contact times reported in 60-minute intervals.

For more information on the default summary report or the possible output generated using the Report module, please refer to Chapter 7.

Conclusions

This chapter illustrates the ease of building a simulation model using Arena Contact Center Edition. The Contact Center environment is designed to require less effort to create a model in order to allow more attention to be focused on using the simulation to address and answer key business issues and questions.

While the Telethon model is relatively simple, it does use all seven of the Contact Data panel modules and six of the Script panel modules. The process of creating a more complex model is virtually the same, although complex models would generally contain multiple modules of each type.

With a completed model in hand, you may want to experiment with some of the model parameters or some advanced options. Try making incremental adjustments to the model and examining their impact on center performance (as summarized in the output statistics). Performing these types of “what if?” analyses are common practice in a simulation study. Here are some potential changes and enhancements to evaluate:

5 • GETTING STARTED

 Increase the volume of donor calls. What impact does this have on blocking,

abandonment, and agent utilization?

 Alter the number of agents and/or trunk lines. What impact does this have on customer

service?

 Add animation to show counts of abandoned calls.

 Generate a report containing counts of calls generated, blocked, abandoned, and

handled.

 Add contact back in the case of abandonment.

 Add a new agent group to process “lifetime memberships” and transfer 10% of the

calls to this group following their service with the regular volunteer group.

 Extend the telethon’s hours of operation (remember that both arrival pattern and agent

schedules must be adjusted).

 Add an agent group to handle overflow from the regular volunteers after calls have

been on the line more than one minute. Modify the routing script to overflow calls to this group.

• • • • •

5 • Getting Sttarted

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

The Contact Data Panel

This chapter describes each of the seven modules that form the Contact Data template panel, one of the two template panels contained in the Arena Contact Center Edition. Chapter 7 describes the modules located in the second template panel—the Script panel.

The following modules are located on the Contact Data panel:

 Configuration  Schedule  Pattern  Agent  Contact  Animate  Report

All of the above modules allow the definition of a single object (e.g., Agent Group, Contact, etc.). Multiple modules of the same type are placed to complete the model. Several modules incorporate the notion of component repeat groups. That is, the module may be composed of many similar pieces (e.g., Days within a Week for the Pattern and Schedule modules), and each piece is defined separately. The repeat groups are described in the prompt text and will be obvious within the template constructs, although their repetitive nature does not appear in the prompt tables. Similarly, many modules have custom dialogs that vary depending on the options selected. This conditional input is also not explicitly highlighted in the prompt tables.

6 • Contact Data Panel

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Configuration module

ESCRIPTION

This module’s purpose is to specify the layout of the contact center simulation. The planning horizon and all trunk groups applicable to the contact center are defined within this module.

ROMPTS

Planning Horizon—Length 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 Definitions—This repeat group defines the contact capacity of the contact center in terms of trunk lines. Trunk groups will be useful in defining different functions within a contact center and for networked contact centers that are not at the same physical location.

Trunk Group—Text descriptor of the trunk group being defined (e.g., Sales, Dallas Office, Outsourcer).

Trunk Capacity—Number of trunks in this trunk group.

Inbound Contacts—Indicates if this trunk is used for inbound contacts.

Inbound Contact Script—Routing script for inbound contact associated with this trunk

group, chosen from the list of defined Scripts.

6 • THE CONTACT DATA PANEL

• • • • •

Inbound Contact Priority—Integer used to rank inbound contact associated with Trunk Group when queued to a priority queue.

Outbound Contacts—Indicates if this trunk is used for outbound contact.

Outbound Contact Script—Routing script for outbound contact associated with this

trunk group, chosen from the list of defined Scripts.

Outbound Contact Priority—Integer used to rank outbound contact associated with Trunk Group when queued to a priority queue.

Trunk Cost/Hour—Cost of trunk lines in $/hour/trunk line.

Advanced—The following group of items support several advanced features of the run.

6 • Contact Data Panel

Number of Replications—Number of simulation runs to be performed during this analysis. Each run’s length is determined by the Planning Horizon.

Initialize System Between Replications—Controls whether each replication is started with an empty contact center or continues from the endpoint of the previous replication.

Initialize Statistics Between Replications—Controls whether statistics collection is reset at the beginning of each replication or accumulates throughout all replications.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Max Number of Agent Groups—Upper bound on the number of Agent Groups to be included in the simulation model. This value may need to be increased for very large simulation runs.

Prompt Valid Entry Default

Planning Horizon Day, Week, Bi-Week, Month Day

Trunk Definitions

Trunk Group Symbol Name [Trunk Group] Trunk 1

Trunk Capacity Integer >= 1 100

Inbound Contacts Checked, Unchecked Checked

Inbound Contact Script Symbol Name [Scripts] Script 1

Inbound Contact Priority Expression 5

Outbound Contacts Checked, Unchecked Unchecked

Outbound Contact Script Symbol Name [Scripts] Script 1

Outbound Contact Priority Expression 100

Trunk Cost/Hour Real Number >= 0 0.00

Advanced

Number of Replications Integer >= 1 1

Initialize System Checked, Unchecked Checked

Initialize Statistics Checked, Unchecked Checked

Max Number of Agent Groups Integer >= 1 50

EMARKS

Only one Configuration module may be defined for each simulation model.

The Planning Horizon value specified in the Configuration module is independent of planning horizon values specified in other modules.

The Planning Horizon defined within the Configuration module determines the length (in minutes) of the simulation run.

The Priorities and Scripts defined at the Trunk Group level are provided as defaults for the Contacts incoming on those trunk lines. Overrides of these attributes may be specified in the Contact module.

6 • THE CONTACT DATA PANEL

• • • • •

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.

XAMPLE

Prompt Entry

Planning Horizon Week

Trunk Definitions

Trunk Group Phone Bank

Trunk Capacity 24

Inbound Contacts Checked

Inbound Contact Priority 1

Inbound Contact Script Direct Routing

Outbound Contacts Unchecked

This example sets up a weekly planning horizon. A single trunk group with 24 lines is also defined.

6 • Contact Data Panel

Schedule module

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

ESCRIPTION

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

ROMPTS

Schedule Name—Text descriptor of the schedule being defined (e.g., Graveyard).

Planning Horizon—Length of the planning horizon chosen from the following pre-

defined list of options: Month, Bi-Week, Week, Day.

Timeslot (in minutes)—Length of the intervals composing the schedule: 15, 30, or 60 minutes.

Daily Schedule—This repeat group is used to define a schedule for each individual day within the planning horizon. Each day is identified by its week and day of week, if applicable. Within each day, multiple agent shifts may be defined.

6 • THE CONTACT DATA PANEL

• • • • •

We ek —Selection of the week within the planning horizon for which the agent shifts apply.

Day of Week—Selection of the day within the planning horizon for which the agent shifts apply.

Shift Schedule—This repeat group is used to define the agent shifts that are in effect on the particular day. Each shift is specified by an agent availability state and a starting and ending time.

Agent State—This field defines the agent availability state for this particular shift.

Alter Capacity by—This field allows you to specify whether the shift schedule being

defined applies to the entire agent group capacity or for a specified number of the group.

Number of Agents—This option defines the number of agents for which the shift schedule applies.

Group Capacity —This option defines the absolute capacity of the agent. It must be a positive integer and cannot be larger than the Agent’s capacity as defined in the Agent module.

Schedule Adherence Factor—Multiplier used to calculate the actual number of agents used for a given timeslot.

Shift Begins at—This dialog specifies the time the shift begins (e.g., 8:00

AM).

Shift Ends at—This dialog specifies the time the shift ends (e.g., noon).

6 • Contact Data Panel

Prompt Valid Entry Default

Schedule Name Symbol Name [Schedule] <Module Name and

instance number>

Planning Horizon Day, Week, Bi-Week, Month Day

Timeslot 15, 30, 60 30

Week Week 1, Week 2, Week 3, Week 4 Week 1

Day Of Week Monday, Tuesday, Wednesday, Thursday,

Friday, Saturday, Sunday

Agent State On Duty, Lunch, Break, Meeting,

Research

Alter Capacity by Group Capacity, Number of Agents Group Capacity

Number of Agents Integer > 1 0

Monday

On Duty

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Prompt Valid Entry Default

Schedule Adherance Factor

Shift Begins at Time (hour, minute,

Shift Ends at Time (hour, minute, AM/PM) 12 PM

EMARKS

By default, all timeslots are initialized to an off-duty availability state. Therefore, agent shifts need only be defined for those time intervals that are not off-duty.

There are error checks to prevent infeasible shifts from being entered (e.g., shifts that end before they begin). All shifts must be entered in chronological order starting with midnight, going until midnight the following day. For example, if an agent has two separate shifts (noon to 4 Entering the 5

PM to 9 PM shift will raise an error.

Overlapping agent shift intervals are not permitted.

Shifts are defined for each calendar day. Therefore, a shift that overlaps days must be defined in two separate pieces (e.g., Monday: 8:00

AM).

6:00

Integer > 1 0

AM/PM) 12 AM

PM, and 5 PM to 9 PM), the shifts must be entered in this order.

PM–midnight; Tuesday: midnight–

The planning horizon defined in the Schedule module dictates the number of days for which schedules must be defined. An entry must be made in the Daily Schedule for each day within the planning horizon, although no shifts need to be defined for any day (e.g., if everyone is off-duty on the weekends, no shifts would be defined for Saturday and Sunday, although Saturday and Sunday must appear in the Daily Schedule list).

Note that schedules are repeated to fill the simulation run length as defined in the Configuration module (e.g., a weekly pattern will be repeated four times to fill a month-long run). However, schedules defined for longer than the run length will raise an error.

Timeslots, as defined in the Schedule module, determine the start and end points of shift intervals. It is important to synchronize shift changes with statistics collection in the Report module to ensure consistency. Agent Utilization will be distorted if groups go onor off-duty in the middle of a reporting interval. Therefore, the intervals defined for statistics should be no larger than the shift timeslots, and coincide with shift changes. For instance, when shifts change on the hour, statistics can be collected on the hour or halfhour. However, if shifts change on the half-hour, statistics must be collected on the halfhour.

6 • THE CONTACT DATA PANEL

• • • • •

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.

XAMPLE

Prompt Entry

Schedule Name Telethon Hours

Planning Horizon Week

Timeslot 60

Daily Schedule

Day of Week Monday/Tuesday/Wednesday/Thursday/Friday

Agent State On-Duty

Shift Begins at 6:00

Shift Ends at 10:00 AM

Day Of Week Saturday

Day Of Week Sunday

6 • Contact Data Panel

This example defines the schedule the volunteer agents will follow (coinciding with the on-air pledge drive) in the Basic Telethon case study.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Pattern module

ESCRIPTION

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.

ROMPTS

Pattern—Text descriptor of the contact pattern being defined (e.g., Windows, DOS).

Planning Horizon—Length of the planning horizon chosen from the following pre-

defined list of options: Month, Bi-Week, Week, Day.

Timeslot (in minutes)—Length of the intervals composing the pattern: 30 or 60 minutes.

Scale Factor—Method of scaling the arrival pattern data up or down. Each timeslot value

will be multiplied by the scale factor to determine the expected total contacts for each timeslot.

6 • THE CONTACT DATA PANEL

• • • • •

6 • Contact Data Panel

Daily Arrival Pattern—This repeat group is used to define a pattern for each individual day within the planning horizon. For each day, the expected total contacts arriving within each timeslot are specified.

We ek —Selection of the week within the planning horizon for which the pattern applies.

Day Of Week—Selection of the day within the planning horizon for which the pattern applies.

Daily Contact Pattern—Specification of the expected total contacts for each timeslot for the given day.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

XAMPLE

Prompt Valid Entry Default

Pattern Symbol Name [Pattern] <Module Name and

Planning Horizon Day, Week, Bi-Week, Month Day

Timeslot 30, 60 30

Scale Factor Real Number 1.0

Daily Arrival Pattern

Week Week 1, Week 2, Week 3, Week 4 Week 1

Day Of Week Mon, Tue, Wed, Thu, Fri, Sat, Sun Mon

Daily Contact Pattern Real Number >= 0 0.0

EMARKS

An entry must be made in the Daily Arrival Pattern for each day of the planning horizon, although no patterns need to be defined for any day (e.g., if no contacts are received on the weekends, no patterns would be defined for Saturday and Sunday, although Saturday and Sunday must appear in the Daily Arrival Pattern list).

instance number>

Patterns are repeated (if necessary) to fill the simulation run length as defined in the Configuration module (e.g., a weekly pattern will be repeated four times to fill a month-long run). In these cases, patterns are adjusted so that the distribution covers the entire run length (e.g., the expected number of contacts entered in the Contact module will be generated over the simulation run). However, patterns defined for longer than the run length will raise an error.

The timeslot specified within the Pattern module is independent of timeslot lengths in all other modules. These timeslots determine at what level patterns are entered and when the arrival rates for contacts change within the simulation.

6 • THE CONTACT DATA PANEL

• • • • •

XAMPLE

Prompt Entry

Pattern Basic Pattern

Planning Horizon Week

Day Of Week Mon/Tue/Wed/Thu/Fri

Daily Arrival Pattern (6:00

AM - 7:00 AM)

Daily Arrival Pattern

AM - 8:00 AM)

(7:00

Daily Arrival Pattern

AM - 9:00 AM)

(8:00

Daily Arrival Pattern

AM - 10:00 AM)

(9:00

This example illustrates the donor arrival patterns for the Basic Telethon case study. This pattern corresponds to calls arriving uniformly over the timeslots in the planning horizon (50 calls are expected in each of the 20 timeslots).

Agent module

6 • Contact Data Panel

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

ESCRIPTION

This module defines the agents of the contact center. Each Agent Group is composed of identical agents based on a generic definition. A Skill Set, defined by a set of talk-time details, is specified for each Agent Group, along with an associated Schedule.

Parent Groups are used to combine multiple Agent Groups to serve a particular function, as well as provide aggregate statistics. (For example, Agent Groups could be defined for groups that handle Day, Evening, and Graveyard shifts, with a Parent Group to encapsulate all three.)

ROMPTS

Agent Name—Text descriptor of the group being defined.

Agent Type—Choice of Agent Group or Parent Group.

If Agent Type = Agent Group:

These items define the generic agents that belong to this Agent Group and the specific agent operational details. The Agent Group will be defined by the number of agents, their associated skill set, and the schedule they follow.

Max Number Available—Maximum number of agents available in the Agent Group.

Schedule—Associated Agent Schedule, chosen from the list of the defined Agent

Schedules.

Clear Queue when Off Duty—Specifies whether a check is made every 15 minutes to determine if all agent groups comprising the parent group are off-duty and to clear the parent queue by disconnecting all the contacts in the queue. Note that a parent group queue may be cleared several times daily depending upon the member agent group schedules.

Busy Cost/Hour—Cost per hour incurred while a single agent is busy.

Idle Cost/Hour—Cost per hour incurred while a single agent is idle.

Per Use Cost—Cost per contact incurred for a single agent.

6 • THE CONTACT DATA PANEL

Tal k Ti m e—Dialog containing a repeat group that facilitates defining talk time specifics by contact name.

Contact Name—Particular contact name that can be handled by agents with the given skill set.

• • • • •

6 • Contact Data Panel

Talk Time Multiplier—Numerical expression quantifying the skill of the agent with respect to the specified contact name (e.g., 0.9 implies agents with this skill set handle this contact 10% faster than average).

Conference Time Multiplier—Numerical expression quantifying the skill of the agent when conferenced on a particular contact name (e.g., 0.9 implies agents with this skill set resolve this contact 10% faster than average).

Override Contact Priority with Skill Priority—Field indicating whether contact priority should be redefined when served by this Agent Group.

Agent Skill Priority—Number indicating the priority for Contact Name (i.e., 1 for highest priority, 2 for next, etc.). Lower-valued Contact Names will be assigned before those with higher values. This value overrides the Contact Priority when a contact is queued to this Agent Group.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

If Agent Type = Parent Group:

These items define a Parent Group in terms of its component Agent Groups. Preferences may be specified to further define the assignment of contacts to the Agent Groups within the Parent Group.

Clear Queue when Off Duty—Specifies whether contacts are disconnected when all

agent

groups comprising the parent group go off duty at the end of a day.

Members—This repeat group facilitates the selection of the various Agent Groups that compose the given Parent Group.

Agent Group—Text descriptor of the Agent Group that belongs to the Parent Group, chosen from the list of Agent Groups that have been defined.

Preference—Number indicating the preference of this Agent Group within Parent Group (e.g., 1 for primary preference, 2 for secondary preference). Preference defines

an order within Parent Group for assignment of contacts to Agent Group. Lower- valued groups will always be assigned before higher-valued agents when agents of different Preference are available.

Agent Skill Priority—Dialog containing a repeat group that facilitates defining agent skill priorities by contact name.

Contact Names—This repeat group facilitates defining agent skill priorities by contact name.

Contact Name—Particular contact name that can be handled by agents with the given skill set.

6 • THE CONTACT DATA PANEL

• • • • •

Prompt Valid Entry Default

Agent Name Symbol Name [Agent] Agent Group

Agent Type Agent Group or Parent Group Agent Group

Agent Group

Max Number Available Integer >= 1 1

Schedule Symbol Name [Schedule] Schedule 1

Busy Cost Real Number >= 0 0.00

Idle Cost Real Number >= 0 0.00

Per Use Cost Real Number >= 0 0.00

Talk Time/Contact Names

Contact Name Symbol Name [Contact] Contact 1

Talk Time Multiplier Real Number >= 0 1

Conference Time Multiplier Real Number >= 0 1

Override Contact Priority Checked, Unchecked Unchecked

Agent Skill Priority Integer >= 1 5

Parent Group

Clear Queue when Off-Duty Checked, Unchecked Checked

Members

Agent Group Symbol Name [Agent Group] Agent Group 1

Preference Integer >= 1 5

Agent Skill Priority

Contact Names

Contact Name Symbol Name [Contact] Contact 1

Agent Skill Priority Integer >= 1 5

6 • Contact Data Panel

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

EMARKS

Parent Groups are used for several reasons, including simulation of simultaneous queueing, grouping common resources to support skill-based routing, and isolating the script logic from scheduling complexities (e.g., the Windows Group is a single logical entity to which contacts can be routed, when in reality it is made up of many subgroups, each containing a different number of agents following a different schedule).

Preferences among Agent Groups determine which agent resource from those available is selected to service the next contact in queue. Priorities (Agent Skill and Contact) determine the order of contacts within a queue. Both features can be used concurrently.

Talk Time applies to the entire Agent Group.

Agent Skill Priorities are used to rank contacts within the queue directly associated with the Agent Group. As such, priorities specified at the Agent Group level will not affect the ordering of the Parent Group queue and vice versa. However, priorities at the Agent Group level always override priorities set at other levels when resolving contention among contacts competing for a particular agent resource.

XAMPLES

XAMPLE

Prompt Entry

Agent Name Volunteers

Agent Type Agent Group

Max Number Available 12

Schedule Telethon Hours

Clear Queue when Off-Duty Checked

Busy Cost 0.0

Idle Cost 0.0

Per Use Cost 0.0

Talk Ti m e

Contact Name Donor

Talk Time Multiplier 1

Conference Time Multiplier 1

Override Contact Priority Unchecked

1—B

ASIC USE

This example defines the volunteers in the Basic Telethon case study as an Agent group of 12 generic agents.

6 • THE CONTACT DATA PANEL

• • • • •

XAMPLE

Prompt Entry

Agent Name Expert

Agent Type Agent Group

Max Number Available 1

Schedule First Shift

Clear Queue when Off-Duty Checked

Busy Cost 0.0

Idle Cost 0.0

Per Use Cost 0.0

Talk Ti m e

Contact Name Regular

Talk Time Multiplier 0.8

Conference Time Multiplier 0.8

Contact Name Premium

Talk Time Multiplier 0.8

Conference Time Multiplier 0.8

2—U

SING BASIC MULTIPLIER TO MODEL SKILL LEVELS

6 • Contact Data Panel

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.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Contact module

ESCRIPTION

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.

ROMPTS

Contact Type—Defines the type of contact (e.g., Call, Email, Fax, Web Hit or Other).

Option—Defines a contact as inbound or outbound.

Contact Name—Text descriptor of the contact being defined (e.g., Reservations).

Pattern—Associated Pattern, chosen from the list of the defined Patterns.

Expected Talk Time—Average talk time for contacts of Contact Name. This value is used

as the mean of an exponential distribution from which talk time values are generated for each contact.

Trunk Group—Associated Trunk Group, chosen from the list of the defined Trunk Groups.

6 • THE CONTACT DATA PANEL

Contact Back—Dialog that defines contact-back behavior:

Contact Back Reasons—Blocked, Disconnected, Message, Abandoned, Served.

Probability—Numerical expression for probability of contact back.

• • • • •

6 • Contact Data Panel

Wait Time—Distribution for the delay (in minutes) before contacting back.

Abandonment—Specification of Abandonment module to apply to the contact.

Wait Time Until Abandonment—Distribution specifying time until abandonment.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Advanced

—Dialog that allows incorporation of the following advanced modeling features:

Override Trunk Priority—Check box determines whether or not the priority specified in the Configuration module will be used for a given contact name.

Override Trunk Priority—Expression used to rank contacts of Contact Name when queued in a priority queue. If not entered, Priority is “inherited” from Trunk Group

Priority (see Configuration module).

Override Trunk Script—Check box used to indicate whether the Script “inherited”

from Trunk Group Script (see Configuration module) is to be overridden.

[Override Type]—Defines whether the default trunk group script will be overridden with another script or if the contact will be routed directly to a particular agent queue.

Call Routing Script—Overriding Script, chosen from the list of defined Routing Scripts. If not specified, Script is “inherited” from Trunk Group Script (see the

“Configuration module” on page 60).

[Agent Type]—Defines whether the overriding agent type is a parent group or basic agent group.

Agent Group—Name of the overriding agent group to which contacts of Contact Name will be sent directly to its associated queue.

Parent Group—Name of the overriding parent group to which contacts of Contact Name will be sent directly to its associated queue.

6 • THE CONTACT DATA PANEL

• • • • •

Selection Rule—Rule used to determine which agent is selected from among multiple member agent groups.

Talk Time Distribution—Overrides default talk-time distribution by allowing specification of any general distribution.

After Contact Time—Specifies the distribution for after-contact delay. This is the amount of time the primary agent spends in contact wrap-up before becoming ready for another contact.

Service Level (seconds)—Number defining the target amount of time in seconds (service level) by which this Contact Name should be answered. The percentage of contacts meeting this target is reported in the simulation output.

Can Preempt—Indicates whether a contact of Contact Name can preempt another contact that is being served by an agent.

Can Be Preempted—Indicates whether a contact of Contact Name currently being serviced by an agent can be preempted by another contact.

Contact Picture Name—Defines the name of the entity symbol used for animating Contact Name contacts.

Create Contact—Indicates if a Contact Name contact is created when another entity executes the Contact module.

Contact Characteristics—Dialog that allows the assignment of user-defined contact attributes or user-defined global variables.

Assignments—Specified one or more assignments that will be made when a contact of Contact Name is generated.

6 • Contact Data Panel

[Assignment Type]—Type of assignment to be made. This is a choice of either a user-defined contact attribute or global variable.

Contact Attribute Name—Name of the user-defined contact attribute that will be assigned a value when a contact of Contact Name is generated.

Global Variable Name—Name of the global variable being assigned.

Va l ue —Assignment value of the attribute or variable.

Contact Return check box—Displays a dialog that defines return contact characteristics.

Contact Return—Dialog that specifies contact return behavior.

Priority—Integer used to rank returned contacts in an agent’s queue.

[Contact Return Logic Type]—Determines whether a returned contact follows a script or is queued for an agent.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Contact Return Script—The script that returned contacts will follow.

[Contact Return Agent Type]—Determines whether the returned contact is queued to an agent group or a parent group.

Contact Return Agent Group—The name of the agent group that will service the returned contact.

Contact Return Parent Group—The name of the parent group of agents that will service the returned contact.

Selection Rule—The rule to use when there is more than one available agent to handle the returned contact.

Pre Work—The amount of time an agent needs prior to returning a contact.

Connection Time—The amount of time it takes to connect with the returned contactor.

Probability of Connection—The probability that an agent will be able to connect with

the returned contactor.

Max Number of Attempts—The number of attempts an agent will make to connect with a returned contactor prior to abandoning it.

Time Between Attempts—The time between subsequent contact return attempts.

Outbound Contacts—Dialog that specifies outbound contact behavior.

Pre Work—The amount of time an agent needs prior to making an outbound contact.

Connection Time—The amount of time it takes to connect the outbound contact.

Probability of Connection—The probability that an agent will be able to connect with

the outbound contact.

Max Number of Attempts—The number of attempts an agent will make to connect with an outbound contact prior to abandoning it.

Time Between Attempts—The time between subsequent outbound contact attempts.

Prompt Valid Entry Default

Contact Name Symbol Name [Contact] <module name and

instance number>

Contact Type Call, Email, Fax, Web Hit or Other

Call

Pattern Symbol Name [Pattern] Pattern 1

Expected Talk Time Real Number > 0 1

Call

6 • THE CONTACT DATA PANEL

• • • • •

Prompt Valid Entry Default

Trunk Group Symbol Name [Trunk Group] Trunk 1

Contact Back

Contact Back Reason: Blocked, Disconnected, Message, Abandoned, Served

Probability 0 <= Real Number

Wait Time Expression (Distribution) 1

Abandonment

Wait Time Until Abandonment

Advanced

Override Trunk Priority Check box

Override Trunk Priority Integer >= 1 5

Override Trunk Script Checked, Unchecked Unchecked

[Override Type] Script, Agent Script

Call Routing Script Symbol Name [Script] Script 1

[Agent Type] Agent Group, Parent Group Agent Group

Agent Group Symbol Name [Agent Group] Agent Group 1

Parent Group Symbol Name [Parent Group] Parent Group 1

Selection Rule First Available, Longest Available,

Talk Time Distribution Expression (Distribution) (Uses Expected Talk Time

After Contact Time Distribution

Service Level Real Number > 0 60

Can Preempt Checked, Unchecked Unchecked

Can Be Preempted Checked, Unchecked Unchecked

Checked, Unchecked Unchecked

<= 1.0 or expression

Expression (Distribution) None

Checked, Unchecked Unchecked

Uniform by Availability

from main dialog)

Expression (Distribution) 0.0

6 • Contact Data Panel

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Prompt Valid Entry Default

Contact Picture Name Symbol Name [Pictures] Contact 1 Picture

Create Contact Checked, Unchecked Unchecked

Contact Characteristics

[Assignment Type] Contact Attribute, Global Variable Contact Attribute

Contact Attribute Name Symbol Name [Attributes] Attribute 1

Global Variable Name Symbol Name [Variables] Variable 1

Value Expression 1

Contact Return Check box Checked, Unchecked Unchecked

Contact Return

Priority Integer>=1 50

[Contact Return Logic Typ e]

Contact Return Script Symbol Name [Script] Script 1

[Contact Return Agent Typ e]

Contact Return Script Symbol Name [Script] Script 1

Contact Return Agent Group

Contact Return Parent Group

Selection Rule First Available, Longest Available,

Pre Work Expression (Distributions) 0.0

Connection Time Expression (Distributions) 0.0

Probability of Connection

Max Number of Attempts

Time Between Attempts

Script, Agent Script

Agent Group, Parent Group Agent Group

Symbol Name [Agent Group] Agent Group 1

Symbol Name [Parent Group] Parent Group 1

Uniform by Availability

0<=Expression<=1 1

Integer>=1 1

Expression (Distributions) 0.0

6 • THE CONTACT DATA PANEL

• • • • •

Prompt Valid Entry Default

Outbound Contacts

Pre Work Expression (Distributions) 0.0

Connection Time Expression (Distributions) 0.0

Probability of Connection

Max Number of Attempts

Time Between Attempts

EMARKS

0<=Expression<=1 1

Integer>=1 1

Expression (Distributions) 0.0

Note that the Talk Time field in the main dialog of the Contact module requires a numerical input representing the mean of an exponential delay distribution. On the other hand, any Time field in the Contact Back, Abandonment, or Advanced sections requires a statistical distribution or constant to be specified for that time value.

In the event of contact back, the priority of the contact will be reset as though it were a new contact (i.e., the contact is not credited for any priority adjustments that occurred in a previous visit to the contact center).

A contact return is generated when a contact executes a Message module.

6 • Contact Data Panel

Preemption of and by contacts only occurs in the Queue for Agent module of the Script panel. Preemption does not occur for outbound, transferred, or conferenced contacts. Animation of preempted contacts can be made available by placing an animated storage and naming the storage Agent Group_STO.

Logic modules may be connected to a contact module if the “Allow contact creation via external logic” check box is checked. When this happens, a single contact is created and sent to its assigned routing script. The original entity that triggered the contact creation continues to the next logic module. For more information on using this feature, see CSmart21.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

XAMPLE

Prompt Entry

Contact Name Donor

Pattern Basic Pattern

Tal k Ti m e 10

Trunk Group Phone Bank

Abandonment

Wait Time Until Abandonment

This example defines the call type Donor contact name for the Basic Telethon case study. Talk time is sampled from an exponential distribution with a mean of 10. Calls will wait a random amount of time following an exponential with a mean of 1 prior to abandoning. Note that no contact back has been indicated, meaning there is no second chance to serve donors who are blocked or abandoned.

Animate module

EXPO(1)

ESCRIPTION

The Animate module enables animation of real-time statistics during the simulation run.

ROMPTS

Data Object—Indicates the type of contact center statistic to be displayed.

6 • THE CONTACT DATA PANEL

• • • • •

If Data Object = Contact:

Contact Name—Selection of the Contact Name to animate, from a list of all defined Contact Names.

Contact Statistic Type—Selection of the Contact Statistic Type to animate. Choices

include:

Contact Count—Running total number of contacts in particular stages.

Contact Back Count—Running totals of contact backs by contact-back reason.

Contact Times—Average time contacts spend in a particular state.

Percentages—Percentages of contacts in various categories.

Contact Data—Selection of the particular real-time statistic to animate. Choices depend

on the Contact Statistic Type being animated and are summarized in Table 6.1.

Table 6.1 Summary of Contact Statistic Type

Contact Statistic Definition

Contact Count

Created Count of number of original contacts created

Blocked Count of the number of blocked (denied entry) contacts

Offered Count of the number of contacts entering the center

Abandoned Count of the number of contacts that abandon (hang up) before being

connected to an agent

Handled Count of the number of contacts connected to an agent

Serviced in X minutes Count of the number of contacts connected to an agent within the

specified service-time cutoff

Leaving Message Count of the number of contacts leaving messages

Disconnected Count of the number of contacts disconnected

In System Count of the number of contacts currently in the contact center

Waiting Count of the number of contacts currently waiting for service

6 • Contact Data Panel

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Contact Statistic Definition

Contact Back Counts

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

Abandoned Count of the number of contacts contacting back after abandoning the

Disconnected Count of the number of contacts contacting back after being

Leaving Message Count of the number of contacts contacting back after leaving messages

Served Count of the number of contacts contacting back after being served by

Contact Times

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

Handle Time Average time the primary agents spends serving the contact, including

Time in Contact Center

Percentages

Blocking Percentage of attempted contacts that are blocked

Abandonment Percentage of offered contacts that abandon the center

Serviced in X minutes Percentage of served contacts that are handled within the specified

(denied entry)

center

disconnected

an agent

agent

both talk and after-contact time

Average amount of time the contact spends in the contact center

service cutoff

6 • THE CONTACT DATA PANEL

• • • • •

If Data Object = Agent Group or Parent Group:

Agent/Parent—Selection of the Agent/Parent Group to animate, from a list of all defined Agent/Parent Groups.

Object Data—Selection of the particular cumulative real-time statistic to animate.

Choices include:

Utilization—The fraction of on-duty time during which members of the Agent Group are serving customers.

Number Busy—The average number of agents concurrently serving customers.

Number Available—The average number of idle agents.

6 • Contact Data Panel

If Data Object = Trunk Group:

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

Trunk—Selection of the Trunk Group to animate, from a list of all defined Trunk Groups.

Object Data—Selection of the particular cumulative real-time statistic to animate.

Choices include:

Utilization—The fraction of time during which trunk lines of the Trunk Group are busy.

Number in Use—The average number of trunk lines concurrently in use.

Number Available—The average number of trunk lines that are idle.

If Data Object = Overflow:

Source Group—Selection of the Agent Group from which overflowed contact counts should be animated.

Destination Group—Selection of the Agent Group to which overflowed contact counts should be animated.

6 • THE CONTACT DATA PANEL

• • • • •

If Data Object = System Time:

Display As—Selection of the view(s) by which the system time should be animated. Choices include:

Variable—Display of the day of the simulation run as a numerical quantity (1-28).

Analog Clock—Illustration of the day of simulation run as a clock face.

Digital Clock—Illustration of digital 24-hour clock in numeric form.

If Data Object = Other:

6 • Contact Data Panel

Other Data—Specification of an expression to be animated throughout the simulation run.

ARENA CONTACT CENTER EDITION USER’S GUIDE

• • • • •

If Data Object is not System Time:

Display As—Selection of the view(s) by which the chosen statistic should be animated. Choices include:

Variable—Display of the statistic as a numerical quantity.

Level—Illustration of the statistic as a graphical quantity.

Histogram—Illustration of the statistic as a histogram of values it assumes over time.

Plot—Display of the statistic as a plot over time.

Prompt Valid Entry Default

Data Object Contact, Agent Group, Parent Group, Trunk

Contact

Contact Name Symbol Name [Contact] Contact 1

Contact Statistic Type Contact Count, Contact-Back, Count,

Contact Data Selection from list of available statistics Abandoned

Agent Group

Agent Group Symbol Name [Agent Group] Agent Group 1

Agent Data Selection from list of available statistics Utilization

Parent Group

Parent Group Symbol Name [Parent Group] Parent Group 1

Parent Data Selection from list of available statistics Utilization

Trunk Group

Trunk Group Symbol Name [Trunk Group] Trunk 1

Trunk Data Selection from list of available statistics Utilization

Overflow

Source Group Symbol Name [Agent] Agent Group 1

Destination Group Symbol Name [Agent] Agent Group 2

Contact

Group, Overflow, System Time or Other

Contact Count

Contact Times, Percentages

Rockwell Automation Arena Contact Center Edition User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Contents

Welcome to Arena Contact Center Edition

What is Arena Contact Center Edition?

Intended audience

Simulation of contact centers

Arena Contact Center Edition: A custom-designed simulation system for contact centers

Where can I go for help?

Reference the user’s guides

Explore our examples

Get help

Use the SMARTs library

Access the Arena Symbol Factory

Get phone support

Get Web support

Get training

Get consulting services

Contact us

Introduction to Simulation

Simulation defined

Systems and models

Advantages of simulation

The simulation process

Problem definition and project planning

Style definition and model formulation

Experimental design

Input data

Verification and validation

Documentation and implementation

References

General Concepts

Overview

Planning horizon

Timeslots

Contact types

Data sources

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

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

Wait