A model for determining the daily manpower of a Contact Center

(1)

A model for determining the daily

manpower of a Contact Center

Application of the model to the Service Desk of the Rabo Financial

Logistics Portal

Pieter van der Mijle

(2)

Master thesis Econometrics, Operations Research and Actuarial Studies Supervisor: dr. J.W. Nieuwenhuis (University of Groningen)

(3)

A model for determining the daily

manpower of a Contact Center

Applying the model to the Service Desk of the Rabo Financial

Logistics Portal

Pieter van der Mijle

∗

Abstract

In this thesis, the problem of determining the required manpower for a contact center is studied. Comparing to call centers, contact centers deliver services via other means of communication than only telephone. Therefore, contact centers have different workflows for

each means of communication. The model that we will develop determines the required manpower for each workflow. Often each workflow has its own service level agreement that

has to be achieved.

The determination of required manpower is done for the Service Desk RFLP of Rabobank International. The Service Desk RFLP offers support to clients who make use of the Rabo Financial Logistics Portal, an online banking application for corporate clients and large business clients. The Service Desk RFLP mainly handles requests by phone and e-mail. However, the Service Desk RFLP is different from other contact centers, because the agents also handle requests that are not directly solved. Those requests cause an extra workflow for

the first line agents of Service Desk RFLP.

∗_{Master student in Econometrics, Operations Research and Actuarial Studies; University of Groningen;}

(4)

Preface

This master thesis is the final project of my study Econometrics, Operations Research and Ac-tuarial Studies at the University of Groningen. For this thesis I did an internship at Rabobank International in Utrecht.

First of all I would like to thank Heleen de Nooijer for her supervision at Rabobank. She gave me valuable feedback during my internship. Furthermore my gratitude goes to Corence Klop who helped me a lot to understand the processes at the Service Desk RFLP. At the university I would like to thank dr. Nieuwenhuis. His suggestions and comments have always been helpful to improve my thesis. Besides that I want to thank dr. van Foreest as my co-assessor. Finally I would like to thank my family and friends for supporting me.

(5)

Management summary

A contact center delivers services to clients via more means of communication than only telephone. An example of a contact center is the Service Desk RFLP. The Service Desk RFLP offers technical and functional support to corporate clients and big commercial clients who use the online banking applications of Rabobank International. One of the goals of the management of the Service Desk RFLP is to create a good match between the number of first line agents, the workload and the service level agreements. An over-capacity of agents often leads to less productivity and is costly, while a shortage of agents results in a low performance on the service level agreements and a high pressure of work. Until now, only rough calculations are made to determine the number of first line agents for the Service Desk RFLP. Quantitative methods gain insights into the determination of the required manpower. This leads to the following research question of this thesis: How can we build a mathematical model that determines the required manpower for the first line support of the Service Desk RFLP daily, based on predefined input parameters and requirements?

Currently, the majority of the client’s requests arrive by phone or e-mail. For the most part, the client’s requests are solved after the first handling by the first line agents. A small part of client’s requests has to be solved at a later moment. Those requests lead to an outstanding service request. So, three workflows determine the required manpower for the first line support of the Service Desk RFLP. Namely handling phone requests, handling e-mail requests and handling outstanding service requests. Each workflow has its own service level agreement.

The required manpower is initially determined for each workflow separately. Next to the service level agreements, main parameters that have to be incorporated are, for instance, the arrival pattern and the service times. Both the arrival pattern and the service times show a high variability. Due to this variability, more manpower is required to achieve the service level agreements than simply multiplying the average service time and the average number of arrivals. This is the ‘price’ that has to be paid to achieve the service level agreement. In general, the stricter the service level agreement, the more manpower is required. Phone calls have the strictest service level agreement and hence require relatively the most manpower.

The phone agents of the Service Desk RFLP are to a large extent not occupied with handling phone calls. Main reasons are the high variability of a relatively small number of incoming phone calls and a strict service level agreement. Therefore, those phone agents can partially spend their time on handling e-mails and outstanding service requests. However switching between tasks does not work effectively. Furthermore, a shrinkage percentage has to be incorporated, because it is unrealistic to assume that agents spend their whole working time on doing their tasks. Finally, the total required manpower is calculated by combining the required manpowers per workflow. In conclusion, the model that is developed determines the required manpower for the first line support of the Service Desk RFLP based on a number of input parameters. By adjusting the input parameters alternative scenarios can be analyzed. The model can be used as an advising tool for determining the daily occupation of the Service Desk RFLP, but the model is also applicable to budgeting purposes.

(6)

1 Introduction

The call center industry is rapidly expanding. During recent years, the call center industry had an annual growth of 20%. Also the range of duties a call center has increased, i.e. call centers offer more services. More than 50% of the business transactions are conducted over the phone. For other call center statistics, seehttp://callcenternews.com/resources/statistics.shtml. According to Gans, Koole, and Mandelbaum (2003), a call center constitutes a set of resources (typically personnel, calculaters, and telecommunication equipment), which enable the delivery of services via the telephone. A call center that also delivers services via other means of communi-cation (e-mail, fax, letter, etc.) is called a contact center. A request regardless the means of communication is called a client’s request. There is a distinction between inbound and outbound call centers. Inbound call centers handle incoming calls that are initiated by outside callers. Often, inbound call centers offer client support for example, help desks, reservation and sales support, and web-based merchants. Outbound call centers handle outgoing calls, calls that are initiated from within a call center. Examples of this kind of call centers are: advertisers, telemarketers, poll-takers etc.

The call center industry is subject to improvements and innovations. Usually, the goal of these improvements and innovations is to enhance service quality of handling client’s requests given the budget. Service quality is defined as the degree of satisfaction of clients with the offered service. Service quality can be divided into two parts, namely qualitative service quality and quantitative service quality. The former is friendliness, fast solution, etc. The latter contains for example, wait-ing times and abandonments. The costs of a call center are mainly personnel costs. Approximately 70% of the total operating costs are personnel costs. Often, the objective of call and contact centers is to maximize service quality such that the budget constraints are satisfied. A possible way to achieve this objective is to find efficiency gains in the whole process of serving clients.

(10)

2 Problem description

First, the context of the research is discussed. Some information on Rabobank is provided. Fur-thermore, the Rabo Financial Logistics Portal is described in more detail and the important de-partments regarding the support process are explained. Next, the possible paths of an incoming client and the registration of a client request are described. After that, the objective and research question are defined. Finally, some literature about call and contact center research is discussed.

2.1 Context of the Research

Rabobank Group is a Dutch international financial services provider. It came into being as a co-operation of small local banks, which offer services to the local markets. Rabobank is a merger of two cooperative banks, namely the Co¨operatieve Centrale Raiffeisen-Bank and the Co¨operatieve Centrale Boerenleenbank. Both were a cooperation of local banks and provided the rural folk with financial services, they merged in 1972. Nowadays, Rabobank Group consists of 143 independent member banks (in Dutch: Aangesloten Banken (AB)) and their central organization Rabobank Nederland. Based on this, Rabobank operates on the basis of cooperative principles and is not quoted on the stock exchange. In the course of time, Rabobank has expanded its international activities. These international activities are joined together under the name Rabobank Interna-tional. Currently, Rabobank Group has around 60,000 employees, who serves 9.5 million clients in 48 countries. It offers retail banking, wholesale banking, asset management, leasing and real estate services. This thesis mainly concerns the online banking application RFLP and especially the support of clients who use RFLP. First, RFLP will be explained in more detail. Next, the relevant departments are described.

