vicidial.org

Have been using ViciDial on an inbound/outbound campaign with pretty good results. However, as we've gotten busier, I've noticed an issue.

If all of our reps are on calls, and several callers are waiting in the queue, it would make sense that the next available rep gets the caller who is waiting the longest. If one caller has been waiting 5 minutes and the rest just entered the queue, we should help the person who waited 5 minutes.

However, this does not appear to be the way that Vici is handling the inbound queue -- it almost looks like Vici is randomly selecting from the queued calls. Is this the case? IF not, how can I see callers waiting for 10 minutes when the reps are being directed the calls that just barely entered the queue?

On another issue (but still inbound related) how are incoming calls able to be dispositioned as DC or N?

Hello

I would suggest you buy the Manager's Manual from http://www.eflo.net .

and to answer some of your questions.

The reason why vicidial behave that way is because Next Agent Call is set to

- random: orders by the random update value in the vicidial_live_agents table
- oldest_call_start: orders by the last time an agent was sent a call. Results in agents receiving about the same number of calls overall.
- oldest_call_finish: orders by the last time an agent finished a call. AKA agent waiting longest receives first call.
- overall_user_level: orders by the user_level of the agent as defined in the vicidial_users table a higher user_level will receive more calls.

Thank you for your answer, but our issue is kind of the opposite than what you're addressing. The calls are routed fairly to our reps on the line. The one who has been sitting around the longest does get the call first.

But we're running into an issue with customers who are calling our office. If we have a wait-time before speaking with a rep, then it *should* be first-come, first-served. Instead, Vici appears to be randomly picking which one of the queued calls to be answered first, regardless of wait time.

There's got to be some way to change the way it's prioritizing the inbounds. (And I do have the manager's manual)

That is how it is supposed to work. What version of astguiclient do you have installed?

We're using Vicidial 2.0.3.

I would recommend upgrading to 2.0.4. There have been several bug fixes and improvements since 2.0.3.

Okay, so we upgraded to the new version. This morning was the first chance to see it in action, and once again we're having the same issues with answer order.

We have incoming calls from 15 separate in-groups -- I have tried to see if certain offices are being helped first, but have not seen a pattern like this. It still appears as if the calls waiting in queue are being picked up at random.

Do you have any logs that we can see that shows this happening?

can you give a simple example?

Are all of your agents logged into all of the same queues?

The only thing I have showing it happening is a screenshot from the "Agents Time on Calls" report. Would that be good enough?

If there are multiple callers in the queue, sometimes those waiting one or two minutes are helped before those who have waited for 10 or more. All of the reps are logged into the same queues, and able to receive from all of the in-groups.

see:
http://i260.photobucket.com/albums/ii35 ... xample.jpg


Not as extreme as some cases, however here you can get an idea of what is happening.

Why was the caller from San Antonio helped at 29 seconds while the other callers from Toledo haven't been helped (at 3 minutes, 33 seconds and 1 minute, 1 second)?

I jsut did a review of the code and the prioritization is per queue, so yes it is possible for someone from another queue to wait longer.

I am going to be working on in-group(queue) prioritization in the next few weeks that should enforce global queue time prioritization.

The reason this isn't in the existing version is the complexity of dealing with agents that can choose in-groups and different settings across in-groups, so that determining which calls should wait in line behind which other calls is not very easy to figure out.

That sounds great. I had a hunch it was due to the in-groups, but was looking for some sort of pattern.

Look forward to the patch. :)