Call in queue for 2 hours

[bryanata]

On friday I had a call sit in queue for nearly 2 hours before the caller abandoned. Oddly enough other calls were being presented to the skillset and being answered during this time. I am running SCCS 5.0. Does anybody have any idea as to why my caller was stuck in queue for almost 2 hours?

Thanks

 

[carolien]

If you use call priorities this can happen. If the priority assigned to this call was 2 and for other calls it was 1, all calls with priority 1 will be presented first.

 

[bryanata]

All priorities are set to default "6".

 

[lretrievers]

Did you see this only on the real time display, or has it come up on the reports also? If it only a RTD, it most likely was not a real call, it is just something that didnt' get torn down completely in the PBX. If that is the case, you may want to check to see if all patches in the PBX are up to date.

 

[charliesp]

Trapped calls is an issue, which although rare does occur from time to time and can be "phantoms".

Assuming the call showed up on your skillset stats, you could check your application stats for the call and check that they agree - otherwise it is more like to be corruption, also compare interval to daily etc.

We have a holding loop in our scripts which checks the age of a call. Anything older that an hour (our hold times don't get that bad) gets sent to a courtesy message and disconnected.

 

[rfwhite]

charliesp,
I'm a little confused about the logic of your setup. I realize it's probably a political decision rather than technical one, but:
If a call has been holding for an excessive amount of time wouldn't it be more desirable to requeue it with a higher priority rather than dump it?

 

[MrToad6378]

You can clear the call by using the pscan utility. Below are instructions on using the tool.

From the Symposium Server go to a command prompt and type pscan at the C prompt. You are then asked for a password, enter anything you want. The Phantom Scan Utility window appears, select all calls then click on analyze. Browse for the longest wait field to find the call. When you find it, highligh the call id then click on clear.

 

[charliesp]

Within the holding loop we have checks to ensure that the call is queued and re-queued it if it slips through the net, therefore it is impossible for a genuine call to not be queued for an hour.

An hour was chosed because it was well clear of our longest ever wait times.

There's no point in increasing the priority on a phantom call as it will never be presented to the agent, therefore it needs a disconnect command.

It was not a political decision to have this in the script, it's a very practical solution which effectively automates the termination of these calls without the need for support issues being raised.

 

[rfwhite]

Right. The original post appeared to reference a 'real' call though, so that's where I was headed. Your phantom treatment is appropriate.

 

[Jeff325]

FYI - TampaTodd

PSCAN is no longer supported by Nortel - use at your own risk

When I say "Good Luck" you know what I mean!

 

[rwylie81]

Hi guys

I am having similar problems. I haven't actually seen them in the real time data, but if I look at a Symposium web client report, Application delay before abandon, I see very high maximum delay times. Up to 5 hours. I have been able to cross reference these calls from raw call data from my service provider, so I know that they are not phantom calls.

I have tried using both IF NOT QUEUED and IF PRIORTIY IN NETWORK SKILLSET = 0, to re-queue the call, but to no avail.

Anyone had similar problems, and found a resolution?

 

[lretrievers]

Do you mean that they ARE phantom calls? I hope someone wasn't really waiting for 5 hours in your queue, I would think they would hang up by then. There are several things that can cause phantom calls; you may want to check with your service provider to be sure you have all the patches in the PBX (there are some written specifically for this problem) and also that all the Symposium Servers are up to date with PEPs. Do you have HLOC codes on all your PBXs that are networked? Are you using CDP or UDP for the network CDNs? UDP is preferred.

 

[rwylie81]

Hi lretrievers,

They are not phantoms, as I had reports of people calling back in to complain they were stuck on hold. I think my 5 hours caller, had possible misplaced their handset when they handup, as I agree they wouldn't have stayed on for that long. We are fully PEPed up so to speak, all HLOC codes are fine, but I am not sure whether we are using CDP or UDP.

 

[Jeff325]

Are you using call priorities? If so, what is the Skillset set up for? First in Queue or Oldest in Queue? If you are using First in Queue and a call gets either transfered back to the queue or gets Returned to Queue the call timer starts of for the call but not the RTD which means the call will have to wait it's turn all over and the RTD sees it as a very long call. Nortel believes this will be addressed in the next SU.

Jeff

 

[rwylie81]

Hi Jeff325, all skillsets are Oldest in Queue.

 

[esteede]

Consider using a callback solution for any customer waitin too long in the queue...Callback Q4U and queuebuster are solutions that can assist.

Dont wait for Nortel to fix.......

 

[lretrievers]

Has your network script been modified so that it can handle calls that may be stuck there? If a call is a network call, and a call gets presented to an agent across the network, and the agent hits Not Ready to kick the call back, it goes to the Network Script. Unless you have scripting in place to handle this situation, the call can get "hung there".

 

[rwylie81]

Yes. the Network script has this covered also

 

[CassieM]

Could someone provide some detail on the reply below? I am not familiar with Callback Q4U or queuebuster.

"Consider using a callback solution for any customer waitin too long in the queue...Callback Q4U and queuebuster are solutions that can assist."

Thanks! CassieM