2.1.1 Rabo Financial Logistics Portal (RFLP)

Big companies have very complex financial logistics. To keep control over a huge amount of bank accounts and cash flows Rabobank has developed the Rabo Financial Logistics Portal (RFLP). RFLP provides an actual online overview into your entire financial position. RFLP consists of five different modules, namely Rabo Cash Management, Rabo Trade Access, Rabo Deal Assist, Online Money Order, and Deposit Announcement. Rabo Cash Management (RCM) is the heart of RFLP and allows to bank online at home and abroad. Using Rabo Trade Access (RTA) it is possible to deliver, authorize, modify, and examine the Letters of Credit. Rabo Deal Assist (RDA) gives online access to the dealing room. With Online Money Order (OMO) it is possible to order cash money. Finally, Deposit Announcement (DA) allows to enter deposits in advance. In conclusion, with RFLP the different modules are integrated into one application, an overview is given in Figure 1.

RFLP

RDA

RCM

RTA

DA

OMO

Figure 1: RFLP and its underlying modules.

(11)

Rabo TransAct is a new entrance portal for treasury services, TransAct Valuta is one of its under-lying modules that has the same functions as RDA. In the future, the modules of RFLP will be part of Rabo TransAct and Rabo TransAct will be the only entrance portal for financial services to corporate clients and large business clients. Rabo TransAct also has a report tool for clients, namely Rabo TransAct Report (RTR). RTR allows clients to make their own statistical reports about for instance transfers of certain bank accounts.

Finally, the Automated Transfer Tool (ATT) is a simple tool to import a big amount of transfers automatically in RCM without logging in, or using passes. Furthermore, it is possible to export a big amount of account statements from RCM to another files.

The ‘served products’ are defined as the products that are supported to some extent by the Ser-vice Desk RFLP. RFLP, RCM, RDA, RTA, OMO, Rabo Transact, RTR, and ATT are the served products.

2.1.2 Relevant Departments Corporates Operations & Services

Corporates Operations & Services (COS) is the service organization for corporate clients and large business clients of Rabobank International and the member banks. The majority of the clients of COS are active in the Food and Agribusiness, Trade, Industry and Provision of Services. COS offers service to these clients in the field of payments, loans and facilities. COS has several underlying departments namely, Transaction Portal Support, Cash Management Operations, Agency Desk, Contract Management, and Business Management. This research mainly focuses on Transaction Portal Support and its underlying teams, the other above mentioned departments are left out of consideration.

Transaction Portal Support

Transaction Portal Support (TPS) engages with development, fulfillment, and support of Rabo Cash Management in the Rabo Financial Logistics Portal.

Service Desk RFLP

The staff of the Service Desk RFLP offers support to corporate clients (CC) of Rabobank Interna-tional and big commercial clients of the member banks (AB) with respect to the use of the served products. Tasks are answering technical and functional requests about RFLP, RCM, and OMO. Simple technical questions about RDA, RTA, TransAct, RTR, and ATT such as login, authoriza-tion, and card reader requests, are also answered by the Service Desk RFLP. Banking requests will be forwarded to the Corporate Client Support Desk for CC clients. In case of AB clients, banking requests are answered by the corresponding member banks. All incoming calls, e-mail, faxes and letters related to the served products are treated by the first line support of the Service Desk RFLP. If the first line support is not able to answer the request from the client, the request will be forwarded to the second line support or other specialized departments. Furthermore, all requests about fulfillment and migration will be sent to the Fulfillment Desk RFLP Desk and Financial Lo-gistics Implementation Management respectively. This process of solving and forwarding a client’s request is explained in more detail in Section 2.1.3.

Fulfillment Desk RFLP

(12)

RDA, RTA, and OMO. New clients for RCM are handled by another department, namely RCM Migration Quality Team, see the paragraph below.

RCM Migration Quality Team

RCM Migration Quality Team (RMK) is responsible to complete the fulfillment in RCM. The RMK imports for instance the client data, the bank accounts and the permission profiles in RCM. RMK fulfills both migration clients and new clients in RCM. If this is done, the users will be activated and RCM is ready for use.

Competence Center TPS

Next, Competence Center TPS is involved in new features around RCM and participates in several RFLP projects. Their tasks are translating the demands from the clients into requests for changes (RFCs), doing acceptance tests, managing the support and fulfillment processes, but also preparing new releases of RCM. New releases of RCM need adjustments in manuals, procedures, etc. The organization chart of Transaction Portal Support is given in Figure 2. Finally, MOVE is explained.

TPS RFLP Fulfillment Desk Sevicedesk RFLP RCM Migration Quality Team Competence Center

Figure 2: Organization chart TPS.

MOVE

Actually, MOVE is a project rather than a department. At this moment, a lot of clients (CC and AB) change from an old offline banking system, RTE (in Dutch: Rabo Telebankieren Extra), to RCM. MOVE serves this specific group of clients. During the migration process, various depart-ments are involved, including Financial Logistics Implementation Management and RMK. RMK does the actual fulfillment in RCM. The expectation is that at the end of 2010 the portal RFLP will have 5, 000 clients, from which 3, 000 are new (migrated) clients. In the future, if all clients are migrated from RTE to RCM, the project MOVE has done its job and disappears. In this research about the support process, we will refer to MOVE if clients have to migrate from RTE to RCM.

2.1.3 The way of an incoming client’s request

(13)

Client’s requests

Support requests

Other requests

Figure 3: Distinction between support requests and other requests.

second line. The first line agent has to provide information about the problem like screenshots, error messages, logs, etc. The second line is responsible for analyzing and solving more complex and/or more time-consuming requests and technical incidents. Requests about ATT are forwarded to the second line faster, because these requests are often too technical or complex for the first line to handle within the 20 minutes time limit. If the second line is able to solve the request, they communicate the solution to the client by e-mail. It can happen that the second line cannot solve the request either. In this case, the request will be forwarded to the third line of IS&D E-Commerce Financial Logistics Applications (Application Support). The second line sends all required information to the third line. If the third line solves the request, the solution will be sent to the second line. The second line checks the solution and communicates the solution to the client by e-mail. In case it is not possible to solve the request internally, the problem is sent to the vendor of RFLP, Computer Communication Networks GmbH (CoCoNet)1. If a serious delay in serving a client’s request occurs, the first line communicates this to the client in question. Also straightforward technical requests about RDA, RTA, TransAct, and RTR are handled by the first line agents of the Service Desk RFLP, e.g. login, authorization, and card reader requests. Requests with respect to content or functional requests are forwarded via phone or e-mail to the first line support of the IS&D E-Commerce Treasury department, for TransAct, RTR, and RDA respectively. More complex requests about RTA are forwarded to Mid-office RTA. These depart-ments will handle further communication with the client. Other requests (fulfillment, migration, etc.) are forwarded to the departments concerned.

2.1.4 Registration of an incoming client’s request CARE

