[Asterisk-Users] Enhanced queue app

[John Todd]

I think the key point to the queue application was hit upon earlier: 
statistics.  About one-half of the problem with queues is getting the 
functionality into Asterisk; the rest is reports.

What you measure, you manage.  While I have not worked with getting 
statistics out of the queue functions, it does not seem to be readily 
apparent how one would obtain that data.  Every call center manager 
wants to know a large number of stats on their queues:

for each queue:
  - average delay time per queue ("hold time")
  - max delay time
  - min delay time
  - service level % (# of calls answered within acceptable number of seconds)
  - total calls to the queue
  - # of calls abandonded
  - # of of calls answered
  - # of agents in that queue
  - # of agents available in that queue
  - # of agents in wrap-up mode in that queue
  - # of agents in other "unavailable" mode for that queue


for each call in each queue:
  - delay time
  - talk time (if answered)
  - ANI for that call
  - number of times that call has been answered (tells you # of transfers)


for each agent:
  - number of calls taken since login
  - avg # of calls taken per minute
  - avg length of calls per agent
  - max call length per agent
  - length of current call for that agent
  - CID for current call for that agent
  - status of agent
  - average idle time for agent
  - total amount of idle time for agent during login
  - total amount of talk time for agent during login
  - avg amount of wrap-up time per call
  - total amount of wrap-up time during login

This is an incomplete list, but it's what I can recall off the top of 
my head as things I've had to supply in previous jobs when I was a 
call-center manager.  I am unashamed to say that I really loved 
SwitchView for my Meridian system - it had really amazing output, and 
let me know what was going on with my call center and let me fix 
problems before they were noticed.

These values could be presented via the manager interface, and then 
some third-party applications like Nagios can create alarms based on 
values falling outside of standard norms, or RRDTool can graph/plot 
those numbers on a running basis.

Now, I know that's a big list of things to think about, and is almost 
certainly outside the scope of the small changes that were requested 
to app_queue.  However, to a manager, any "real" call queue system is 
only as valuable as the data you can get out of it.  Any person who 
is not an Asterisk hacker and who is evaluating call queue solutions 
will not consider Asterisk as a solution; these are people who live 
on numbers, and a system that in any way comes up short on 
statistical reports will be seriously handicapped in any evaluation.

JT