Calls not showing in Symposium

[rwylie81]

I have a problem where some calls are not showing in Symposium call by call statistics. My seervice provider shows me that I have calls lasting over an hour, and I have infrequent reports from callers that they have been stuck in a loop for a long time only hearing music. If they redial, they get serviced much quicker.

I can't find all of these in call by call statistics. Is it possible that this means that the call was never passed to Symposium, and control remained with Meridian. Any thoughs?

Bob

 

[atascoman]

We had a similiar problem awhile back and it was that the calls were going to the DFDN of the CDN which was the ACD queue that the phones were assigned to. While I could never prove it as I don't have acces to our network gear, I believe that the ELAN link was losing connection between where the SCCS server was installed and where the PBX connects to the ELAN. We moved the server and PBX to new ports on each end and did a reboot. Since then it has been OK.

 

[M1Garand]

This definitely sounds like calls going to the DFDN or ACD Queue directly. You didn't say how long your Symposium has been in service, but a long time ago, I had a customer who had their Symposium for several months, and was experiencing the same thing. It turned out that when the Symposium was rolled out, they kept the original ACD Queue for all the sets (almost 200), and started using the new CDN's to route calls. Since many people in the company knew the old ACD number, that's where they all continued to send calls to. When the call center wasn't busy, it really acted weird because some agents kept getting all the calls, while the others sat twiddling their thumbs.

 

[rwylie81]

Hi Guys

Thanks for this so far.

I have actually been able to find records of these calls in the swc report, Application Delay before abandon. I have seen calls with a maximum delay of upto 5 hours!

I thought I had resolved it by building into the script loop, if prioirty in network skillset xxx = 0, remove from network skillset, queue to network skillset.

The idea behind this was if the call had somehow been queued to the network skillset , but then wasn't actually queued, then this would re-queue it. however, to no avail.

Any thoughts on this?