How would the amount of SIP Channels affect a call center if the call center had an average of 20 to 30 calls queued up per hour. Would this customer need to have more SIP channels than the total amount of estimated callers in a queue or would 4 to 6 channels suffice? SIP uses 2 channels per conversion correct? Please let us know how that would work in the SIP world. Thank-you.
1 comment
-
Ray Howe 1) No – SIP uses one channel. Actually, one from the world to the PBX (the trunk), one to the agent on a phone (if the call connects to an agent), but WE only care about the trunk.
2) so, it is one trunk per call in progress, including those in queue.
SO – 20-30 calls queued up per hour. Does that mean 20-30 calls in queue? (I assume not), or 20-30 calls total per hour.
You need to use an erlang-C calculator to model trunk needs, but you will need more input:
a) calls per hour
b) average call length
c) average length of “after call work”.
d) service level desired (i.e. average delay, or percentage answered on X seconds)
Without at least knowing average call length it is impossible to estimate trunking. Take this simple example:
30 calls per hour, average call length 60 minutes = obviously, you must have 30 call paths.
30 calls per hour, average call length 1 minute = theoretically, only one trunk! but real world you need two or three since several may call at once.
Here is a decent free tool http://www.kooltoolz.com/ccm.htm?gclid=CJX67pCFirACFc6R7Qod7TYjNg
Real world example using that tool
30 call per hour
average talk time 240 seconds
Average after call work time 60 seconds
service level desired – average delay 40 seconds
Agents required: 5
Trunks required: 7
Answered without queueing: 87%
Max time in queue: 309 seconds.
And here is a more technical definition of erlang C
The Erlang traffic models were established by A.K. Erlang, a Danish scientist who is credited with much of the early work in telephone traffic design. He discovered the mathematics underlying queuing, a branch of statistics now termed 'queuing theory'.
'Erlang' calculators are used throughout the world to carry out a variety of statistical calculations associated with telecommunications systems and call centers.
There are several variants of Erlang calculator for specific purposes -
|
|Erlang C
|
Erlang calculators for call centers, help desks, checkout queues, where customers can wait in a queue. cc-Modeler Lite and cc-Modeler Professional use Erlang C calculations.
|
|
|Extended Erlang B
|
Used by telephone system designers to estimate the number of lines required for PSTN connections and takes into account the additional traffic load caused by blocked callers immediately trying to call again if their calls are blocked.
|
|
|Erlang B
|
Estimates the number of lines required for PSTN connections (CO trunks) or private wire connections.
|
|
|Engset
|
Used to explore the relationship between the traffic offered to a trunk group, the blocking that will be experienced and the number of lines provided when there are a finite number of sources from which the traffic is generated. It is more accurate than Erlang B, which tends to over-estimate blocking.
|
The Erlang C calculator models the performance of systems which incorporate queuing (rather than a caller simply getting a busy signal and hanging up). Queuing applications include switchboard operators, call center agents and helpdesks. However the same calculations also apply to supermarket checkout queues, toll booths etc.
The Erlang C model makes the following assumptions -
|
|Calls are offered randomly in a queue (Poisson arrivals)
|
|
|Users wait if they find the system busy (no account is made of the effect of abandoned calls)
|
|
|Service times are exponential
|
|
|Users are served in the order of their arrival
|
|
|Users are directed to the first-available agent
|
|
|Queue sizes are unlimited
|
|
|There are not dramatic variations in call volumes within the period being calculated
|
The actual formula for Erlang C calculations is -
where the result is the probability that a caller will not be answered immediately and will have to wait (i.e. be queued).
Other parameters can also be derived from this formula including the number of agents needed, the ASA, the service level (e.g. percent of calls answered within 40 seconds), number of calls queued etc.