Sizing Call Center Resources
Central to designing an IP Contact Center (or any call center) is the proper sizing of its resources. This chapter discusses the tools and methodologies needed to determine the required number of call center agents (based on customer requirements such as call volume and service level desired), the number of IP IVR ports required for various call scenarios (such as call treatment, queuing, and self-service applications), and the number of voice gateway ports required to carry the traffic volume coming from the PSTN or other TDM source such as PBXs and TDM IVRs.
The methodologies and tools presented in this chapter are based on traffic engineering principles using the Erlang-B and Erlang-C models applied to the various resource in an IPCC deployment. Examples are provided for an IPCC deployment to illustrate how resources can be impacted under various call scenarios such as call treatment in the IP IVR and agent wrap-up time. These tools and methodologies are intended as building blocks for sizing call center resources and for any telephony applications in general.
Call Center Basic Traffic Terminology
It is important to be familiar with, and to be consistent in the use of, common call center terminology. Improper use of these terms in the tools used to size call center resources can lead to inaccurate sizing results.
The terms listed in this section are the most common terms used in the industry for sizing call center resources. For additional call center industry terminology, refer to the definitions at
(There are also other resources available on the internet for defining call center terms.)
In addition to the terms listed in this section, the section on the Cisco IPC Resource Calculator, defines the specific terms used for the input and output of the Cisco call center sizing tool, IPC Resource Calculator.
Also, for more details on various call center terms and concepts discussed in this document, refer to the IPCC product documentation available online at
Busy Hour or Busy Interval
A busy interval could be one hour or less, such as 30 minutes or 15 minutes, if sizing is desired for such smaller intervals. The busy interval occurs when the most traffic is offered during this period of the day. The busy hour or interval varies over days, weeks, and months. There are weekly busy hours and seasonal busy hours. There is one busiest hour in the year. Common practice is to design for the average busy hour (the average of the 10 busiest hours in one year). This average is not always applied, however, when staffing is required to accommodate a marketing campaign or a seasonal busy hour such as an annual holiday peak. In a call center, staffing for the maximum number of agent is determined using peak periods, but staffing requirements for the rest of the day are calculated separately for each period (usually every hour) for proper scheduling of agents to answer calls versus scheduling agents for offline activities such as training or coaching. For trunks or IVR ports (in most cases), it is not practical to add or remove trunks or ports daily, so these resources are sized for the peak periods. In some retail environments, additional trunks could be added during the peak season and disconnected afterwards.
Busy Hour/Interval Call Attempts (BHCA)
The BHCA is the total number of calls during the peak traffic hour (or interval) that are attempted or received in the call center. For the sake of simplicity, we will assume that all calls offered to the voice gateway are received and serviced by the call center resources (agents and IP IVR ports). Calls normally originate from the PSTN, although calls to a call center can also be generated internally, such as by a help-desk application.
Servers are resources that handle traffic loads or calls. There are many types of servers in a call center, such as PSTN trunks and gateway ports, agents, voicemail ports, and IVR ports.
Talk time is amount of time an agent spends talking to a caller, including the time an agent places a caller on hold and the time spent during consultative conferences.
Wrap-Up Time (After-Call Work Time)
After the call is terminated (caller finishes talking to an agent and hangs up), the wrap-up time is the time it takes an agent to "wrap up" the call by performing such tasks as updating a database, recording notes from the call, or any other activity performed until an agent becomes available to answer another call. The IPCC term for this concept is "after-call work time."
Average Handle Time (AHT)
AHT is the mean (or average) call duration during a specified time period. It is a commonly used term that refers to the sum of several types of "handle time," such as call treatment time, talk time, and queuing time. In its most common definition, AHT is the sum of agent talk time and agent wrap-up time.
Erlang is a measurement of traffic load during the busy hour. The Erlang is based on having 3600 seconds (60 minutes, or 1 hour) of calls on the same circuit, trunk, or port. (One circuit is busy for one hour regardless of the number of calls or how long the average call lasts.) If a contact center receives 30 calls in the busy hour and each call lasts for six minutes, this equates to 180 minutes of traffic in the busy hour, or 3 Erlangs (180 min/60 min). If the contact center receives 100 calls averaging 36 seconds each in the busy hour, then total traffic received is 3600 seconds, or 1 Erlang (3600 sec/3600 sec).
Use the following formula to calculate the Erlang value:
Traffic in Erlangs = (Number of calls in the busy hour * AHT in sec) / 3600 sec
The term is named after the Danish telephone engineer A. K. Erlang, the originator of queuing theory used in traffic engineering.
Busy Hour Traffic (BHT) in Erlangs
BHT is the traffic load during the busy hour and is represented as the product of the BHCA and the AHT normalized to one hour:
BHT = (BHCA * AHT seconds) / 3600, or
BHT = (BHCA * AHT minutes) / 60
For example, if the call center receives 600 calls in the busy hour, averaging 2 minutes each, then the busy hour traffic load is (600 * 2/60) = 20 Erlangs.
BHT is typically used in Erlang-B models to calculate resources such as PSTN trunks or self-service IVR ports. Some calculators perform this calculation transparently using the BHCA and AHT for ease of use and convenience.
Grade of Service (Percent Blockage)
This measurement is the probability that a resource or server is busy during the busy hour. All resources might be occupied when a user places a call. In that case, the call is lost or blocked. This blockage typically applies to resources such as voice gateway ports, IVR ports, PBX lines, and trunks. In the case of a voice gateway, grade of service is the percentage of calls that are blocked or that receive busy tone (no trunks available) out of the total BHCA. For example, a grade of service of 0.01 means that 1% of calls in the busy hour would be blocked. A 1% blockage is a typical value to use for PSTN trunks, but different applications might require different grades of service.
A blocked call is a call that is not serviced immediately. Callers are considered blocked if they are rerouted to another route or trunk group, delayed and put in a queue, or if they hear a tone (such as a busy tone) or announcement. The nature of the blocked call will determine the model used for sizing the particular resources.
This term is a standard in the contact center industry, and it refers to the percentage of the offered call volume (received from the voice gateway and other sources) that will be answered within x seconds, where x is a variable. A typical value for a sales call center is 90% of all calls answered in less than 10 seconds (some calls will be delayed in a queue). A support-oriented call center might have a different service level goal, such as 80% of all calls answered within 30 seconds in the busy hour. Your contact center's service level goal drives the number of agents needed, the percentage of calls that will be queued, the average time calls will spend in queue, and the number of PSTN trunks and IP IVR ports needed. For an additional definition of service level within IPCC products, refer to the IPCC glossary available online at
When all agents are busy with other callers or are unavailable (after call wrap-up mode), subsequent callers must be placed in a queue until an agent becomes available. The percentage of calls queued and the average time spent in the queue are determined by the service level desired and by agent staffing. Cisco's IPCC solution uses an IP IVR to place callers in queue and play announcements. An IVR can also be used to handle all calls initially (call treatment, prompt and collect - such as DTMF input or account numbers - or any other information gathering) and for self-service applications where the caller is serviced without needing to talk to an agent (such as obtaining a bank account balance, airline arrival/departure times, and so forth). Each of these scenarios requires a different number of IP IVR ports to handle the different applications because each will have a different average handle time and possibly a different call load. The number of trunks or gateway ports needed for each of these applications will also differ accordingly. (See the section on Sizing Call Center Agents, IVR Ports, and Trunks, for examples on how to calculate the number of trunks and gateway ports needed.)
Call Center Resources and the Call Timeline
The focus of this chapter is on sizing the following main resources in a call center:
•Gateway ports (PSTN trunks)
•IP IVR ports.
It is helpful first to understand the anatomy of an inbound call center call as it relates to the various resources used and the holding time for each resource. Figure 4-1 shows the main resources used and the occupancy (hold/handle time) for each of these resources.
Figure 4-1 Inbound Call Timeline
Ring delay time (network ring) should be included if calls are not answered immediately. This delay could be a few seconds on average, and it should be added to the trunk average handle time.
Erlang Calculators as Design Tools
Many traffic models are available for sizing telephony systems and resources. Choosing the right model depends on three main factors:
•Traffic source characteristics (finite or infinite)
•How lost calls are handled (cleared, held, delayed)
•Call arrival patterns (random, smooth, peaked).
For purposes of this document, there are mainly two traffic models that are commonly used in sizing call center resources, Erlang-B and Erlang-C. There are many other resources on the internet that give detailed explanations of the various models (search using "traffic engineering").
Erlang calculators are designed to help answer the following questions:
•How many PSTN trunks do I need?
•How many agents do I need?
•How many IVR ports do I need?
Before you can answer these basic questions, you must have the following minimum set of information that is used as input to these calculators:
•The busy hour call attempts (BHCA)
•Average handle time (AHT) for each of the resources
•Service level (percentage of calls that are answered within x seconds)
•Grade of service, or percent blockage, desired for PSTN trunks and IP IVR ports
The remaining sections of this chapter help explain the differences between the Erlang-B and Erlang-C traffic models in simple terms, and they list which model to use for sizing the specific call center resource (agents, gateway ports, and IP IVR ports). There are various web sites that provide call center sizing tools free of charge (some offer feature-rich versions for purchase), but they all use the two basic traffic models, Erlang-B and Erlang-C. Cisco does not endorse any particular vendor product; it is up to the customer to choose which tool suits their needs. The input required for any of the tools, and the methodology used, are the same regardless of the tool itself.
Cisco has chosen to develop its own telephony sizing tool, called Cisco IPC Resource Calculator. The first version discussed here is designed to size call center resources. Basic examples are included later in this chapter to show how to use the Cisco IPC Resource Calculator. Additional examples are also included to show how to use the tool when some, but not all, of the input fields are known or available.
Before discussing the Cisco IPC Resource Calculator, the next two sections present a brief description of the generic Erlang models and the input/output of such tools (available on the internet) to help the reader who does not have access to the Cisco IPC Resource Calculator or who chooses to use other non-Cisco Erlang tools.
The Erlang-C model is used to size agents in call centers that queue calls before presenting them to agents. This model assumes:
•Call arrival is random.
•If all agents are busy, new calls will be queued and not blocked.
The input parameters required for this model are:
•The number of calls in the busy hour (BHCA) to be answered by agents
•The average talk time and wrap-up time
•The delay or service level desired, expressed as the percentage of calls answered within a specified number of seconds
The output of the Erlang-C model lists the number of agents required, the percentage of calls delayed or queued when no agents are available, and the average queue time for these calls.
The Erlang-B model is used to size PSTN trunks, gateway ports, or IP IVR ports. It assumes the following:
•Call arrival is random.
•If all trunks/ports are occupied, new calls are lost or blocked (receive busy tone) and not queued.
The input and output for the Erlang B model consists of the following three factors. You need to know any two of these factors, and the model will calculate the third.
•Busy Hour Traffic (BHT), or the number of hours of call traffic (in Erlangs) during the busiest hour of operation. BHT is the product of the number of calls in the busy hour (BHCA) and the average handle time (AHT).
•Grade of Service, or the percentage of calls that are blocked because not enough ports are available
•Ports (lines), or the number of IP IVR or gateway ports
Cisco IPC Resource Calculator
Figure 4-2 is a snapshot of the current Cisco IP Communications (IPC) Resource Calculator, followed by a definition of each of the input and output fields, how to use them, and how to interpret them.
Cisco is continually enhancing the IPC Resource Calculators, and the latest versions are available at
The Cisco IPC Resource Calculators are accessible to Cisco internal employees and Cisco partners. These tools are based on industry Erlang traffic models. Other Erlang traffic calculators available on the Web can also be used for sizing various contact center resources.
Figure 4-2 Cisco IPC Resource Calculator
IPC Resource Calculator Input Fields (What You Must Provide)
When using the Cisco IPC Resource Calculator, you must provide the following input data:
This field is a description to identify the project or customer name and the specific scenario for this calculation. It helps to distinguish the different scenarios run (exported and saved) for a project or a customer proposal.
Calls Per Interval (BHCA)
The number of calls attempted during the busiest interval, or busy hour call attempts (BHCA). You can choose the interval to be 60 minutes (busy hour), 30 minutes (half-hour interval), or 15 minutes. This choice of interval length allows the flexibility to calculate staffing requirements more accurately for the busiest periods within one hour, if desired. It can also be used to calculate staffing requirements for any interval of the day (non-busy hour staffing).
Service Level Goal (SLG)
The percentage of calls to be answered within a specified number of seconds (for example, 90% within 30 seconds).
Average Call Talk Time
The average number of seconds a caller will be on-line after an agent answers the call. This value includes time talking and time placed on hold by the agent, until the call is terminated. It does not include time spent in the IVR for call treatment or time in queue.
Average After-Call Work Time
The average agent wrap-up time in seconds after the caller hangs up. This entry assumes that agents are available to answer calls when they are not in wrap-up mode. If seated agents enter into another mode (other than the wrap-up mode) where they are unavailable to answer calls, then this additional time should be included (averaged for all calls) in the after-call work time.
Average Call Treatment Time (IVR)
The average time in seconds a call spends in the IVR before an attempt is made to send the call to an agent. This time includes greetings and announcements as well as time to collect and enter digits (known as prompt and collect, or IVR menuing) to route the call to an agent. It does not include queuing time if no agents are available. (This queuing time is calculated in the output section of the calculator.) The call treatment time should not include calls arriving at the IVR for self-service with no intention to route them to agents. Self-service IVR applications should be sized separately using an Erlang-B calculator.
Wait Before Abandon (Tolerance)
This field is the amount of time in seconds that a contact center manager expects callers to wait in queue (tolerance) for an agent to become available before they abandon the queue (hang up). This value has no effect on any of the output fields except the abandon rate (number of calls abandoned).
Blockage % (PSTN Trunks)
This field is also known as Grade of Service, or the percentage of calls that will receive busy tone (no trunks available on the gateway) during the busy hour or interval. For example, 1% blockage means that 99% of all calls attempted from the PSTN during the interval will have a trunk port available on the gateway to reach the IVR or an agent.
Check to Manually Enter Agents
The user may manually enter the number of agents, after checking this box. If the number of agents is too far from the recommended number, the calculator will show an error message. The error will appear any time the number of calls queued reaches 0% or 100%.
IPC Resource Calculator Output Fields (What You Want to Calculate)
The IPC Resource Calculator calculates the following output values based on your input data:
The number of seated agents (calculated using Erlang-C) required to staff the call center during the busy hour or busy interval.
Calls Completed (BHCC)
This field is the busy hour call completions (BHCC), or the number of expected calls completed during the busy hour. It is the number of calls attempted minus the number of calls blocked.
Calls Answered Within Target SLG
The percentage of calls that are answered within the set target time entered in the Service Level Goal (SLG) field. This value is the calculated percentage of calls answered immediately if agents are available. It includes a portion of calls queued if no agents are available within the SLG (for example, less than 30 seconds). It does not include all queued calls because some calls will be queued beyond the SLG target.
Calls Answered Beyond SLG
The percentage of calls answered beyond the set target time entered in the Service Level Goal (SLG) field. For example, if the SLG is 90% of calls answered within 30 seconds, the calls answered beyond SLG would be 10%. This value includes a portion of all calls queued, but only the portion queued beyond the SLG target (for example, more than 30 seconds).
The percentage of all calls queued in the IVR during the busy hour or interval. This value includes calls queued and then answered within the Service Level Goal as well as calls queued beyond the SLG. For example, if the SLG is 90% of calls answered within 30 seconds and queued calls are 25%, then there are 10% of calls queued beyond 30 seconds, and the remaining 15% of calls are queued and answered within 30 seconds (the SLG).
Calls Answered Immediately
The percentage of calls answered immediately by an agent after they receive treatment (if implemented) in the IVR. These calls do not have to wait in queue for an agent. As in the preceding example, if 25% of the calls are queued (including those beyond the target of 30 seconds), then 75% of the calls would be answered immediately.
Average Queue Time (AQT)
The average amount of time in seconds that calls will spend in queue waiting for an agent to become available during the interval. This value does not include any call treatment in the IVR prior to attempting to send the call to an agent.
Average Speed of Answer (ASA)
The average speed of answer for all calls during the interval, including queued calls and calls answered immediately.
Average Call Duration
The total time in seconds that a call remained in the system. This value is the sum of the average talk time, the average IVR delay (call treatment), and the average speed of answer.
The percentage of agent time engaged in handling call traffic versus idle time. After-call work time is not included in this calculation.
Calls Exceeding Abandon Tolerance
The percentage (and number) of calls that will abandon their attempt during the interval, based on expected Tolerance time specified in the input. If this output is zero, it means that all queued calls were answered by an agent in less than the specified abandon time (longest queued call time is less than the abandon time).
PSTN Trunk Utilization
This value is the occupancy rate of the PSTN trunks, calculated by dividing the offered load (Erlangs) by the number of trunks
Voice Trunks Required
The number of PSTN gateway trunks required during the busy interval, based on the number of calls answered by the voice gateway and the average hold time of a trunk during the busy interval. This value includes average time of call treatment in the IVR, queuing in the IVR (if no agents are available), and agent talk time. This calculated number assumes all trunks are grouped in one large group to handle the specified busy hour (or interval) calls. If several smaller trunk groups are used instead, then additional trunks would be required, therefore smaller groups are less efficient.
IVR Ports Required for Queuing
The number of IVR ports required to hold calls in queue while the caller waits for an agent to become available. This value is based on an Erlang-B calculation using the number of queued calls and the average queue time for those calls.
IVR Ports Required for Call Treatment
The number of IVR ports required for calls being treated in the IVR. This value is based on an Erlang-B calculation using the number of calls answered and the average call treatment time (average IVR delay).
Total IVR Ports Requirement
This value is the total number of IVR ports required if the system is configured with separate port groups for queuing and treatment. Pooling the ports for treatment and queuing results in fewer ports for the same amount of traffic than if the traffic is split between two separate IVR port pools or groups. However, Cisco recommends that you configure the number of ports required for queuing in a separate group, with the ability to overflow to other groups if available.
After entering data in all required input fields, click on the Submit button to compute the output values.
Click on the Export button to save the calculator input and output in a comma-separated values (CSV) format to a location of your choice on your hard drive. This CSV file could be imported into a Microsoft Excel spreadsheet and formatted for insertion into bid proposals or for presentation to clients or customers. Multiple scenarios could be saved by changing one or more of the input fields and combining all outputs in one Excel spreadsheet by adding appropriate titles to columns reflecting changes in the input. This format makes comparing results of multiple scenarios easy to analyze.
Sizing Call Center Agents, IVR Ports, and Trunks
The call center examples in this section illustrate how to use the IPC Resource Calculator in various scenarios, along with the impact on required resources. The first example is a basic call flow, where all incoming calls to the call center are presented to the voice gateway from the PSTN. Calls are routed directly to an agent, if available; otherwise, calls are queued until an agent becomes available.
Basic Call Center Example
This example forms the basis for all subsequent examples in this chapter. After a brief explanation of the output results highlighting the three resources (agents, IVT ports, and PSTN trunks) in this basic example, subsequent examples build upon it by adding different scenarios, such as call treatment and agent wrap-up time, to demonstrate how the various resources are impacted by different call scenarios.
This basic example uses the following input data:
•Total BHCA (60-minute interval) into the call center from the PSTN to the voice gateway = 2,000.
•Desired service level goal (SLG) of 90% of calls answered within 30 seconds.
•Average call talk time (agent talk time) = 150 seconds (2 minutes and 30 seconds).
•No after-call work time (agent wrap-up time = 0 seconds).
•No call treatment (prompt and collect) is implemented initially. All calls will be routed to available agents or will be queued until an agent becomes available.
•Wait time before abandoned (tolerance) = 150 seconds (2 minutes and 30 seconds).
•Desired grade of service (percent blockage) for the PSTN trunks on the voice gateway = 1%.
After entering the above data in the input fields, pressing the Submit button at the bottom of the calculator results in the output shown in Figure 4-3.
Figure 4-3 Basic Example
Notice that the output shows 1980 calls completed by the voice gateway, out of the total of 2000 calls attempted from the PSTN. This is because we have requested a provisioning of 1% blockage from our PSTN provider, which results in 20 calls (1%) being blocked and receiving busy tone out of the total 2000 calls.
The result of 90 seated agents is determined by using the Erlang-C function imbedded in the IPC Resource Calculator, and calls will be queued to this resource (agents).
Notice that, with 90 agents, the calculated service level is 93% of calls answered within 30 seconds, which exceeds the desired 90% requested in the input section. Had there been one less agent (89 instead of 90), then the 90% SLG would not have been met.
This result also means that 7% of the calls will be answered beyond the 30 second SLG. In addition, there will be 31.7% of calls queued; some will queue less than 30 seconds and others longer. The average queue time for queued calls is 20 seconds.
If 31.7% of the calls will queue, then 68.3% of the calls will be answered immediately without delay in a queue, as shown in the output in Figure 4-3.
IVR Ports Required for Queuing
In this basic example, the IP IVR is being used as a queue manager to queue calls when no agents are available. The calculator shows the percent and number of calls queued (31.7%, or 627 calls) and the average queue time (20 seconds).
These two outputs from the Erlang-C calculation are then used as inputs for the imbedded Erlang-B function in the calculator to compute the number of IVR ports required for queuing and the corresponding PSTN trunks required. The Erlang-B function is used here because a call would receive a busy signal (be lost) if no trunks or IVR ports were available to answer or service the call.
The following traffic load impacts the required number of IP IVR ports for queuing derived from the output of the calculator:
•The traffic load presented by the calls that queue (627 queued) with an average queue time of 20 seconds when no agents are available to answer the call immediately. This load shows that 10 IVR ports are required for queuing.
PSTN Trunks (Voice Gateway Ports)
The following traffic loads impact the required number of trunks:
•The load presented by the incoming traffic (1980 answered calls), with an average agent talk time for all calls of 150 seconds.
•The traffic load presented by the calls that queue (31.7% queued), with an average queue time of 20 seconds when no agent is available to answer the call immediately.
Total trunks required to carry this total traffic load above is 103 trunks.
This calculation does not include trunks that might be needed for call scenarios that require all calls to be treated first in the IVR before they are presented to available agents. That scenario is discussed in the next example.
Call Treatment Example
This example builds upon the basic example in the preceding section. Again, all incoming calls to the call center are presented to the voice gateway from the PSTN, then calls are immediately routed to the IP IVR for call treatment (such as an initial greeting or to gather account information) before they are presented to an agent, if available. If no agents are available, calls are queued until an agent becomes available.
The impact of presenting all calls to the IP IVR is that the PSTN trunks are held longer, for the period of the call treatment holding time. More IP IVR ports are also required to carry this extra load, in addition to the ports required for queued calls.
Call treatment (prompt and collect) does not impact the number of required agents because the traffic load presented to the agents (number of calls, talk time, and service level) has not changed.
Using a 15-second call treatment and keeping all other inputs the same, Figure 4-4 shows the number of PSTN trunks (112) and IP IVR ports (16) required in addition to the existing 10 ports for queuing.
Figure 4-4 Call Treatment in IVR
After-Call Work Time (Wrap-up Time) Example
Using the previous example, we now add the assumption that agents will spend an average of 45 seconds of work time (wrap-up time) after each call. We can then use the IPC Resource Calculator to determine the number of agents required to handle the same traffic load (see Figure 4-5).
After-call work time (wrap-up time) begins after the caller hangs up, so trunk and IP IVR resources are not impacted and should remain the same. Assuming the SLG and traffic load also remain the same, additional agents would be required only to service the call load and to compensate for the time agents are in the wrap-up mode.
Figure 4-5 After-Call Work Time
Note that trunks and IVT ports remained virtually the same, except that there is one additional trunk (113 instead of 112). This slight increase is not due to the wrap-up time, but rather is a side effect of the slight change in the SLG (92% instead of 93%) due to rounding calculations for the required 116 agents due to wrap-up time.
Call Center Sizing With Self-Service IVR Applications
Self-service applications route calls to an IVR (Cisco IP IVR or Cisco Internet Service Node (ISN)) and present them with a menu of choices to access information from various databases. The calls are serviced in the IVR and not answered by agents. At the end of the transaction, the caller hangs up and does not need to speak to an agent. Examples include accessing bank account balances and transactions, airline flight arrival and departure information, menu services such as driving directions, and so forth.
These self-service applications have a different call load and IVR average handle time than the call load presented to the agents. In this case, only PSTN trunks (voice gateway ports) and IVR ports are required, and no additional agents are required.
For such self-service applications, a standalone Erlang-B calculation is necessary to compute the additional PSTN trunks and IVR ports required, as shown in the following example. These trunks and IVR ports can then be added to the rest of the requirements needed in a call center for calls presented to agents, as described in previous examples and illustrated in the following example.
Call Center Example with IVR Self-Service Application
In this example, we assume that the call center receives 18,000 calls in the busy hour, and a portion of the calls (20%) are self-serviced in the IVR without ever being transferred to an agent. These calls last an average of about 60 seconds before they complete their transaction and hang up.
Another portion (20%) are identified as "high priority" callers (based on calling number, number dialed, or other automatic identifier) and are immediately routed to a specialized group of agents without any call treatment in the IVR but with a high service level goal of 95% of the calls to be answered within 10 seconds.
The remaining portion (60%) is normal calls that are presented with a menu in the IVR (call treatment, prompt and collect) before they are transferred to an agent, and they have an SLG of 90% answered within 30 seconds. The average call treatment is about 3 minutes and 9 seconds (171 seconds), and the average talk time is 5 minutes (300 seconds).
In summary, the three traffic loads (call types) coming into this call center consist of the following:
•IVR self-service calls:
18,000 * 20% = 3600 calls.
Average IVR call treatment = 60 seconds.
•High-priority calls (transferred to agents directly, no delay in IVR):
18,000 * 20% = 3600 calls.
Routed immediately to agents if available; no IVR call treatment.
Average talk time = 6 minutes (360 seconds).
SGL = 95% of the calls to be answered within 10 seconds.
18,000 * 60% = 10,800 calls.
Average time in IVR for call treatment = 171 seconds.
Average talk time = 5 minutes (300 seconds).
SGL = 90% of the calls to be answered within 30 seconds.
For high-priority and normal calls, a call might have to wait in queue in the IVR if no agents are available to answer the call immediately.
We can compute the required resources for each of the three types of calls as follows:
IVR Self-Service Calls
•18,000 * 20% = 3600 calls.
•Average IVR call treatment = 60 seconds.
For self-service applications only, where no agents are required or involved, we will use the Cisco IP IVR Stand-Alone Calculator (shown in Figure 4-6), which uses Erlang-B to compute the necessary trunks and IP IVR ports.
•Busy hour traffic (BHT) = (3600 calls * 60 sec/3600) = 60 Erlangs.
•Assume PSTN blockage = 1%.
Inserting these values into the first column, titled Self Service, in the calculator produces the following results, as illustrated in Figure 4-6:
•75 IVR ports for self-service
These PSTN trunks and IVR ports are in addition to any that might be needed for priority calls (20%) and normal calls (60%) that require PSTN trunks and IVR ports for queuing and call treatment before transferring to an agent. The remaining columns could be used if you had multiple trunk and IVR groups that were not pooled together (multiple self-service applications) or if the IVR employed had the capability to queue calls at the edge (remote branch with local PSTN incoming gateway), as is the case with Cisco ISN.
Figure 4-6 IVR Self-Service Calls
Note There are many Erlang-B calculators available for free on the Web. (Search on Erlang-B.)
High-Priority Calls (Transferred to Agents Directly, no IVR Call Treatment)
•18,000 * 20% = 3600 calls.
•Routed immediately to agents if available; no IVR call treatment.
•Average talk time = 6 minutes (360 seconds).
•SGL = 95% of the calls to be answered within 10 seconds.
Inserting these parameters into the IPC Resource Calculator produces the following results (as illustrated in Figure 4-7):
•384 agents are required.
•386 trunks are required.
•6 IVR ports are needed for queuing.
•No call treatment ports are required here.
Figure 4-7 High-Priority Calls
•18,000 * 60% = 10,800 calls.
•Average time in IVR for call treatment = 171 seconds.
•Average talk time = 5 minutes (300 seconds).
•SGL = 90% of the calls to be answered within 30 seconds.
Inserting these parameters into the IPC Resource Calculator produces the following results (as illustrated in Figure 4-8):
•907 agents are required.
•1469 trunks are required.
•44 IVR ports are needed for queuing.
•563 IVR ports are needed for call treatment.
Figure 4-8 Normal Calls
Now that we have sized all the resources required for the three types of calls in this call center example, we can add the results to determine the total required resources of each type (agents, PSTN trunks, and IVR ports):
•Agents for high-priority calls (calls answered by agents, no IVR) = 384
•Agents for normal calls (calls transferred to agents after IVR treatment) = 907
•Total agents = 384 + 907 = 1291
•IVR ports for self-service = 75
•IVR ports for queuing = 6 + 40 = 46
•IVR ports for call treatment = 540
•Total IVR ports = 75 + 46 + 540 = 661
•Total PSTN trunks = 75 + 386 + 1469 = 1930
If IP IVR is used, then you must enter the number of call treatment and queuing ports into the Configuration and Ordering Tool for proper sizing of server resources. You can access the Configuration and Ordering Tool at
If Cisco ISN is the IVR type used, refer to the section on Sizing ISN Components, for additional details on sizing ISN servers.
Sizing ISN Components
Internet Service Node (ISN) sizing involves the following components:
•ISN Server Sizing
•Sizing ISN Licenses
•Cisco IOS Gateway Sizing
•ICM Peripheral Gateway (PG) Sizing
•Prompt Media Server Sizing
ISN Server Sizing
According to the Cisco Internet Service Node Technical Reference (available at http://www.cisco.com), an ISN Combo Box (an ISN Application server and an ISN Voice Browser hosted on the same server) deployed in the common comprehensive ISN deployment model can support 300 effective calls. An effective call can be a call that is undergoing call treatment or queuing in the IVR on the Cisco IOS gateway (under VXML control of the ISN), or it can be a call that the ISN has transferred to an agent and that is still being monitored/controlled by the ISN. In the latter case, for example, if the ISN uses the IP Transfer method to route a call to an agent, then the ISN is still monitoring that call and it counts as an effective call. On the other hand, if an Outpulse or IN Transfer is used to route a call to an agent, then ISN no longer has any control over that call, so that call does not count as an effective call. In addition, calls that are transferred to agents directly without ISN (Voice Browser) control or involvement do not count as effective calls either, unless those calls are unable to find an agent and are subsequently treated by the ISN.
Note This section uses the same example as in the preceding Call Center Example with IVR Self-Service Application, but it reiterates the parameters of that example for clarity and simplicity.
ISN Server Sizing Example
Consider an example where a call center receives BHCAs of 18,000 calls. Assume a portion of the calls, 20%, are self-serviced in the IVR without ever being transferred to an agent. These calls last an average of about 60 seconds before they complete their transaction and hang up.
Also assume that another portion of the incoming calls, 20%, will be identified as high-priority callers (based on calling number, number dialed, or other automatic identifier) and will be routed immediately to a specialized group of agents with a high service level goal (SLG) of 95% of the callers to be answered within 10 seconds without any intended ISN involvement (no call treatment). Note, however, that a small percentage of these calls will not be able to reach an agent immediately and will have to be diverted for queuing by the ISN.
The remaining portion, 60%, is normal calls that will be presented with IVR treatment by the ISN before they are transferred to an agent with an SLG of 90% answered within 30 seconds. The average call treatment is 3 minutes and 9 seconds (171 seconds) and the average talk time is 5 minutes (300 seconds).
The traffic loads (call types) coming into this call center are as follows:
•IVR self-service calls:
18,000 * 20% = 3600 calls.
Average IVR call treatment = 60 seconds.
•High-priority calls (transferred to agents directly):
18,000 * 20% = 3600 calls.
Calls routed immediately to agents if available; no IVR call treatment.
Average talk time = 6 minutes (360 seconds).
SLG = 95% of the callers to be answered within 10 seconds.
If agent is not available, call must be queued by ISN.
18,000 * 60% = 10800 calls.
Average IVR time for call treatment = 171 seconds.
Average talk time = 5 minutes (300 seconds).
SLG = 90% of the callers to be answered within 30 seconds.
In the latter two call types, high-priority and normal calls, a call might have to wait in queue in the IVR (ISN) if no agents are available to answer the call.
After computing the required IVR ports and agents for each of these call types using the tools and methodology described in chapter on Sizing Call Center Resources, we obtain the following results:
•IVR self-service calls (using the Cisco IP IVR standalone Erlang-B calculator):
–75 ports for IVR (prompt and collect)
•High-priority calls transferred to agents directly, with no ISN involvement or call treatment (using the Cisco IPC Resource Calculator):
–384 agents are required
–386 trunks (no VXML required)
–7 ports for queuing if calls cannot reach an agent immediately
–No IVR ports are required
•Normal calls (using the Cisco IPC Resource Calculator):
–907 agents are required
–44 ports for queuing
–563 ports for IVR (prompt and collect)
Totaling the Results
Now that we have calculated all the resources required for the three types of calls, we can total the results to determine the number of effective calls needed to size the ISN properly. Remember that an effective call is a call undergoing IVR call treatment or queuing treatment by the ISN, or it is a call that the ISN has transferred to an agent but that the ISN still needs to monitor. In our example, the agents are all IPCC agents. Therefore, when the ISN routes calls to the agents, the ISN uses the IP Transfer routing method, which means that the ISN continues to monitor those calls.
For this example, the totals are:
•Ports required for IVR = (75 + 563) = 638
•Ports required for queuing = (7 + 44) = 51
•PSTN trunks (with VXML) = 75 + 1469 = 1544
•PSTN trunks (no VXML) = 386
•PSTN trunks (total) = 75 + 1469 + 386 = 1930
Thus, the combined IVR and queuing load on the ISN is 689 simultaneous calls, where the IVR queuing treatment is physically performed on Cisco IOS gateways (using the ISN Comprehensive deployment model).
The number of calls transferred to IPCC agents by the ISN (which still require monitoring by the ISN) includes the simultaneous calls handled by the 907 agents needed for normal calls (because the ISN treated every normal call before sending it to an agent) plus a slight extra amount for the high-priority calls that are transferred to agents after being queued by ISN (because they could not initially reach agents). The extra amount needed for the these high-priority calls is a fairly complex calculation that can be approximated in most cases by simply doubling the number of ISN queue ports required for the high-priority calls, which in this case is:
(7 * 2) = 14 extra calls
The number of transferred calls to agents monitored by ISN in this example is, therefore:
907 + 14 = 921 simultaneous calls
Thus, the total simultaneous number of effective calls for ISN sizing purposes is:
689 (IVR and queuing) + 921 (transferred) = 1610 effective calls
Each ISN Combo Box supports 300 effective calls, so for our example we will need:
1610/300 = 6 ISN Combo Boxes
An additional ISN Combo Box is normally recommended for redundancy, giving us a final total of:
7 ISN Combo Boxes
Figure 4-9 illustrates the preceding ISN sizing example. (For simplicity, the Cisco IOS gatekeeper and Cisco CallManager are not shown.)
Figure 4-9 ISN Server Sizing Example
Sizing ISN Licenses
ISN deployments require the following types of licenses:
•ISN Software Licenses
•ISN Session Licenses
ISN Software Licenses
An ISN Application Server software license and an ISN Voice Browser software license are required for each ISN Combo Box. Therefore, our example deployment in Figure 4-9 would require 7 ISN Application Server software licenses and 7 ISN Voice Browser software licenses.
ISN Session Licenses
In addition to the ISN software licenses, the following session licenses are also required:
•ISN Application Server
An ISN Application Server session license is required for the maximum number of simultaneous calls requiring IVR/queuing treatment by the ISN. In our example, 689 ISN Application Server session licenses are required.
•ISN Voice Browser
An ISN Voice Browser session license is required for the maximum number of simultaneous IVR/queuing calls plus the number of calls transferred to agents that are still being monitored by the ISN. In other words, ISN Voice Browser session licenses are required for the number of effective calls, as defined earlier. In our example, 1610 ISN Voice Browser session licenses are required.
Alternative Simplified Method for ISN Capacity Sizing
This section presents a fast, conservative alternative to the fairly rigorous ISN sizing calculations used in the preceding sections. This simplified method can be used if you already know the number of agents and the number of IVR/queuing sessions required. The simplified method also assumes a worst-case scenario, wherein every call sent to an agent is being monitored by the ISN.
For the example in Figure 4-9, assume that we know 689 sessions are required for IVR/queuing and that there are 1291 agents. In a worst-case scenario, we simply add the number of IVR/queuing sessions to the number of agents to reach a conservative estimate of 1980 effective calls. This number of effective calls requires 7 ISN Combo Boxes plus an extra for redundancy, giving us 8 ISN Combo Boxes. Therefore, 8 ISN Application Server software licenses and 8 ISN Voice Browser software licenses are also required.
With this method, we would estimate that 689 ISN Application Server session licenses are required (for the 689 IVR/queuing sessions), but the number of ISN Voice Browser session licenses would now be (689 + 1291) = 1980. This estimate is higher than the number derived from the more rigorous sizing calculations, but it is not a bad estimate, and it has the advantage of being conservative.
However, if the estimates for the number of agents and IVR ports are very high compared to what are actually need (calculated method), then the licenses and servers would be overestimated and overpriced. One reason the number of agents might be overestimated is that sometimes this count includes all hired agents rather than the actual number of seated agents required for the busy hour. (See Agent Staffing Considerations, for more information on estimating the number of agents needed.)
Cisco IOS Gateway Sizing
You can estimate the number of PSTN ingress ports required on the Cisco IOS gateway by adding all the IVR/queuing ports plus the number of agents. For the example in Figure 4-9, 1980 gateway ingress ports are required.
With the ISN comprehensive deployment model, the Cisco IOS gateway does more than simply terminate PSTN ports. It can also act as a VXML browser to perform prompt/collect and queuing treatment under ISN control. The VXML and PSTN functions can reside on the same Cisco IOS gateway or on separate gateways. Contact your Cisco Systems Engineer (SE) for guidance on sizing Cisco IOS gateways for VXML performance.
ICM Peripheral Gateway (PG) Sizing
Each ISN Application Server requires an instance of the ICM VRU PIM. Therefore, based on our estimate of 7 ISN Combo Boxes, our example deployment would require 7 ICM VRU PIM instances. There is no explicit charge for the PIM licenses; they are included with the ISN Application Server software licenses.
For details on VRU PG and PIM capacities, refer to the chapter on Sizing IPCC Components and Servers, page 5-1
Prompt Media Server Sizing
The prerecorded prompts played out by Cisco IOS gateways (under VXML control of the ISN) can be stored in gateway flash memory, provided there is enough gateway memory to hold the prompt .wav files. In most cases, however, the prompt files are stored on a separate web server called the prompt media server.
Use the following method to estimate how many prompt media servers are required:
Assume that the prerecorded prompt .wav files have to be pushed to the Cisco IOS gateway using G.711 bandwidth (approximately 80 kbps). Thus, each call receiving prompt play from the Cisco IOS gateway requires 80 kbps of media from the prompt media server.
The other piece of required information is the media serving capacity of the web server that will act as the prompt media server. To determine the maximum number of prompts that serve can support, divide the media serving capacity of the media server by 80 kbps per prompt.
For example, assume the prompt media server has a media serving capacity of 32 Mbps. That server can support:
32 Mbps / 80 kbps = 400 simultaneous prompts per media server
For the example in Figure 4-9, we need to play prompts (media) for 689 self-service and IVR/queued calls, which would require 689/400 = 2 prompt media servers (plus a recommended third prompt media server for failover purposes).
This sizing method is not rigorous, but it is nonetheless reasonably accurate and conservative. If you can cache some of the prompts in gateway memory, then you might be able to reduce the required number of prompt media servers.
Agent Staffing Considerations
In calculating agent requirements, make the following adjustments to factor in all the activities and situations that make agents unproductive or unavailable:
Agent shrinkage is a result of any time for which agents are being paid but are not available to handle calls, including activities such as breaks, meetings, training, off-phone work, unplanned absence, non-adherence to schedules, and general unproductive time.
Agent Shrinkage Percentage
This factor will vary and should be calculated for each call center. In most call centers, it ranges from 20% to 35%.
This number is based on Erlang-C results for a specific call load (BHCA) and service level.
To calculate this factor, divide the number of agents required from Erlang-C by the productive agent percentage (or 1 minus the shrinkage percentage). For example, if 100 agents are required from Erlang-C and the shrinkage is 25%, then 100/.75 yields a staffing requirement of 134 agents.
Call Center Design Considerations
Consider the following design factors when sizing call center resources:
•Compute resources required for the various busy intervals (busy hours), such as seasonal busy hours and average daily busy hour. Many businesses compute the average of the 10 busiest hours of the year (excluding seasonal busy hours) as the busy-hour staffing. Retail business call centers will add temporary staff based on seasonal demands such as holiday seasons. Run multiple interval calculations to understand daily staff requirements. Every business has a different call load throughout the day or the week, and agents must be staffed accordingly (using different shifts or staffing levels). Customer Relationship Management (CRM) and historical reporting data help to fine-tune your provisioning computations to maintain or improve service levels.
•When sizing IVR ports and PSTN trunks, it is better to over-provision than to under-provision. The cost of trimming excess capacity (disconnecting PSTN lines) is much cheaper than lost revenue, bad service, or legal risks. Some governmental agencies are required to meet minimum service levels, and outsourced call centers might have to meet specific service level agreements.
•If the call center receives different incoming call loads on multiple trunk groups, additional trunks would be required to carry the same load using one large trunk group. You can use the Erlang-B calculator to size the number of trunks required, following the same methodology as in the Call Treatment Example. Sizing of required trunks must be done for each type of trunk group.
•Consider marketing campaigns that have commercials asking people to call now, which can cause call loads to peak during a short period of time. The Erlang traffic models are not designed for such short peaks (bunched-up calls); however, a good approximation would be to use a shorter busy interval, such as 15 minutes instead of 60 minutes, and to input the expected call load during the busiest 15 minutes to compute required agents and resources. Using our Basic Call Center Example, a load of 2000 calls in 60 minutes (busy interval) requires 90 agents and 103 trunks. We would get exactly the same results if we used an interval of 15 minutes with 500 calls (¼ of the call load). However, if 600 of the calls arrive during a 15-minute interval and the balance of the calls (1400) arrive during the rest of the hour, then 106 agents and 123 trunks would be required instead to answer all 600 calls within the same service level goal. In a sales call center, the potential to capture additional sales and revenue could justify the cost of the additional agents, especially if the marketing campaign commercials are staggered throughout the hour, the day, and the various time zones.
•Consider agent absenteeism, which can cause service levels to go down, thus requiring additional trunks and IP IVR queuing ports because more calls will be waiting in queue longer and fewer calls will be answered immediately.
•Adjust agent staffing based on the agent shrinkage factor (adherence to schedules and staffing factors, as explained in Agent Staffing Considerations).
•Allow for growth, unforeseen events, and load fluctuations. Increase trunk and IVR capacity to accommodate the impact of these events (real life) compared to Erlang model assumptions. (Assumptions might not match reality.) If the required input is not available, make assumptions for the missing input, run three scenarios (low, medium, and high), and choose the best output result based on risk tolerance and impact to the business (sales, support, internal help desk, industry, business environment, and so forth). Some trade industries publish call center metrics and statistics, such as those shown in Table 4-1, available from web sites such as http://www.benchmarkportal.com. You can use such industry statistics in the absence of any specific data about your call center (no existing CDR records, historical reports, and so forth).
Table 4-1 eBusiness Best Practices for All Industries, 20011
Inbound Call Center Statistics
80% calls answered in? (seconds)
Average speed of answer (seconds)
Average talk time (minutes)
Average after-call work time (minutes)
Average calls abandoned
Average time in queue (seconds)
Average number of calls closed on first contact
Average TSR occupancy
Average time before abandoning (seconds)
Average adherence to schedule
Cost per call
Inbound calls per 8-hour shift
Use the output of the IPC Resource Calculator as input for other Cisco configuration and ordering tools that may require as input, among other factors, the number of IVR ports, number of agents, number of trunks, and the associated traffic load (BHCA).