vicidial.org

Vicibox 7.03
VERSION: 2.14-585a
BUILD: 170114-1356
Asterisk 1.8.23.0

I have inbound_group_rank routing setup. I have a team of users at RANK 9 and the rest at RANK 1. Calls are being delivered to the higher rank first.

My question is... For the pool of available agents at RANK 9, what is the method used to determine who to hand off the call to? It appears to be doing oldest_call_start but also seems random at times.

Also, Is there a way to change the strategy of delivery to the agents within the same rank?

Thanks

The secondary ordering parameter would be the longest wait time.

Thanks Matt,

If the user "Pause toggles" does it reset their time? Or is it going off last_call_finished?

It will reset their time if they pause/resume. It is based upon waiting time, not last call received.

I keep getting reports that the secondary ordering parameter is sending calls randomly. I was just monitoring the real-time screen and I witnessed it. Is there something I can check or look into to help identify why its not delivering rank then longest wait time?

retloc wrote:I keep getting reports that the secondary ordering parameter is sending calls randomly. I was just monitoring the real-time screen and I witnessed it. Is there something I can check or look into to help identify why its not delivering rank then longest wait time?

"It" is a little vague. Can you describe the timings involved? Screenshots with names blotted or cropped?

Real time screen redraws anywhere from 5 to 40 seconds, and can be misleading. So try to be precise in your timings.

Remember that a call landing, then immediately terminating, is still a call and will mean that this agent is now at the bottom of the pile. But evidence of this occurrence would be the call count going up and the wait time zeroing.

apologies, "It" was vague.

I have my refresh real-time screen set at 4 seconds. I had 3 agents waiting set at in-group RANK 9 while the others are at RANK 1. Of the RANK 9 users, two were over 10 minutes of ready time while the third was only at 3 minutes. The agent at 3 minutes got the next call while the other 2 users stayed at over 10 minutes


Something else I didn't mention... I have about 20 in-groups allowed on two different campaigns('400' and '500'). The RANK 9 users are working in campaign '400' while the rank 1 users are working in campaign '500'

I have ranks setup by user for in-group and campaigns.

I just switched my routing to go off of campaign_rank instead. I will let know you know if I have any issues or can provide better evidence

Did you verify that the inbound call was able to hit the other two agents? (Not from memory, of course, but by checking their ingroups in the real time screen LIVE).

You'd be surprised at how often people get to say "oops" at this point. lol

Campaign and agent must both be allowed and the agent must have actually chosen the ingroup that the call arrived on, which of course is visible in the + next to the agent in the real time screen.

The server that managed the call would have logs, if they are active and recording, regarding the decisionmaking process.

Another "override" method is to put the higher-ranked agents in their own Ingroup with a drop call seconds of 2 into a secondary ingroup. Then you can return to longest-wait-time or any other method within each ingroup. Cascade.

Here are some screenshots. I have my RANK 9 agents in campaign 400 and my RANK 1 agents in campaign 500,

I have double checked they have selected the correct ingroups during login and verified on their stats.

Check out the pictures in the link here that Erika should get the next call. But Hannah gets it.
http://imgur.com/a/y8xRw


Which log file should I look at on the server?

I was hoping not needing to do the multiple in-groups per line routing.

Another thing I left out that I feel dumb for not bringing up. I have been updating their stats via mysql queries since I have so many ingroups and agents.

I have been updating only two tables. Could I be missing something?

UPDATE
vicidial_inbound_groups
SET
next_agent_call = 'inbound_group_rank'

UPDATE
vicidial_inbound_group_agents
INNER JOIN
vicidial_users
ON
(vicidial_inbound_group_agents.user = vicidial_users.user )
SET
vicidial_inbound_group_agents.group_rank = '9'
vicidial_inbound_group_agents.group_weight = '9',
WHERE
vicidial_users.user_group = 'TRIAGE'

I would definitely stop updating via mysql in case any of the scripts involved store data longer than you expect or refresh the data because it changed in the GUI and was told to refresh it's data (which doesn't happen when you skip the gui). I don't think that's the case here, but worth consideration.

"double checked they have selected "

I'm not worried so much about "they" as about "Megan". Something about her pissed off the system and it decided to ignore her? Or is she not selected for this particular ingroup right now?

agi debug will show you the decisionmaking process for the call as it passes through the dialer in question and lands on an agent. Test an inbound call with agi debugging on to see whassup.

Thanks for the help. I will take a look into it.

The more I am thinking about it I might start working towards having multiple in-groups so I can cascade routing by Last_call_finished.