For each incoming client’s request consisting of a request a call is registered. For client’s requests about an existing request no new call is registered, in this case the existing call will be updated. Registering a request as a call is independent from the communication line the requester uses (e-mail, telephone etc.). The call is registered in CARE (this is a Rabobank name, the underlying system name is OMNITRACKER2). For a new call, the agent of the service desk has to fill in client data, title of the request, description of the request, source (telephone, e-mail, etc.). To solve the request, the agent has to create service requests. Hence, calls can consist of various service requests. Service requests are the required actions that have to be executed such that the client’s request can be solved. Sometimes, a whole set of service requests has to be executed in a specific sequence to solve the request of the client. A lot of sequences of service requests are preprogrammed, these are called packages of service requests. For example, to add an extra bank account in RCM two service requests have to be executed. First, the permission profiles of one or more RCM users have to be adjusted. Next, the bank account has to be added to the client agreement in RCM. Often, the service requests have to be executed by other departments for example, the Fulfillment

1_{CoCoNet is a market leading provider of tailored software solutions for banks, corporates, and service providers.}

CoCoNet develops secure, high-end systems for financial transactions; seehttp://www.coconet.de/.

2_{OMNITRACKER is a software package that contains a registration and tracking system for service organizations}

(14)

Desk RFLP. Hence, the Service Desk RFLP produces the required set of service requests, but the service requests are executed by the appropriate departments. Finally, if all service requests are completed, the call is solved. The solution of the request is communicated to the client by e-mail. Furthermore, the state of the call is set to ‘Solved’. When a call is generated and not directly solved, the state of the call is ‘In Progress’.

If there is a direct solution, the agent is immediately able to answer the request and its corre-sponding service requests. The agent fills in the solution in the call. It is possible to sent the solution to the client by e-mail. Sometimes, this is not necessary, for instance if the solution is already directly communicated to client during the phone conversation.

CARE contains also a Frequently Asked Questions (FAQ) folder, this folder contains solutions for requests that frequently occur. However, the FAQ folder is not complete, sometimes there is only a solution available for the agents and not a standard e-mail to the client. Furthermore, some solutions of the FAQ folder are not up to date anymore.

Assyst

Assyst3 _{is a similar software system as CARE. This system is used by the IS&D E-Commerce} department. If the second line of the Service Desk RFLP has to forward a request to the third line of IS&D E-Commerce Financial Logistics Applications this is done via Assyst.

Avaya

The Service Desk RFLP uses an Avaya4 Automated Call Distribution (ACD), this device dis-tributes the incoming calls to the agents. The routing strategy is as follows, the client who waits longest in queue will be served first. The client is connected to the agents who is idle for the longest time. Using the Avaya environment a lot of data is stored. For example, the precise date that a phone call arrives, the waiting time, the serving time, the number of calls served per agent, etc. The various paths of a client’s request are shown in Figure 4, this process is also called the support process. If a support request of one of the served products is not solved by the Service Desk RFLP, the request will be boarded out to another department. This is depicted in the figure with an arrow where the concerning product of the request is between brackets. For example, the outsourcing of RCM support requests are sent to the third line of IS&D E-Commerce Financial Logistics Applications.

