Problem

A bank is attempting to improve customer satisfaction by offering better service to its customers.
Specifically, the management wants to ensure that on average, customers wait no longer than 2
minutes before receiving service and the waiting line is no more than 2 people long. We are
provided the probability distribution of the difference between customer arrival times (ranging
from 0‐5 minutes) and the probability distribution of the time it takes for the bank to serve a
customer (ranging from 1‐4 minutes). Using these probabilities and assuming that 150 customers
arrive at the bank each day to receive service from only one server (teller), we are tasked with
establishing whether or not the bank’s current system is satisfactory. If necessary, we can then
determine the minimal changes for servers required to accomplish the management’s goal.

Assumptions
1) Customers only arrive at the bank and are served at exact minute intervals.
The data given to us is only applicable by the minute, so estimating data and
probabilities in between minutes is impossible.
2) Customers are served in the order they arrive at the bank.
Most lines (queues in general) work this way. This is necessary in order to properly count
the waiting time of customers.
3) Servers work continuously until all 150 customers have been served (no breaks), and the
time difference between serving customers is negligible.
As soon as one customer is done being served, the next customer should immediately
begin receiving service in order to keep times on the minute.
4) The service time data provided corresponds to the rate of service of a single server, and
this single server serves all the customers in the original service system.
The provided data implies that there is only one line and one server, and the rate of
service for a single server needs to be consistent for us to create a model.
5) Multiple servers work at the same rate.
Servers need to all work at the same rate given to us in order for us to be able to predict
the outcome of waiting times and the length of the queue.
6) The time for an “emergency” (back‐up) server to begin servicing customers from when
he or she is called is two minutes.
It is not practical for someone to immediately begin working when they are called, so we
added a two minute delay period during which the worker would be transitioning.

define the following:

1) Customers are numbered from 1 to 150 in the order that they arrive.
2) The queue is the line in which the customers stand waiting to be served.
3) A server is a person who is capable of providing service to customers
4) All times are measured in minutes unless otherwise specified.
5) An emergency server is a server that only begins working whenever the queue length
exceeds a predetermined limit and stops working whenever the queue is empty.
6) qenter is the length of the queue before an emergency server begins to provide service to
customers.
 7) A probability mass function, or PMF, is the discrete‐time equivalent of a probability
density function. A PMF gives the probability that a random variate is exactly equal to any
given integer value [2]. For example, if F is a PMF, then F(x) = P(f = x).
.
Computational Approach (Model Designing)
In order to simulate more complex circumstances (specifically the effects of adding more servers)
and estimate the mean queue length, it is much more feasible to analyze the results of multiple
computer simulation trials. We designed a computer model based on state transitions at each
discrete time step: at any given minute, customers arrive at the bank, customers finish being
served, other customers begin being served, and emergency servers transition between serving
as tellers and performing other tasks.
We differentiate between two types of servers: regular servers, who are ready to accept
customers at all times, and emergency servers, who usually perform other, non‐customer‐service
tasks but can act as regular servers if needed, but only after some constant transition period.
We simulate the bank queue using the following algorithm:
1. All 150 customers are initialized, each with randomly determined t (time between arrival
of previous customer and arrival of current customer) and s (service time).
2. Using t1, t2, … t150, the arrival time a is computed for all the customers using cumulative
summation.
3. An internal clock variable time is set to 0 minutes. All customers are placed into a
customer queue, and a list of servers is created.
4. Perform the following procedure until all consumers are served, the waiting queue is
empty and no customers are in service:
a. All customers who were calculated to arrive at this time step (a = time) are
removed from the customer queue and added to the waiting queue.
b. All servers decrease their service counters by one. If the counter reaches 0,
remove the currently served customer and mark the server as inactive (not serving
a customer).
c. For every emergency server in the server list, increment the emergency‐server‐
time‐spent counter.
d. For every server that is currently inactive:
i. If this server is an emergency server and the waiting queue is smaller than
the emergency server’s exit queue length, mark the emergency server for
removal from the server list.
ii. Otherwise, if there is anyone waiting in the waiting queue, remove the
next customer from the waiting queue and record their waiting time (the
difference between time and a). Set this server as active and set their
service counter to s (the time this customer will be served for)
 iii. If there is no one waiting in the queue and this server is not an emergency
