vicidial.org

I'm struggling to explain some calls which had long inbound queue times which eventually were answered and some turned into drops.

I made a call export and selected some calls in Excel with long queue times. Now the next step would be to explain how they happened.

Can anyone recomment an easy way to see how many agents were logged in from minute to minute and what their status was during a certain period? I can't find a report that provides this information.

Modify the user, go to user-stats. That shows the "in a call" times by showing their calls. I don't know of a "report" that will allow you to reconstruct the "up to the second" status of an agent specifically. You'd have to sponsor that, lol. But there are logs showing specific moments when activity occurs with which this could be "pretty much" reconstructed.

The reports are all about aggregating activity, totals for the categories. They'll tell you that between this call and the next call a total of XX seconds was spent in each condition. But it won't say "on pause from this second to that second".

What an agent's status was at every moment of a specific time period would probably be a popular report. As would "here's the status of all agents at this moment in history". They just don't exist. It would take several hours to build, and may be a bit "CPU intensive" to run. But should be possible with the existing logs. In Theory.

I have not confirmed, for instance, that the moments of "Pause" and "Resume" are specifically logged each time rather than tallying the times in an already-existing log entry.

What i ended up doing was:

-use the agent performance detail report to filter from and to the specific time range that you want to investigate and then check which agent were logged in during that time
-then click on the agent names to go to the stats page of each agent en scroll to the agent activity and download that section to Excel
-start analyzing each status change around the time of the call(s) you want to investigate

What i found out is that the agent session froze and because of this the call was never answered and the fallback we created with a remote agent didn't work because the agent had unchecked the ingroups on the vdremote page.

What i found out is that the agent session froze and because of this the call was never answered and the fallback we created with a remote agent didn't work because the agent had unchecked the ingroups on the vdremote page.

How did you get "agent session froze" from those logs?

And how did you get "agent had unchecked" from those logs? Is chosen ingroups actually available in the log? I don't remember seeing that.

When i checked the remote agent profile the ingroups were deselected which should never be the case. Of course this doesn't prove that they were deselected at the time the problem happened but it's highly likely.
Also in the agent activity i could see extreme times at some point, if i remember correctly a dead time for over 5000 seconds.

dspaan wrote:When i checked the remote agent profile the ingroups were deselected which should never be the case. Of course this doesn't prove that they were deselected at the time the problem happened but it's highly likely.
Also in the agent activity i could see extreme times at some point, if i remember correctly a dead time for over 5000 seconds.

what is a "remote agent profile"? (and remember that while you can check an ingroup in "remote agents" for a remote agent, the ingroup must still be allowed in the campaign or the "select" will be ignored)

where did you check "agent activity"?

"agent session frozen" is still not shown. How do you know the agent didn't just leave his desk or something similar?

By remote agent profile i mean when you go the remote agents page and open the remote agent, you can see which settings are there. Actually i spoke with the supervisor and she confirmed that the agent had unchecked the ingroups. I know the ingroup has to be selected in the campaign.

I checked agent activity by going to users and looking up the connected agent id and then going to the stats page for that user.

You are right, it could have been just that the agent was in a dead call for hours. We didn't use the auto next settings in the campaign which could have prevented this. However we are using max timer and no agent no queueing in the ingroup to overflow the call to another ingroup where the remote agent is logged on who is on hook with a special fixed-mobile simcard so this was already the fallback for situations like this which also didn't work because she deselected the ingroups....

When all else fails, set up a php page that uses mysql to ... check and email a supervisor that somebody needs to be Fired (or trained). Red Flag Pages. Alternately, of course, you could set a process to REcheck the ingroups, lol.