I have noticed that most of the Call Center Statistic questions are from quite some time ago. (usually 2 to 3 years
Has anything changed on the landscape of queue stats? How do the big three stack up?
Asternic
iSymphony
Queuemetrics
Success? Failure?
Is there anything new?
Any current info would be appreciated.
Submitted by eeman on Mon, 07/25/2011
Permalink
isymphony is not historic reporting, it reports on realtime and since last reload of the queue module.
the historic software does not work well with MTE. Most of them will put you in violation of CPNI by allowing other tenants to view call records of another company. The queue_log itself is a single log from which all queues log their information. The file itself has no partitions. Queuemetrics uses a perl script that takes entries into queue_log and injects them into MySQL. This would be useful for MTE if the script could be more robust and inject different queues into different databases or at least different tables/partitions. This would still require a separate server for each tenant wanting to run queuemetrics as the gui itself is not as robust to take this into account. This could be performed as a virtual machine however I do not know how many VMs you can scale to in order to give an idea of tenants. However, when calculating the actual hassle factor of writing and modifying all the custom scripts to make the agent login/logoff sections of queuemetrics work with MTE, and the complexities of separating partitions with the perl script... It might simply be easier to just have a separate server for each customer needing queue reporting and install queuemetrics directly on their separate TL server.
for queuemetrics to be truely Multi-tenant they would need to implement:
1) a grouping by company so that a company can only see information pertaining to their company without having to require the very manual and very complex permission grouping they currently have. An accidental omission of grouping should not leave you in legal jeopardy. Company name would have to match the tenant name in MTE obviously.
2) a means where the qloaderd utility could read from an array to determine which partition to place call records for specific queues. Currently its an 'all-queue on this server goes into partition X' scenario.
3) the configuration where all the actions refer to dialplan scripting to add/pause/remove agents would have to account for the fact that each company/tenant would require different commands unique to their context.
4) the realtime screens have the same issue with #1
if you chose to only use queuemetrics as historic reporting and ignore its quasi-realtime and macro features then only 1 and 2 apply.