server (in other words, if this server remains inactive), increment the idle‐
time counter.
e. If there are emergency servers not on duty and the queue is larger than or equal
to the emergency enter queue length, add an emergency server to the server list
and decrement the number of not‐on‐duty emergency servers. Give this
emergency server a service time equal to the transition time, as this server will be
unable to accept a customer until after the transition.
f. Record current values of queue length.
At the end of every run, the average queue length for that “day” can be found by summing up all
the recorded queue lengths and dividing by the final value of time. Similarly, the average wait
time for each customer can be found by averaging the w’s for all of the customers. In this way,
our simulation accurately models the proceedings of a random day at the bank, and its versatility
allows it to be easily extended to fit new circumstances, such as the addition of new servers or
changes in server efficiency. However, because our algorithm simply produces a single random
outcome during each run, it can only approximate the true average wait time. Multiple trials thus
become essential to increasing the confidence of our results.

Model Data and Testing

wn is the difference in minutes between the nth customer’s arrival time and the time
when he/she begins getting served, equivalent to the nth customer’s waiting time.
Using Wolfram Mathematica, we iteratively evaluated the recurrence relations in Equations 2a
and 2b from the starting point W1(0) = 1, and found the average wait time to be 4.92761 minutes.
We also computed the probability mass distribution (average probability that any customer waits
x minutes) taking the average of each customer’s wait time distributions. The theoretical values
of can be found in Table A. Interestingly, with the given probabilities for differences in arrival time
and service time, there is a 0 = 25.08% chance that any given customer is served immediately,
indicating that over one quarter of customers should not have to wait even if only one server is
present.
Experimentally, we ran our computer simulation 10000 times, recording the wait times for every
customer and the average queue length for each trial. Plotting the experimental wait times
against the theoretical wait times ( ), we can see that the two distributions match each other
almost exactly ‐ the data points for the theoretical values are hardly even visible (Figure 1). A
more detailed comparison of experimental values can be found below
Table A: Experimental values for values of x from 0 to 5
x W(x)experimental
0 0.249608994
1 0.098389626
2 0.093728065
3 0.087623596
4 0.072983742
5 0.061038971
6 0.052988052
7 0.044584274
8 0.037916183
9 0.031980515
10 0.026967049
11 0.022891045
12 0.019203186
13 0.016200066
14 0.013542175
15 0.011408806
16 0.009776115
17 0.008030891
18 0.006660461
19 0.005592346
20 0.004709244
21 0.003953934
22 0.003400803
23 0.002817154
24 0.00228405
25 0.002033234
Figure 1: A comparison of the theoretical and experimental probability distributions for average customer wait time
on a 150 customer day with only one server available. Notice that the two graphs match each other almost exactly,
indicating that our computational simulation has a high accuracy when run over 10,000 trials. The only significantly
visible error is the slightly higher experimental value for wait time 0.

We computed the average wait time for the theoretical distribution to be 4.92761 min., whereas
the average wait time for the experimental distribution over 10000 trials evaluated to 4.9195
min., a difference of only 0.164%. With this level of accuracy, we can safely extend our computer
simulation into cases with multiple servers without having to worry about insufficient confidence
levels.
Because our theoretical model is incapable of evaluating average queue times, we assumed that
our simulation’s accuracy in average wait times is indicative of overall accuracy, especially
accuracy in average queue length, as the two quantities are closely related. Though this
assumption is not entirely justified, strong correlation between the theoretical and experimental
wait times still helps to support the validity of our computation model.
With only one server available, the experimental average queue length evaluated to 1.84773, a
value already less than the 2 persons or fewer goal desired by the manager. Because our average
wait time of 4.92761 minutes per customer is considerably over 2 minutes, however, a strategy
must be adopted to help reduce this average wait time. Furthermore, the standard deviation of
average wait times on each given day is 3.30591 minutes, indicating that the wait
times vary greatly between days.

Potential Strategy
We tested two different changes in server structure in order to reduce the average customer wait
time:
 1. Increase the number of servers
2. Have additional “emergency” servers that only work when queue length exceeds a
certain number
Strategy 1: Increase the number of servers
By introducing only one additional server to the bank, we can drastically reduce both the average
queue length and average wait time of customers. Using our computer simulation, we obtained
an average wait time of 0.11285 minutes (about 6.77 seconds) and an average queue length of
0.043093, well within the 2 minute and 2 customer bounds specified. Furthermore, the standard
deviation of the daily average wait times is a negligible 0.06283 minutes (about 3.8 seconds),
indicating that the wait time is very consistently small. However, note that when two servers are
assigned there is a large period of time for which one or both of the servers are idle (on average
429.8945 server‐minutes, or 7.165 server‐hours), resulting in a greatly reduced work efficiency.
This data is summarized in Table 1.
Mean wait time Mean queue length Mean server idle time
Full‐time server 0.112851 0.043093 429.8945
Table 1: A summary of the mean statistics for the addition of a full‐time server. A full‐time server lowers
both the wait time and queue length well below the manager’s goals, but significantly increases the
amount of time servers spend idling, reducing in greatly reduced worker efficiency.

