Jim Friedeck
------------------------------------------
John Todd wrote:
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 _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
