|
|
|
|
|
Date : |
3 May 2007 |
Subject : |
Omni Channel |
Source : |
CRM Today (http://www.crm2day.com) |
Title : |
Call Center Design |
PurposeThis white paper describes the steps involved in assessing the staffing requirements of a call centre and the estimating the number of trunks (central office lines) required to serve a call centre for incoming calls.
Software tools required
In order to help you with your calculations, we have provided free online traffic calculators at this Web site which you can use now. A Windows version is available for immediate download at 80 US Dollars and offers increased speed, capacity and convenience.
Ansapoint is a call centre analyser which automates the design process discussed in this paper. It is available for immediate download for just 160 US Dollars.
Description of the design process
There are two distinct areas of design required in such an application. The questions which must be answered are:
1. How many call centre agents do I need?
2. How many trunks do I need?
As call holding times depend upon average queuing times (which depend upon the number of agents deployed), the two questions must be addressed in the order shown.
How many agents do I need?
Calculating the number of agents required is a continuous process which will require regular reassessment as the circumstances of a call center change. Assessments may be made for each working hour of a day, and should take such factors as marketing campaigns and daily call peaks into account.
We suggest performing a calculation for each working hour. In order to estimate the number of agents required in a particular hour, the following information relating to that hour is required as a minimum:
1. Number of calls received
2. Average duration of these calls
3. Average delay that you accept that incoming callers may experience.
Items 1 and 2 describe the incoming traffic levels and must be established from call statistics or from estimates based on your understand of your business. Item 3 is your performance criterion. Another performance criterion which can be used defines call handling in terms of the percentage of calls answered within a target queuing time (e.g. 85% of calls answered within 20 seconds of ringing). This can be more meaningful and is supported by our Windows 95 / NT product, Westbay Traffic Calculators, but is not yet supported by our online calculators.
Wrap up time (or wrap time) is the time an agent remains unavailable to answer a call after a call has been completed. It is usually the time taken to carry out administrative tasks relating to a call such as entering an order on a terminal. For the purposes of Erlang C, wrap up time should be included in average call duration.
Having established these three minimum parameters for an hour, an estimate of the number of agents required can be made using the Erlang C Traffic Model. You can use our online calculator to work through this example now.
· Calls received in the hour 350
· Average call duration 180 seconds (160 seconds duration + 20 seconds wrap up time).
· Average delay to all calls 25 seconds
Pressing the Calc button reveals that 21 agents will be required during the hour in question. Performing this calculation using our Windows product, Westbay Traffic Calculators is similar, but please refer to the user guide or help system for detailed instructions.
How many trunks do I need?
Whereas the number of agents required can (and should) be dynamic, changing from hour to hour, the number of lines required to connect a call center with a central office exchange is fixed (at least in traditional circuit switched technology) and must cater for the maximum anticipated traffic levels which will be encountered. Engineering the number of lines required is known as dimensioning a trunk group.
The Erlang B traffic model can be used to estimate the number of lines required. This traffic model requires the following inputs:
· Busy Hour Traffic
· Blocking
This figure represents the quantity of traffic expressed in a unit called Erlangs. For the purposes of these calculations, 1 Erlang can be considered equivalent to 1 hour of calls.
The busiest hour must always be used for busy hour traffic calculations. But, wrap up time is not included. In working out the number of lines required, the busy hour traffic must be based on the duration of the calls and the queuing times as these account for trunk occupancy; wrap up time does not occupy a trunk.
Assuming our earlier call centre example represents the busiest hour, the busy hour traffic is calculated as follows:
BHT = [ Average call duration (s) + Average delay (s) ] * Calls per hour / 3600
The resulting figure shows the total trunk occupancy in hours, including the average delay period during which calls are being queued in an ACD and occupying trunks.
So, the busy hour traffic figure would be:
BHT = [ 160 + 25 ] * 350 / 3600
BHT = 17.986 Erlangs
It is important to note that the busy hour traffic figure should represent the busiest traffic load a call centre will ever be offered. The trunk group being designed must be large enough to cater not just for today's peak, but for every peak. Therefore, extreme caution should be exercised when calculating BHT.
The blocking figure describes the calls which cannot be completed because insufficient lines have been provided. A figure of 0.01 means that 1% of calls would be blocked; this is a normal figure to use in traffic engineering. For some applications, 0.03 (3%) blocking is used.
Having established these two parameters, an estimate of the number of lines required can be made using the Erlang B Traffic Model. You can use our online calculator to work through this example now.
· BHT = 17.986 Erlangs
· Blocking = 0.01
Pressing the Calc button reveals that 28 lines will be required during the hour in question. Performing this calculation using our Windows 95 / NT product, Westbay Traffic Calculators is similar, but please refer to the user guide or help system for detailed instructions.
Reasons for caution
The Erlang B and C traffic models make certain assumptions about the nature of the call arrivals. Amongst them is the assumption that call arrivals are random (Poisson arrivals). Although this is quite reasonable in most applications, it can cause inaccurate results when there is a sudden peak of calls.
This type of peak can be produced by a radio or television advertisement being shown (which can often be the reason for a call centre's existence in the first place!) Where drastic call peaks are expected, over-engineering of trunks and call center agents should always be carried out - always be on the safe side!
The Erlang C traffic model does not take abandoned calls into account, but if your call center is engineered correctly, this should not be a factor. It may cause a problem when attempting to use Erlang C to analyse an existing call centre with poor performance.
Conclusion
This document has demonstrated how to use our online and Windows traffic calculators to design some aspects of call center operations. If you have any questions, please send us an email.
|
|
|
|