Manual dial with multilead

[mav2287]

We have been using the multi-lead function in combination with the list local call times code I wrote around Christmas with Matt. In our setup we are using auto-dial with multi-lead, but we are also allowing agents to manual dial leads in the campaign. The manual dials are normally used when a lead wants a call back at a specific time of day or for odd ones like a work number that needs to be called outside the hours for our work list. Doing this we are running into two issues we would like to solve as soon as possible. The first I have a really good idea of how to solve the second I need advice on where to start before I start making code changes.

The first issue we are having is that agents need to be able to call leads outside of their list local call time, but still with the campaign local call time. Right now when you turn on Manual call times it is either on or off and this means it applies both list and camp local call time rules. This is a side effect of the new time code for individual lists. My thought on a fix for this is really simple, change the way the manual dial time works so that in addition to enable/disable you would have "Camp_Only". Campaign Only would only apply the campaign local call time rules and not the List local call time rules. This way you could call any lead anytime as long as it is within the campaign call time.

The second issue we are having has to do with manual dial aftercall code not doing what autodial aftercall code does in a multi-lead campaign. When in a multi-lead campaign after a call if it is a status that doesn't allow any more calls to the lead the code will change the status on all the other leads with same vendor_lead_code to a non-dialable one. HOWEVER if you are in that same multi-lead campaign, you lookup a lead, manual dial that lead, and dispo it with a status that would prevent calls to all the other leads with the same vendor_lead_code it will not update the status on all the other leads with the same vendor_lead_code like an autodial call would have. The issue with this is that if an agent manual dials a lead in the campaign to follow up with them in the morning after they dispo that manual dial call it won't do anything with the other leads with the same vendor lead code. This means that the campaign will dial the other leads with same vendor_lead_code later on because the manual dial didn't change the status on those other leads with the same vendor_lead_code. My thought on this is that I would just need to get the code that updates the other leads in multi-lead for autodialing and then make sure it also applies and is ran when a manual dial is dispo-ed if multi-lead is on. I would like to figure out the best way to do this before I start making changes. I also don't know where that code is so any help in where to find it and why it behaves this way would also be a appreciated. I am also looking for general insight and thoughts on this. When I do code work I am always open to other items that need work along the way. If there is anything else that makes sense to do while going down this road please also let me know so I can knock it out as well.

[mflorell]

For the ticket that you created for the second issue, I already suggested using the agc/deactivate_lead.php script as your Dispo Call URL. Have you tried this yet?

http://www.vicidial.org/VICIDIALmantis/view.php?id=830

[mav2287]

The first ones seems pretty straight forward. I spent alot of time in those parts of the code and I am pretty comfortable making the change there. I would even be ok with doing any clean up or extra that needs done in that area.

The second is a bit more complex. I did see your suggestion and I spent some time trying to figure out how to use it. The issue I ran into with that is that the dispo URL is already in use and it is talking to the CRM so it isn't something I can sacrifice. That is why I am thinking it makes more sense to take the code that is being ran for the multi-lead and have it run with a manual dial or duplicate it and add it in there so if you have multi-lead set it will execute it.

[mav2287]

Did some more digging into this to see what I could do to fix this issue or how it could be handled. The one interesting thing I realized though is the AST_VDauto_dial.pl sets the MLINAT not the dispo of a call. My thought is that this means that there are two potential ways in which a multilead could get called twice, Inbound Sale and/or Manual Sale. Both of these would trigger MLINAT and would cause the leads to get 2 calls.

Is there any reason this was only added to AST_VDauto_dial.pl and couldn't be moved to the Dispo of a call? It seems like there should be code for this in any script that auto-sets a status for a call and doesn't have a human on the call.

[mflorell]

The MLINAT process can't be moved to dispo because if that happened there would be nothing to properly terminate leads related to a survey call that was able to contact the customer, since the survey process does not necessarily involve an agent, and it is actually one of the first uses of the MLINAT processes, which is why it was written that way to begin with.

As for adding this for inbound calls, there could be a lot of problems with that, especially with all of the leads that would be new and have blank vendor_lead_codes.

As for Manual dialing campaigns, you could try removing that restriction from this line in AST_VDauto_dial.pl and see how it works:

$stmtA = "SELECT count(*) FROM vicidial_campaigns where auto_alt_dial='MULTI_LEAD' and dial_method NOT IN('MANUAL','INBOUND_MAN') and campaign_calldate > \"$MCDSQLdate\";";

would become:

$stmtA = "SELECT count(*) FROM vicidial_campaigns where auto_alt_dial='MULTI_LEAD' and dial_method NOT IN('') and campaign_calldate > \"$MCDSQLdate\";";

[mav2287]

The location makes sense now. One interesting thing I noticed though is that I don't see anywhere that would prevent a call from being updated that was made manually in a campaign that is set to ratio. The statements looks at the campaign dial setting not how the individual call was actually made. So a manual dial in a campaign that is set to "Ratio" should still trigger this shouldn't it?

I also saw you check vicidial_auto_calls, but I don't know that I fully understand the reason you are checking it.

My thought on inbounds was pretty basic but effective. It was to add a check to make sure the vendor_lead_codes isn't blank. This could add extra error protection as well. In the event you turn on multi-lead and your vendor_lead_codes don't get put in.

[mav2287]

