vicidial.org

Were moving agents off Genesys onto ViciDial (ViciBox 11) and I'm keen to replicate the Outbound Skills Based Routing functionality in Vici. I'm aware of the AGENT MULTI-CAMPAIGN DIALING option (thanks Matt), but the client does not want multiple campaigns & lists. I think that I can do it and am busy with the customization now, but I would really value your input if you have attempted this before and succeeded (or failed).

a) For Manual Preview campaigns, I'm planning on putting one or more agent skills into the agent Territory field and the lead skill (only one per lead supported) into the vicidial_list.owner field and then modifying the Owner Only (Territory) Dialling to match if the lead.owner matches any of the words in the user.territory. This should be quite straightforward. (With No Hopper Dialling of course.)

b) For Ratio (and possibly Hopper based Manual Dial Next) campaigns, here's my plan:
- Put skills in the same fields as a) above.
- We will Achieve Skills Based Routing by adding a Next Agent Call option "skills_longest_wait_time". This will call a stored proc to replace the "UPDATE vicidial_live_agents set status='QUEUE'..." part of agi-VDAD_ALL_outbound.agi. Here, I can chose an agent for the call based on my skills matching algorithm.
- We will Achieve Skills Based Dialling (to make sure that agents of all skills get calls) by 2 possible means:
Determine what calls are immediately required by looking at the skills mix of currently ringing calls and the skills mix of waiting agents. Then,
1) Change AST_VDauto_dial.pl to replace "UPDATE vicidial_hopper set status='QUEUE' ..." with a selection of leads in the hopper to match the immediately required skills. (I will add a skills column to vicidial_hopper.)
or 2) [possibly as an initial method] I could look at running a DB event that changes the hopper priority of the leads to make sure that the next leads dialled (by an un-modified AST_VDauto_dial) will be of the skills required for waiting agents.
- I will also look at whether we need to alter the hopper load logic to load the right mix of leads to match the skills required.

We will use this for campaigns where leads have multiple languages, but agents can only speak some, as well as other agent skill sets.

What do you think? Please let me have your ideas and feedback.

Thanks

Roger

That would be quite an accomplishment. It seems logical to me, I believe you may be on to something but I'm sure Matt can confirm. Good shit bro

Chris

When we developed the AGENT MULTI-CAMPAIGN DIALING features, we had to factor in a lot of existing campaign features into it, and using multiple campaigns was really the only way to make everything work well together, and to allow it to still scale to hundreds of concurrent agents. We currently have dozens of clients using it, and it does work very well if configured properly.

As for your specific requirements, we actually have a client that only uses and manages a single set of lists and campaign settings for the outbound side, and there are processes set up on the back-end to divide the leads up and change other campaign settings so they don't have to actually manage a bunch of separate outbound campaigns. From the agent side, all of the agents are in a single campaign already, so that isn't much of an issue.

The main issue of concern with what you have described is that some other features may break due to some of the modifications to the code that are made to make it work differently. But as long as you take all of that into account, it might not be much of an issue at all

Thanks Chris and Matt for the feedback and encouragement. I think that I've done it! Campaigns go live in the next week and the testing has gone well so far.

a) The Manual/Preview no-hopper dialling did not need any customization. I had not seen that there was already the ability to add multiple Territories per agent. Works well.

b) For the Ratio dialling I did the following:
- Added new Campaign Next Agent Call option: owner_wait_time
- Added lead owner & hopper load datetime columns to vicidial_hopper. Changed AST_VDhopper.pl to only load leads with skills matching agents logged in: (only key bits of code shown here)

Code: Select all

if ($next_agent_call[$i] == "owner_wait_time")
$stmtA = "select group_concat(agent_territories) from (select agent_territories from vicidial_live_agents vla where campaign_id='$campaign_id[$i]' group by agent_territories) as t;";
$lead_filter_sql[$i] = $lead_filter_sql[$i] . " and '$SBDRterritories' like concat('% ',owner,' %')";


- Added DB event to sort top half of hopper (by assigning priorities up to 49) to make sure that the leads next autodialled match the current agent skills mix. (This was an attempt at a quick solution, but I then added the changes to hopper load and auto dial which are a neater solution, but I'll leave this in for now.)
- Same DB event unloads leads from the hopper if all agents with a skill agents log out. This is to avoid dialling and dropping a lead with no skills match.
- Added a dial_ratio column to vicidial_territories to allow for a different mix of skills when dialling leads
- Changed AST_VDauto_dial.pl to call DB proc to do the "UPDATE vicidial_hopper set status='QUEUE', user='VDAD_$server_ip' ..." part using algorithms to dial only leads with skills matching READY agents and weighting the mix using skills dial_ratio. Since some agents have more than one skill, we can get clever choosing which leads to mix in. Having this logic in a MySQL routine makes it easy to tune, log and extend this:

Code: Select all

if ($DBIPnext_agent_call[$user_CIPct] =~ /owner_wait_time/i)
$stmtA = "CALL T_owner_auto_dial('$server_ip','$DBIPcampaign[$user_CIPct]','$DBIPmakecalls[$user_CIPct]', \@rtnVal);";


- Changed agi-VDAD_ALL_outbound.agi to call DB proc to do the "UPDATE vicidial_live_agents set status='QUEUE' ..." part. Again, having this algorithm in a proc allows easy tuning and we plan to add smarter call routing by introducing agent Proficiency or Desire to Use settings into the mix at a later stage. (May use the vicidial_user_territories.level TOP_AGENT/STANDARD_AGENT type logic for this.):

Code: Select all

if ($CAMP_callorder =~ /owner_wait_time/i)
$stmtA = "CALL T_owner_wait_time('$CIDlead_id','$unique_id','$VARserver_ip','$callerid','$channel','$VDADcampaign', \@rtnVal);";


So, only about 150 lines of extra code (mostly in the stored procs). Took a lot of hours and some middle-of-the-night thinking to get it right, but the agent experience and the stats look good and show that it's working.

Roger

That's so awesome bro, have you submitted this to the tracker yet?

Thanks Chris, I'm going to wait until we have this bedded down and fine tuned before submitting it. Went live yesterday.

Sounds good