Simulation of a Call Center

[pic 1][pic 2][pic 3]

Table of Contents

OBJECTIVE        3

CURRENT SITUATION        3

DATA COLLECTION        3

FITTING DATA        4

DATA ASSUMPTIONS        5

MODEL BUILDING        6

MODEL RESULTS and PRECISION        6

ANALYSIS OF ALTERNATE MODELS        8

CONCLUSION        10

OBJECTIVE

The objective of the project is to understand the One Stop Information helpline (call center) structure and come up with an improvement in the current resource structure to try to improve the waiting time or total time spent in system for callers.

I decided to try to simulate the call center because I had faced very high waiting times while trying to contact them. I decided to use Arena Simulation Software with the help of Arena Process Analyzer to improve the existing structure.

CURRENT SITUATION

The one stop information helpline is open on weekdays from 8AM – 5PM (9 hours). Students who have an issue with their Finances, Registration, Bursar or any other Issue can call the One Stop Information helpline to have their queries resolved. Upon calling the helpline, they are welcomed with a message and asked to enter their University ID. After this, the callers are asked to select the category of their query:

• Finances
• Registration
• Billing
• Other

After selecting one of these options they proceed to join a queue, with an unusually long waiting time to speak to one of 4 agents. The time spent waiting for the agent and service times are very high.

This project aims to analyze the benefits of adding additional trunk lines or an additional resource and to see the improvement in waiting times for callers.

DATA COLLECTION

Data collection for the project proved to be a challenge because the One Stop Office staff were not prepared to share their data, and were unavailable to answer my questions. I was left with the option of calling the One Stop Information helpline and tracking the waiting times for each trial and conducting surveys of multiple call center agents. I was able to collect data about delays in the welcome message and the Interactive Voice response system myself, but had to rely on the agents for data about number of people calling per day, and service times for each call type.

FITTING DATA

The Input Analyzer for Arena was used to fit data to distributions. The following Distributions were fitted to the respective call types. (All times in minutes)

• Triangular (4,5,7) –Service time for Registration Queries
• Triangular (4,6,7) –Service time for Financial queries
• 5+4*Beta (2,1.6) –Service time for Billing Queries
• Triangular (7,8,9) –Service time for any Other queries

Registration queries- Service time

[pic 4]

Financial Queries- Service time

[pic 5]

Billing queries- Service time 

[pic 6]

Other queries- Service time

[pic 7]

Apart from this, the following distributions were also used

• Welcome message – Uniform (45,50) Seconds
• Enter MID – Uniform (15,20) seconds
• Category type message – Uniform (30,40) seconds

DATA ASSUMPTIONS

• Proportion of calls made and their category. This information was obtained through Call center agent survey

• 25% of calls are made for Registration queries
• 15% of Calls are made for Financial queries
•  10% of calls are made for Billing queries
• 50%- All other queries

• No information about the number of Trunk lines available was available. It has been assumed in the model that there are 25 available trunk lines which are available for callers. In case a call arrives when all the 25 Trunk lines are seized, then that call will be dropped
• Inter-arrival time of Exponential (1.8) minutes. This was obtained from a survey question to the agents about the number of people that they talk to every day

 MODEL BUILDING

• Arrive Module: The call arrives with a first creation value of Expo (1.8) minutes and inter-arrival time of Expo(1.8) minutes
• Record Module: For recording the total number of calls that were made in the system including dropped/ rejected calls
• Decide Module: A decide module has been used to ascertain the number of Trunk lines that have been seized at that moment. If the number of Trunk lines seized is less than 26 then the call proceeds to seize one of the available trunk lines. Else the call is rejected using a dispose module.
• Seize and Release Modules: The calls which pass the Decide module proceed to seize one of the available Trunk line resources. This trunk line is released just before the call exits the system after speaking to the agent
• Delay modules: 3 Delay modules have been used to replicate the following stages in the call

• Soothing music and welcome message
• The Interactive voice system asks the user to enter their University ID
• The user is then instructed to choose the Query category from Registration, Finance, Billing and others

• Assign Module: Assign module has been used with the “Disc” function to segment the calls into the 4 categories based on their probabilities
• Process Module: The Process module has been used along with the ‘Expression’ feature to specify different service times for different categories of query
• Dispose Module: The caller exits the system after releasing the Trunk line that the caller had seized

Flow Chart Screenshot

[pic 8]

MODEL RESULTS AND PRECISION

The model was initially run for 30 replications to determine the number of replications required for a particular precision value.