I spent some more time looking at this on a line by line basis and found something interesting. It would appear the reason this doesn't apply to inbounds and manual dials is that their multi_alt_processed field is set to 'U' and this code only looks at 'N' in this query.

Code: Select all

$stmtA = "SELECT uniqueid,lead_id,call_date,caller_code FROM vicidial_log_extended where server_ip='$server_ip' and call_date > \"$MCDSQLdate\" and multi_alt_processed='N' order by call_date,lead_id limit 100000;";

My thought here is that if I change it to this

Code: Select all

$stmtA = "SELECT uniqueid,lead_id,call_date,caller_code FROM vicidial_log_extended where server_ip='$server_ip' and call_date > \"$MCDSQLdate\" and multi_alt_processed IN('N','U') order by call_date,lead_id limit 100000;";


It would now look at all calls in the log entry for that specific campaign and then apply the multi_lead rules to them. I was thinking that this should take care of the problem of not having this apply to inbounds or manual calls. Any thoughts on this?

[mflorell]

Give it a try and test it out. If it works I think I would rather add a new option to specifically enable it instead of just changing the current behavior.

[mav2287]

I agree with it being an option and I can write the code for that as well and submit it to the tracker after I am happy with results in testing. As I was looking at this code the other thing that occurred to me is that it may make sense to change the update queries for the hopper and lead so they only update if the vendor_lead_code is populated. This would solve your concern about times where there isn't a link between vendor lead codes. The way the code is written that seems like the least intrusive place to put that.

In terms of testing I would just change the query I already mentioned and then the two updates and then beat on it a bit and see what it does.

[mav2287]

Started testing today and things are going really well. I have solved the issue of having manual dialed leads within the campaign update and I am currently working on inbounds. The issue I am running into though is that inbounds don't seem to added to the vicidial log. This means that with the work I am doing with inbounds it will fail because it is trying to get data from the vicidial log that is not there. I am going to look at this some more and look at solutions, however shouldn't inbounds be in the vicidial_log?

[mav2287]

I now have a working protoype running and will be putting some leads through it tomorrow. It was not quite as easy as I thought it would be, but it turned out to be fairly close. The only issue I ran into was that inbounds don't seem to show up in the vicidial_log which was used to get campaign_id and status. To work around this what I did was to use the vicidial_list table to get the lead status and list_id. The code already gets all the lists for each campaign well before I do this so I stored that in a hash. I then use that hash to turn the list_id into the campaign_id. I could have done this with another DB query, but I hate adding unneeded queries and the code for that method would have been longer. I was also going to add code so that it didn't run if a vendor_lead_code wasn't set, but it would seem that the code already had this in place.

At this point the code could be taken further and multi-lead could be an option for manual and inbound-manual dialing. I don't know if there is a need or desire for that, but at this point it seems that is a real possibility.

The other major part I want input on is the switch to turn this on and off. My thought was an option in the multi-lead page that said something like "Apply to all types calls within campaign". It would then set an enum(Y,N) column in the vicidial_campaigns table to Y. There is already a call to the vicidial_campaigns table so it wouldn't add an additional query this way. I also am not opposed to anything else that makes sense to add while I am in here if there is anything that makes sense to add in.

[mflorell]

I was thinking about this, it might be possible to just add another option to "auto_alt_dial", something like MULTI_LEAD_ALLCALLS. That way it is differentiated within the existing option, and it would not require much in the way of altering existing code.

Thanks for your work on this, I look forward to hearing how your testing goes this week.

[mav2287]

The big questions for me is how far we want to take this. At this point it will only work with auto dialing campaigns not manual or inbound (we could change/expand this part). It is further locked down in that it will only deactivate leads that are in lists that are part of the Multi_lead campaign (I think changing this to work right would be a lot of work for little ground. I also think the only time it would make sense is if you wanted inbounds to cause a Multiact system wide to leads with the same VLC. Currently my prototype code will do nothing if an inbound is looked up and it is not part of the multi-lead campaign.) I think that it might make sense to just modify the code and not have an option visible to users. As it stands it only applies to manual and inbound calls WITHIN a multi-lead campaign. This means you have to have manual dialing and inbound turned on for it to take effect. However in theory if we dropped the Inbound/Manual restriction it could apply to those type of campaigns too... We would need to do testing though and see what happens.

Back to your original idea I think this depends entirely on if we want to open Multi-lead up to other forms of dialing. My only concern is with another multi-lead option is that it may cause confusion. As it stands you can pick the multi-lead option no matter what the dial method is, however if you do It won't change to Multi-lead it just stays with what auto-alt is set to. Right now you don't get any popup or anything that tells you what happened it just doesn't change the auto_alt value to multi-lead.

[mav2287]

Did a pretty good amount of testing in production yesterday and today and it is working out great. The only big thing left would be to decide on if it makes sense to open this up to other types of dialing other than auto dial.

[williamconley]

... it would not require much in the way of altering existing code.

My position is that any feature worth implementing that CAN be easily "filled out" all the way, should be while it's still "hot". Waiting until you need it for a specific purpose generally causes the intangible costs to increase dramatically. Look at it as an investment and it should be worth the development time while you're already in there with the details at the top of the developer's brain. IMHO

[mav2287]

I am fine coding it all in. My concerns were aimed more at the need, desire and potential usage. It already does what we needed it to. At this point it would be a matter of getting it to a point where it makes sense for others to take advantage of. I do agree with do it while it's fresh but, I don't want to write code that no one will use just because I can.