From the perspective of a manager, adding another dedicated (full‐time) server would definitely
reduce the average queue length and wait time to values below his/her desired goals, but at the
same time this strategy would waste money on hiring a full‐time server who would only work
for a small percentage of the total time.

Strategy 2: Add an emergency server

Unlike a dedicated server, an emergency server only begins working when the queue length
exceeds a predetermined limit (qenter) and continues to work until no customers remain in the
queue. Because it would be unreasonable for an emergency server to switch between tasks
instantaneously, we added a two minute transition delay before the emergency server could
begin his/her duties as server into our simulation. We tested various values of qenter to minimize
the amount of time the emergency server spends serving customers while still keeping the
average wait time below two minutes. Using our computer simulation, we obtained average
wait times and average queue lengths for the two minute and two customer bounds specified.
While adding an emergency server also creates time for which the dedicated server is idle, this
idle time is much less than that in strategy one. By setting qenter to 3 customers, we can
minimize the average server downtime to only 61.7 minutes while still satisfying the manager’s
desired conditions. Our results are summarized in Table 2:
qenter Mean Mean customer Mean queue Average number of Mean server
emergency wait time length times emergency idle time
server use time server is called
2 64.7958 0.927046667 0.35010662 10.7512 75.2787
 8
3 38.5827 1.464951 0.552342 4.6354 61.7095
4 25.0496 2.034833 0.7677 2.3729 53.0709

Table 2: A comparison of three values of qenter for an emergency server. The emergency server with qenter
= 3 meets the established requirements of the manager while minimizing the mean server idle time and
time spent by the emergency server providing services.

Comparison of Strategies
Overall, adding an emergency server with qenter = 3 keeps the average wait time under two
minutes and the average queue length to at most two customers while limiting the time that
additional server provides service to an average of only 38.5 minutes each day and keeping the
server idle time to a reasonable 61.7 minutes. This makes adding an emergency server the
minimal change for servers required to accomplish the manager’s goal. A comparison of the
approaches for an emergency server, the simple additional server, and the original single server
are shown below in Table 3, and graphical representation comparing the distribution of
customer wait times for these three strategies can be found in Figure 2.

Mean total server Mean additional Mean customer Mean queue

idle time server work time wait time length
(customers)
Single server 36.8365 min n/a 4.91953 min 1.847728
Emergency server 61.7095 min 38.5827 min 1.464951 min 0.552342
(qenter = 3)
Full‐time second 429.8945 min 397.6912 min 0.112851 min 0.043093
server
Table 3: A comparison of three different service systems. Note that the emergency server meets the goals
required by the manager while minimizing the mean total server idle time.
Note that while adding a full‐time server significantly reduces the mean wait time and mean
queue length, adding a single emergency server with qenter = 3 is sufficient to meet the manager’s
requirements while significantly reducing the total amount of time each server spends idle.
Figure 2:A comparison of the experimental wait time distribution for three different service systems: a
single full‐time server, two full‐time servers, and an emergency server with a full‐time server. The setup
with two full‐time servers clearly minimizes the amount of time customers have to wait in line, but its
lower efficiency compared to the emergency server setup makes it a worse strategy for management to
adopt.

Conclusion
We model the bank service queue using approach: computational simulation. Our computational
model suggests that the best method for management to satisfy the given requirements (at most
an average queue length of 2 and at most an average wait time per customer of 2 minutes)
would be to implement a single emergency server who would only begin working when the
queue length exceeded 3 customers. If this is not feasible, adding an additional server would also
reduce the average queue length and average wait time significantly below the manager’s
requirements, though this approach would result in a significant amount of server idle time and
thus reduced worker efficiency. The emergency server would only need to provide service for
customers for an average of about 40 minutes per day, leaving plenty of time to accomplish other
tasks that a full‐time server would not be capable of completing. This makes using a single
emergency server more profitable for the bank. Additionally, during the time when the
emergency server is not interacting with customers, he/she could be performing other tasks such
as organizing files, returning messages, or answering the phone. Through our sensitivity analysis,
we also determined that, when an emergency server was present, wait times fluctuated only
slightly given different arrival and service rates, as the emergency server would always be ready
to provide services to customers once the queue increased in length.

In the future, we could apply our computational method to larger scale banks with more servers
and more customers. This would make our model more applicable to practical situations. It
would be interesting to consider different probability distributions of customer arrivals
depending on the time of day, as customers are generally more inclined to arrive at the bank at
certain times of day, such as rush hour. We could also look at the economic impacts of adding
extra servers on the management. Additionally, if we had time, we could attempt to construct a
computational method with continuous intervals between arrivals and continuous service
lengths, using integration and probability density functions to model the situation with greater
accuracy.