High ERI/INCALL Count

[edooze]

Guys, I am getting a high percentage of calls stuck in either ERI on INCALL status.

I have done some research, but can't find reliably what could be causing this. Can you shed light on some things I could check?

We connect to the system over VPNs, and the connection doesn't disconnect between statuses or connections - the only assistance I could find is that it's supposed to happen when the agent closes their browser before dispositioning the call, but none of our agents are doing this either.

Could it be a problem with the dialer's connection to the database? Is there a way I can check this aspect?

Thanks for any help.

[williamconley]

Look for a pattern. Same workstation? Same time of day ... anything.

What is your average server load?

It's also VERY likely that the culprit is "Virtual!" since that is almost always the problem if you have more than one agent. LOL

[edooze]

Some more information on this issue!

- I worked from a different location yesterday, and got a 20% ratio of INCALL statuses (no ERIs this time). I was the only agent using the system at the time.
- I was using a different softphone, and different extension during yesterday's test session.
- The Agent Performance Report has all calls with the correct dispo against them, it's only when I search for leads (show all leads in a list) that I can see a lot of them haven't had the dispo applied as they should.
- Call notes seem to be being recorded correctly, regardless of the dispo issue. I am using these to manually change the dispo after the fact.
- I have monitored internet quality over the last month, it doesn't seem to be related (it's poor at times, but not in a 1 to 1 relationship with error times).
- We are looking at changing VPS providers to get a better service in the hopes that this will solve it.
- I connect to the server via VPN connection to a gateway server at the same location (shouldn't make a difference, I don't think).

My thoughts are that it might be an I/O issue on the server, possibly the MySQL write to the database doesn't happen immediately, and isn't being re-tried? I just pulled this idea out of thin air, so it may not even be possible - in which case, forgive my ignorance.

Any thoughts appreciated. Virtualisation is a necessary evil for us, but with the range of technologies and options available, I'm confident we can find a way that will work scalably for our operation.

Next step is to set up a local (virtualised) cluster server, and see if I still get the problem running from that.

Thanks for any opinions or suggestions for how to track it down.

EDIT: Server load: 0.06, 0.05, 0.05 (htop) - System Load: 87 - 53% (Server Record)

Here is the performance report for the last month:
http://i.imgur.com/OE16vw1.png

EDIT 2: I have just gone in to do some more work on yesterday's leads, and now 6 Calls are in ERI status. All report correctly in the reports (including the agent stats). This is strange. I wonder if this could be because after I manually edited them, they didn't stick? I may not have clicked 'close window' after submitting the changes to the lead - could this be it?

[williamconley]

Virtualization is not necessary. Anywhere there are virtual servers, there are also physical servers. They just cost more, and in this case THAT is the necessary evil.

That being said: Are you somehow certain that the INCALL leads are not ... in a call? (Autodialer? AMD in progress? Listening to a survey?)

There's also the chance that these calls area awaiting a process to complete their recordkeeping after termination. You may want to track them to see if the get "fixed" within a couple minutes.

In that case, the system may be working properly now and you're just overthinking it.