Number of "Lost" calls too high - please help 1

[emissman]

After being up and running on CCC v5 for a couple months now, we understand there are reporting (along with many other) issues. The biggest problem we are having right now is that when reporting to management just on daily or weekly call volume, the number of lost calls appears high because it seems like calls that don't ring right through to an agent (if the agent is on the phone, etc) and "queue" to VMPro are counting as lost because they weren't answered by their intended target, which was the agent group. Is this true?

I've only seen very rare cases where someone has actually hung up and the reports list the call type as "LOST" specifically. What can we do about this? In doing further research on many incoming line ID's, I'm able to verify later that an agent did actually handle the call, but only after it had queued for some amount of time. I can provide report examples if needed. Thanks!

 

[IPOJedi]

Your customer needs to understand wahta lost, and a refused call is as the way the ipo does it is unique!!!

Two groups each with two members in...ok so far..


Call comes into first group...ring ring on 1st agent...ring ring on 2nd agent....overflows to 2nd group and is answered..

Stats will show on each agent 1 refused call and one lost call.

On the group one lost call...


Are you still with me?

Same sceario but this time the 2nd group does not answer it as well adn it returns to the 1st group 1st agent and is answered..

This time it will show

The 1st agent will have 1 lost calls 1 answered 1 refused

Got it...phew


with this in mind it may be that the stats are correct but because of the unique wy it works it looks wronG?

 

[emissman]

Thanks for the reply! The customer in this case is basically myself and my boss, the company Operations VP. Currently, what we have is actually one group where if the only member is not available, the call rolls to the other group, so hopefully we'll be eliminating that 1-member group soon and maybe the stats will make more sense.

However, we don't really have an overflow group, especially when you think about the transaction where all agents are busy and the call queues in the VM Pro system. Those particular transactions don't show that the calls are lost when viewing tracking information by ICLID, but they appear to be counting as lost calls because the original target the call was intended for was the hunt group extension and not the VM system. If the VM system (that apparently handles queuing) is the problem, what happens if we turn off VM or is there something else we can do to stop these misrepresented calls?

 

[hohumIPO]

Hey emissman, welcome to my hell for a very long time however after much pain and agony over this for one particular company I figured out a way around the reporting issue. You need to create two groups. One is obviously the one you have now and another one called voicemail. In the group called Voicemail you have a bogus extension that is forwarded unconditionally to voicemail using a shortcode which has to be programmed in the bogus extensions sourcenumbers tab as a forward unconditional and forward huntgroup calls. THis group is to act as an overflow for the main group. Ensure you have given the first group access the these voicemails. Now whwen you run an agent group report you run one against the current group and one against the voicemail group then calcluate the figures as follows:

Main Group
Inc Presented 388
Inc Answered 311

Voicemail Queue
Inc Presented 63

thus => 388 - 311 - 63 = 14 real lost calls.

All this because of highest group call count (the "unique" way the IPO counts calls

 

[emissman]

Thanks for the advice hohumIPO. I want to say that we originally had the setup you describe, but ran into issues when we were testing the night before we went live. I will look into it again. One question, though. What sort of parameters would we want to set on the voicemail group? Is there any hold time or is it basically after a call has held for x amount of time in the main group, it forwards to the overflow? Can it come back from overflow or are you just saying the only option would be to leave a voicemail? Still a bit confused...

 

[KevDBF]

Hi There

I have the same problem but I need to report on Incoming DDIs!

I seem to have hundreds of "extra" lost calls and I thought it was for this reason so it's nice to know I am not mental!

Any ideas on getting these reports to show correctly - I need to use this report as I have 30+ collections (on different DDIs) and this is the only report I can get (as far as I know...) that shows average answer speeds. All the other info is fine apart from the lost calls.

I do however use phantom extensions to forward calls from the VM to the hunt groups - is there a report that shows these calls like the Incoming DDI???

Appreciate any help!