Handling of List that is being continuously added to

[ajax1515]

So I'm sure there is a way to do this within Vicidial, but I can't seem to get the settings right.

Basically the situation is I have a campaign, with a list, and there is an API that my publishers dump leads into. That API scrubs the leads nicely and loads them into the Vicidial List as NEW leads. No problem there.

So here's how I need the agents to be calling. First the agents should always be calling the Newest (Most Recent) Lead loaded into the list, (aka first dials, never been called). If there are no new leads left to call then it needs to go to most recent second dials which could be from a variety of different statuses such as answering machine, no answer, callback, etc.

I know I can use "list order" and "list order second" to get close to what I am looking for here, however the problem is the publishers are constantly dumping leads in through the API as they come, so the list is being added to while it is being called on and as far as I can tell the list order just keeps moving through the list as is and can't really handle a list that is dynamic, changing as its being dialed on.

I may need to write some customized code to deal with this but I'm hoping there is a VICIDial feature or trick I'm just missing here.

UPDATE: So I'm thinking I can use this method:

List Order: DOWN COUNT
List Order Second: LEAD ASCEND

And then everytime a new batch of leads is added by a publisher have a short bit of code call for the script to be resorted... I'm just worried that this will have a negative impact on the dialing efficiency especially if the publishers are uploading frequently (FYI my list gets pretty large, we're talking up to 100,000 leads sometimes)

Any insights you lovely and intelligent peoples?

[smontoya]

Wouldn't it have to be backwards? for what I dounderstand it whould be:
List Order: UP COUNT
List Order Descont: LEAD DESCID

This will pickup non called or least called count leads (starting from 0) and additionally sorting those by the newest added ones, or if you want to have the newest added ones called last giving priority to the least called leads but go through the oldest ones then would have to be LEAD ACENDID

I think the efficiency impact would really go (if any) to the hopper, not the dialer itself, the sorting and number picking gets fetched by the hopper and then the dialer will read the picked up numbers from the hopper.

[nandotech]

Another thing:
have you considered using the add_to_hopper=Y function to posting string?

Aside from this, I seemed to have a similar bug if I passed in any leads with both a LIST ID and a CAMPAIGN ID. Only the list id is required--keep it simple.

If anything, sound s to me like using add_to_hopper in your string would accomplish the behavior you want.

[williamconley]

Also try List Order: UP 2nd NEW.

Note that this will not work if you also add to hopper during load (since NO leads will ever be new unless they're in the hopper in that situation.

If you reduce your hopper size and use add to hopper, new adds will get called almost immediately.

[nandotech]

Another way to handle this, since I actually just ran into it with a new client....

Use the built-in "Lead Fitler" on the campaign and use that to limit the entry_date of the leads being called.

This customer has the same issue--about 5 publishers constantly dumping API leads into "live posts" along with regular leads being loaded daily.
So, what I did was add in some custom filters for the lists that are being constantly dumped to.

Here below is how I used the filters (with the specific list_id's pertaining to this system) to somewhat solve the same issue.
Technically, the last part is not required--I used that because I wanted to set the call_count_limit to 4 for those "manually loaded" lists

Code: Select all

 ( (list_id=3200) and (entry_date > DATE_ADD(CURDATE(), INTERVAL -4 DAY) ) and (called_count < 7) )  or
 ( (list_id=9400) and (entry_date > DATE_ADD(CURDATE(), INTERVAL -4 DAY) ) and (called_count <= 4) ) or
 ( (list_id in (5200,2400,7900,10500,10800)) and (entry_date > DATE_ADD(CURDATE(), INTERVAL -7 DAY) and (called_count <= 8) ) ) or
 ( (list_id not in (3200,9400,5200,2400,7900,10500,10800) and (entry_date > DATE_ADD(CURDATE(), INTERVAL -4 DAY) ) and (called_count <= 4) ) )


In this way--publisher 3200 we will never call leads older than 4 days or called more than 6 times.
Publisher 9400, 4 days, 4 attempts.
All other publishers: Up to 7 day old leads, 8 attempts

In this way, I am assuring they are never calling "too old" leads from those particular lists and in some cases I'm even limiting the call count lower than the standard campaign count. This in tandem with other advice in the thread should work nicely for you.

[williamconley]

be careful nandotech, if your list size gets too large with that customer the hopper query could begin to seriously slow the server.

[nandotech]

be careful nandotech, if your list size gets too large with that customer the hopper query could begin to seriously slow the server.

I figured as much. Especially such convoluted rules.

And these bastards add TONS of data to one particular list.

As an aside, I was considering setting up a cronjob or script to archive >30day old leads into another list not even included with the campaign to help alleviate this issue if it came up.

As of now hopper load script is still fine--thanks for the heads up, though

[williamconley]

We have several clients with "archived lists" as an option. Separate page that allows moving leads to "vicidial_list_archive" and back based on whether they are checked or not (along with a button for each campaign to be archived, to avoid having to check 30 boxes!).

We even have a client who has so many leads we had to create an overnight version (Safe Lead Archiver) to allow selecting archive/unarchive during the day and have the leads move overnight at 3AM, thus avoiding shutting down the dialer. It also provides a count of how many will be archived/unarchived.

[nandotech]

That makes sense.

It is only a matter of time for these higher volume clients to require it.

I've created a vicidial_list_archive table before...but since at the time I only had 1 dialer I just archived them manually