3_{Assyst is an integrated Help Desk & IT Service Management software solution; see}_{http://www.axiossystems.}

com/.

(15)

Solved Requests @ Client’s requests First Line Second Line @ CC# CC _{# AB}@ AB Third Line RFLP Fulfilment Desk Solved Requests #/@ Corporate Client Support Desk @ @ # Financial Logistics Commercial Support @ # C #/@ @ Unilateral communication Bilateral communication

Communication via phone

Communication via e-mail

Communication via CARE

Communication via Assyst

Corporate Clients

Large business clients of member banks Servicedesk RFLP (COS) C @ # @ C Information delay @ A (RF LP/RC M/OMO /ATT) Mid-office RTA # (RTA) CoCoNet (RFLP/RCM) MOVE (Migration) Third Line Second Line First Line

E-Commerce (IS&D Utrecht)

#/@ (TransAct/RDA/RTR) FL applications Treasury China Systems (RTA) A Nexaweb (TransAct/RDA/ RTR) A CC AB

Figure 4: Possible paths of a client’s request.

(16)

2.2 Objective and research question

At this moment, the number of clients that use RFLP is rapidly increasing. The main reasons are changing from an old offline banking system (RTE) to RCM and a more complex financial situation of many companies. Hence, there is more pressure on the departments that facilitate RFLP and its underlying modules. Due to the increase of RFLP clients, there is also an increase in client’s requests. Hence, the departments related to the support process will be more busy. In general, there are two solutions to manage this increase, namely:

increase workforce;

streamline the support process in a more effective way.

This thesis deals with both solutions. First, a model is made that determines the required man-power for the first line support of the Service Desk RFLP, such that the Service Desk RFLP performs well. Second, based on the model it is possible to analyze various alternative scenarios by adjusting the input parameters. The results might give incentives to streamline the support process and especially the first line support of the Service Desk RFLP.

The next question that comes up is how is the performance of the first line support of the Service Desk RFLP measured. Performance measures are variables to evaluate the performance of an organization and reflect the critical success factors of an organization. They are also called Key Performance Indicators (KPIs) and show how well an organization works. According to e.g. Stollets (2003), the main KPIs related to contact centers are stated below:

average speed of answer (ASA);

service level (percentage of calls answered within a predefined number of seconds); number of served calls;

number of abandoned calls; abandon rate;

average service time;

average after call work time; average waiting time; agent utilization; agent availability;

first contact resolution rate; costs per call;

costs per minute of service time;

average cycles late (ACL), where a cycle is the standard time to answer for instance an e-mail. If an e-mail needs two days to answer, while the standard time is one day. That e-mail is one cycle too late.

(17)

Objective:

To get insight into how the support process is currently formed and to determine the required manpower for the Service Desk RFLP.

The following research question is formulated to satisfy the objective:

How can we build a mathematical model that determines the required manpower for the first line support of the Service Desk RFLP daily, based on predefined input parameters and requirements? In order to solve the research question, the following subquestions are important:

1. How is the support process currently formed?

2. Which workflows determine the workload of the first line support of the Service Desk RFLP? 3. What are the key performance indicators and the service level agreements of the first line

support of the Service Desk RFLP?

4. What are other requirements or input parameters that have influence on the manpower of the first line support of the Service Desk RFLP?

5. How can a mathematical model be designed that relates a set of predefined input parameters and required manpower for the first line support of the Service Desk RFLP and makes it possible to analyze alternative scenarios by adjusting the input parameters?

Some possibilities of adjusting the input parameters are listed below: change parameter of the arrival distribution of client’s requests; change parameter of the distribution of service times;

allow different routings for groups of client’s requests; change in service level agreements;

Note that, the routing of client’s requests may change due to, for example, the training of first line agents, such that they are able to solve requests, which were previously forwarded to other departments.

In Section 3 the first three subquestions are treated. Based on the workflows defined in Section 3 the required manpower is determined for each workflow separately in Sections 4, 5 and 6. The determination incorporates the service level agreements and other important input parameters. So, in Sections 4, 5 and 6 the fourth subquestion and partially the fifth subquestion are discussed for each workflow. Section 7 completes the fifth subquestion by aggregating the workflows to determine one total required manpower for the Service Desk RFLP. Besides that, we take into account that agents do not effectively work the whole day on their main tasks. Finally in Section 8 the conclusions of this thesis are stated. Furthermore, Section 8 provides recommendations to Rabobank International regarding the Service Desk RFLP and lists some limitations of this thesis and topics for further research.

2.3 Assumptions

(18)

in for instance CARE. For letters it is very difficult to trace both its arrival time and service time. Requests by fax will be transferred into an e-mail and handled as an e-mail.

During the research of the support process, we mainly restrict ourselves to the first line support of the Service Desk RFLP. The first line and second line of the Service Desk RFLP are principally involved with client’s requests. Other parties are only partially involved if the requests are related to other departments, or if requests could not solved by the Service Desk RFLP itself. If requests ‘leave’ the Service Desk RFLP the process behind the exit destination will not be monitored. Ac-cording to Figure 4, we take into account the flows of requests within the Service Desk RFLP and all incoming and outgoing flows of the Service Desk RFLP.

Furthermore, the parameters in the model are based on data analysis. Hence, we have to limit ourselves on a certain time period. Changes in the environment of the Service Desk RFLP also affect the Service Desk RFLP. For example, due to the increase in clients, the Service Desk RFLP also has to increase its manpower. Therefore, the Servcicedesk RFLP is almost always involved with new unexperienced agents. These new agents are far from efficient in doing the daily tasks. This has influence on, among other things, the service times to handle requests. So, we have to incorporate the fact that new agents do not work as effective as an experienced agent. Besides that, we use data of the Service Desk RFLP from a relative stable period. Stable in the sense, that during the period there are no rigorous changes related to the Service Desk RFLP.

2.4 Literature research

Due to the rapid increase of the call and contact center industry the last decades, also research related to call and contact center industry is boosted. In this section, some literature will be discussed that is published and is related to the theory of analyzing call and contact centers. First of all, Mandelbaum (2004) provides a whole list of call center related work. It includes references and abstracts of published articles in various kinds of research fields, but also books, cases, journals, and web sites. Some articles that are related to my research will be singled out below.

Gans et al. (2003) provide a general description of the main call center theory. Based on an example the article shows how and which academic research is implemented in a call center. Furthermore, the article states some problems that have not been researched yet, but may be interesting for future research. Koole and Mandelbaum (2002) is a summarized version of Gans et al. (2003). Koole (2007) is an e-book that offers scientific methods to improve call and contact centers. The e-book is a bridge between the call center management and those parts of mathematics that are useful for call and contact centers.

The following articles have been written on the planning of manpower in various kind of fields. In Kwan, Davis, and Greenwood (1988), the worker requirements are determined for short scheduling periods, since there is non stationary customer demand. Using simulation, the performance of this method is determined. The performance is compared with results based on queueing theory. Integer linear programming is often used to formulate a mathematical model that generates an optimal schedule. Kolesar, Rider, Crabill, and Walker (1975) propose a method to schedule in this instance police patrol cars in New York. First, patrol car requirements are estimated. After that, an integer linear program is designed based on the requirements with an optimal schedule as solution. Before trying any such schedule in real-life, the optimal schedule is tested using a time-dependent M/M/c queueing model that represents more complexity. Later, in Gaballa and Pearce (1979) integer linear programming models are used for scheduling manpower of sales reservation offices.

(19)

transportation, and call center analysis.

Jackson (1957) provides theory about modeling queueing networks. Queueing networks are sys-tems of an arbitrary number of queues. In fact, the support process that is considered in this thesis consists of more than one queue. To use Jackson’s theorem, the system should satisfy several re-strictions. Gordon and Newell (1967) extended Jackson’s theorem, such that is applicable to more kinds of networks.

(20)

3 Current situation

Nowadays, clients are often supported via other means of communication than telephone. The successors of call centers are called contact centers. Beside telephone services, a contact center provides support via e-mail, internet, fax, etc. The Service Desk RFLP is an example of a contem-porary contact center. In this section, the current situation of the Service Desk RFLP is described in more detail, especially with respect to the workflows of the first line. How is the support process currently formed? What are the main workflows that determine the agents’ tasks? And, what are the key performance indicators and corresponding service level agreements that describe the performance of the first line support of the Service Desk RFLP? This section treats the first three subquestions and is actually a continuation and an extension of Section 2.1.3 and Section 2.1.4. As already mentioned, client’s requests arrive by telephone, e-mail, fax, and letter to the Service Desk RFLP. During this research, we only consider telephone and e-mail requests. Generally, all client’s requests are registered in CARE as calls. There are some exceptions, for example, if a client’s request is immediately forwarded to another department that does not use CARE. A call in CARE consists of at least one service request. Support requests usually contain only one service request, whereas other requests generally contain more than one service request. Service requests belonging to support requests are initially solved by the first line agents. On the other hand, service requests belonging to other requests will only be registered by the first line agents, but executed by other departments.

If support requests are being considered, there are in general three possibilities. The request is solved directly (direct solution), the request is forwarded to the second line or other specialized departments, or the request is solved at a later moment by the first line agents. A direct solution for support requests with telephone as source means that the request is solved during the telephone conversation or directly after the telephone conversation. For e-mail, a direct solution means that the support request is solved during the first handling by an agent.

Possible reasons why a support request cannot be solved directly are: complexity of the request, additional information from the requester needed, or time pressure. The corresponding service request becomes an outstanding service request. The agent who has initially handled the request is still responsible. Usually, agents have a number of outstanding service requests that are not solved directly. To conclude, first line agents are working on three kinds of tasks, namely:

handling phone requests; handling e-mail requests;

handling outstanding service requests.

Every day, the first line agents are divided into two groups: phone agents and CARE/e-mail agents. Phone agents mainly handle requests by phone and CARE/e-mail agents handle requests by e-mail and their outstanding service requests. Sometimes, agents deviate from their assigned tasks. For example, if there is an overflow of telephone calls, CARE/e-mail agents temporarily handle phone calls too. On the other hand, if phone agents are idle, they handle e-mails or outstanding service requests. In general, phone requests have priority over e-mail and outstanding requests. The reason is that phone requests cannot be postponed and e-mail requests can. Furthermore, if callers have to wait too long before reaching an agent, there is a higher probability that callers abandon. Of course, e-mails never abandon. At this moment, 6 phone agents and 4 CARE/e-mail agents are scheduled on average. All agents are skilled to do both tasks. One of the main arguments to do this research is to gain an insight into the factors that determine the required manpower per workflow.

(21)

Phone queue E-mail queue Arrivals by Phone Arrivals by e-mail abandonment CARE/e-mail agents Phone Agents Call SR Call SR SR SR Solved SRs (direct solution) Other departments (2nd line) Call SR Call SR SR queue Outstanding SRs SR SR Solved SRs (direct solution) Other departments (2nd line) Outstanding SRs SR level Call level

Figure 5: Workflow diagram of the Service Desk RFLP.

3.1 Key Performance Indicators and Service Level Agreements

In this section, the Key Performance Indicators (KPIs) and Service Level Agreements (SLAs) of the Service Desk RFLP will be discussed. By definition, a SLA is a part of a service contract where the level of service is formally defined. The KPIs which we will describe are the performances against the predefined SLAs.

The three kinds of workflows phone requests, email requests, and outstanding service requests -all have their own SLA. For phone requests, the SLA is to answer 85% of the incoming c-alls within 20 seconds daily. In call center terms this is called a service level (SL) or telephone service factor (TSF) of 85/20. The KPI is the actual percentage of incoming calls that is answered within 20 seconds daily. This service level measure is a bit under discussion, because a caller that has to wait 22 seconds is counted the same as a caller that has to wait 5 minutes. Hence, the extent of exceeding 20 seconds is not taken into account. Another frequently used performance metric or KPI is the average speed of answer (ASA), which is the average waiting time of all incoming phone arrivals. The average speed of answer is not yet used by the Service Desk RFLP.

The SLA for e-mails is that 100% of the incoming e-mails before 4:00pm should be registered the same day, hence before 5:30pm which is the closing time of the Service Desk RFLP. The KPI is the actual percentage of incoming e-mails before 4:00pm that is registered before 5:30pm the same day. Under registering we mean:

the support request is directly solved;

the support request is not directly solved, the corresponding outstanding service request should be solved later;

(22)

After registering an e-mail, the clients receives a confirmation of receipt containing the client’s request and the possible direct solution.

Finally, the SLA for outstanding service requests is that all the outstanding service requests should be solved within 5 working days. The KPI is the actual percentage of outstanding service requests that is answered within 5 working days.

(23)

4 Determination manpower for phone workload

First, we will look at the arrival process of phone calls of the Service Desk RFLP in various time intervals. Next, the service time of phone calls is analyzed. After that, the relation between Queueing theory and the phone workload of the Service Desk RFLP is discussed. Based on this theory, we will model the phone activities of the Service Desk RFLP as a queueing system and argue why we use this model. Finally, the methods to determine the manpower during the day given the SLA are discussed.

4.1 The arrival process of phone calls

This section provides an analysis of the arrivals of phone calls. Our data originates from the Avaya system that is used by the Service Desk RFLP. The start date of the phone arrival data is April 6, 2010, the end date is June 30, 2010. We have chosen this period of time, because since April 6, 2010 the Avaya system provides half-hourly data instead of hourly data. So, for each half-hour in a day the number of phone arrivals is counted. Furthermore, this period of time is quite stable. There are no rigorous changes related to the Service Desk RFLP. Due to privacy legislation, it is not allowed to get exact exact data of the arrivals per person.

Figure 6 shows the number of phone calls per day in our dataset. The dips in the graph are the weekends and other days off, like Ascension Day, etc. Due to a new release of RCM there occurs a high peak at the end of April.

0 50 100 150 200 250 300 April 12, 2010 April 19, 2010 April 26, 2010 May 3, 2010 May 10, 2010 May 17, 2010 May 24, 2010 May 31, 2010 June 7, 2010 June 14, 2010 June 21, 2010 June 28, 2010 Numb er of phon e cal ls Date

Figure 6: Number of phone calls per day (April 6, 2010 - June 30, 2010).

(24)

0,00% 5,00% 10,00% 15,00% 20,00% 25,00%

Monday Tuesday Wednesday Thursday Friday

A ver ag e p er cen tag e of phon e cal ls Weekdays

Figure 7: Average percentage of phone calls per day (April 6, 2010 - June 30, 2010). The absolute values of the average number of phone calls per day and its corresponding standard deviations are shown in Table 1.

Table 1: Average number of phone calls per working day

Monday Tuesday Wednesday Thursday Friday Average 163.82 179.29 158.07 172.70 121.44 Standard deviation 24.34 21.28 27.06 17.75 26.16

(25)

0 5 10 15 20 25 30 A ver ag e n um ber of phon e cal ls Time Monday Tuesday Wednesday Thursday Friday Average

Figure 8: Average number of phone calls per hour (April 6, 2010 - June 30, 2010).

0,00% 2,00% 4,00% 6,00% 8,00% 10,00% 12,00% 14,00% 16,00% A ver ag e % of phon e cal ls Time Monday Tuesday Wednesday Thursday Friday Average

(26)

0 1 2 3 4 5 6 7 8 8: 00 :0 0 8: 30 :0 0 9: 00 :0 0 9: 30 :0 0 10 :0 0: 0 0 10 :3 0: 0 0 11 :0 0: 0 0 11 :3 0: 0 0 12 :0 0: 0 0 12 :3 0: 0 0 13 :0 0: 0 0 13 :3 0: 0 0 14 :0 0: 0 0 14 :3 0: 0 0 15 :0 0: 0 0 15 :3 0: 0 0 16 :0 0: 0 0 16 :3 0: 0 0 17 :0 0: 0 0 A ve rag e n u mb e r of p h on e c alls Time Avg. Variance Average

Figure 10: Average number of phone calls per quarter of an hour on average during a week (April 6, 2010 - June 30, 2010).

In sum, Figures 6, 7, 8, and 9 show patterns per day of the month, per working day, and per hour of the day.

4.2 The service time of phone calls

Another important factor that determines the workload originated by phone calls is the service time of a phone call. Handling requests originated by phone calls consist of (actively) handling a phone call (ACDTime) and doing after call work (ACWTime). After call work is work that is required immediately following a call. ACDTime and ACWTime together is the service time of an incoming phone call. Both the average ACDTime and average ACWTime per 15 minutes are stored in the Avaya system. During the service time there are three possibilities for the corresponding request of the phone call namely:

the support request is directly solved;

the support request is not directly solved, the corresponding outstanding service request should be solved later;

the request is prepared in CARE and forwarded to the responsible department.

(27)

0 2 4 6 8 10 12 Ap ri l 12 , 20 10 Ap ri l 19 , 20 10 Ap ri l 26 , 20 10 Ma y 3, 20 10 Ma y 10 , 201 0 Ma y 17 , 201 0 Ma y 24 , 201 0 Ma y 31 , 201 0 June 7, 2010 June 14 , 20 10 June 21 , 20 10 June 28 , 20 10 Ser vice time (minu tes) Date

Avg. Service Time

Figure 11: Average service time per day (April 6, 2010 - June 30, 2010).

Figure 12 shows the average service time during the day, consisting of the average ACDTime and the average ACWTime. The daily average service time equals 8.7 minutes. In general the average service is quite constant during the day. Only at the tails of the daily opening hours there occurs some variation. In the morning, the average service time is below the daily average mainly due to a low average ACDTime at that moment. A possible reason might be that agents call the Service Desk RFLP when they are ill or too late. At the end of the day, the average service time is above the daily average, due to a high average ACDTime at that moment. This can be explained by the fact that both agents and clients are less effective at the end of the day. Furthermore, note that we have less observations at the tails of the day.

0 2 4 6 8 10 12 8: 00 :0 0 8: 30 :0 0 9: 00 :0 0 9: 30 :0 0 10 :0 0: 0 0 10 :3 0: 0 0 11 :0 0: 0 0 11 :3 0: 0 0 12 :0 0: 0 0 12: 30: 0 0 13 :0 0: 0 0 13 :3 0: 0 0 14 :0 0: 0 0 14 :3 0: 0 0 15 :0 0: 0 0 15 :3 0: 0 0 16 :0 0: 0 0 16 :3 0: 0 0 17 :0 0: 0 0 Ser vice Time (minu tes) Time Avg. ACDTime Avg. ACWTime Avg. Service Time

Figure 12: Average service time during the day (April 6, 2010 - June 30, 2010).

(28)

4.3 Call Centers and Queueing models

Since, we have separated the three workflows - phone requests, e-mail requests, and outstanding service requests - that determine the workload and thus the manpower of the Service Desk RFLP, we can model the ‘phone workflow’ as an ordinary call center. Later on in this research we will return to this statement. For now it is useful to model the phone workflow completely separate from the rest.

Figure 13: Operational scheme of a call center (adapted from Gans et al. (2003)).

In Figure 13 an operational scheme of a call center is shown. In the figure, the relation between queueing theory and call centers is shown. In a queueing model of a call center, the arrivals are callers and servers are agents. If all agents are busy serving clients, new callers (clients) enter the queue. Since callers in the queue do not observe each other, the queue is called an invisible queue. The callers are not aware of how long the queue is. Sometimes the callers are informed about the queue, this may be in the form of an announcement to the callers indicating the expected waiting time. The Service Desk RFLP does not inform its callers about expected waiting times.

Based on queueing theory a call center can be analyzed mathematically. Among others, queueing models can be classified by various input parameters. Kendall (1953) provides a shorthand notation to characterize the various queueing models, the so-called Kendall’s notation. Each queueing model can be described by A/B/C/K/N/D. The explanation of each capital letter is given below:

A, the arrival process;

B, the service time distribution; C, the number of servers;

K, the number of places in the system; N, the population;

D, the queueing discipline.

(29)

agents. All other capital letters of Kendall’s notation are omitted, which is quite common in practice. If this shorthand notation is used, the following assumptions are made: K = ∞, N = ∞ and D = F IF O. This means that there are infinite places in the system, the size of the calling population is infinite, and the queueing discipline is First In, First Out. I.e., F IF O means, the caller who waits longest in queue will be served first. Other queueing disciplines are: Last in, First Out (LIFO), Service In Random Order (SIRO), Priority service, etc. Furthermore, multi-server queueing models assume one service time distribution. I.e., according to this modeling assumption all agents have the same service time distribution and are from a mathematical point of view identical. Often, the distribution parameters are chosen in such a way that they describe the average agent behavior.

4.3.1 Justifying the use of the Erlang-C model

In this research, we have decided to use the Erlang-C model to determine the number of phone agents such that the service levels are still achieved. So, we have made some assumptions which we will substantiate in this section. First of all, arrivals are assumed to behave like a Poisson process. A Poisson process is a stochastic process, a definition of stochastic process is stated below, see e.g. Dembo and Ross (2008):

Definition A stochastic process {N (t)} is a collection {N (t), t ∈ I} of random variables where the index t belongs to the index set I. Typically, I is an interval in R (in which case we say that {N (t)} is a continuous time stochastic process), or a subset of {1, 2, . . . , n, . . .} (in which case we say that {N (t)} is a discrete time stochastic process).

Poisson processes count the number of events that happen between time 0 and time t. In this case, an event is a client that calls the Service Desk RFLP. So, Poisson processes are also counting processes. The definition of a counting process is given below, see e.g. Van Mieghem (2006): Definition A counting process {N (t), t ∈ R+_{} is the number of events up to the time t. Counting} processes have the following properties:

1. N (t) ≥ 0;

2. N (t) is integer-valued;

3. N (s) ≤ N (t) for any s < t, i.e. N (t) is non-decreasing in t;

4. For s < t, N (t) − N (s) is the number of events that have occurred in the interval (s, t].

According to the definitions of both a stochastic process and a counting process, a Poisson process is a continuous time stochastic counting process where I = R+_{. Furthermore, a Poisson process} {N (t), t ∈ R+_{} must satisfy some additional properties, the definition is given below, see e.g.} Van Mieghem (2006):

Definition A Poisson process with a strictly positive parameter or rate λ is an integer-valued, continuous time stochastic counting process {N (t), t ∈ R+_{} satisfying:}

1. N(0) = 0;

2. The process has independent increments;

3. For t ≥ 0, s > 0 and non-negative integers k, the increments have the Poisson distribution, P [N (t + s) − N (s) = k] = (λt)

(30)

Where N (t) denotes the number of events that occur in the interval (0, t] and N (t + s) − N (s) denotes the number of events in the interval (s, s + t]. The mean and variance of a Poisson process are given by,

E(N (t)) = λt; V ar(N (t)) = λt.

Where λ is the expected number of events per time unit t.

For k ≥ 1, let Tk be the arrival time of the kthevent, in mathematical terms:

Tk= inft ∈ R+: N (t) = k .

Let Sk = Tk− Tk−1be the interarrival time between the (k − 1)thand the kth event. Clearly,

Tk= k X i=1

Si.

Now, we will show that the interarrival times, Si, i = 1, 2, . . ., are independent identically dis-tributed exponential random variables having mean _λ1. For S1 we know the following,

P (S1≤ t) = 1 − P (N (t) = 0)

= 1 − exp(−λt). (1)

Equation (1) equals the cumulative distribution function of an exponential distribution with pa-rameter λ. So, S1 follows the exponential distribution. Next, S2,

P (S2≤ t|S1= s) = 1 − P (S2> t|S1= s)

= 1 − P (N (T1+ t) − N (T1) = 0|S1= s) = 1 − P (N (T1+ t) − N (T1) = 0)

= 1 − exp(−λt). (2)

(31)

interval (0, t]. In mathematical terms for all 0 < x < t, P (T1≤ x) = P (N (x) = 1|N (t) = 1) = P (N (x) = 1T N (t) = 1) P (N (t) = 1) = P (N (x) = 1T N (t) − N (x) = 0) P (N (t) = 1) = P (N (x) = 1)P (N (t) − N (x) = 0) P (N (t) = 1) = λx exp(−λx) exp(−λ(t − x)) λt exp(−λt) = x t. (3)

Where Equation (3) equals the cumulative distribution function of a uniform distribution on the interval [0, t].

According to Figures 8 and 9 we obtain that the arrival rate fluctuates strongly per day and during the day. However, the Erlang-C model assumes a constant arrival rate for the arrival process. Therefore, we assume a piecewise constant arrival rate during short time intervals. Per time interval we will determine the required number of agents. The next question is, what is an appropriate time interval to analyze? The smaller the time interval, the more homogeneous the arrival rate is. However, in real life it is not possible to change the number of phone agents every 5 minutes. Therefore, we choose a half-hour as a suitable time interval length, this is in line with e.g. Gans et al. (2003) and Aldor-Noiman, Feigin, and Mandelbaum (2009). To determine the manpower regarding the phone workload, we set the arrival rate λ of the Poisson process equal to arrival rate from our dataset (April 6, 2010 - June 30, 2010) per half-hour and per working day. Hence, we model the arrival process as a homogeneous Poisson process half-hourly. Furthermore, we implicitly assume that the arrival rates in the future can be estimated by the arrival rates from the past per half-hour and per working day. Of course, we have to keep in mind that major changes in the future with respect to the Service Desk RFLP will have an influence on the arrival rates. For example, a new release of RCM definitely has impact on the number of phone calls in the subsequent weeks.

To conclude, we assume a homogeneous Poisson process half-hourly. So, determining the phone manpower takes place from the bottom up. First, the required number of agents is determined half-hourly during the day. Subsequently, the number of agents per day and per week can be calculated. Further argumentation, why an Poisson process is used to model the phone arrivals is provided in Section 4.3.2.

Next, the M/M/c model assumes that the service times are independently exponentially distributed with a parameter µ. To determine the manpower we have to make an assumption about the average service time 1_µ in the future, because logically the average service time in the future is not known. Based on Figure 11, the average service time 1

µ is set equal to the overall average service time in the dataset. This seems to be a reasonable assumption, because in Figure 11 we do not observe a clear upward or downward sloping trend of the average service time during this time period. Furthermore, inspecting the figure does not give cause for possible non-linear relationships between time and the average service time. We have applied ordinary least squares to the data, where the time is the only independent variable xi, i = 1, . . . , n and the average service time is the dependent variable yi, i = 1, . . . , n. Note that, the start date of our time period (April 6, 2010) is set equal to 1. In this way, the dates are numbered from 1 to n consecutively, n equals the end date of our time period (June 30, 2010). Let,

(32)

For any individual observation i, the relation is given by,

yi= β0+ xiβ1+ i, i = 1, . . . , n.

Where β0 denotes the intercept and i an error term, such that i = yi− β0− xiβ1. In order to estimate the unknown vector β that gives the relation between X and y, the ordinary least squares method minimizes the sum of the squared residuals. In our case, ˆβ, the estimate of β becomes,

ˆ β = _ˆ β0 ˆ β1 = (X0X)−1X0y = 8.79 −0.0075 .

The corresponding coefficient of variation R2 _{equals 0.0075. Since R}2_{≈ 0, we can conclude there} is no indication for a linear relationship. In this case of straight line regression, our regression equation is a constant line. This is plausible, because ˆβ0 is approximately equal to the overall average service of the data set and ˆβ1 ≈ 0. To conclude, the average service time of phone calls is approximately constant over time. Therefore, it is a reasonable assumption to use the overall average service time for determining the manpower in the near future.

Besides that, we have to test if the service times are exponentially distributed. Unfortunately, there is no exact data available of the service time per call. Only average service times are available per 15 minutes. So, it is difficult to verify if the service time distribution behaves exponential. Nevertheless, in Section 4.3.3 some hypothesis testing is done, where our assumption of exponential service times will be strengthened. This is in line with some studies that have compared empirical service time data of call centers to exponential distributions, see e.g. Kort (1983) and Harris, Hoffman, and Saunders (1987). It turns out that the exponential distribution gives a quite good fit for those data. A mathematical argument for using the exponential distribution to model the service times is its analytical tractability. A M/G/c queue, where the G stands for a General distribution, is analytically intractable. Approximation methods are required to solve a M/G/c queue.

(33)

telephone service factor, if the number of agents and the arrival rates are kept constant. However, a high abandonment percentage is a bad indication for a call center.

Another option to incorporate abandonment, is to introduce a patience time. Patience time is defined as the maximum time that a caller wants to wait, otherwise he or she will abandon. The patience time is assumed to be exponentially distributed. Each arriving caller encounters a waiting time, which is the time that the caller has to wait if his or her patience is infinite. If a caller’s waiting time exceeds his or her patience time, the caller will abandon. This model is called the Erlang-A model (‘A’ stands for Abandonment) and is denoted by M/M/c + M , the last M stands for exponentially distributed patience times.

The decision for the determination of the number of required phone agents of the Service Desk RFLP is based on the total number of arrivals during a time interval, answered calls and abandoned calls. In this thesis, we assume that a call never abandons, however in real life it is not possible to prevent abandonment completely. At this moment, a very small fraction of the arrivals at the Service Desk RFLP abandons, less than 3%. So, the calculations are based on the total number of arrivals during a time interval assuming that each arrival has to be served, while in reality a small fraction of the arrivals will abandon. To conclude, in this research the Erlang-C model is used to model the phone arrivals. The main reasons are a low incidence of blocking due to a surplus of trunk lines and a low percentage of abandonment.

4.3.2 Justifying the use of the Poisson distribution to model the number of call arrivals

At this moment, the portal RFLP has around 2,300 contracts and 16,000 users. All these users are supported by the Service Desk RFLP to answer technical and functional requests. Hence, there exist many potential clients that can call the Service Desk RFLP. However, the probability that an arbitrary client calls during a certain time interval, for instance a day or a half-hour, is very small. Furthermore, we assume that callers decide whether or not to call independently from each other.

Therefore, we are able to model each client as a Bernoulli random variable, where the probability that an arbitrary client calls the Service Desk RFLP during a certain time interval equals p ∈ [0, 1]. If the client population has size n ∈ N, we have X1, . . . , Xn random variables, all Bernoulli distributed with the same probability of calling p. Hence, we have made the assumption that all clients are statistically identical. However, in reality this is not true. Some clients extensively use RCM and its underlying modules and have a lot of bank accounts with very complex user authorization structures, while other clients use RCM only little. So, p is the probability that an arbitrary client calls during an arbitrary time interval. Furthermore, we assume that callers call independently from each other, so the random variables X1, . . . , Xn are independent. During a time interval, either the client does not call or calls once, so we do not incorporate the possibility that a certain client calls twice or more times. Using half-hourly time intervals this is a quite reasonable assumption.

Note, according to Section 4.1 the probability p changes over time, though in this section we will work with a fixed p. The sum of n i.i.d. Bernoulli random variables follow a Binomial distribution with parameters n and p and have the following probability mass function:

f (k; n, p) = P ( n X i=1 Xi= k) = n k pk(1 − p)n−k, (4)

(34)

approximated by a Poisson distribution with parameter λ = np = E(Pn i=1Xi). lim n=λ p→∞ P ( n X i=1 Xi= k) = lim n=λ p→∞ n k pk(1 − p)n−k = lim n→∞ n! (n − k)!k! λ n k 1 − λ n n−k = lim n→∞ _n! nk_{(n − k)!} λk k! 1 −λ n n 1 −λ n −k Recall: limn→∞ 1 − λ_n n = exp(−λ), = lim n→∞ _n! nk_{(n − k)!} λk k! exp(−λ) = lim n→∞ n · (n − 1) . . . (n − (k − 1)) nk λk k! exp(−λ) = lim n→∞ 1 · 1 − 1 n . . . 1 − (k − 1) n λk k! exp(−λ) = λ k k! exp(−λ). (5) Equation (5) equals the probability mass function of a Poisson distribution with parameter λ. Hence, if n is sufficiently large and p is sufficiently small the Poisson distribution can be used to approximate the Binomial distribution. This is also called as the law of rare events, since each of the n individual Bernoulli events rarely occurs.

To conclude, the arrival process of phone calls is modeled as a homogeneous Poisson process per time interval. The rate λ equals the average number of arrivals per unit of time. According to the Poisson distribution, the variance of the number arrivals also equals λ. This is in line with Figure 10.

4.3.3 Justifying the use of the exponential distribution to model the service times In this section some tests are performed to test whether the service times behave exponential. As stated before there is no exact data available of the service time per call. Only the average service times per 15 minutes are known. This makes it hard to test whether the service times are exponentially distributed. Nevertheless there are some possibilities to investigate if the service times behave exponentially. For instance, in the time intervals where only one client has called, the average service time equals the actual service time of that client. In our dataset, we have 224 time intervals that contain one observation (caller). So for these 224 callers we are able to test if the service times behave exponentially. We have to keep in mind that intervals that contain only one observation are often early in the morning or late in the afternoon.

(35)

distribution is derived given the dataset X1, X2, . . . , Xk. For the exponential distribution ˆλmle = 1

1 k

Pk

i=1Xi. So ˆλmle is used as parameter of the fitted exponential distribution.

Now, we will test statistically if the exponential distribution with parameter ˆλmle fits the dataset X1, X2, . . . , Xn. The cumulative distribution function of the fitted distribution is denoted by: Ff it(x) : R → [0, 1]. The Kolmogorov-Smirnov goodness-of-fit test is applied to test the following null hypothesis:

H0: The observations in the dataset X1, X2, . . . , Xk are i.i.d. random variables follow-ing the exponential distribution with parameter ˆλmle.

I.e., we test whether the fitted distribution is actually the true distribution of the dataset. The alternative hypothesis is that the fitted distribution is not the true distribution of the dataset. According to Law (2007), the Kolmogorov-Smirnov goodness-of-fit test compares the empirical dis-tribution function of the dataset with a disdis-tribution function of the hypothesized disdis-tribution. The empirical distribution function Femp,k(x) : R → [0, 1] for the k i.i.d. observations X1, X2, . . . , Xk is defined as, Femp,k(x) = 1 k k X i=1 1Xi≤x.

Where 1Xi≤x is an indicator function,

1Xi≤x=

1, if Xi≤ x, 0, otherwise.

The empirical cumulative distribution function and the fitted cumulative distribution function of the service times for the 224 time intervals that contain only one caller are plotted in Figure 14. The dotted line is the empirical cumulative distribution function and the red line the fitted cumulative distribution function. According to the figure, the exponential distribution with parameter ˆλmle fits the data quite well. However, based on the Kolmogorov-Smirnov goodness-of-fit test we will make our judgment.

Figure 14: Empirical cdf and exponential cdf with parameter ˆλmle.

(36)

function. The Kolmogorov-Smirnov test statistic provides a p-value. If the p-value exceeds the significance level α, the null hypothesis is not rejected. In this research, we use a significance level of 5% (α = 0.05). We have performed the Kolmogorov-Smirnov goodness-of-fit test for our dataset of 224 observations where the hypothesized distribution is exponential with parameter ˆλmle, the p-value equals 0.84. Since 0.84 > 0.05, the null-hypothesis is not rejected at a significance level of 5%, which is in line with our conclusions based on Figure 14.

In time intervals where more than one client has called, the average service time does not equal the actual service times anymore. Nevertheless, it is possible to perform a test, such that if we do not reject the H0 of that test we have a strong indication that the individual service times are exponentially distributed. For all time intervals where n callers have arrived, we test whether the average service time per time interval multiplied by n is Erlang-n distributed with scale parameter θ. If this is the case, we have a strong indication that the individual service times are exponential distributed with the same scale parameter θ. The other way around, if n clients have called in a certain time interval, the average service time is composed of the service times of the n clients. If the n service times are i.i.d. exponentially distributed per time interval, the average service time multiplied by n is Erlang-n distributed. We will show this statement using moment generating functions. Let Y1, . . . , Yn i.i.d. exponential distributed random variables with parameter θ. Then,

n X i=1 Yi∼ Erlang(n, θ). By definition: MYi(t) = E(exp(tYi)) = 1 1−t θ

, i = 1, . . . , n is the moment generating function of the exponential distribution. n Y i=1 MYi(t) = n Y i=1 1 1 − _θt = 1 1 − _θtn (6)

Equation (6) equals the moment generating function of a Erlang-n distribution with parameter θ. In Appendix A.2, the MLE for the Erlang-n distribution is derived given the dataset Y1, Y2, . . . , Yk. For the Erlang-n distribution ˆθn,mle = 1 n

k

Pk

i=1Yi

. So, ˆθn,mle is used as parameter of the fitted Erlang-n distribution. We have again performed the Kolmogorov-Smirnov goodness-of-fit test for a number of datasets. Let Zithe dataset of average service times per time period where the number of calls in that time period equals i, i = 2, . . . 6. The number of calls per 15 minutes can exceed 6, however these datasets contain too few observations. We have the following null hypothesis:

H0: The observations in the dataset Zi multiplied by i are i.i.d. random variables following the Erlang-i distribution with parameter ˆθi,mle.

If the null hypothesis is not rejected, we have a strong indication that the individual service times are exponentially distributed with parameter ˆθi,mle. The calculated Kolmogorov-Smirnov p-values are shown in Table 2 for i = 2, . . . , 6.

Table 2: Kolmogorov-Smirnov test of the Erlang-i distribution i: # calls per time interval p-value

2 0.49

3 0.50

4 0.97

5 0.08

(37)

Table 2 shows that the null hypothesis is not rejected for i = 2, . . . 6 at a significance level of 5%. So, we have a strong indication that the individual service times behave exponentially. In Appendix B, figures are shown where both the empirical cumulative distribution function and the fitted cumulative distribution function are plotted. besides that, the Q-Q plots of the various datasets and the fitted (theoretical) distributions for modeling the service times are plotted in Appendix B.

Based on the statistical tests we have performed in this section, we conclude that the exponential distribution can be used to model the service times of callers. Since in Section 4.3.1 the averaged service time is assumed to be constant over time, according to the MLE technique the parameter of the exponential distribution equals the reciprocal of the overall average service time.

4.4 Derivation of the Erlang delay formula

In this section, we will analyze the Erlang-C model and derive the Erlang delay formula, which is the probability that a caller has to wait. From the Erlang delay formula we are able to derive closed form expressions for the average speed of answer (ASA) and the service level (TSF). For our calculations, the interarrival times have mean 1

λ and the service times have mean 1

µ, where λ ∈ R++

and µ ∈ R++ _{are the arrival rate and service rate per unit of time respectively. For} example, if we have an average service time of 5 minutes and approximately 6 arrivals between 10:00am and 10:30am, then the service rate is 1₅ and the arrival rate per minute is ₃₀6 = 1₅, i.e. per minute on average 1₅ = µ callers are served and 1₅ = λ callers have arrived. Per half-hour on average, 30 × µ = 6 callers are served and 30 × λ = 6 callers will arrive. Furthermore, we assume that _cµλ _{< 1, where c ∈ Z}+ is the number of agents that is required. This is a very logical assumption, because if there are on average more arrivals than departures per time unit, then the number of waiting calls increases to infinity.

Since both the service times and the interarrival times are exponential distributed, the memoryless property holds, see Section 4.3.1. I.e., when the memoryless property holds, information about the history of previous callers does not yield a better prediction of the future. Therefore, the state of the system is only described by the number of callers in the system. Let pi∈ [0, 1] be the limiting probability that there are i callers in the system. Roughly speaking, the limiting probability pi is the probability that there are i callers in the system if the system is analyzed for a long period of time. Algebraically,

pi= lim

t→∞P (X(t) = i).

Where X(t) means the number of clients in the system at time t, or equivalently the state of the system at time t. The limiting probabilities exist in the Erlang-C model provided that _cµλ < 1 holds. In this section, we will focus on the limiting probabilities of the system which is reasonable according to Gans et al. (2003).

Figure 15: Balance equations M/M/c model.

A model for determining the daily manpower of a Contact Center

A model for determining the daily

manpower of a Contact Center

Application of the model to the Service Desk of the Rabo Financial

Logistics Portal

Pieter van der Mijle

A model for determining the daily

manpower of a Contact Center

Applying the model to the Service Desk of the Rabo Financial

Logistics Portal

Pieter van der Mijle

Preface

Contents

1

Introduction

2

Problem description

2.1

Context of the Research

RFLP

RDA

RCM

RTA

DA

OMO

2.2

Objective and research question

2.3

Assumptions

2.4

Literature research

3

Current situation

3.1

Key Performance Indicators and Service Level Agreements

4

Determination manpower for phone workload

4.1

The arrival process of phone calls

4.2

The service time of phone calls

4.3

Call Centers and Queueing models

4.4

Derivation of the Erlang delay formula