Minor bug and a question

[rjch]

I've spotted one minor bug in QueueMetrics 1.4.3 - a mis-spelling of length ("lenght") on the Distribution page of a report.  Very minor and probably already spotted, but best to be sure. 

One other quick question - I've noted on this same page (under Queue length per hour and Queue length per day of week) the statistics "Cover" and "Steps".  What are "steps"?  While I can guess at what "cover" is, I'd be interested to know how it's calculated.  The current documentation is for version 1.4.1 of QueueMetrics and thus doesn't address these stats.

[QueueMetrics]

Thanks - we filed the bug as #252.

Cover is coverage as those stats cannot be computed for all calls because Asterisk does not log it in every case.
Step is a tenative metrics to see how "fast" your queue is turning, i.e. how much time it took on average to advance one place in queue.

[rjch]

Cover is coverage as those stats cannot be computed for all calls because Asterisk does not log it in every case.
Step is a tenative metrics to see how "fast" your queue is turning, i.e. how much time it took on average to advance one place in queue.

Thanks for the clarification.  I hadn't considered the "step" metric, but it certainly does sound like a very useful statistic to watch.  Just to clarify, if I'm showing a step of 320, this means that on average it's taken 5 minutes and 20 seconds for a call to progress one step further in the queue, correct?

An idea possibly for future development - it would perhaps be very useful if a tooltip could be added to each statistic so that hovering over the column name in each report would give a more thorough description of what the statistic represents.  It would prevent (or at least reduce) questions such as this on the forums.

[QueueMetrics]

No: if it shows 320, it means that you are processing 320 calls per hour, i.e. the queue is advancing at 320 steps per hour.

[rjch]

No: if it shows 320, it means that you are processing 320 calls per hour, i.e. the queue is advancing at 320 steps per hour.

Then I'm not sure the results I'm getting make a great deal of sense.  Our call centre has 3 staff that answer an average of 110 calls per day, with an average talk time of 2.5 minutes per call.  This would theoretically mean that in one hour, we could answer no more than (60 / 2.5) x 3 = 72 calls, whereas in a typical day we seem to have a step rate of anywhere between 67 and 338 per hour - and those stats are fairly well spread.

Our abandoned call rate is somewhere between 5 and 10%, depending on how busy the day has been, so I wouldn't think that would contribute to this metric.

How is this metric calculated?

[QueueMetrics]

Basically, it tracks the queueu position of a caller in queue and how much time it takes for the caller to be answered.
For example: a caller he enters the queue as 10th and waits 10 minutes. This means that the queue moves on average one step per minute, so it would be 60 steps per hour.
QM averages this for all calls and gives the result per hour.

This is experimental, so improvements are welcome

[rjch]

Basically, it tracks the queueu position of a caller in queue and how much time it takes for the caller to be answered.
QM averages this for all calls and gives the result per hour.
This is experimental, so improvements are welcome

Hmmm... my results would seem to indicate that it's likely adding them all together, not averaging them.  An average step of around 250 would indicate that our queues advance one step per 15 seconds (approximately)

Unfortunately we're not quite that efficient.   

[QueueMetrics]

We'll have it checked :-) Bug #259.
Thanks for pointing out this issue.

[QueueMetrics]

I've spotted one minor bug in QueueMetrics 1.4.3 - a mis-spelling of length ("lenght") on the Distribution page of a report.  Very minor and probably already spotted, but best to be sure. 

Fixed in 1.4.4. Thanks for making QM a better product!
 

[QueueMetrics]

Hmmm... my results would seem to indicate that it's likely adding them all together, not averaging them.  An average step of around 250 would indicate that our queues advance one step per 15 seconds (approximately)

Unfortunately we're not quite that efficient.   

Bug #259 has been fixed in QM 1.4.4.

The whole counting logic has been thrown away and reimplemented.

Also, we now espress steps as average seconds per step, not  average steps per hour (saying that your queue advances on average one step every 27 seconds is the same as saying that it rotates at 133 steps per hour, but we find the first  easier to understand).

Thanks everybody for helping us.